Troika: पाठ की रूपरेखा

मुझे लगभग ऐसा लगता है कि मुझे जो चाहिए वह डिबगएसडीएफ ध्वज द्वारा पूरा किया जाता है, अगर केवल मैं इसे रंग सकता हूं।

एसडीएफ दिखाना मूल रूप से मुझे एक रूपरेखा देता है जो शायद काम करेगा यदि मैं इसे रंगीन कर सकता हूं, आकार समायोजित कर सकता हूं, और संभावित रूप से इसे थोड़ा और कुरकुरा बना सकता हूं।

यह करना बहुत कठिन नहीं होना चाहिए। मैंने कुछ समय पहले टेक्स्टऑउटलाइन के साथ एक फीचर के रूप में खेलना शुरू किया लेकिन इसे कभी समाप्त नहीं किया।

सिद्धांत रूप में, ग्लिफ़ किनारों को केवल किनारे से मेल खाने वाले हस्ताक्षरित दूरी क्षेत्र में मान को बदलकर विस्तारित किया जा सकता है। वर्तमान शेडर कोड में यह 0.5 है, लेकिन इसे वर्दी के रूप में पास करके इसे कॉन्फ़िगर करने योग्य बनाया जा सकता है।

आदर्श रूप से शेडर एक ही ड्रॉ कॉल में सामान्य ग्लिफ़ और उसके चारों ओर किसी भी रूपरेखा को चित्रित करने में संभाल सकता है, इसलिए आपको कुछ नई वर्दी की आवश्यकता होगी: रूपरेखा चौड़ाई (सुनिश्चित नहीं है कि यह कौन सी इकाइयां होगी?), और का रंग रूपरेखा क्षेत्र।

मैंने कुछ समय पहले टेक्स्टऑउटलाइन के साथ एक फीचर के रूप में खेलना शुरू किया लेकिन इसे कभी समाप्त नहीं किया।

अगर इसे मूल रूप से समर्थित किया गया तो मुझे बहुत खुशी होगी :)
हालांकि, मैं शेडर्स के लिए बहुत नया हूं, इसलिए मुझे यकीन नहीं है कि मैं कितनी मदद कर सकता हूं। मैं इस मामले को करीब से देखूंगा।

मैं इसमें थोड़ा वापस आया और जल्दी से महसूस किया कि मैंने इसे मूल रूप से समाप्त क्यों नहीं किया। जबकि SDF _can_ का उपयोग रूपरेखा के लिए किया जा सकता है, कुछ चेतावनी हैं:

• रूपरेखा की अधिकतम संभावित चौड़ाई दूरी क्षेत्र की सीमा तक सीमित होती है (~ 64x64 SDF बनावट में 8 टेक्सल्स)।
• यह सभी ग्लिफ़ में एक सुसंगत दृश्य आकार के अनुरूप नहीं है, क्योंकि SDF बनावट को प्रत्येक ग्लिफ़ की सीमा तक बढ़ाया जाता है।

इसलिए "W" जैसे बड़े ग्लिफ़ को शालीनता से मोटी रूपरेखा मिल सकती है, लेकिन छोटे ग्लिफ़ जैसे पीरियड्स केवल बहुत पतली रूपरेखा प्राप्त कर सकते हैं। और प्रत्येक ग्लिफ़ को अपनी रूपरेखा को नेत्रहीन रूप से सुसंगत बनाने के लिए एक अलग SDF कटऑफ़ बिंदु का उपयोग करने की आवश्यकता होती है।

मुझे नहीं लगता कि यह अभी तक दुर्गम है, लेकिन यह उतना आसान नहीं है जितना मैंने शुरू में सोचा था।

@lojjic , ​​इस पुस्तकालय से प्यार है 🥇, लेकिन पाठ की रूपरेखा हमारी परियोजना के लिए एक आवश्यकता है ...

मैं इसमें थोड़ा वापस आया और जल्दी से महसूस किया कि मैंने इसे मूल रूप से समाप्त क्यों नहीं किया। जबकि SDF _can_ का उपयोग रूपरेखा के लिए किया जा सकता है, कुछ चेतावनी हैं:

• रूपरेखा की अधिकतम संभावित चौड़ाई दूरी क्षेत्र की सीमा तक सीमित होती है (~ 64x64 SDF बनावट में 8 टेक्सल्स)।
• यह सभी ग्लिफ़ में एक सुसंगत दृश्य आकार के अनुरूप नहीं है, क्योंकि SDF बनावट को प्रत्येक ग्लिफ़ की सीमा तक बढ़ाया जाता है।

इसलिए "W" जैसे बड़े ग्लिफ़ को शालीनता से मोटी रूपरेखा मिल सकती है, लेकिन छोटे ग्लिफ़ जैसे पीरियड्स केवल बहुत पतली रूपरेखा प्राप्त कर सकते हैं। और प्रत्येक ग्लिफ़ को अपनी रूपरेखा को नेत्रहीन रूप से सुसंगत बनाने के लिए एक अलग SDF कटऑफ़ बिंदु का उपयोग करने की आवश्यकता होती है।

मुझे नहीं लगता कि यह अभी तक दुर्गम है, लेकिन यह उतना आसान नहीं है जितना मैंने शुरू में सोचा था।

मैं उत्सुक हूं, क्या हम रूपरेखा और/या छाया प्रभाव प्राप्त करने के लिए शेडर्स का उपयोग करके किसी प्रकार की पोस्ट प्रोसेसिंग कर सकते हैं? अग्रिम में धन्यवाद!
यहां वह प्रभाव है जिसे मैं प्राप्त करने का प्रयास कर रहा हूं:

संपादित करें: यह मैपबॉक्स जीएल से है, मुझे लगता है कि वे एसडीएफ का भी उपयोग कर रहे हैं https://blog.mapbox.com/drawing-text-with-signed-distance-fields-in-mapbox-gl-b0933af6f817 , शायद हम कर सकते हैं उन्होंने क्या किया यह देखने के लिए उनके कोड को विच्छेदित करें। https://github.com/mapbox/mapbox-gl-js

मैपबॉक्स, @anzorb के बारे में जानकारी के लिए धन्यवाद। मैं निश्चित रूप से उनके कार्यान्वयन की अधिक बारीकी से जांच करूंगा, लेकिन उस ब्लॉग पोस्ट से (वे रूपरेखा को "हेलो" कहते हैं) ऐसा लगता है जैसे वे एसडीएफ अल्फा थ्रेसहोल्ड दृष्टिकोण का उपयोग करते हैं जैसा मैंने पहले उल्लेख किया था। लेकिन उनकी एसडीएफ पीढ़ी और एटलस पैकिंग रणनीति मेरी तुलना में अलग है और गैर-समान दूरी फ़ील्ड आकार प्रति ग्लिफ़ के साथ समान समस्याएं नहीं हैं। हालांकि इसकी अधिकतम रूपरेखा चौड़ाई सीमा समान होगी।

मैंने वास्तव में मानक डेरिवेटिव का उपयोग करके _स्क्रीन स्पेस_ रूपरेखा पर कुछ प्रगति की है। स्क्रीन स्पेस का अर्थ है कि आउटलाइन जैसे टेक्स्ट के आकार/पैमाने या तिरछेपन की परवाह किए बिना 1 स्क्रीन पिक्सेल चौड़ा होगा। यदि लक्ष्य केवल पृष्ठभूमि के साथ कंट्रास्ट जोड़ना है, तो ऐसा लगता है कि यह उतना ही अच्छा हो सकता है (या इससे भी बेहतर) टेक्स्ट आकार के साथ उस पैमाने को रेखांकित करता है। क्या उस पर आपकी कोई राय है?

स्केलिंग चौड़ाई की तुलना में मानकीकृत चौड़ाई अधिक पसंद की जाती है। यह इस तरह से भी सीएसएस की तरह व्यवहार करेगा।
कोई भी text-shadow जिसे css के माध्यम से लागू किया जाता है, font-size से स्वतंत्र रूप से कॉन्फ़िगर किया गया है।
यदि आपका प्रस्तावित समाधान @lojjic उसी तरह से प्रदर्शन करता है, तो वह होगा

आपकी त्वरित प्रतिक्रिया @lojjic के लिए धन्यवाद!

लक्ष्य इसके विपरीत जोड़ना है , और आपका प्रस्ताव बहुत अच्छा लगता है। क्या आपका मतलब है कि रूपरेखा स्थिर होगी? यानी इसे नियंत्रित करने का कोई तरीका नहीं है (जैसा कि @stephencorwin ने टेक्स्ट-छाया-आश दृष्टिकोण का उपयोग करके वर्णित किया है)।

ईमानदारी से, मैं इसे एक समस्या के रूप में नहीं देखता, जब तक कि 1 पिक्सेल सुपर उच्च घनत्व डिस्प्ले पर दिखाई दे रहा है (क्योंकि हम वर्तमान में "समान" अनुपात प्राप्त करने के लिए डिवाइस पिक्सेल अनुपात द्वारा फ़ॉन्ट-आकार को गुणा करते हैं, घनत्व की परवाह किए बिना) , मुझे लगता है कि आपके प्रस्ताव का मतलब है कि उच्च डीपीआई उपकरणों पर रूपरेखा स्पष्ट रूप से पतली होगी, नहीं?

अग्रिम में धन्यवाद!

मुझे लगता है कि आपके प्रस्ताव का मतलब है कि उच्च डीपीआई उपकरणों पर रूपरेखा स्पष्ट रूप से पतली होगी, नहीं?

हां, यह स्क्रीन-स्पेस दृष्टिकोण का एक नकारात्मक पहलू है। यह कई परिदृश्यों के लिए ठीक हो सकता है लेकिन यह मुझे एक डिजाइनर के रूप में सभी उपकरणों पर एक अलग नज़र रखने के लिए परेशान करेगा।

दूसरा बड़ा नकारात्मक पहलू यह है कि (मुझे लगता है) प्रभामंडल की मोटाई बढ़ाने से अधिक बनावट पढ़ने की आवश्यकता के कारण प्रदर्शन प्रभाव पड़ेगा। हालांकि मुझे इस पर शोध करते रहने की जरूरत है।

मुझे भी यह सुविधा चाहिए। मैंने इस तरह की एक सुविधा को एक एंड्रॉइड ऐप में लागू किया है जिसे मैंने सदियों पहले विकसित किया था और सिर्फ अपने और दोस्तों के लिए उपयोग किया है। मैंने इस ऐप को रिएक्ट के साथ फिर से लागू करना शुरू कर दिया है और आपकी परियोजना को खोजने आया हूं।
दूसरों की तरह, मैं इस पुस्तकालय के लिए आपको धन्यवाद देना चाहता हूं। मैं इससे चकित हूं।

अधिक बनावट पर आपकी टिप्पणी पर लिखा है, मुझे नहीं लगता कि आपको इस बारे में ज्यादा चिंता करनी चाहिए। आपको जिन अतिरिक्त टेक्सल्स की आवश्यकता होगी, वे टेक्सल्स के पड़ोसी टुकड़ों की आवश्यकता होगी और इस प्रकार मुझे लगता है कि वे वैसे भी GPU के कैश में रहने वाले हैं और उनकी कीमत कुछ भी नहीं होगी।

@FunMiles इनपुट के लिए धन्यवाद। (कोलोराडो प्रतिनिधित्व करते हैं! )

मुझे लगता है कि आप शायद 1 की रूपरेखा के लिए सही हैं, शायद 2 टुकड़े मोटे। मेरी चिंता यह है कि जैसे-जैसे मोटाई बढ़ती है, यह दोनों बनावट की संख्या में विस्फोट कर रहा है (मोटाई 4 = 56 पढ़ता है?) लेकिन मैं सिर्फ कुछ चीजों को पढ़ने के आधार पर अनुमान लगा रहा हूं, मैं किसी भी तरह से जीपीयू का विशेषज्ञ नहीं हूं। मुझे शायद बस इसे आजमाना होगा।

@lojjic (आप में से उत्तर यहाँ 😄 ) मैंने टुकड़ा शेडर के लिए कोड खोजने की कोशिश की। मैं मानता हूं कि चीजों को समझने में कठिन समय लगता है (और मुझे लगता है कि मैंने इसे कहीं पढ़ा है) कि आप इसे पूरी तरह से लिखने के बजाय शेडर को संशोधित करते हैं।
हालांकि, हालांकि मैं यह नहीं समझ सकता कि पूर्ण शेडर कैसा है और आप वास्तव में इसमें कैसे प्लग इन करते हैं, मुझे लगता है कि मुझे कुछ मूल दिनचर्या मिलती है ...

अभी आप texture2D(uTroikaSDFTexture, vTroikaSDFTextureUV).r; के साथ पिक्सेल के लिए एक अदिश दूरी पढ़ते हैं। अगर मैं समझ रहा हूं कि आपने पहले क्या लिखा था, तो एक मुद्दा ग्लिफ़ के आसपास के स्थान से संबंधित है। क्या आप अधिक विवरण में समझा सकते हैं?
'W' और ',' के अपने उदाहरण पर वापस जा रहे हैं, क्या बनावट में vTroikaSDFTextureUV स्पैन ग्लिफ़ के चारों ओर कसकर फिट बैठता है, या कुछ अतिरिक्त स्थान है? क्या टुकड़ा शेडर वर्तमान ग्लिफ़ के लिए यूवी की सीमा को जानता है? यदि ऐसा होता है, तो एक टुकड़े के लिए जो बाहर गिर जाएगा, आप वर्तमान यूवी को सीमा तक प्रोजेक्ट कर सकते हैं और डेटा को ठीक अंदर पढ़ सकते हैं।

मुझे लगता है कि यह पता लगाना संभव है कि अधिकतम 5 टेक्सल रीड या डेरिवेटिव के उपयोग के साथ क्या आवश्यक है (मुझे लगता है कि आप जांच करते हैं कि वे उपलब्ध हैं या नहीं)।

'W' और ',' के अपने उदाहरण पर वापस जा रहे हैं, क्या बनावट में vTroikaSDFTextureUV स्पैन ग्लिफ़ के चारों ओर कसकर फिट बैठता है, या कुछ अतिरिक्त स्थान है?

प्रत्येक ग्लिफ़ की वास्तविक पथ सीमा के चारों ओर एक छोटा सा अतिरिक्त स्थान होता है, जो दूरी क्षेत्र के बाहरी हिस्सों को समायोजित करने के लिए पर्याप्त होता है। एसडीएफ में यह 8 टेक्सल्स है, लेकिन चूंकि प्रत्येक एसडीएफ एक समान 64x64 है जो अलग-अलग आकार के ग्लिफ़ क्वाड पर स्केल किया गया है, इसलिए दृश्यमान मार्जिन ग्लिफ़ से ग्लिफ़ में भिन्न होता है।

क्या टुकड़ा शेडर वर्तमान ग्लिफ़ के लिए यूवी की सीमा को जानता है? यदि ऐसा होता है, तो एक टुकड़े के लिए जो बाहर गिर जाएगा, आप वर्तमान यूवी को सीमा तक प्रोजेक्ट कर सकते हैं और डेटा को ठीक अंदर पढ़ सकते हैं।

वह जानकारी उपलब्ध होनी चाहिए। मैं "वर्तमान यूवी को सीमा तक प्रोजेक्ट करने और डेटा को सही अंदर पढ़ने" पर आपका अनुसरण नहीं कर रहा हूं।

यदि आप कम टेक्सल रीड के साथ मोटी रूपरेखा प्राप्त करने का कोई तरीका जानते हैं तो मैं आभारी रहूंगा! मैं इसे इस रूप में अवधारणा कर रहा हूं: ग्लिफ़ पथ के अंदर नहीं एक टुकड़े के लिए, यह देखने के लिए एक रेडियल खोज करें कि आर = के भीतर कोई टुकड़ा है या नहींग्लिफ़ पथ के भीतर गिर जाएगा। इसके बारे में सोचने का यह गलत तरीका हो सकता है।

एक मुद्दा यह है कि क्या होता है जब ग्लिफ़ को एक साथ रखा जाता है। इसे अभी के लिए अलग रखते हुए, आइए एक एकल वर्ण को काफी मोटी रूपरेखा t के साथ खींचे जाने के मामले को लेते हैं। चरित्र को इसके चारों ओर एक आयत के साथ खींचा जा रहा है जो कि रूपरेखा को समायोजित करने के लिए काफी बड़ा है।
टुकड़ा शेडर में दो मुख्य सूचनाएं हैं: vTroikaSDFTextureUV और vTroikaGlyphUV ।

मेरी समझ यह है कि vTroikaGlyphUV में ग्लिफ़ के अंदर 0 और 1 के बीच का मान होता है। जब मैंने प्रक्षेपण के बारे में बात की तो मेरा मतलब यह था कि यदि vTroikaGlyphUV उन सीमाओं के बाहर है, तो आप ग्लिफ़ सीमा पर "अनुमानित" बिंदु की दूरी को पुनः प्राप्त कर सकते हैं। अर्थात्, यदि uv = (1.05, 0.7) है, तो प्रक्षेपित बिंदु (1.0, 0.7) है। (1.0, 0.7+epsilon) और (1.0, 0.7-epsilon) पर मानों का उपयोग करके, आप दूरी के लिए एक ढाल प्राप्त कर सकते हैं और इसका उपयोग करके, अनुमानित दूरी की गणना (1.05, 0.7) कर सकते हैं।
जब मैंने इसके लिए अपना खुद का काम किया, तो मुझे याद है कि बनावट में ढाल के साथ एसडीएफ करने वाले किसी व्यक्ति का लेख भी पढ़ना। यह दृष्टिकोण तीन टेक्सल्स को पढ़ने से बचाता है, लेकिन यह बनावट को 3 घटक बनावट बनाता है और बनावट के निर्माण में जटिलता जोड़ता है।

क्या इससे आपके सवाल का जवाब मिलता है?

अब जब आपके पास कई पात्र साथ-साथ हैं, तो प्रत्येक को पड़ोसियों के बारे में पता होना चाहिए, जिससे यह थोड़ा और जटिल हो जाता है। आपको न केवल वर्तमान चरित्र के लिए, बल्कि पड़ोसी के लिए भी GlyphUV और TextureUV ले जाने की आवश्यकता है। इसके लिए प्रत्येक वर्ण को दो आयतों में काटने की आवश्यकता हो सकती है, ताकि पड़ोसी पहले आयत के लिए पहले वाला और दूसरे आयत के लिए बाद वाला हो सके। मुझे यकीन नहीं है कि मल्टी-लाइन से कैसे निपटें .... मुझे अपने आवेदन में उस मामले से निपटने की ज़रूरत नहीं थी। मेरा आवेदन एक नक्शा था और प्रत्येक लेबल सिंगल लाइन था।

पीएस: मैंने आपके "प्रत्येक ग्लिफ की वास्तविक पथ सीमाओं के आस-पास अतिरिक्त जगह" को गलत समझा होगा। क्या आप कह रहे हैं कि एक एक्स के लिए, उदाहरण के लिए, यह एक आयत में संलग्न है और चार त्रिभुज हैं जिनका कोई मान्य मान नहीं है?

@FunMiles I _think_ शायद मैं देखूं कि आप कहां जा रहे हैं। मुझे इसके बारे में सोचने के लिए कुछ समय की आवश्यकता होगी, लेकिन अन्य समय सीमा का काम है जिस पर मुझे इस समय ध्यान देने की आवश्यकता है।

पीएस: थोड़ा मजेदार गणित नोट:
यदि किसी को आश्चर्य होता है कि दो या तीन संरेखित बिंदुओं से ग्रेडिएंट कैसे प्राप्त किया जा सकता है, तो किसी को यह याद रखना होगा कि दूरी के ग्रेडिएंट का एक निश्चित मानदंड (चुने हुए पैमाने के आधार पर) होता है। और ग्रेडिएंट निश्चित रूप से ग्लिफ़ बॉक्स के बाहर की ओर इशारा करता है। तो उदाहरण के लिए यदि उदाहरण के सभी 3 बिंदु (1.0, 0.7), (1.0, 0.7+epsilon) और (1.0, 0.7-epsilon) समान दूरी पर हैं, तो ग्रेडिएंट (स्केल, 0) है।

हालांकि यह निश्चित रूप से निष्पादक नहीं है, ऑफसेट का उपयोग करना संभव है। मैं react-three-fiber का उपयोग कर रहा हूं, जो ड्रेई पैकेज के साथ ट्रोइका-टेक्स्ट का लाभ उठाता है, लेकिन मुझे लगा कि अगर अन्य लोग स्टॉपगैप के रूप में समाधान की तलाश कर रहे हैं तो मैं साझा करूंगा जब तक कि पुस्तकालय मूल रूप से स्ट्रोक का समर्थन नहीं करता:

import React from 'react';
import {Text} from 'drei';

const StrokedText: React.FC<
  {
    strokeWidth?: number;
    strokeColor?: string;
    strokeResolution?: number;
    bold?: boolean;
  } & any
> = ({
  strokeWidth = 1,
  strokeColor: color = '#000000',
  strokeResolution = 100,
  position,
  bold,
  ...props
}) => {
  const font = bold ? FONTS.BOLD : undefined;
  const sharedProps = {
    ...props,
    font,
    color,
    sdfGlyphSize: 12,
    debugSDF: true,
  };

  let zOffset = 0;
  const offset = () => (zOffset += 0.001);

  return (
    <group name="Stroked Text" position={position}>
      {Array(strokeWidth)
        .fill({})
        .map((_, i) => {
          const s= i / strokeResolution;
          return (
            <React.Fragment key={i}>
              {/* <Text {...sharedProps} position={[-s, 0, offset()]} />*/}
              {/* <Text {...sharedProps} position={[s, 0, offset()]} />*/}
              <Text {...sharedProps} position={[0, -s, offset()]} />
              <Text {...sharedProps} position={[0, s, offset()]} />
              <Text {...sharedProps} position={[-s, -s, offset()]} />
              <Text {...sharedProps} position={[s, s, offset()]} />
              {/* <Text {...sharedProps} position={[-s, s, offset()]} /> */}
              {/* <Text {...sharedProps} position={[s, -s, offset()]} /> */}
            </React.Fragment>
          );
        })}
      <Text name="Text" {...props} position={[0, 0, strokeWidth ? offset() : 0]} />
    </group>
  );
};

export default StrokedText;

फिर कहीं और, मैं इसे सामान्य रूप से <Text /> $ के बजाय <StrokedText /> के साथ कॉल कर सकता हूं:

<StrokedText
  color="#ffffff"
  fontSize={fontSize}
  clipRect={[-0.5, -0.15, 0.5, 0.15]}
  textAlign="center"
  position={[0, 0, 0.01]}
>
  {text}
</StrokedText>

@FunMiles अंत में आपके सुझावों को पार्स करने के लिए मेरे पास कुछ समय है। मुझे लगता है कि यह समझ में आता है कि ग्लिफ़ के एसडीएफ आयत की संपूर्णता में उपयोगी (> 0.0) दूरी मान शामिल हैं। वर्तमान में ऐसा नहीं है; मुझे लगता है कि आप इसे "एक्स" के बारे में अपने फॉलोअप में महसूस कर रहे थे, जहां एसडीएफ क्वाड की सीमा के भीतर शून्य तक गिर जाता है, इसलिए ऐसे महत्वपूर्ण क्षेत्र हैं जहां कोई उपयोगी दूरी ढाल नहीं है जिससे एक्सट्रपलेशन किया जा सके:

शायद मैं क्वाड की संपूर्णता में एक गैर-शून्य ढाल सुनिश्चित करने के लिए एसडीएफ जनरेटर को बदलने पर विचार कर सकता हूं ...? ज़ोर से सोचना, जो दूरी की सटीकता के लिए अर्थ हो सकता है, और एटलस बनावट के भीतर पात्रों के बीच कलाकृतियों को पेश कर सकता है ...

शायद मैं क्वाड की संपूर्णता में एक गैर-शून्य ढाल सुनिश्चित करने के लिए एसडीएफ जनरेटर को बदलने पर विचार कर सकता हूं

मैंने यह कोशिश की है, और हाँ यह दूरी क्षेत्र को क्वाड सीमाओं से परे निकालने की इजाजत देता है, लेकिन जैसा कि मुझे डर था कि यह ग्लिफ की गुणवत्ता को काफी कम कर देता है। यह केवल 8-बिट ग्रेडिएंट के साथ अपेक्षित है; इसे बड़ी दूरी पर फैलाने से प्रत्येक टेक्सल पर कम परिशुद्धता प्राप्त होती है। :(

शायद मैं सिर्फ रूपरेखा के लिए एक अलग एसडीएफ उत्पन्न कर सकता हूं - एक उच्च-प्रसार लेकिन कम-सटीक क्षेत्र - एक दूसरे बनावट चैनल में एन्कोड किया गया। यह बनावट के आकार को दोगुना कर देगा लेकिन काफी धीमा नहीं होना चाहिए। मैं

एक दूसरे बनावट चैनल में एन्कोड किया गया।

@lojjic यह बहुत ही उचित लगता है और मूल रूप से अभी मेरे कामकाज की नकल करता है। साथ ही, यह ऑप्ट-इन हो सकता है, इसलिए यदि उपयोगकर्ता आउटलाइन नहीं मांगता है तो कोई पूर्ण हिट नहीं है।

@lojjic @stephencorwin द्वारा सुझाए गए ऑप्ट-इन दृष्टिकोण से यह सुनिश्चित होगा कि कोई भी भुगतान करने के लिए तैयार होने से अधिक भुगतान नहीं करता है।

तकनीकी पहलू पर वापस। आइए आपकी प्रतिक्रिया में एक्स छवि लें। क्या मैं सही ढंग से समझ रहा हूँ कि सभी ग्लिफ़ के लिए, यह 64x64 पिक्सेल है? 8 बिट्स के साथ, यदि आपको पूरी दूरी के स्थान को एन्कोड करना है, तो इसका मतलब है कि आपके पास 2 _fractional_ बिट्स की सटीकता है। मुझे लगता है कि आप कह रहे हैं कि यह सटीकता पर्याप्त नहीं है।

बहुत कम लागत पर सटीकता हासिल करने के लिए शायद एक तरकीब है। 8 बिट्स के 64x64 के ग्रिड को करने के बजाय, 2x2 ब्लॉक के डेटा को 32-बिट डेटा में संपीड़ित करें। दो पिक्सल के बीच हस्ताक्षरित दूरी की एक स्पष्ट विशेषता यह है कि यह हमेशा [-1,1] दाएं और बाएं, ऊपर और नीचे और [-sqrt(2), sqrt(2)] विकर्ण में होता है। तो कल्पना कीजिए कि आप 2x2 ब्लॉक के केंद्र के एसडी के लिए 12 बिट्स का उपयोग करते हैं, आपके पास पिक्सेल के प्रत्येक केंद्र के लिए उनके केंद्र और 2x2 के केंद्र के बीच अंतर को एन्कोड करने के लिए 5 बिट होंगे। ये 5 बिट अधिकतम sqrt(2)/2 दूरी पर प्रतिनिधित्व करते हैं। प्रभावी रूप से आपके पास 5.5 बिट सटीकता है।
केंद्र बिंदु 12 बिट्स अधिकतम 64 की दूरी पर सटीकता के कम से कम 6 बिट्स को एन्कोड करते हैं। तकनीकी रूप से यदि बॉक्स में एक कोने पर केवल एक बिंदु होता है तो 12 बिट को sqrt(2)*64 तक एन्कोड करने में सक्षम होना चाहिए, लेकिन मुझे नहीं लगता कि यह वास्तव में संभव है क्योंकि बॉक्स प्रत्येक ग्लिफ़ के आसपास उचित रूप से केंद्रित है। वास्तव में, किसी भी ग्लिफ़ किनारे से आगे और कम जानकारी को डेल्टा को एन्कोड करना पड़ता है, (जब आप ग्लिफ़ किनारे से बहुत दूर होते हैं, तो ढाल क्षेत्र एक पड़ोस में लगभग एक समान हो जाता है) इसलिए सूचना सिद्धांत के दृष्टिकोण से, यह सम है एन्कोडिंग में सुधार संभव है
वास्तविक जानकारी के अधिक अंश प्राप्त करने के लिए.... लेकिन मैं इस तरह के एक अतिरिक्त अनुकूलन के साथ शुरू नहीं करूंगा।

इस दृष्टिकोण का एक दिलचस्प परिणाम यह है कि कोई बनावट वाले हार्डवेयर को कोई प्रक्षेप नहीं करने देगा। लेकिन दूसरी तरफ, किसी को मुफ्त में ग्रेडिएंट मिलेंगे।

अगर आपको मदद की ज़रूरत है, तो मैं इन सभी के एन्कोडिंग/डिकोडिंग को लागू कर सकता हूं।

पुनश्च: मेरे पास एक अधिक परिष्कृत एसडीएफ के बारे में README.md में से एक में चर्चा देखने की स्मृति है। क्या मैंने सपना देखा? 😛 क्या कोई मुझे यह देखने के लिए वापस इंगित कर सकता है कि क्या वह अन्य प्रणाली यहां मदद कर सकती है?

@FunMiles बहुत चालाक संपीड़न विचार। यदि अन्य विकल्प विफल हो जाते हैं तो मैं इसे ध्यान में रखूंगा। हार्डवेयर द्वारा रैखिक इंटरपोलेशन खोना एक ट्रेडऑफ है जिसे मुझे बनाना नहीं है। मैं

यह मेरे साथ हुआ कि पर्याप्त बिट्स के साथ मेरी समस्या 0.5 "शून्य" दूरी के रूप में उपयोग करके तेज हो गई है, इसलिए दूरी _outside_ ग्लिफ को एन्कोड करने के लिए केवल आधा अल्फा मान उपलब्ध हैं। मैं संभावित रूप से बाहरी दूरी के लिए अधिक मूल्यों का उपयोग करने के लिए और अंदर की दूरी के लिए कम, परिधि पर कुछ सटीकता प्राप्त करने के लिए स्थानांतरित कर सकता हूं।

पुनः। एक "अधिक परिष्कृत एसडीएफ", आपका मतलब "एमएसडीएफ" हो सकता है जहां एकाधिक रंग चैनलों का उपयोग किया जाता है?

@FunMiles बहुत चालाक संपीड़न विचार। यदि अन्य विकल्प विफल हो जाते हैं तो मैं इसे ध्यान में रखूंगा। हार्डवेयर द्वारा रैखिक इंटरपोलेशन खोना एक ट्रेडऑफ है जिसे मुझे बनाना नहीं है। मैं

मुझे नहीं लगता कि आपको उस प्रक्षेप को खोने की चिंता करनी चाहिए। लागत बहुत कम है लेकिन हार्डवेयर समर्थन में नहीं होने पर हमेशा ढाल (और यहां तक ​​​​कि थोड़ी सी वक्रता) होने का लाभ मेरे विचार में अधिक महत्व रखता है। असल में, आप नमूना बिंदु को गोल करते हैं और गोलाकार नमूना बिंदु पर एक नया ऑफ़सेट मान प्राप्त करते हैं। एंटी एलियासिंग आय के लिए टुकड़े के आंशिक कवरिंग की गणना करना जैसा कि सामान्य रूप से ग्रेडिएंट उपलब्ध होने के साथ होता है।
यह मेरे साथ हुआ कि पर्याप्त बिट्स के साथ मेरी समस्या 0.5 "शून्य" दूरी के रूप में उपयोग करके तेज हो गई है, इसलिए दूरी _outside_ ग्लिफ को एन्कोड करने के लिए केवल आधा अल्फा मान उपलब्ध हैं। मैं संभावित रूप से बाहरी दूरी के लिए अधिक मूल्यों का उपयोग करने के लिए और अंदर की दूरी के लिए कम, परिधि पर कुछ सटीकता प्राप्त करने के लिए स्थानांतरित कर सकता हूं।

इससे आपको अधिक से अधिक एक बिट सटीकता प्राप्त होगी। छींक नहीं आनी चाहिए लेकिन फिर भी इतना महत्वपूर्ण नहीं है।

पुनः। एक "अधिक परिष्कृत एसडीएफ", आपका मतलब "एमएसडीएफ" हो सकता है जहां एकाधिक रंग चैनलों का उपयोग किया जाता है?
मेरा मतलब यही था। मुझे इसके बारे में सी ++ में गिटहब प्रोजेक्ट मिला। क्या आपके पास इसका उपयोग करने के लिए कुछ था या क्या मैं भ्रमित हो गया था, मैंने दो सप्ताह पहले विभिन्न चीजों को देखा था?

मुझे नहीं लगता कि एमएसडीएफ वैसे भी मदद करेगा।
क्या मैं पूछ सकता हूं कि क्या आपके पास एक छोटी .md फ़ाइल हो सकती है जो यह बताए कि आप जावास्क्रिप्ट में एसडीएफ कैसे बनाते हैं? इसके साथ, मुझे लगता है कि मैं अपने संपीड़न विचार को लागू करने के लिए कोड बना सकता हूं।

एसडीएफ यहां बनाया गया है: https://github.com/protectwise/troika/blob/master/packages/troika-three-text/src/worker/SDFGenerator.js#L134 - इसके बारे में समझाने के लिए वास्तव में बहुत कुछ नहीं है, ज्यादातर टेक्सल्स को फॉन्ट यूनिट्स में मैप करना और टेक्सल वैल्यू में मापी गई दूरियों को लिखना। हमें प्रत्येक 2x2 ब्लॉक के केंद्र बिंदु के लिए वहां कुछ अतिरिक्त दूरी माप जोड़ना होगा।

मेरे दिमाग को इसके चारों ओर पूरी तरह से लपेटने की कोशिश कर रहा है ... जीएलएसएल में बिलिनियर इंटरपोलेशन को दोहराना सरल/सस्ता लगता है, एक बार आपके पास 4 निकटतम मान हो जाते हैं। उन मानों को प्राप्त करने के लिए जब वे आपकी संपीड़न योजना के साथ एन्कोड किए जाते हैं, मुझे लगता है कि इसमें शामिल होगा:

• यदि बिल्कुल एक टेक्सल के केंद्र पर: या तो 2 या 3 बनावट के नमूने
• यदि 2x2 ब्लॉक के 4 टेक्सल्स के बीच: 4 बनावट के नमूने
• यदि दो पड़ोसी ब्लॉकों के बीच: ~9 बनावट के नमूने~ या तो 7 या 8 बनावट के नमूने
• यदि चार पड़ोसी ब्लॉकों के बीच: ~11 बनावट के नमूने~13 बनावट के नमूने

क्या मैं इसे सही तरीके से टटोल रहा हूँ?

ओह रुको, मैं अभी भी एकल-चैनल बनावट के बारे में सोच रहा था। चार आरजीबीए चैनलों का उपयोग करते हुए, प्रत्येक डेटा ब्लॉक केवल एक ही पढ़ा जाता है। तो अधिकतम 4 बनावट के नमूने।

मैंने SDFGenerator.js पढ़ना शुरू कर दिया था। मैं इसे और देखूंगा।

मुझे नहीं लगता कि आपको प्रति खंड एक टेक्सल पढ़ने से अधिक की आवश्यकता है, जब तक कि आप कोने के मामलों के लिए अल्फा सम्मिश्रण में विशेष रूप से सुधार नहीं करना चाहते हैं, जहां आप सभी तरफ ग्लिफ़ किनारों से घिरे बिंदु पर हो सकते हैं। आपको बस 2x2 ब्लॉक के निकटतम केंद्र की आवश्यकता है जहां टुकड़े का केंद्र है।
हालांकि, मुझे एहसास है कि एक ऐसी कठिनाई हो सकती है जिसकी मैंने कल्पना नहीं की थी... वेबजीएल 1.0 जो प्रदान करता है उसमें बहुत सीमित है जो यहां उपयोग के लिए होगा: कोई अहस्ताक्षरित पूर्णांक प्रकार uint 32 बिट पूर्णांक भी नहीं! और कोई बिटवाइज़ ऑपरेशन नहीं ... इसलिए मैं जो कंप्रेशन सुझा रहा हूं वह 16 बिट पूर्णांकों का उपयोग करके लिखना थोड़ा अधिक मुश्किल है।

ये सभी वेबजीएल 2.0 में उपलब्ध हैं लेकिन मुझे लगता है कि हम यहां वेबजीएल 1.0 को लक्षित करना चाहते हैं?

ये सभी वेबजीएल 2.0 में उपलब्ध हैं लेकिन मुझे लगता है कि हम यहां वेबजीएल 1.0 को लक्षित करना चाहते हैं?

मुझे लगता है कि टेक्स्ट रूपरेखा को वेबग्ल 2 पर प्रतिबंधित करना उचित हो सकता है और यह पता लगा सकता है कि उपयोगकर्ता के पास ब्राउज़र संगतता है या नहीं। हालाँकि, मैं समझ सकता हूँ कि संभवतः एक webgl 1 फ़ॉलबैक के साथ एक webgl 2 इष्टतम संस्करण दोनों कर रहा हूँ। इमो हम वेबग्ल 2 के साथ शुरू कर सकते हैं और दोनों का समर्थन करने का तुरंत प्रयास करने से पहले समुदाय के साथ भीगने दें।

मुझे लगता है कि मेरे पास सटीक मुद्दे को हल करने के लिए एक वैकल्पिक दृष्टिकोण है, इसलिए @FunMiles अभी के लिए संपीड़न सामग्री से लड़ने के बारे में चिंता न करें।

अरे @lojjic , ​​बस इस पर जाँच कर रहा हूँ। कोई प्रगति या चीजें जिससे हम मदद कर सकते हैं?

साइड नोट: सफारी अंततः WebGL2 का समर्थन करने के लिए आ रही है, इसलिए इस सुविधा के लिए WebGL1 का समर्थन नहीं करना संभव हो सकता है।

हमारा WebGL2 कार्यान्वयन काफी अच्छी स्थिति में है कि हमें इसे व्यापक परीक्षण के लिए डिफ़ॉल्ट रूप से सक्षम करना चाहिए।
https://trac.webkit.org/changeset/267027/webkit

मेरे पास एक आईफोन 6 है जिस पर वेबजीएल 2.0 कभी नहीं होगा

दिलचस्प बात यह है कि वेबजीएल 1.0 मेरे विचार से भी बदतर आवश्यकताओं को निर्दिष्ट करता है। पूर्णांक वास्तव में मौजूद नहीं हैं:

4.1.3 पूर्णांक
पूर्णांक मुख्य रूप से प्रोग्रामिंग सहायता के रूप में समर्थित हैं। हार्डवेयर स्तर पर, वास्तविक पूर्णांक सहायता करेंगे
लूप और सरणी सूचकांकों का कुशल कार्यान्वयन, और बनावट इकाइयों को संदर्भित करना। हालाँकि, वहाँ नहीं है
आवश्यकता है कि भाषा मानचित्र में पूर्णांक हार्डवेयर में एक पूर्णांक प्रकार के लिए। यह अपेक्षित नहीं है कि
अंतर्निहित हार्डवेयर को पूर्णांक संचालन की एक विस्तृत श्रृंखला के लिए पूर्ण समर्थन प्राप्त है। एक ओपनजीएल ईएस छायांकन
भाषा कार्यान्वयन उन पर संचालित करने के लिए पूर्णांकों को फ़्लोट में बदल सकता है। इसलिए, कोई पोर्टेबल नहीं है
लपेटने का व्यवहार।

हालांकि मैंने उम्मीद नहीं खोई है। मुझे बस थोड़ा सा पुनर्विचार करना है ...
इस बीच, @lojjic , ​​क्या आप हमें बता रहे हैं कि आपने किस वैकल्पिक दृष्टिकोण के बारे में सोचा है?

@FunMiles ज़रूर। मैं गैर-रैखिक पैमाने का उपयोग करके दूरी मानों को एन्कोड करके, ग्लिफ़ के आकार के लिए पर्याप्त सटीकता बनाए रखते हुए, बनावट के किनारों तक दूरी क्षेत्र का विस्तार करने में सक्षम हूं। इसलिए ग्लिफ़ के पथ के बहुत निकट की दूरी (1-2 टेक्सल्स के भीतर) के साथ काम करने के लिए कई मूल्य हैं, जबकि आगे की दूरी कम है। शेडर को सिर्फ यह जानना है कि मूल रैखिक दूरी में वापस कैसे परिवर्तित किया जाए। ग्लिफ़ का उचित आकार बहुत अच्छा दिखता है, और एक्सट्रूडेड आउटलाइन के लिए कम सटीकता शायद ही ध्यान देने योग्य हो, क्योंकि वे वैसे भी गोल होते हैं।

मैंने इसे दो-स्तरीय रैखिक पैमाने और एक घातीय पैमाने दोनों का उपयोग करके साबित कर दिया है। दोनों के पक्ष और विपक्ष हैं।

अब मैं क्वाड के बाहर ढाल का अनुमान लगाने के लिए पड़ोसी किनारे के मूल्यों का उपयोग करने के आपके (बहुत स्मार्ट) दृष्टिकोण को लागू करने के बीच में हूं। यह अब तक समझ में आता है, हालांकि मुझे यकीन नहीं है कि कोनों के बाहर के क्षेत्रों के बारे में क्या करना है। एक बार जब मैं इसमें आगे बढ़ूं तो यह स्पष्ट हो सकता है, लेकिन अगर आपके पास मेरे लिए एक आसान जवाब है तो मैं आभारी रहूंगा :)

अब मैं क्वाड के बाहर ढाल का अनुमान लगाने के लिए पड़ोसी किनारे के मूल्यों का उपयोग करने के आपके (बहुत स्मार्ट) दृष्टिकोण को लागू करने के बीच में हूं। यह अब तक समझ में आता है, हालांकि मुझे यकीन नहीं है कि कोनों के बाहर के क्षेत्रों के बारे में क्या करना है। एक बार जब मैं इसमें आगे बढ़ूं तो यह स्पष्ट हो सकता है, लेकिन अगर आपके पास मेरे लिए एक आसान जवाब है तो मैं आभारी रहूंगा :)

मुझे यकीन नहीं है कि _बाहर कोनों_ से आपका क्या मतलब है। क्या आपका मतलब प्रत्येक कोने पर निहित क्वार्टर विमानों से है, जहां निकटतम प्रक्षेपण कोना ही है? मुझे लगता है कि आप लंबवत और क्षैतिज दोनों किनारों पर किनारे पर नियम का उपयोग कर सकते हैं और प्रत्येक के लिए दूरी के आधार पर भारित औसत कर सकते हैं।

पीएस: वेबजीएल पूर्णांक बकवास पढ़ने के बाद आज मेरे पास सटीकता को कम करने का विचार आया था ... अधिक परीक्षण के साथ अधिक बिट्स। यानी rgba का उपयोग करके, a औसत के 8 बिट रख सकता है, फिर प्रत्येक rgb के लिए, उन पर हस्ताक्षर किए जाएंगे और संकेत प्रत्येक सटीकता के 1 बिट का प्रतिनिधित्व करेगा औसत, फिर अंत में शेष, जो कि 0-127 की सीमा में होगा, का मान 64 घटाया जाएगा, जो आवश्यक 4 में से 3 मानों के लिए 7 बिट्स का प्रतिनिधित्व करेगा। वास्तविक मान यह केंद्र होगा (0 से 2^11-1 तक) + dist_i. चौथा मान उनकी राशि को घटाकर वसूल किया जाएगा, क्योंकि योग औसत होना चाहिए। एक को केवल 11 बिट मिलेंगे, लेकिन यह शायद पर्याप्त है। अधिक बिट्स प्राप्त करने के लिए यह परीक्षण करने की आवश्यकता होगी कि क्या मूल्य या r , g , और b -64 से छोटे हैं, सकारात्मक या नकारात्मक, 64 से बड़े हैं। यह अनिवार्य रूप से होगा केंद्र के लिए 14 बिट और अंतर के लिए केवल 6 बिट दें। शायद एक अच्छा समझौता? मुझे यह परीक्षण करने की आवश्यकता होगी कि बहुत ही ढीली गारंटी है कि WebGL 1.0 सटीकता पर रखता है, इस सोच में हस्तक्षेप नहीं करेगा ....

हाँ, मेरा यही मतलब था, वे क्षेत्र जहाँ U और V दोनों 0-1 से बाहर हैं। धन्यवाद, मैं इसे एक शॉट दूंगा।

@lojjic एक अलग प्रश्न के रूप में, पिछली पोस्ट में, आप स्मृति के कारण प्रति एसडीएफ टेक्सल में दो बनावट मान रखने के बारे में चिंतित थे। हालाँकि मैं स्वयं मेमोरी को कम करना पसंद करता हूँ, 64x64 ग्रिड पर 256 ग्लिफ़ केवल 1/4MB बनावट मेमोरी की खपत कर रहे हैं। मुझे पता है कि कुछ भाषाओं में और अधिक ग्लिफ़ की आवश्यकता हो सकती है, लेकिन फिर भी, बीबीसी का कहना है कि समाचार पत्र पढ़ने के लिए केवल 2000/3000 वर्णों की आवश्यकता होती है। तो 4000 वर्ण एक बाइट प्रति टेक्सल एसडीएफ के साथ 4 एमबी के लिए बनाएंगे। चिंता करने लायक?

@FunMiles मेला बिंदु, और मैं वास्तव में उस tbh के बारे में बहुत चिंतित नहीं था।

कुछ बकाया काम करना बाकी है, लेकिन b19cd3aff4b0876253d76b3fc66b7e2a1f16a7e5 इस समस्या को ठीक करता है। प्रतिक्रिया-तीन-फाइबर का उपयोग करने वालों के लिए, इसे ड्रेई v2.2.0 . में जारी किया गया है
https://github.com/pmndrs/drei/pull/156

मुझे पता है कि यह बंद है लेकिन मैं काम के लिए धन्यवाद कहना चाहता हूं। मुझे यह मेरे ऐप में काम करने के लिए मिला है। थोड़ा समझ में आया कि गुण रूपरेखा आकार के लिए केवल एक संख्या को स्वीकार नहीं करेंगे। हालाँकि परिणाम वही है जो मुझे चाहिए था।

@FunMiles अच्छा लग रहा है! आप _ चाहिए_ outlineWidth के लिए एक संख्यात्मक मान का उपयोग करने में सक्षम हों, इसलिए यदि किसी कारण से यह आपके लिए काम नहीं कर रहा है तो मुझे बताएं।

और रास्ते में आपके इनपुट के लिए धन्यवाद। मैं अभी भी आपके द्वारा बताई गई तकनीक का उपयोग करके क्वाड बाउंड्स के बाहर की दूरी का एक सहज एक्सट्रपलेशन प्राप्त करने में सक्षम नहीं था, इसलिए एक मोटी रूपरेखा में वर्तमान में विशेष रूप से कोनों पर ढेलेदार बिट्स हैं, लेकिन यह ज्यादातर मामलों के लिए पर्याप्त है (~ ~ तक) 10% फ़ॉन्ट आकार)। मैं निश्चित रूप से इसे अभी भी परिष्कृत करने की कोशिश करने के लिए तैयार हूं।