सारांश
यह आलेख बताता है कि लाइव रेंडरिंग को रेंडरर प्लग-इन में कैसे कार्यान्वित किया जा सकता है और निम्नलिखित विषयों को शामिल किया गया है:
- गुण सम्मलेन
- रेंडररइन्फो प्लग-इन फ़ंक्शन
- प्लग-इन फ़ंक्शंस प्रस्तुत करें
- पायथन उपयोगिताएँ
- लाइवरेंडरएपीआई
- लाइवरेंडरएक्शन
- कॉलबैक - पकड़ लिया
- एकल नमूना अद्यतन
- गैर सतत अद्यतन
लाइवरेंडरिंग की सामान्य व्याख्या के लिए, कृपया रेंडर प्रकार पर Katana उपयोगकर्ता गाइड अनुभाग में इसका विवरण ढूंढें, साथ ही रेंडर करने के लाइव रेंडरिंग शुरू करने और रोकने के उप-अनुभाग और लाइव रेंडरिंग को नियंत्रित करने पर अनुभाग देखें।
रेंडरर प्लग-इन के अन्य हिस्सों का विस्तृत विवरण, और रेंडरएपीआई के अन्य कार्यों का दस्तावेज़ीकरण जो सीधे लाइवरेंडरिंग से संबंधित नहीं हैं , Katana डेवलपर गाइड के रेंडरर प्लग-इन अनुभाग में पाया जा सकता है।
अधिक जानकारी
गुण सम्मलेन
Katana का लाइव रेंडरिंग सिस्टम दृश्य ग्राफ़ में विशेषताओं द्वारा संचालित है। दक्षता के नाम पर, केवल वे विशेषताएँ जो रेंडरर को अद्यतन करने के लिए आवश्यक हैं, रेंडर प्लग-इन में भेजी जाती हैं। ये कौन सी विशेषताएँ हैं यह निर्धारित करने के लिए एक विशेषता सम्मेलन है, जो इस प्रकार है:
लाइवरेंडर. <अपडेटग्रुप> । <विशेषतानाम>
<updateGroup> - यह एक GroupAttribute है जिसका उपयोग विशेषताओं को एक ही अपडेट में एक साथ समूहित करने के लिए किया जाता है।
<attributeName> - यह मॉनिटर करने के लिए शीर्ष-स्तरीय विशेषता का नाम है। ऊपर की छवि में LiveRender.geoXform.xform विशेषता लाइव रेंडर सिस्टम को शीर्ष-स्तरीय xform विशेषता में कोई भी परिवर्तन भेजने का निर्देश दे रही है। ध्यान दें कि यह एक StringAttribute है जिसका मान आमतौर पर updateGroup से मेल खाता है , यह विरासत कारणों से है, लेकिन आम तौर पर आंतरिक रूप से उपयोग नहीं किया जाता है। यदि एक ही अद्यतन समूह में एकाधिक विशेषताएँ निर्दिष्ट हैं तो उनमें से किसी एक के बदलने पर वे सभी रेंडरर को भेज दी जाएंगी।
रेंडररइन्फो प्लग-इन फ़ंक्शन
void fillLiveRenderTerminalOps( OpDefinitionQueue & terminalOps ,
const FnAttribute::GroupAttribute& stateArgs )
हालांकि नोड ग्राफ़ में उपरोक्त विशेषता कन्वेंशन को सेट करना संभव है, लाइव रेंडर शुरू होने पर विशेषताओं को स्वचालित रूप से सेट करने के लिए RendererInfo प्लग-इन में fillLiveRenderTerminalOps() फ़ंक्शन का उपयोग करना आम तौर पर अधिक उपयोगी होता है। फ़ंक्शन को टर्मिनलऑप्स नामक एक तर्क पारित किया जाता है जो एक std::deque है जिसमें op प्रकार ( std::string के रूप में) और op तर्क ( GroupAttribute के रूप में) वाले कोई भी या अधिक std::pair ऑब्जेक्ट शामिल नहीं हैं।
जैसे. नीचे दिया गया कोड /root/world/lgt के नीचे प्रकाश स्थानों की xform विशेषता में परिवर्तन पर नज़र रखता है ।
FnAttribute::GroupBuilder opArgs;
opArgs. set ( "type" , FnAttribute::StringAttribute( "light" ));
opArgs. set ( "location" , FnAttribute::StringAttribute( "/root/world/lgt" ));
opArgs. set ( "attributeNames" , FnAttribute::StringAttribute( "xform" ));
terminalOps.push_back( std ::make_pair( "LiveRenderFilter" , opArgs.build()));
Katana के साथ आने वाले कई जियोलिब3 ऑप्स यहां उपयोगी हैं:
लाइवरेंडरफ़िल्टर यह इंगित करने के लिए उपयोग किया जाता है कि लाइव रेंडरिंग के लिए किन विशेषताओं की निगरानी की जानी चाहिए। एक ही LiveRenderFilter द्वारा एकाधिक विशेषताओं की निगरानी की जा सकती है और यदि उनमें से कोई भी बदलता है तो सभी को एक ही GroupAttribute के रूप में भेजा जाएगा। यह ऊपर वर्णित लाइवरेंडर विशेषता सम्मेलन स्थापित करने का मानक तरीका है । |
OpArgs - विशेषतानाम (स्ट्रिंगएट्रिब्यूट) - परिवर्तनों के लिए विशेषताओं के नामों की निगरानी की जानी चाहिए और जब भी कोई परिवर्तन होता है तो उन्हें एकल अपडेट के रूप में रेंडर प्लग-इन पर भेजा जाना चाहिए। - स्थान (स्ट्रिंगएट्रिब्यूट) - एक सीईएल अभिव्यक्ति जो पहले स्थान को परिभाषित करती है जहां यह ऑप लागू होता है। इसके बाद इसे सभी बाल स्थानों पर लागू किया जाएगा। - बहिष्करण (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की एक सूची, जहां यह ऑप नहीं चलना चाहिए। - टाइपअलियास (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) 'टाइप' विशेषता के लिए एक नाम जो रेंडर प्लग-इन पर भेजा जाएगा। यदि सेट नहीं है तो इसके स्थान पर स्थान प्रकार का उपयोग किया जाएगा। - प्रकार (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) यदि सेट किया गया है, तो ऑप केवल इस प्रकार के स्थानों पर चलेगा। - कलेक्टअपस्ट्रीम (इंटएट्रिब्यूट) - (वैकल्पिक) यदि शून्य नहीं है तो प्रत्येक मूल स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मान को लाइव रेंडर अपडेट में भी शामिल किया जाएगा। |
लाइवएट्रिब्यूट यह ऑप उन मानों को संग्रहीत करता है जो हेरफेर के दौरान व्यूअर मैनिपुलेटर्स द्वारा उत्पन्न किए जा रहे हैं (हेरफेर पूरा होने और पैरामीटर को अंतिम रूप देने की प्रतीक्षा करने के विपरीत)। यह ऑप एक विशेष मामला है जिसे लाइव रेंडरिंग मॉड्यूल द्वारा विशेष रूप से देखा जाता है। |
OpArgs इस ऑप के लिए तर्क लाइव रेंडर सिस्टम द्वारा स्वचालित रूप से सेट किए जाते हैं और इन्हें मैन्युअल रूप से सेट नहीं किया जाना चाहिए। |
लोकलाइज़एक्सफॉर्म किसी स्थान के xforms को उसके सभी पूर्वजों से एक एकल विश्व-अंतरिक्ष मैट्रिक्स में समतल करता है जिसे xform.matrix कहा जाता है। |
OpArgs - एक्सक्लूसिवसेल (स्ट्रिंगएट्रिब्यूट) - एक सीईएल अभिव्यक्ति जो दृश्य ग्राफ़ स्थानों का वर्णन करती है जिस पर ऑप लागू नहीं होना चाहिए। - addMaterialHash (IntAttribute) - (वैकल्पिक) लाइव रेंडरिंग के पुराने संस्करण के लिए विरासती व्यवहार। यदि गैर-शून्य है, तो 'मटेरियल' विशेषता का हैशेड मान 'मटेरियलहैश' के रूप में संग्रहीत किया जाएगा। - आउटपुटएट्रनाम (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) नई स्थानीय एक्सफॉर्म विशेषताओं को संग्रहीत करने के लिए उपयोग किया जाने वाला नाम। मौजूदा विशेषता को अधिलेखित करते हुए डिफ़ॉल्ट रूप से 'xform' कर दिया जाता है। |
LocalizeLiveAttributeXform व्यूअर में हेरफेर के दौरान स्थान की वास्तविक xform विशेषता नहीं बदलती (पेन-अप तक)। इसके बजाय LiveAttribute op का उपयोग LiveAttributes.xform के अंतर्गत अस्थायी xform को संग्रहीत करने के लिए किया जाता है। यह ऑप लोकलाइज़एक्सफॉर्म की तरह काम करता है, लेकिन इस लाइवएट्रिब्यूट कन्वेंशन से अवगत है, इसलिए यदि यह मौजूद है तो xform के बजाय लाइवएट्रिब्यूट्स.xform का उपयोग किया जाएगा। यह हेरफेर के दौरान स्थानों के xform को अद्यतन करने की अनुमति देता है। स्वाभाविक रूप से इस ऑप को LiveAttribute ऑप के बाद लागू किया जाना चाहिए। |
OpArgs - addMaterialHash (IntAttribute) - (वैकल्पिक) लाइव रेंडरिंग के पुराने संस्करण के लिए विरासती व्यवहार। यदि गैर-शून्य है, तो 'मटेरियल' विशेषता का हैशेड मान 'मटेरियलहैश' के रूप में संग्रहीत किया जाएगा। |
LocalizeLightListLiveRenderFilter यह Op विशेष रूप से प्रकाश सूचियों के उपयोग के लिए मानक LiveRenderFilter op की विशेषज्ञता है। यह LiveRenderFilter ऑप के समान व्यवहार करता है, सिवाय इसके कि यह प्रत्येक स्थान पर लाइटलिस्ट विशेषता के बारे में अतिरिक्त जानकारी तैयार करेगा। इस जानकारी में प्रकाश का पथ शामिल है, क्या प्रकाश लिंकिंग वर्तमान स्थान के लिए सक्षम है, और क्या यह मूल स्थान पर सक्षम है। यह जानकारी "लाइटलिंक" अपडेट के रूप में रेंडर प्लगइन पर भेजी जाएगी। |
OpArgs - विशेषतानाम (स्ट्रिंगएट्रिब्यूट) - परिवर्तनों के लिए विशेषताओं के नामों की निगरानी की जानी चाहिए और जब भी कोई परिवर्तन होता है तो उन्हें एकल अपडेट के रूप में रेंडर प्लग-इन पर भेजा जाना चाहिए। - स्थान (स्ट्रिंगएट्रिब्यूट) - एक सीईएल अभिव्यक्ति जो पहले स्थान को परिभाषित करती है जहां यह ऑप लागू होता है। इसके बाद इसे सभी बाल स्थानों पर लागू किया जाएगा। - बहिष्करण (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की एक सूची, जहां यह ऑप नहीं चलना चाहिए। - टाइपअलियास (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) 'टाइप' विशेषता के लिए एक नाम जो रेंडर प्लग-इन पर भेजा जाएगा। यदि सेट नहीं है तो इसके स्थान पर स्थान प्रकार का उपयोग किया जाएगा। - प्रकार (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) यदि सेट किया गया है, तो ऑप केवल इस प्रकार के स्थानों पर चलेगा। - कलेक्टअपस्ट्रीम (इंटएट्रिब्यूट) - (वैकल्पिक) यदि शून्य नहीं है तो प्रत्येक मूल स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मान को लाइव रेंडर अपडेट में भी शामिल किया जाएगा। |
कोऑर्डिनेटसिस्टमलाइवरेंडरफ़िल्टर यह मानक LiveRenderFilter ऑप की एक और विशेषज्ञता है। यह समन्वय प्रणालियों के साथ प्रयोग के लिए है। यह LiveRenderFilter op के समान व्यवहार करता है, सिवाय इसके कि यह पहले जांच करेगा कि वर्तमान स्थान ग्लोबल्स.कोऑर्डिनेटसिस्टम्स विशेषता में /root/world/ पर सूचीबद्ध है या नहीं और यदि यह सत्य है तो ही निष्पादन जारी रखेगा। |
OpArgs - विशेषतानाम (स्ट्रिंगएट्रिब्यूट) - परिवर्तनों के लिए विशेषताओं के नामों की निगरानी की जानी चाहिए और जब भी कोई परिवर्तन होता है तो उन्हें एकल अपडेट के रूप में रेंडर प्लग-इन पर भेजा जाना चाहिए। - स्थान (स्ट्रिंगएट्रिब्यूट) - एक सीईएल अभिव्यक्ति जो पहले स्थान को परिभाषित करती है जहां यह ऑप लागू होता है। इसके बाद इसे सभी बाल स्थानों पर लागू किया जाएगा। - बहिष्करण (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की एक सूची, जहां यह ऑप नहीं चलना चाहिए। - टाइपअलियास (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) 'टाइप' विशेषता के लिए एक नाम जो रेंडर प्लग-इन पर भेजा जाएगा। यदि सेट नहीं है तो इसके स्थान पर स्थान प्रकार का उपयोग किया जाएगा। - प्रकार (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) यदि सेट किया गया है, तो ऑप केवल इस प्रकार के स्थानों पर चलेगा। - कलेक्टअपस्ट्रीम (इंटएट्रिब्यूट) - (वैकल्पिक) यदि शून्य नहीं है तो प्रत्येक मूल स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मान को लाइव रेंडर अपडेट में भी शामिल किया जाएगा। |
रेंडरर प्लग-इन फ़ंक्शन
int startLiveEditing()
int stopLiveEditing()
लाइव रेंडरिंग सक्रिय होने पर आपको सूचित करने के लिए Katana से इन दो कार्यों को बुलाया जाता है और स्थानों के अपडेट की उम्मीद की जानी चाहिए
int processControlCommand( const std::string & command )
यह फ़ंक्शन Katana यूआई से रेंडर प्लग-इन तक संचार की एक विधि है। यूआई पायथन LiveRenderAPI.SendCommand() फ़ंक्शन के माध्यम से एक कमांड को स्ट्रिंग के रूप में भेज सकता है , जिसे आप अपनी इच्छानुसार किसी भी उद्देश्य के लिए रेंडर प्लग-इन में संभाल सकते हैं।
int queueDataUpdates(FnAttribute::GroupAttribute updateAttribute)
जब एक मॉनिटर की गई विशेषता बदलती है, तो इसका नया मान इस फ़ंक्शन के माध्यम से रेंडर प्लग-इन में भेज दिया जाएगा। पारित विशेषता में तीन बाल विशेषताएँ शामिल होंगी:
- प्रकार - अद्यतन का प्रकार (यह उपरोक्त विशेषता सम्मेलन अनुभाग में सूचीबद्ध <updateGroup> है)
- स्थान - वह दृश्य ग्राफ़ स्थान जिसके लिए यह अद्यतन है।
- विशेषताएँ - परिवर्तित विशेषताओं का मान। ध्यान दें कि यदि स्थान हटा दिया गया है, तो इसमें हटाए गए नाम की एक विशेषता शामिल होगी
ध्यान दें कि इस फ़ंक्शन को एक समर्पित थ्रेड में कॉल किया जाता है जो विशेष रूप से लाइव रेंडर अपडेट प्राप्त करने के लिए है।
bool hasPendingDataUpdates()
यह फ़ंक्शन रेंडरबूट प्रक्रिया को बताता है कि क्या कोई लाइव रेंडर अपडेट हैं जो queueDataUpdates() में कतारबद्ध हैं जिन्हें लागू किया जाना चाहिए।
int applyPendingDataUpdates()
इस फ़ंक्शन को मुख्य रेंडर थ्रेड में कॉल किया जाता है और इसे किसी भी कतारबद्ध लाइव अपडेट को लेना चाहिए और वास्तव में उन्हें लागू करना चाहिए। इसे केवल तभी कॉल किया जाता है जब hasPendingDataUpdates() सत्य लौटाता है।
पायथन उपयोगिताएँ
Katana के यूआई में लाइव रेंडरिंग अनुभव को बेहतर बनाने में मदद के लिए कई उपयोगिताएँ हैं, जो नीचे प्रस्तुत की गई हैं:
लाइवरेंडरएपीआई
यह एपीआई आपको LiveRenderAPI.SendCommand() और LiveRenderAPI.SendData() फ़ंक्शंस के साथ चल रहे लाइव रेंडर में एक कस्टम कमांड (स्ट्रिंग) या लाइव अपडेट भेजने की अनुमति देता है। इसमें लाइव रेंडर सबसिस्टम द्वारा उपयोग किए जा रहे टर्मिनल ऑप्स की सूची को क्वेरी करने और संशोधित करने के लिए विभिन्न कार्य भी हैं। इन टर्मिनल ऑप्स का उपयोग यह निर्धारित करने के लिए किया जाता है कि कोई स्थान कब बदला जाता है, न कि वर्तमान दृश्य ग्राफ़ में परिवर्तन का कारण बनता है (जैसा कि आपके नोड्स द्वारा उत्पन्न होता है)। यह प्रभावी रूप से कॉल के दौरान पारित किए गए ऑप्स को RendererInfo::fillLiveRenderTerminalOps() में बदलने का एक तरीका है।
LiveRenderActions
Plugin_apis/python/BaseLiveRenderAction.py में क्लास के उपयोग के माध्यम से अपने स्वयं के कस्टम मेनू आइटम के साथ रेंडर> लाइव रेंडरिंग मेनू का विस्तार करना संभव है। बस BaseLiverRenderAction क्लास (जो स्वयं QtGui.QAction से लिया गया है) से प्राप्त करें और सदस्य फ़ंक्शन को ओवरराइड करें। इसके बाद आपकी कक्षा LiveRenderAPI सहित Katana के किसी भी पायथन एपीआई का उपयोग कर सकती है, जो इसे रेंडर प्लग-इन में कस्टम कमांड या अपडेट भेजने की अनुमति देती है। LiveRenderActions के उदाहरणों को $KATANA_RESOURCES/UIPlugins निर्देशिका में रखा जाना चाहिए ताकि यह सुनिश्चित हो सके कि वे केवल UI सत्रों के दौरान लोड करने का प्रयास करते हैं।
कॉलबैक
रेंडर Katana -इन में लाइव अपडेट या लाइव रेंडर कमांड भेजने से पहले कटाना क्रमशः onLiveRenderUpdate या onLiveRenderCommand नामक कॉलबैक ट्रिगर करेगा। ये कॉलबैक कमांड या अपडेट विशेषता को पारित कर दिया जाएगा जो रेंडर प्लग-इन को पारित किया जाने वाला है। यह मुख्य रूप से निगरानी उद्देश्यों के लिए है, जो आपको रेंडर प्लग-इन में भेजे जा रहे डेटा का निरीक्षण करने की अनुमति देता है, लेकिन अपवाद बढ़ाकर संदेश को भेजे जाने से रोकना भी संभव है। हालाँकि यह Katana के संदेश लॉग में एक त्रुटि संदेश ट्रिगर करेगा।
पकड़ लिया
एकल नमूना अद्यतन
जब कोई रेंडर शुरू होता है तो जियोलिब मोशन ब्लर आदि की अनुमति देने के लिए बहु-नमूना विशेषताएँ उत्पन्न करता है। हालाँकि, Katana यूआई में, विशेषताएँ आम तौर पर केवल एक नमूने का उपयोग करके पुनर्प्राप्त की जाती हैं और लाइव रेंडर अपडेट Katana यूआई से आते हैं। इसका मतलब यह है कि लाइव अपडेट के दौरान भेजी जाने वाली विशेषताओं में आम तौर पर केवल एक ही समय का नमूना होता है।
गैर सतत अद्यतन
जब रेंडर शुरू होता है, तो दृश्य उत्पन्न करने के लिए ऑप ट्री को Katana द्वारा डिस्क पर लिखा जाता है और रेंडर प्रक्रिया द्वारा पढ़ा जाता है, जो अपने स्वयं के जियोलिब3 रनटाइम का उपयोग करता है। दृश्य ग्राफ़ और उसकी विशेषताओं को क्वेरी करने के लिए रेंडर प्लग-इन को SceneGraphIterator तक पहुंच दी गई है। हालाँकि यह दृश्य अपरिवर्तनीय है। जब Katana से लाइव रेंडर अपडेट पास किया जाता है तो यह जियोलिब3 रनटाइम को अपडेट नहीं कर सकता है। इसका मतलब यह है कि सीनग्राफइटरेटर्स हमेशा मूल दृश्य लौटाएंगे, भले ही रेंडर प्लग-इन द्वारा लाइव अपडेट प्राप्त हुए हों। इसलिए यह एक आवश्यकता है कि लाइव अपडेट विशेषताओं में वह सारी जानकारी शामिल हो जो रेंडर प्लग-इन के लिए आवश्यक है, क्योंकि आप अतिरिक्त जानकारी प्राप्त करने के लिए SceneGraphIterator का सुरक्षित रूप से उपयोग नहीं कर सकते हैं।
हम चाहते हैं कि खेद व्यक्त करते हैं
कृपया हमें बताएँ कि