जब किसी एनीमेशन को दुनिया को छूना हो

लेखक: Oleg Sidorkin, Cinevva के सीटीओ और सह-संस्थापक

चलने का एनीमेशन जानता है कि पैर कैसे हिलते हैं। वह यह नहीं जानता कि एक पैर किसी सीढ़ी तक पहुँच गया है। हाथ बढ़ाने का एनीमेशन जानता है कि बाँह कैसे हिलती है। वह यह नहीं जानता कि यह विशेष ताले का छेद कहाँ है, या किसी ने कप को खिसका दिया है।

किसी पात्र की ऑटो-रिगिंग के बाद अगली समस्या यही है: एनीमेशन को दृश्य के अनुसार गेम चलते समय प्रतिक्रिया देने योग्य बनाना। हमने Cinevva के Three.js रनटाइम में एक प्रयोगात्मक सुधार लेयर लागू की है। यह एनीमेशन द्वारा बनाई गई मुद्रा को पढ़ती है, दृश्य से जानकारी लेती है और फ़्रेम रेंडर होने से पहले पात्र के जोड़ों को समायोजित करती है।

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

अंतर आज़माएँ

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

Open the demo in a full window ↗

हर उदाहरण में Cinevva द्वारा ऑटो-रिग किया गया वही मेंढक इस्तेमाल होता है। चलने वाला उदाहरण यूनिवर्सल एनीमेशन लाइब्रेरी का Walk चलाता है, जिसे Auto Rigger में इस्तेमाल होने वाले उसी कोड से रीटार्गेट किया गया है। दोनों व्यूपोर्ट वास्तविक क्लिप चलाते हैं; दायाँ व्यूपोर्ट रनटाइम पर भूभाग-संबंधी सुधार जोड़ता है। अन्य उदाहरण एम्बेड किया गया Idle संदर्भ और अपने इंटरैक्शन कंट्रोलर बनाए रखते हैं।

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

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

सीढ़ी पर चढ़ना एक बार में एक अंग को स्थानांतरित करता है, जबकि तीन संपर्क अपनी-अपनी डंडियों को पकड़े रहते हैं। चढ़ने वाले को दृश्य में बनाए रखने के लिए सीढ़ी नीचे जाती है। टखने और हाथ के स्पष्ट लक्ष्य संपर्कों को स्थापित करते हैं, जबकि कोहनी और घुटने के गाइड मोड़ों को सीढ़ी से दूर रखते हैं। शरीर की गति और संपर्क क्रम पहले से बनाए गए हैं; यह कोई स्वचालित चढ़ाई प्लानर नहीं है।

क्या लागू किया गया है

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

यह अपनी इच्छा से सक्षम किया जाने वाला रनटाइम प्रोटोटाइप है। इंटरैक्टिव उदाहरण इसके कार्यान्वयन को प्रदर्शित करते हैं; उनका अर्थ यह नहीं है कि Cinevva से जनरेट होने वाला हर गेम इसे अपने-आप सक्षम कर देता है।

टिके हुए पैर को एक संदर्भ फ़्रेम चाहिए

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

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

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

मेंढक ने एक अलग कैलिब्रेशन त्रुटि उजागर की: सबसे निचली उँगली का छूना यह नहीं दर्शाता कि तलवा ठीक से बैठा है। अब इसका डेमो प्रत्येक पोज़ किए गए पैर की मेश पर सहायक समतल फ़िट करता है और स्थिति तथा नॉर्मल दोनों को कैलिब्रेट करता है। रेंडर किया गया रिग्रेशन पूरे Idle के दौरान सबसे निचले सतह बिंदु के साथ-साथ तलवे के तीन अलग-अलग संपर्कों को मापता है।

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

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

चाबी को छेद में रखें, फिर हाथ का समाधान निकालें

कलाई को ताले के छेद की ओर करना पर्याप्त नहीं है। चाबी की एक लंबाई, प्रवेश अक्ष और पकड़ ऑफ़सेट होता है। कलाई अपने लक्ष्य तक पूरी तरह पहुँच जाए, तब भी चाबी का सिरा चूक सकता है।

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

पहुँच से बाहर लक्ष्य वाला उदाहरण जानबूझकर उस विफलता को प्रदर्शित करता है। मेट्रिक को सफल दिखाने के लिए अंग को खींचकर लंबा नहीं किया जाता; रनटाइम बताता है कि पात्र की स्थिति बदलनी होगी।

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

तरल उड़ेलना ओरिएंटेशन की भी समस्या है

तरल उड़ेलने वाला उदाहरण पात्र को झुकाते समय उसकी टोंटी को कप के ऊपर बनाए रखता है। पात्र के घूमने के साथ आवश्यक कलाई की स्थिति बदलती है। हाथ-लक्ष्य वाला वही तंत्र इस बदलती मुद्रा का अनुसरण करता है।

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

सुधार कहाँ चलता है

गेम में क्रम यह है:

पात्र को चलाएँ → एनीमेशन का मूल्यांकन करें → मुद्रा ऑफ़सेट लागू करें → दृश्य संपर्क हल करें → द्वितीयक गति अपडेट करें → रेंडर करें।

रनटाइम इसे वैकल्पिक sceneIK कॉन्फ़िगरेशन के साथ createAnimator के माध्यम से उपलब्ध कराता है। गेम संपर्क वेट, हाथ के लक्ष्य और ज़मीन पर होने की स्थिति को update में भेजते हैं। यह किसी मौजूदा Three.js एनीमेशन मिक्सर को रैप भी कर सकता है।

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

अंतर्निहित तकनीकों के स्थापित समकक्ष Unity के टू-बोन IK और Unreal के IK सॉल्वर में उपलब्ध हैं। हमारा कार्यान्वयन हमारे ऑटो-रिग किए गए पात्रों की आवश्यकताओं के अनुसार बनाई गई एक छोटी, इंजन-साइड सुधार लेयर है।

हमने क्या जाँचा—और क्या बाकी है

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

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

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

फ़िलहाल उपयोगी परिणाम ठोस है: कोई एनीमेशन अपनी मूल गति बनाए रखते हुए अपने पैरों और हाथों को प्रत्येक फ़्रेम में दृश्य के अनुसार प्रतिक्रिया करने दे सकता है। इससे ऑटो-रिग किए गए पात्र को अपने आसपास की दुनिया के साथ इंटरैक्ट करने का शुरुआती आधार मिलता है।