👨🏽‍✈️ 🖕🏽 😍 कंकाल एनीमेशन संपीड़न गाइड 👩🏻‍🚀 🧑🏻‍🤝‍🧑🏻 🧜🏾

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

आरंभ करने से पहले, यह कंकाल एनीमेशन और इसकी कुछ बुनियादी अवधारणाओं का एक संक्षिप्त परिचय देने के लायक है।

एनीमेशन और संपीड़न की मूल बातें

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

कंकाल एनीमेशन सिर्फ (आमतौर पर) निरंतर फ्रेम दर के साथ keyframes की एक आदेशित सूची है। मुख्य फ्रेम कंकाल मुद्रा है। यदि हम कीफ्रेम के बीच एक मुद्रा प्राप्त करना चाहते हैं, तो हम दोनों केफ्रेम का मिश्रण करते हैं और उनके बीच मिश्रण करते हैं, मिश्रण के वजन के रूप में उनके बीच के समय का अंश का उपयोग करते हैं। नीचे दी गई छवि 30fps पर बनाए गए एनीमेशन को दिखाती है। एनीमेशन में कुल 5 फ्रेम हैं और हमें शुरुआत के बाद 0.52 s प्राप्त करने की आवश्यकता है। इसलिए, हमें फ्रेम 1 में मुद्रा और फ्रेम 2 में मुद्रा का नमूना लेने की आवश्यकता है, और फिर उनके बीच लगभग 57% के मिश्रण वजन के साथ मिश्रण करें।

5 फ़्रेमों के एनीमेशन का एक उदाहरण और एक मध्यवर्ती फ़्रेम समय में मुद्रा के लिए एक अनुरोध

ऊपर जानकारी होने और उस स्मृति पर विचार करना हमारे लिए कोई समस्या नहीं है, मुद्रा की अनुक्रमिक बचत एनीमेशन को संग्रहीत करने का आदर्श तरीका होगा, जैसा कि नीचे दिखाया गया है।

सरल एनीमेशन डेटा भंडारण

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

इस दृष्टिकोण के साथ समस्या यह है कि यह बहुत बड़ी मात्रा में मेमोरी लेता है, खासकर उन खेलों में जहां 95% डेटा के लिए निम्न स्थितियां सत्य हैं।

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

इस सब को ध्यान में रखते हुए, यदि आप मूल डेटा प्रारूप को देखते हैं, तो आप देख सकते हैं कि यह स्मृति खर्च करने में कितना अक्षम है। हम प्रत्येक हड्डी के विस्थापन और पैमाने के मूल्यों की नकल करते हैं, भले ही वे बदल न जाएं। और स्थिति जल्दी से हाथ से निकल रही है। आमतौर पर, एनिमेटर 30fps की आवृत्ति पर एनिमेशन बनाते हैं, और एएए-स्तरीय गेम में, एक चरित्र में आमतौर पर लगभग 100 हड्डियां होती हैं। इस जानकारी और 8 फ़्लोट के प्रारूप के आधार पर, हमें परिणामस्वरूप 3 केबी प्रति पोज़ और 94 केबी प्रति सेकेंड एनीमेशन की आवश्यकता होती है। मान तेजी से जमा होते हैं और कुछ प्लेटफार्मों पर आसानी से सभी मेमोरी को रोक सकते हैं।

तो चलो संपीड़न के बारे में बात करते हैं; डेटा को संपीड़ित करने का प्रयास करते समय, विचार करने के कई पहलू हैं:

दबाव अनुपात
- कब्जे वाली मेमोरी की मात्रा को कम करने के लिए हमने कितना प्रबंधन किया
गुणवत्ता
- स्रोत डेटा से हमने कितनी जानकारी खो दी
संपीड़न दर
- .

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

यह भी ध्यान रखना बेहद महत्वपूर्ण है कि आपको प्रदर्शन पर एनीमेशन संपीड़न के प्रभाव को कम नहीं करना चाहिए: मेरी पिछली परियोजनाओं में से एक में, नमूना दर लगभग 35% कम हो गई, और कुछ गुणवत्ता की समस्याएं भी थीं।

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

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

डेटा विवेकाधिकार

इस खंड के लगभग सभी एक सिद्धांत को कम किया जा सकता है: डेटा को विवेकाधीन करें।

विवेक कहना एक कठिन तरीका है कि हम मूल्य को निरंतर अंतराल से मूल्यों के असतत सेट में बदलना चाहते हैं।

विवेकाधीन फ्लोट

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

एक 32-बिट फ्लोट को एक अहस्ताक्षरित 16-बिट पूर्णांक के नमूने का एक उदाहरण

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

मैं स्रोत कोड का उदाहरण नहीं दूंगा, क्योंकि बुनियादी नमूना संचालन करने के लिए एक काफी सुविधाजनक और सरल पुस्तकालय है, जो इस विषय पर एक अच्छा स्रोत है: https://github.com/r-lyeh-archived/quant (मैं कहूंगा कि आप इसके चतुर्भुज विवेकाधीन फ़ंक्शन का उपयोग न करें, लेकिन बाद में इस पर अधिक)।

चतुर्धातुक संपीड़न

चतुर्धातुक संपीड़न एक अच्छी तरह से अध्ययन किया गया विषय है, इसलिए मैं अन्य लोगों को बेहतर तरीके से समझाए जाने वाले कार्यों को नहीं दोहराऊंगा। यहां एक स्नैपशॉट संपीड़न पोस्ट का लिंक दिया गया है जो इस विषय पर सबसे अच्छा विवरण प्रदान करता है: https://gafferongames.com/post/snapshot_compression/ ।

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

सैंपलिंग के कारण डाउनसाइज़ करना

इससे पहले कि हम विभिन्न संपीड़न विधियों और अभिलेखों की व्यवस्था पर विचार करना शुरू करें, आइए देखें कि यदि हम मूल सर्किट में विवेकाधिकार को लागू करते हैं तो हमें किस प्रकार का संपीड़न मिलता है। हम पहले के रूप में एक ही उदाहरण का उपयोग करेंगे (100 हड्डियों का एक कंकाल), इसलिए यदि हम 48 बिट्स (3 x 16 बिट्स) प्रति चतुर्थांश, 48 बिट्स (3 × 16) को स्थानांतरित करने के लिए और 16 बिट्स को स्केल करने के लिए उपयोग करते हैं, तो रूपांतरण के लिए कुल में हमें 32 बाइट्स के बजाय 14 बाइट्स की आवश्यकता है। यह मूल आकार का 43.75% है। यही है, 30FPS की आवृत्ति के साथ एनीमेशन के 1 सेकंड के लिए, हमने वॉल्यूम को 94 KB से घटाकर लगभग 41 KB कर दिया।

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

रिकॉर्ड संपीड़न

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

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

हड्डियों के डेटा को रिकॉर्ड के रूप में

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

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

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

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

इन सभी पहलुओं का खुलासा Riot / BitSquid और निकोलस के पदों में किया गया है (मेरे लेख की शुरुआत में लिंक देखें)। मैं उनके बारे में विस्तार से बात नहीं करूंगा। इसके बजाय, मैं उन बातों के बारे में बात करूँगा जो मैंने रिकॉर्ड्स को संपीड़ित करने के बारे में तय की थीं ...

मैंने ... रिकॉर्ड्स को संपीड़ित नहीं करने का निर्णय लिया।

इससे पहले कि आप लहराते हैं, मुझे समझाने दें ...

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

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

हमारे एनीमेशन उदाहरण में, चलती के साथ केवल दो रिकॉर्ड हैं और पैमाने के साथ कोई रिकॉर्ड नहीं हैं। फिर एनीमेशन के 1 सेकंड के लिए, डेटा की मात्रा 41 KB से घटकर 18.6 KB हो जाती है (अर्थात, मूल डेटा की मात्रा का 20% तक)। एनीमेशन की अवधि बढ़ने पर स्थिति और भी बेहतर हो जाती है, हम संसाधनों को केवल रिकॉर्डिंग मोड़ और गतिशील आंदोलनों पर खर्च करते हैं, और स्थिर रिकॉर्डिंग की लागत स्थिर रहती है, जिससे लंबे एनिमेशन में अधिक बचत होती है। और हमें नमूना लेने से होने वाली गुणवत्ता हानि का अनुभव नहीं करना है।

यह सब जानकारी को ध्यान में रखते हुए, मेरा अंतिम डेटा स्कीमा इस तरह दिखता है:

एक संकुचित एनीमेशन डेटा योजना का एक उदाहरण (प्रति रिकॉर्ड 3 फ्रेम)

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

एक मेमोरी ब्लॉक में संग्रहीत एनीमेशन डेटा के अलावा, मेरे पास प्रत्येक रिकॉर्ड के लिए संपीड़न विकल्प भी हैं:

मेरे क्रूगर इंजन से रिकॉर्ड के लिए संपीड़न मापदंडों का उदाहरण

ये पैरामीटर उन सभी डेटा को संग्रहीत करते हैं जिन्हें मुझे प्रत्येक रिकॉर्ड के नमूना मूल्यों को डीकोड करने की आवश्यकता होती है। वे रिकॉर्ड के स्थैतिक की निगरानी भी करते हैं ताकि मैं जानता हूं कि जब मैं नमूना लेते समय एक स्थिर रिकॉर्ड पर ठोकर लगाता हूं तो संपीड़ित डेटा को कैसे संभालना है।

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

जैसा कि यह हो सकता है, यहाँ एनीमेशन संपीड़न को लागू करने के मेरे बेवकूफ प्रयासों का एक संक्षिप्त सारांश है: अंत में, मैं लगभग संपीड़न का उपयोग करता हूं।