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

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

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

लेखों की इस श्रृंखला में, हम उस तकनीक का विस्तार से वर्णन करेंगे जिसका उपयोग हम तीन भागों में करते हैं:

पहले भाग में, हम सीखेंगे कि एक समान ग्रिड से नमूना लेकर 16xAA का उपयोग करके वास्तविक समय में ग्लिफ़ को कैसे रेंडर किया जाए।
दूसरे भाग में, हम घुमाए गए ग्रिड पर क्षैतिज और लंबवत किनारों के खूबसूरती से प्रदर्शन करने के लिए आगे बढ़ेंगे। हम यह भी देखेंगे कि समाप्त बनावट एक बनावट और एक देखने की मेज पर लगभग पूरी तरह से कैसे कम हो जाती है।
तीसरे भाग में, हम सीखेंगे कि कॉम्प्यूट और सीपीयू का उपयोग करके वास्तविक समय में ग्लिफ़ को कैसे व्यवस्थित किया जाए।

आप प्रोफाइलर में तैयार परिणामों को भी देख सकते हैं, लेकिन यहां एक स्क्रीन का उदाहरण है, जिसमें Segoe UI फ़ॉन्ट दिया गया है, जो हमारे कंप्यूटर रेंडर का उपयोग कर प्रस्तुत किया गया है:

यहाँ पत्र S में वृद्धि हुई है, जो केवल 6x9 टेक्सल्स का एक रेखांकित आकार है। मूल वेक्टर डेटा को एक पथ के रूप में प्रस्तुत किया गया है, और घुमाया गया नमूना पैटर्न हरे और लाल आयतों से प्रदान किया गया है। चूंकि यह 6 × 9 से अधिक रिज़ॉल्यूशन के साथ प्रदान किया गया है, ग्रे के रंगों को पिक्सेल की अंतिम छाया में नहीं दर्शाया गया है, यह उप-पिक्सेल के रंग को प्रदर्शित करता है। यह सुनिश्चित करने के लिए एक बहुत ही उपयोगी डिबगिंग विज़ुअलाइज़ेशन है कि सबपिक्सल स्तर पर सभी गणना सही ढंग से काम कर रही हैं।

विचार: छाया के बजाय कोटिंग का भंडारण

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

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

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

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

लेकिन क्या होगा अगर हमें पिक्सल्स के बीच ग्लिफ़ को स्वतंत्र रूप से घुमाने की ज़रूरत है? यदि अग्रिम में गणना की जाती है, तो हम यह पता नहीं लगा सकते हैं कि लक्ष्य पिक्सेल क्षेत्र में पिक्सेल के बीच चलते समय क्या होना चाहिए। हालाँकि, हम रेंडरिंग के समय कवरेज से रूपांतरण तक देरी कर सकते हैं। ऐसा करने के लिए, हम छाया को स्टोर नहीं करेंगे, लेकिन कोटिंग । हम 16 लक्ष्य रिज़ॉल्यूशन की आवृत्ति के साथ एक ग्लिफ़ का नमूना लेते हैं, और प्रत्येक नमूने के लिए हम एक बिट बचाते हैं। जब एक 4 × 4 ग्रिड पर नमूना लिया जाता है, तो यह केवल 16 बिट प्रति पिक्सेल स्टोर करने के लिए पर्याप्त है। यह हमारा कवर मास्क होगा । रेंडरिंग के दौरान, हमें यह गिनने की ज़रूरत है कि लक्ष्य पिक्सेल विंडो में कितने बिट्स हैं, जिसमें टेक्सल रिपॉजिटरी के समान रिज़ॉल्यूशन है, लेकिन शारीरिक रूप से इसके साथ संलग्न नहीं है। नीचे दिए गए एनीमेशन में ग्लिफ़ (नीला) का एक हिस्सा दिखाया गया है, जो चार टेक्सल्स में रस्टीकेटेड है। प्रत्येक टेक्सेल को 4 × 4 सेल के ग्रिड में विभाजित किया गया है। एक ग्रे आयत एक पिक्सेल खिड़की को इंगित करता है जो गतिशील रूप से ग्लिफ़ के पार चलती है। रन समय में, पिक्सेल विंडो में आने वाले नमूनों की संख्या को निर्धारित करने के लिए गिना जाता है।

संक्षेप में मूल फ़ॉन्ट रेंडरिंग तकनीकों पर

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

रेंडरर को लागू करने की प्रक्रिया में, मैंने फ़ॉन्ट रेंडरिंग के विकास के लंबे इतिहास के बारे में अधिक से अधिक सीखा। अनुसंधान पूरी तरह से फ़ॉन्ट रेंडरिंग के एकमात्र पहलू पर केंद्रित है - छोटे आकारों में पठनीयता। बड़े फोंट के लिए एक उत्कृष्ट रेंडरर बनाना काफी सरल है, लेकिन छोटे आकार में पठनीयता बनाए रखने वाली प्रणाली को लिखना अविश्वसनीय रूप से कठिन है। फ़ॉन्ट प्रतिपादन के अध्ययन का एक लंबा इतिहास है, इसकी गहराई में हड़ताली। उदाहरण के लिए, रेखापुंज त्रासदी के बारे में पढ़ें। यह तर्कसंगत है कि कंप्यूटर विशेषज्ञों के लिए यह मुख्य समस्या थी, क्योंकि कंप्यूटरों के शुरुआती चरणों में, स्क्रीन रिज़ॉल्यूशन काफी कम था। यह ओएस डेवलपर्स के साथ सामना करने वाले पहले कार्यों में से एक रहा होगा: निम्न स्क्रीन रिज़ॉल्यूशन वाले उपकरणों पर पाठ को पठनीय कैसे बनाया जाए? मेरे आश्चर्य के लिए, उच्च-गुणवत्ता वाले फ़ॉन्ट रेंडरिंग सिस्टम बहुत पिक्सेल-उन्मुख हैं। उदाहरण के लिए, एक ग्लिफ़ का निर्माण इस तरह से किया जाता है कि यह पिक्सेल की सीमा पर शुरू होता है, इसकी चौड़ाई पिक्सेल की संख्या से कई गुना अधिक होती है, और पिक्सेल को फिट करने के लिए सामग्री समायोजित की जाती है। इस तकनीक को मेशिंग कहा जाता है। मुझे कंप्यूटर गेम और 3 डी-ग्राफिक्स के साथ काम करने की आदत है, जहां दुनिया इकाइयों से निर्मित है और पिक्सल में अनुमानित है, इसलिए मुझे थोड़ा आश्चर्य हुआ। मुझे पता चला कि फ़ॉन्ट रेंडरिंग के क्षेत्र में यह एक बहुत ही महत्वपूर्ण विकल्प है।

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

Antialiasing पिक्सल को दाईं और बाईं ओर समान रूप से ग्रे बना देगा। यदि ग्लिफ़ को थोड़ा स्थानांतरित किया जाता है ताकि यह बेहतर ढंग से पिक्सेल की सीमाओं से मेल खाता हो, तो केवल एक पिक्सेल रंग का होगा, और यह पूरी तरह से काला हो जाएगा:

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

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

फ़ॉन्ट थोड़े विकृत हो जाते हैं। फ़ॉन्ट ठीक से इच्छित नहीं दिखते।
सभी ग्लिफ़ को पिक्सेल ग्रिड से जोड़ा जाना चाहिए: ग्लिफ़ की शुरुआत और ग्लिफ़ की चौड़ाई। इसलिए, पिक्सेल के बीच उन्हें एनिमेट करना असंभव है।

दिलचस्प है, इस समस्या को हल करने में, Apple और Microsoft अलग-अलग तरीकों से गए। Microsoft पूर्ण स्पष्टता का पालन करता है, और Apple अधिक सटीक रूप से डिस्प्ले फोंट की तलाश करता है। इंटरनेट पर आप लोगों को Apple मशीनों पर धुंधली फोंट के बारे में शिकायत करते हुए पा सकते हैं, लेकिन बहुत से लोगों को यह पसंद है कि वे Apple पर क्या देखते हैं। यह आंशिक रूप से स्वाद की बात है। यहाँ सॉफ्टवेयर पर जोएल का पद है, और यहाँ इस विषय के बारे में पीटर बिलाक का पद है, लेकिन यदि आप इंटरनेट पर खोज करते हैं, तो आप बहुत अधिक जानकारी पा सकते हैं।

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

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

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

एक समान ग्रिड का उपयोग करके ग्लिफ़ प्रदान करना

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

टेक्स प्राप्त करना

हम पिक्सेल विंडो को टेक्सल्स में संग्रहीत कवरेज बिट्स द्वारा स्थानांतरित कर देंगे। हमें निम्नलिखित प्रश्न का उत्तर देने की आवश्यकता है: हमारी पिक्सेल विंडो में कितने नमूने होंगे? यह निम्नलिखित छवि द्वारा सचित्र है:

यहां हम चार टेक्सल्स देखते हैं, जिन पर एक ग्लिफ़ आंशिक रूप से सुपरिंपल होता है। एक पिक्सेल (नीले रंग में संकेतित) टेक्सल्स के हिस्से को कवर करता है। हमें यह निर्धारित करने की आवश्यकता है कि हमारे पिक्सेल विंडो पार कितने नमूने हैं। पहले हमें निम्नलिखित की आवश्यकता है:

4 टेक्सल्स की तुलना में पिक्सेल विंडो की सापेक्ष स्थिति की गणना करें।
हमारे पिक्सेल विंडो के साथ टेक्सल्स प्राप्त करें।

हमारा कार्यान्वयन ओपनजीएल पर आधारित है, इसलिए बनावट स्थान की उत्पत्ति बाईं ओर से शुरू होती है। चलो पिक्सेल विंडो की सापेक्ष स्थिति की गणना करके शुरू करते हैं। पिक्सेल शेडर के लिए दिया गया यूवी समन्वय पिक्सेल के केंद्र का यूवी समन्वय है। यह मानते हुए कि UVs को सामान्यीकृत किया जाता है, हम सबसे पहले UVs को टेक्सल स्पेस में बनावट के आकार से गुणा करके परिवर्तित कर सकते हैं। पिक्सेल के केंद्र से 0.5 को घटाकर, हमें पिक्सेल विंडो के निचले बाएं कोने मिलते हैं। इस मान को नीचे से गोल करके, हम बाएं निचले टेक्सल की निचली स्थिति की गणना करते हैं। छवि इन तीन बिंदुओं के उदाहरण को दिखाती है:

पिक्सेल के निचले बाएँ कोने और टेक्सल ग्रिड के निचले बाएँ कोने के बीच का अंतर सामान्य निर्देशांक में पिक्सेल विंडो की सापेक्ष स्थिति है। इस छवि में, पिक्सेल विंडो की स्थिति [0.69, 0.37] होगी। कोड में:

vec2 bottomLeftPixelPos = uv * size -0.5;
vec2 bottomLeftTexelPos = floor(bottomLeftPixelPos);
vec2 weigth = bottomLeftPixelPos - bottomLeftTexelPos;

बनावट निर्देश का उपयोग करके, हम एक बार में चार टेक्सल्स प्राप्त कर सकते हैं। यह केवल ओपनजीएल 4.0 और उच्चतर में उपलब्ध है, इसलिए आप इसके बजाय चार टेक्सेलफच चला सकते हैं। यदि हम सिर्फ टेक्सचर इकट्ठा करते हैं UV-निर्देशांक, तो टेक्सल के साथ पिक्सेल विंडो के एक परिपूर्ण मैच के साथ, एक समस्या उत्पन्न होगी:

यहाँ हम एक पिक्सेल विंडो (नीले रंग में दिखाया गया है) के साथ तीन क्षैतिज टेक्सल्स देखते हैं जो बिल्कुल केंद्रीय टेक्सल से मेल खाते हैं। गणना की गई वजन 1.0 के करीब है, लेकिन बनावट के बजाय केंद्र और सही टेक्सल्स को चुना। कारण यह है कि बनावट के आधार पर की गई गणना फ़्लोटिंग पॉइंट वज़न की गणना से थोड़ी भिन्न हो सकती है। GPU गणना और फ्लोटिंग पॉइंट वेट गणनाओं को राउंड करने में अंतर पिक्सेल केंद्रों के आसपास glitches में परिणाम देता है।

इस समस्या को हल करने के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि वजन की गणना को बनावट के नमूने से मिलान करने की गारंटी है। ऐसा करने के लिए, हम कभी भी पिक्सेल केंद्रों का नमूना नहीं लेंगे, और इसके बजाय, हम हमेशा 2 × 2 टेक्सल ग्रिड के केंद्र में नमूना करेंगे। गणना की गई और पहले से ही बाईं ओर स्थित निचले तल के नीचे की स्थिति से, हम पूर्ण ग्रंथि को जोड़ते हैं, ताकि ग्रंथिका ग्रिड के केंद्र में पहुंच सकें।

यह छवि दिखाती है कि टेक्सल ग्रिड के केंद्र का उपयोग करते हुए, टेक्सचरगैथर द्वारा लिए गए चार नमूने बिंदु हमेशा टेक्सल्स के केंद्र में होंगे। कोड में:

vec2 centerTexelPos = (bottomLeftTexelPos + vec2(1.0, 1.0)) / size;
uvec4 result = textureGather(fontSampler, centerTexelPos, 0);

पिक्सेल खिड़की क्षैतिज मुखौटा

हमें चार टेक्सल्स मिले और उन्होंने मिलकर 8 × 8 कवरेज बिट्स का एक ग्रिड तैयार किया। बिट्स को पिक्सेल विंडो में गिनने के लिए, हमें पहले पिक्सेल विंडो के बाहर बिट्स को रीसेट करना होगा। ऐसा करने के लिए, हम एक पिक्सेल विंडो मास्क बनाएंगे और बिटवाइंड और पिक्सेल मास्क और टेक्सल कवरेज मास्क के बीच प्रदर्शन करेंगे। क्षैतिज और ऊर्ध्वाधर मास्किंग अलग-अलग किए जाते हैं।

क्षैतिज पिक्सेल मास्क क्षैतिज वजन के साथ बढ़ना चाहिए, जैसा कि इस एनीमेशन में दिखाया गया है:

छवि एक 8-बिट मुखौटा दिखाती है जिसमें 0x0F0 मान के साथ दाईं ओर स्थानांतरण होता है (बाईं ओर शून्य डाला जाता है)। एनीमेशन में, एक मुखौटा रैखिक रूप से वजन के साथ एनिमेटेड है, लेकिन वास्तव में, एक बिट शिफ्ट एक कदम-दर-चरण ऑपरेशन है। जब पिक्सेल विंडो नमूने की सीमा को पार कर जाती है, तो मुखौटा मूल्य बदल जाता है। अगले एनीमेशन में, यह लाल और हरे रंग के कॉलम में दिखाया गया है, एनिमेटेड स्टेप बाय स्टेप। मान तभी बदलता है जब नमूनों के केंद्र प्रतिच्छेद करते हैं:

केवल सेल के केंद्र में मास्क को स्थानांतरित करने के लिए, लेकिन इसके किनारों पर नहीं, एक साधारण गोलाई पर्याप्त है:

unsigned int pixelMask = 0x0F0 >> int(round(weight.x * 4.0));

अब हमारे पास दो टेक्सल्स वाले पूरे 8-बिट स्ट्रिंग का पिक्सेल मास्क है। यदि हम अपने 16-बिट कवरेज मास्क में सही प्रकार का भंडारण चुनते हैं, तो बाएं और दाएं टेक्सल को मिलाने और एक समय में पूर्ण 8-बिट लाइन के लिए क्षैतिज पिक्सेल मास्किंग करने के तरीके हैं। हालांकि, यह ऊर्ध्वाधर मास्किंग के साथ समस्याग्रस्त हो जाता है जब हम घुमाए गए ग्रिड में जाते हैं। इसलिए, इसके बजाय, हम दो 32-बिट कवरेज मास्क बनाने के लिए एक-दूसरे के दो बाएं टेबल्स और अलग-अलग दो राइट टेक्सल्स के साथ संयोजन करते हैं। हम बाएं और दाएं परिणामों को अलग-अलग मुखौटा करते हैं।

बाएं टेक्सल्स के लिए मास्क पिक्सेल मास्क के ऊपरी 4 बिट्स का उपयोग करते हैं, और दाएं टेक्सल्स के लिए मास्क निचले 4 बिट्स का उपयोग करते हैं। एक समान ग्रिड में, प्रत्येक पंक्ति में एक ही क्षैतिज मुखौटा होता है, इसलिए हम बस प्रत्येक पंक्ति के लिए मास्क की प्रतिलिपि बना सकते हैं, जिसके बाद क्षैतिज मुखौटा तैयार हो जाएगा:

unsigned int leftRowMask = pixelMask >> 4;
unsigned int rightRowMask = pixelMask & 0xF;
unsigned int leftMask = (leftRowMask << 12) | (leftRowMask << 8) | (leftRowMask << 4) | leftRowMask;
unsigned int rightMask = (rightRowMask << 12) | (rightRowMask << 8) | (rightRowMask << 4) | rightRowMask;

मास्क करने के लिए, हम दो बाएं टेक्सल्स और दो राइट टेक्सल्स को मिलाते हैं, और फिर क्षैतिज रेखाओं को मास्क करते हैं:

unsigned int left = ((topLeft & leftMask) << 16) | (bottomLeft & leftMask);
unsigned int right = ((topRight & rightMask) << 16) | (bottomRight & rightMask);

अब परिणाम इस तरह दिख सकता है:

हम पहले से ही बिटकॉइन अनुदेश का उपयोग करके इस परिणाम के बिट्स की गणना कर सकते हैं। हमें 16 नहीं, बल्कि 32 से भाग देना चाहिए, क्योंकि वर्टिकल मास्किंग के बाद भी हमारे पास 32 संभावित बिट्स हो सकते हैं, और 16 नहीं। यहां इस स्तर पर ग्लिफ़ का पूरा प्रतिपादन है:

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

ऊर्ध्वाधर मास्किंग

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

हम दो टेक्सल्स की पूरी ऊंचाई को कवर करते हुए एक सिंगल मास्क बनाएंगे। नतीजतन, हम टेक्सल्स की चार पूर्ण लाइनों को बचाना चाहते हैं और बाकी सभी को मुखौटा करते हैं, अर्थात, मुखौटा 4 × 4 बिट्स होगा, जो 0xFFFF के बराबर है। पिक्सेल विंडो की स्थिति के आधार पर, हम नीचे की पंक्तियों को स्थानांतरित करते हैं और शीर्ष रेखाओं को साफ़ करते हैं।

int shiftDown = int(round(weightY * 4.0)) * 4;
left = (left >> shiftDown) & 0xFFFF;
right = (right >> shiftDown) & 0xFFFF;

नतीजतन, हमने पिक्सेल विंडो के बाहर ऊर्ध्वाधर बिट्स को भी मास्क किया:

अब हमारे लिए टेक्सल्स में छोड़े गए बिट्स को गिनना पर्याप्त है, जिसे बिटकॉइन ऑपरेशन के साथ किया जा सकता है, फिर परिणाम को 16 से विभाजित करें और वांछित छाया प्राप्त करें!

float shade = (bitCount(left) + bitCount(right)) / 16.0;

अब पत्र का पूरा प्रस्तुतिकरण इस तरह दिखता है:

जारी रखने के लिए ...

दूसरे भाग में, हम अगला कदम उठाएंगे और देखेंगे कि आप इस तकनीक को घुमाए हुए ग्रिड पर कैसे लागू कर सकते हैं। हम इस योजना की गणना करेंगे:

और हम देखेंगे कि लगभग सभी को कई तालिकाओं तक घटाया जा सकता है।

बनावट की समस्या को सुलझाने में उनकी मदद के लिए सेबस्टियन ऑलटोनन ( @ सिब्लेटन ) और निश्चित रूप से माइकल वान डेर लेउ ( @MvdleeuwGG ) को उनके विचारों और शाम को दिलचस्प बातचीत के लिए धन्यवाद ।

कवरेज मास्क, भाग 1 का उपयोग करके फेंडर रेंडर करना