डिज्नी कार्टून "मोआना" से एक दृश्य के प्रतिपादन का अनुकूलन। भाग ४ और ५

मेरे पास एक pbrt शाखा है, जिसका उपयोग मैं नए विचारों का परीक्षण करने के लिए करता हूं, वैज्ञानिक लेखों से दिलचस्प विचारों को लागू करता हूं, और सामान्य तौर पर उन सभी का अध्ययन करने के लिए जो आमतौर पर शारीरिक रूप से आधारित प्रतिपादन पुस्तक के एक नए संस्करण का परिणाम है। Pbrt-v3 के विपरीत, जिसे हम पुस्तक में वर्णित प्रणाली के जितना संभव हो उतना करीब रखने का प्रयास करते हैं, इस धागे में हम कुछ भी बदल सकते हैं। आज हम देखेंगे कि डिज्नी कार्टून "मोआना" से द्वीप के साथ दृश्य में स्मृति के उपयोग को कैसे कम किया जाएगा।

कार्यप्रणाली पर ध्यान दें: पिछले तीन पदों में, सभी आँकड़े उस दृश्य के WIP संस्करण (वर्क इन प्रोग्रेस) के लिए मापा गया था, जिसके रिलीज से पहले मैंने काम किया था। इस लेख में, हम अंतिम संस्करण पर आगे बढ़ेंगे, जो थोड़ा अधिक जटिल है।

मोआना से अंतिम द्वीप दृश्य का प्रतिपादन करते समय, 81 GB RAM का उपयोग pbrt-v3 के दृश्य विवरण को संग्रहीत करने के लिए किया गया था। वर्तमान में, pbrt-next 41 GB का उपयोग करता है - लगभग आधा। इस परिणाम को प्राप्त करने के लिए, छोटे बदलाव करने के लिए पर्याप्त था जो कोड की कई सौ लाइनों में फैला हुआ था।

प्राइमरी को कम किया

आइए याद रखें कि pbrt में Primitive ज्यामिति, इसकी सामग्री, विकिरण फ़ंक्शन (यदि यह एक प्रकाश स्रोत है) का संयोजन है और सतह के अंदर और बाहर पर्यावरण के बारे में रिकॉर्ड करता है। Pbrt-v3 में, GeometricPrimitive निम्नलिखित को संग्रहीत करता है:

  std::shared_ptr<Shape> shape; std::shared_ptr<Material> material; std::shared_ptr<AreaLight> areaLight; MediumInterface mediumInterface; 

जैसा कि पहले कहा गया है , अधिकांश समय areaLight nullptr , और MediumInterface में MediumInterface एक जोड़ी है। इसलिए pbrt-next में मैंने SimplePrimitive नामक एक Primitive विकल्प जोड़ा, जो केवल ज्यामिति और सामग्री को संकेत देता है। जहां संभव हो, इसका उपयोग GeometricPrimitive बजाय GeometricPrimitive संभव हो:

 class SimplePrimitive : public Primitive { // ... std::shared_ptr<Shape> shape; std::shared_ptr<Material> material; }; 

गैर-एनिमेटेड ऑब्जेक्ट इंस्टेंसेस के लिए, अब हमारे पास TransformedPrimitive , जो केवल प्रिमिटिव और ट्रांसफॉर्मेशन के लिए एक पॉइंटर को स्टोर करता है, जो हमें लगभग 500 बाइट की बर्बादी की जगह बचाता है जिसे AnimatedTransform इंस्टेंस को TransformedPrimitive रेंडरर pbrt-v3 में जोड़ा गया है।

 class TransformedPrimitive : public Primitive { // ... std::shared_ptr<Primitive> primitive; std::shared_ptr<Transform> PrimitiveToWorld; }; 

(यदि आपको pbrt-next में एनिमेटेड रूपांतरण की आवश्यकता है, तो AnimatedPrimitive है।)

इन सभी परिवर्तनों के बाद, आंकड़े बताते हैं कि केवल 7.8 जीबी का उपयोग Primitive तहत किया जाता है, इसके बजाय 28.9 जीबी का उपयोग pbrt-v3 में किया जाता है। हालांकि यह बहुत अच्छा है कि हमने 21 जीबी बचा लिया, यह इतना कम नहीं है जितना कि हम पिछले अनुमानों से उम्मीद कर सकते हैं; हम इस भाग के अंत में इस विसंगति पर लौटेंगे।

कम ज्यामिति

इसके अलावा, pbrt-next ने ज्यामिति द्वारा कब्जा की गई मेमोरी की मात्रा को काफी कम कर दिया: मेष त्रिकोण के लिए उपयोग की जाने वाली जगह 19.4 जीबी से घटकर 9.9 जीबी हो गई, और 1.4 से 1.1 जीबी तक घटता है। बस इस आधे से अधिक बचत आधार Shape क्लास को सरल बनाने से हुई।

Pbrt-v3 में, Shape साथ कई सदस्यों को लाता है जो सभी Shape कार्यान्वयन को पूरा करते हैं - ये कई ऐसे पहलू हैं जो Shape कार्यान्वयन में उपयोग करने के लिए सुविधाजनक हैं।

 class Shape { // .... const Transform *ObjectToWorld, *WorldToObject; const bool reverseOrientation; const bool transformSwapsHandedness; }; 

यह समझने के लिए कि इन सदस्य चर समस्याओं का कारण क्यों हैं, यह समझने में मदद मिलेगी कि त्रिकोण के मलबे का प्रतिनिधित्व कैसे किया जाता है। सबसे पहले, TriangleMesh वर्ग है, जो पूरे जाल के लिए कोने और सूचकांक बफ़र्स को संग्रहीत करता है:

 struct TriangleMesh { int nTriangles, nVertices; std::vector<int> vertexIndices; std::unique_ptr<Point3f[]> p; std::unique_ptr<Normal3f[]> n; // ... }; 

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

 class Triangle : public Shape { // ... std::shared_ptr<TriangleMesh> mesh; const int *v; }; 

जब Triangle क्रियान्वयन को अपने शीर्ष के पदों को खोजने की आवश्यकता होती है, तो यह त्रिभुजमेश से प्राप्त करने के लिए संबंधित अनुक्रमण करता है।

Shape pbrt-v3 के साथ समस्या यह है कि इसमें संग्रहीत मान मेष के सभी त्रिकोणों के लिए समान हैं, इसलिए उन्हें त्रिभुजमेश में प्रत्येक पूरे जाल से बचाने के लिए बेहतर है, और फिर सामान्य मानों की एकल प्रति में Triangle पहुंच प्रदान करें।

यह समस्या pbrt-next में तय की गई थी: pbrt-next में आधार Shape क्लास में ऐसे सदस्य नहीं होते हैं, और इसलिए प्रत्येक Triangle 24 बाइट्स कम होता है। ज्यामिति Curve एक समान रणनीति का उपयोग करता है और अधिक कॉम्पैक्ट Shape से भी लाभान्वित होता है।

साझा त्रिकोण बफ़र्स

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

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

क्रैश के साथ std :: साझा किया गया

इन सभी परिवर्तनों के बाद, आँकड़े 36 जीबी की ज्ञात आवंटित मेमोरी के बारे में रिपोर्ट करते हैं, और रेंडरिंग की शुरुआत में, top 53 जीबी के उपयोग को इंगित करता है। प्रकरण।

मुझे massif की धीमी गति की एक और श्रृंखला से डर था कि यह पता लगाने के लिए कि आंकड़ों में कौन सी आवंटित स्मृति गायब है, लेकिन फिर मेरे इनबॉक्स में आर्सेनी कपुलकिन का एक पत्र दिखाई दिया। आर्सेनी ने मुझे समझाया कि मेरे GeometricPrimitive स्मृति उपयोग के पिछले अनुमान बहुत गलत थे। मुझे लंबे समय तक इसका पता लगाना पड़ा, लेकिन तब मुझे एहसास हुआ; त्रुटि और विस्तृत स्पष्टीकरण के लिए आर्सेनी को बहुत धन्यवाद।

आर्सेनी को लिखने से पहले, मैंने std::shared_ptr के कार्यान्वयन की कल्पना की std::shared_ptr किया गया: इस रूप में std::shared_ptr किया: इन पंक्तियों में एक सामान्य वर्णनकर्ता है जो संदर्भ गणना और एक संकेतक को स्वयं रखी गई वस्तु को संग्रहीत करता है:

 template <typename T> class shared_ptr_info { std::atomic<int> refCount; T *ptr; }; 

तब मैंने सुझाव दिया कि shared_ptr इंस्टेंस केवल इसे इंगित करता है और इसका उपयोग करता है:

 template <typename T> class shared_ptr { // ... T *operator->() { return info->ptr; } shared_ptr_info<T> *info; }; 

संक्षेप में, मैंने मान लिया कि sizeof(shared_ptr<>) पॉइंटर के आकार के समान है, और प्रत्येक साझा पॉइंटर पर अतिरिक्त स्थान का 16 बाइट बर्बाद हो जाता है।

लेकिन ऐसा है नहीं।

मेरे सिस्टम के कार्यान्वयन में, सामान्य डिस्क्रिप्टर आकार में 32 बाइट्स और आकार में 16 बाइट्स sizeof(shared_ptr<>) । इसलिए, GeometricPrimitive , जिसमें मुख्य रूप से std::shared_ptr , मेरे अनुमानों से लगभग दोगुना है। यदि आप सोच रहे हैं कि ऐसा क्यों हुआ, तो ये दो स्टैक ओवरफ्लो पोस्ट महान विस्तार से कारण बताते हैं: 1 और 2 ।

लगभग सभी मामलों में, pbrt-next में std::shared_ptr का उपयोग करने के मामले में, उन्हें साझा पॉइंटर्स साझा करने की आवश्यकता नहीं है। क्रेजी हैकिंग करते हुए, मैंने सब कुछ बदल दिया जो मैं std::unique_ptr साथ कर सकता था, जिसका वास्तव में एक नियमित पॉइंटर के समान आकार है। उदाहरण के लिए, यहाँ SimplePrimitive अब जैसा दिखता SimplePrimitive :

 class SimplePrimitive : public Primitive { // ... std::unique_ptr<Shape> shape; const Material *material; }; 

इनाम मेरी अपेक्षा से अधिक हो गया: प्रतिपादन की शुरुआत में मेमोरी का उपयोग 53 जीबी से घटकर 41 जीबी हो गया - 12 जीबी की बचत, कुछ दिनों पहले पूरी तरह से अप्रत्याशित, और कुल राशि लगभग आधी है जो कि pbrt-v3 द्वारा उपयोग की जाती है। बहुत बढ़िया!

अगले भाग में, हम अंत में लेखों की इस श्रृंखला को पूरा करेंगे - इस दृश्य में आवश्यक स्मृति की मात्रा को कम करने के लिए pbrt-next में प्रतिपादन की गति की जांच करें और अन्य तरीकों के लिए विचारों पर चर्चा करें।

भाग 5

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

रेंडरिंग टाइम

Pbrt-next ने लाइट ट्रांसफर एल्गोरिदम में कई बदलाव किए, जिसमें बीएसडीएफ सैंपलिंग में बदलाव और रूसी रूले एल्गोरिदम में सुधार शामिल हैं। नतीजतन, यह इस दृश्य को प्रस्तुत करने के लिए pbrt-v3 की तुलना में अधिक किरणों का पता लगाता है, इसलिए इन दो रेंडरर्स के निष्पादन समय की सीधे तुलना करना संभव नहीं है। गति आम तौर पर एक महत्वपूर्ण अपवाद के साथ होती है: जब मोआना से एक द्वीप दृश्य का प्रतिपादन किया जाता है, तो नीचे दिखाया गया है, pbrt-v3 निष्पादन समय का 14.5% ptex बनावट के लिए खोज करता है। यह मुझे काफी सामान्य लगता था, लेकिन निष्पादन के समय में केवल 2.2% ही pbrt-next खर्च होता है। यह सब बहुत दिलचस्प है।

आँकड़ों का अध्ययन करने के बाद, हमें ¹ मिलता है:

pbrt-v3:
Ptex 20828624
Ptex 712324767

pbrt-next:
Ptex 3378524
Ptex 825826507

जैसा कि हम pbrt-v3 में देखते हैं, प्रत्येक 34 बनावट खोजों में ptex बनावट को डिस्क से औसतन पढ़ा जाता है। Pbrt-next में, यह हर 244 खोजों के बाद ही पढ़ा जाता है - अर्थात, डिस्क I / O लगभग 7 गुना कम हो गया है। मैंने सुझाव दिया कि ऐसा इसलिए होता है क्योंकि pbrt-next अप्रत्यक्ष किरणों के लिए किरण के अंतरों की गणना करता है, और इससे बनावट के उच्च MIP स्तरों तक पहुंच बनती है, जो बदले में ptex बनावट कैश तक अधिक एकीकृत श्रृंखला बनाता है, कैश मिस की संख्या कम कर देता है, और इसलिए I / O ऑपरेशन ² की संख्या। एक संक्षिप्त जाँच ने मेरे अनुमान की पुष्टि की: जब बीम अंतर को बंद कर दिया गया था, तो ptex की गति बहुत खराब हो गई थी।

Ptex की गति में वृद्धि ने न केवल कंप्यूटिंग की लागत और I / O को प्रभावित किया है। 32-सीपीयू प्रणाली में, pbrt-v3 केवल दृश्य विवरण को पार्स करने के बाद 14.9 बार त्वरित होता है। pbrt आमतौर पर रैखिक समानांतर स्केलिंग के करीब दिखाता है, इसलिए इसने मुझे बहुत निराश किया। Ptex में ताले के दौरान बहुत कम संघर्षों के कारण, pbrt-next संस्करण 32 CPUs के साथ सिस्टम में 29.2 गुना तेज और 96 CPUs के साथ सिस्टम में 94.9 गुना तेज था - हम उन संकेतकों पर वापस आ गए हैं जो हमारे साथ हैं।


मोआँ द्वीप दृश्य से जड़ें प्रति पिक्सेल 256 नमूनों पर 2048x858 के संकल्प के साथ मवाद द्वारा प्रस्तुत की गई हैं। Pbrt-next में 2 GHz की आवृत्ति के साथ 96 वर्चुअल CPU के साथ Google कंप्यूट इंजन उदाहरण पर कुल रेंडरिंग का समय 41 मिनट 22 s है। प्रतिपादन के दौरान मौलिथिंग के कारण त्वरण 94.9 गुना था। (मैं काफी समझ में नहीं आता कि बंप मैपिंग के साथ क्या हो रहा है।)

भविष्य के लिए काम करें

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

आगे चलकर त्रिकोण बफर मेमोरी

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

टाइप	स्मृति
लाइन आइटम	2.5 जीबी
normals	2.5 जीबी
यूवी	98 एमबी
सूचकांक	252 एमबी

मैं समझता हूं कि प्रेषित शीर्ष पदों के साथ कुछ भी नहीं किया जा सकता है, लेकिन अन्य डेटा के लिए बचत है। मेमोरी-कुशल रूप में सामान्य वैक्टरों के कई प्रकार के निरूपण हैं जो मेमोरी साइज / गणनाओं की संख्या के बीच विभिन्न ट्रेड-ऑफ प्रदान करते हैं। 24-बिट या 32-बिट अभ्यावेदन में से किसी एक का उपयोग करने से मानदंड से 663 एमबी और 864 एमबी तक का स्थान कम हो जाएगा, जो हमें 1.5 जीबी से अधिक रैम बचाएगा।

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

अन्य दृश्यों के लिए, बनावट के 16-बिट यूवी निर्देशांक का नमूनाकरण करना या उनके मूल्यों की सीमा के आधार पर आधे-सटीक फ्लोट मान का उपयोग करना, काफी उपयुक्त हो सकता है। ऐसा लगता है कि इस दृश्य में, सभी बनावट समन्वय मूल्य शून्य या एक हैं, जिसका अर्थ है कि उन्हें एक बिट द्वारा दर्शाया जा सकता है - अर्थात, 32 बार से कब्जे वाली स्मृति को कम करना संभव है। मामलों की यह स्थिति संभवत: बनावट के लिए ptex प्रारूप के उपयोग के कारण उत्पन्न हुई, जो यूवी atlases की आवश्यकता को समाप्त करती है। वर्तमान में बनावट के निर्देशांक द्वारा कब्जा की गई छोटी राशि को देखते हुए, इस अनुकूलन का कार्यान्वयन विशेष रूप से आवश्यक नहीं है।

pbrt हमेशा सूचकांक बफ़र्स के लिए 32-बिट पूर्णांक का उपयोग करता है। 256 कोने से कम के छोटे जालों के लिए, प्रति सूचकांक केवल 8 बिट्स पर्याप्त हैं, और 65,536 से कम कोने वाले मेषों के लिए, 16 बिट्स का उपयोग किया जा सकता है। इसे इस प्रारूप में बदलने के लिए pbrt को बदलना बहुत मुश्किल नहीं होगा। यदि हम अधिकतम का अनुकूलन करना चाहते हैं, तो हम सूचकांकों में आवश्यक सीमा का प्रतिनिधित्व करने के लिए आवश्यक बिट्स का चयन कर सकते हैं, जबकि कीमत उनके मूल्यों को खोजने की जटिलता को बढ़ाने के लिए होगी। इस तथ्य के बावजूद कि अब मेमोरी के एक गीगाबाइट का केवल एक चौथाई हिस्सा शीर्ष सूचकांक के लिए उपयोग किया जाता है, यह कार्य दूसरों की तुलना में बहुत दिलचस्प नहीं लगता है।

पीक बीवीएच मेमोरी उपयोग का निर्माण करते हैं

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

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

पॉइंटर्स को पूर्णांक में बदलें

विभिन्न डेटा संरचनाओं में, कई 64-बिट पॉइंटर्स हैं जिन्हें 32-बिट पूर्णांक के रूप में दर्शाया जा सकता है। उदाहरण के लिए, प्रत्येक SimplePrimitive में एक Material लिए एक सूचक होता है। Material अधिकांश उदाहरण दृश्य में कई प्रधानता के लिए सामान्य हैं और कुछ हजार से अधिक कभी नहीं होते हैं; इसलिए, हम सभी सामग्रियों के एकल वैश्विक वेक्टर vector स्टोर कर सकते हैं:

 std::vector<Material *> allMaterials; 

और SimplePrimitive में इस वेक्टर के लिए सिर्फ 32-बिट पूर्णांक ऑफसेट स्टोर करें, जो हमें 4 बाइट्स बचाता है। प्रत्येक Triangle में Triangle के साथ-साथ कई अन्य स्थानों पर भी इसी ट्रिक को पॉइंटर के साथ प्रयोग किया जा सकता है।

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

एरेनास (क्षेत्रों) के आधार पर आवास

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

खाकी वंदनीय

मेरा अंतिम विचार भयानक है, और मैं इसके लिए माफी मांगता हूं, लेकिन उसने मुझे धमकी दी।

दृश्य में प्रत्येक त्रिभुज में कम से कम दो SimplePrimitive का एक अतिरिक्त भार होता है: एक Triangle , और दूसरा SimplePrimitive । यह 16 बाइट्स है। मोआना द्वीप दृश्य में कुल 162 162 124 अद्वितीय त्रिभुज हैं, जो लगभग 2.2 जीबी बेमानी संकेत को जोड़ता है।

क्या होगा अगर हमारे पास Shape और प्रत्येक ज्यामिति कार्यान्वयन के लिए एक सार आधार वर्ग नहीं था, जो कुछ भी विरासत में नहीं मिला? यह हमें व्यवहार्य बिंदुओं पर जगह बचाता है, लेकिन, निश्चित रूप से, जब एक सूचक को एक ज्यामिति में पारित किया जाता है, तो हमें नहीं पता होगा कि यह किस प्रकार की ज्यामिति है, अर्थात यह बेकार होगा।

यह पता चला है कि आधुनिक x86 सीपीयू पर , 64-बिट पॉइंटर्स के केवल 48 बिट्स वास्तव में उपयोग किए जाते हैं । इसलिए, अतिरिक्त 16 बिट्स हैं जिन्हें हम कुछ जानकारी संग्रहीत करने के लिए उधार ले सकते हैं ... उदाहरण के लिए, जैसे कि हम जिस ज्यामिति की ओर इशारा कर रहे हैं। बदले में, थोड़ा सा काम जोड़कर, हम वर्चुअल फ़ंक्शंस पर कॉल का एनालॉग बनाने की संभावना पर एक रास्ता बना सकते हैं।

यहां बताया गया है कि यह कैसे होगा: सबसे पहले हम एक ShapeMethods संरचना को परिभाषित करते हैं जिसमें कार्य करने के लिए संकेत होते हैं, जैसे कि ³ :

 struct ShapeMethods { Bounds3f (*WorldBound)(void *); // Intersect, etc. ... }; 

प्रत्येक ज्यामिति कार्यान्वयन एक बाधा समारोह, एक चौराहे समारोह, और इसी तरह, this सूचक के पहले तर्क के रूप में एक एनालॉग प्राप्त करेगा:

 Bounds3f TriangleWorldBound(void *t) { //       Triangle. Triangle *tri = (Triangle *)t; // ... 

हमारे पास ShapeMethods संरचनाओं की एक वैश्विक तालिका होगी, जिसमें n n तत्व सूचकांक n के साथ एक ज्यामिति प्रकार के लिए होगा:

 ShapeMethods shapeMethods[] = { { TriangleWorldBound, /*...*/ }, { CurveWorldBound, /*...*/ }; // ... }; 

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

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

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

नोट

1. अंत में, इस दृश्य में pbrt-v3 की तुलना में pbrt-next निशान अधिक किरणों का पता लगाता है, जो संभवतः खोज कार्यों की संख्या में वृद्धि की व्याख्या करता है।
2. Pbrt-अगले में अप्रत्यक्ष किरणों के लिए किरण अंतर की गणना pbrt-v3 के लिए बनावट कैश एक्सटेंशन में उपयोग किए गए एक ही हैक का उपयोग करके की जाती है। , , .
3. Rayshade . , C . Rayshade .