सारांश
यह आलेख बताता है कि लाइव रेंडरिंग को रेंडरर प्लग-इन में कैसे क्रियान्वित किया जा सकता है और निम्नलिखित विषयों को शामिल करता है:
- विशेषता सम्मेलन
- रेंडररइन्फो प्लग-इन फ़ंक्शन
- रेंडर प्लग-इन फ़ंक्शन
- पायथन उपयोगिताएँ
- लाइवरेंडरएपीआई
- लाइवरेंडरएक्शन्स
- कॉलबैक - गोचास
- एकल नमूना अद्यतन
- गैर-स्थायी अद्यतन
लाइव रेंडरिंग के सामान्य स्पष्टीकरण के लिए, कृपया रेंडर प्रकारों पर Katana उपयोगकर्ता गाइड अनुभाग में इसका विवरण देखें, साथ ही रेंडर करने के लाइव रेंडरिंग शुरू करने और रोकने के उप-अनुभाग और लाइव रेंडरिंग को नियंत्रित करने के अनुभाग को भी देखें।
रेंडरर प्लग-इन के अन्य भागों का विस्तृत विवरण, तथा रेंडरएपीआई के अन्य कार्यों का दस्तावेज़ीकरण जो सीधे लाइवरेंडरिंग से संबंधित नहीं हैं , Katana डेवलपर गाइड के रेंडरर प्लग-इन अनुभाग में पाया जा सकता है।
अधिक जानकारी
विशेषता सम्मेलन
Katana का लाइव रेंडरिंग सिस्टम सीन ग्राफ़ में मौजूद विशेषताओं द्वारा संचालित होता है। दक्षता के नाम पर, केवल वे विशेषताएँ ही रेंडरर को अपडेट करने के लिए आवश्यक होती हैं, जिन्हें रेंडर प्लग-इन पर भेजा जाता है। ये विशेषताएँ कौन सी हैं, यह निर्धारित करने के लिए एक विशेषता नियमावली है, जो इस प्रकार है:
liveRender.<updateGroup>.<attributeName>
<updateGroup> - यह एक GroupAttribute है जिसका उपयोग विशेषताओं को एक साथ एक अद्यतन में समूहित करने के लिए किया जाता है।
<attributeName> - यह मॉनिटर करने के लिए शीर्ष-स्तरीय विशेषता का नाम है। ऊपर दी गई छवि में, liveRender.geoXform.xform विशेषता, लाइव रेंडर सिस्टम को किसी भी परिवर्तन को शीर्ष-स्तरीय xform विशेषता पर भेजने का निर्देश दे रही है। ध्यान दें कि यह एक StringAttribute है जिसका मान आमतौर पर <updateGroup> से मेल खाता है। यह विरासती कारणों से है, लेकिन आमतौर पर आंतरिक रूप से इसका उपयोग नहीं किया जाता है। यदि एक ही अपडेट समूह में कई विशेषताएँ निर्दिष्ट हैं, तो उनमें से किसी एक में भी परिवर्तन होने पर वे सभी रेंडरर को भेज दी जाएँगी।
रेंडररइन्फो प्लग-इन फ़ंक्शन
void fillLiveRenderTerminalOps( OpDefinitionQueue & terminalOps ,
const FnAttribute::GroupAttribute& stateArgs )
यद्यपि नोड ग्राफ़ में उपरोक्त विशेषता अभिसमय को सेट करना संभव है, फिर भी लाइव रेंडर शुरू होने पर विशेषताओं को स्वचालित रूप से सेट करने के लिए RendererInfo प्लग-इन में fillLiveRenderTerminalOps() फ़ंक्शन का उपयोग करना अधिक उपयोगी होता है। इस फ़ंक्शन को terminalOps नामक एक तर्क दिया जाता है, जो एक 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 के रूप में भेजा जाएगा। यह ऊपर वर्णित liveRender विशेषता कन्वेंशन को सेट करने का मानक तरीका है। |
|
ओपआर्ग्स - attributeNames (StringAttribute) - विशेषताओं के नामों में परिवर्तन के लिए निगरानी की जानी चाहिए और जब भी कोई परिवर्तन होता है, तो उसे एकल अद्यतन के रूप में रेंडर प्लग-इन को भेजा जाना चाहिए। - स्थान (स्ट्रिंगएट्रिब्यूट) - एक CEL व्यंजक जो उस पहले स्थान को परिभाषित करता है जहाँ यह ऑप लागू होता है। फिर इसे सभी चाइल्ड लोकेशन पर लागू किया जाएगा। - बहिष्करण (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की सूची, जहां यह ऑप नहीं चलना चाहिए। - typeAlias (StringAttribute) - (वैकल्पिक) 'type' विशेषता का एक नाम जो रेंडर प्लग-इन को भेजा जाएगा। यदि सेट नहीं किया गया है, तो इसके बजाय स्थान प्रकार का उपयोग किया जाएगा। - प्रकार (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) यदि सेट किया गया है, तो ऑप केवल इस प्रकार के स्थानों पर ही चलेगा। - collectUpstream (IntAttribute) - (वैकल्पिक) यदि शून्य नहीं है तो प्रत्येक पैरेंट स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मान भी लाइव रेंडर अपडेट में शामिल किए जाएंगे। |
|
लाइवएट्रिब्यूट यह ऑप उन मानों को संग्रहीत करता है जो किसी हेरफेर के दौरान व्यूअर मैनिपुलेटर्स द्वारा उत्पन्न किए जा रहे हैं (मैनिपुलेशन के पूरा होने और पैरामीटर के अंतिम रूप दिए जाने की प्रतीक्षा करने के विपरीत)। यह ऑप एक विशेष मामला है जिसे लाइव रेंडरिंग मॉड्यूल द्वारा विशेष रूप से देखा जाता है। |
|
ओपआर्ग्स इस ऑप के लिए आर्ग्स लाइव रेंडर सिस्टम द्वारा स्वचालित रूप से सेट किए जाते हैं और इन्हें मैन्युअल रूप से सेट नहीं किया जाना चाहिए। |
|
लोकलाइज़एक्सफॉर्म किसी स्थान के xforms को उसके सभी पूर्वजों से एक एकल विश्व-स्थान मैट्रिक्स में समतल करता है जिसे xform.matrix कहा जाता है। |
|
ओपआर्ग्स - excludeCel (StringAttribute) - एक CEL अभिव्यक्ति जो दृश्य ग्राफ स्थानों का वर्णन करती है, जिन पर ऑप लागू नहीं होना चाहिए। - addMaterialHash (IntAttribute) - (वैकल्पिक) लाइव रेंडरिंग के पुराने संस्करण के लिए लीगेसी व्यवहार। यदि शून्य नहीं है, तो 'material' विशेषता का हैश मान 'materialHash' के रूप में संग्रहीत किया जाएगा। - outputAttrName (StringAttribute) - (वैकल्पिक) नए स्थानीय xform विशेषताओं को संग्रहीत करने के लिए उपयोग किया जाने वाला नाम। डिफ़ॉल्ट रूप से 'xform', मौजूदा विशेषता को अधिलेखित करता है। |
|
लोकलाइज़लाइवएट्रिब्यूटएक्सफॉर्म व्यूअर में हेरफेर के दौरान, लोकेशन का वास्तविक xform एट्रिब्यूट (पेन-अप तक) नहीं बदलता। इसके बजाय, अस्थायी xform को liveAttributes.xform के अंतर्गत संग्रहीत करने के लिए LiveAttribute ऑप का उपयोग किया जाता है। यह ऑप localizeXform की तरह काम करता है, लेकिन इस liveAttribute परंपरा से अवगत है, इसलिए यदि xform मौजूद है, तो उसके बजाय liveAttributes.xform का उपयोग किया जाएगा। इससे हेरफेर के दौरान लोकेशन xform को अपडेट किया जा सकता है। स्वाभाविक रूप से, इस ऑप को LiveAttribute ऑप के बाद लागू किया जाना चाहिए। |
|
ओपआर्ग्स - addMaterialHash (IntAttribute) - (वैकल्पिक) लाइव रेंडरिंग के पुराने संस्करण के लिए लीगेसी व्यवहार। यदि शून्य नहीं है, तो 'material' विशेषता का हैश मान 'materialHash' के रूप में संग्रहीत किया जाएगा। |
|
स्थानीयकृतलाइटसूचीलाइवरेंडरफ़िल्टर यह ऑप, मानक LiveRenderFilter ऑप का एक विशेष संस्करण है, जो विशेष रूप से लाइट सूचियों के साथ उपयोग के लिए है। यह LiveRenderFilter ऑप के समान ही कार्य करता है, सिवाय इसके कि यह प्रत्येक स्थान पर lightList विशेषता के बारे में अतिरिक्त जानकारी प्रदान करता है। इस जानकारी में लाइट का पथ, वर्तमान स्थान के लिए लाइट लिंकिंग सक्षम है या नहीं, और मूल स्थान पर सक्षम है या नहीं, शामिल है। यह जानकारी रेंडर प्लगइन को "lightLink" अपडेट के रूप में भेजी जाएगी। |
|
ओपआर्ग्स - attributeNames (StringAttribute) - विशेषताओं के नामों में परिवर्तन के लिए निगरानी की जानी चाहिए और जब भी कोई परिवर्तन होता है, तो उसे एकल अद्यतन के रूप में रेंडर प्लग-इन को भेजा जाना चाहिए। - स्थान (स्ट्रिंगएट्रिब्यूट) - एक CEL व्यंजक जो उस पहले स्थान को परिभाषित करता है जहाँ यह ऑप लागू होता है। फिर इसे सभी चाइल्ड लोकेशन पर लागू किया जाएगा। - बहिष्करण (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की सूची, जहां यह ऑप नहीं चलना चाहिए। - typeAlias (StringAttribute) - (वैकल्पिक) 'type' विशेषता का एक नाम जो रेंडर प्लग-इन को भेजा जाएगा। यदि सेट नहीं किया गया है, तो इसके बजाय स्थान प्रकार का उपयोग किया जाएगा। - प्रकार (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) यदि सेट किया गया है, तो ऑप केवल इस प्रकार के स्थानों पर ही चलेगा। - collectUpstream (IntAttribute) - (वैकल्पिक) यदि शून्य नहीं है तो प्रत्येक पैरेंट स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मान भी लाइव रेंडर अपडेट में शामिल किए जाएंगे। |
|
कोऑर्डिनेटसिस्टमलाइवरेंडरफ़िल्टर यह मानक LiveRenderFilter ऑप का एक और विशेषज्ञता है। यह निर्देशांक प्रणालियों के साथ प्रयोग के लिए है। यह LiveRenderFilter ऑप के समान ही कार्य करता है, सिवाय इसके कि यह पहले जाँचता है कि वर्तमान स्थान |
|
ओपआर्ग्स - attributeNames (StringAttribute) - विशेषताओं के नामों में परिवर्तन के लिए निगरानी की जानी चाहिए और जब भी कोई परिवर्तन होता है, तो उसे एकल अद्यतन के रूप में रेंडर प्लग-इन को भेजा जाना चाहिए। - स्थान (स्ट्रिंगएट्रिब्यूट) - एक CEL व्यंजक जो उस पहले स्थान को परिभाषित करता है जहाँ यह ऑप लागू होता है। फिर इसे सभी चाइल्ड लोकेशन पर लागू किया जाएगा। - बहिष्करण (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की सूची, जहां यह ऑप नहीं चलना चाहिए। - typeAlias (StringAttribute) - (वैकल्पिक) 'type' विशेषता का एक नाम जो रेंडर प्लग-इन को भेजा जाएगा। यदि सेट नहीं किया गया है, तो इसके बजाय स्थान प्रकार का उपयोग किया जाएगा। - प्रकार (स्ट्रिंगएट्रिब्यूट) - (वैकल्पिक) यदि सेट किया गया है, तो ऑप केवल इस प्रकार के स्थानों पर ही चलेगा। - collectUpstream (IntAttribute) - (वैकल्पिक) यदि शून्य नहीं है तो प्रत्येक पैरेंट स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मान भी लाइव रेंडर अपडेट में शामिल किए जाएंगे। |
रेंडरर प्लग-इन फ़ंक्शन
int startLiveEditing()
int stopLiveEditing()
इन दो कार्यों को Katana से बुलाया जाता है ताकि आपको सूचित किया जा सके कि लाइव रेंडरिंग कब सक्रिय है और स्थानों के अपडेट की अपेक्षा की जानी चाहिए।
int processControlCommand( const std::string & command )
यह फ़ंक्शन Katana UI से रेंडर प्लग-इन तक संचार का एक तरीका है। UI, python LiveRenderAPI.SendCommand() फ़ंक्शन के माध्यम से एक स्ट्रिंग के रूप में कमांड भेज सकता है, जिसे आप रेंडर प्लग-इन में अपनी इच्छानुसार किसी भी उद्देश्य के लिए प्रबंधित कर सकते हैं।
int queueDataUpdates(FnAttribute::GroupAttribute updateAttribute)
जब कोई मॉनिटर किया गया एट्रिब्यूट बदलता है, तो उसका नया मान इस फ़ंक्शन के ज़रिए रेंडर प्लग-इन को पास कर दिया जाएगा। पास किए गए एट्रिब्यूट में तीन चाइल्ड एट्रिब्यूट होंगे:
- प्रकार - अद्यतन का प्रकार (यह विशेषता सम्मेलन अनुभाग में ऊपर सूचीबद्ध
<updateGroup>है) - स्थान - दृश्य ग्राफ़ का वह स्थान जिसके लिए यह अद्यतन है।
- विशेषताएँ - परिवर्तित विशेषताओं का मान। ध्यान दें कि यदि स्थान हटा दिया गया है, तो इसमें हटाए गए नाम की एक विशेषता होगी
ध्यान दें कि यह फ़ंक्शन एक समर्पित थ्रेड में बुलाया जाता है जो विशेष रूप से लाइव रेंडर अपडेट प्राप्त करने के लिए है।
bool hasPendingDataUpdates()
यह फ़ंक्शन रेंडरबूट प्रक्रिया को बताता है कि क्या ऐसे लाइव रेंडर अपडेट हैं जिन्हें queueDataUpdates() में पंक्तिबद्ध किया गया है, जिन्हें लागू किया जाना चाहिए।
int applyPendingDataUpdates()
यह फ़ंक्शन मुख्य रेंडर थ्रेड में कॉल किया जाता है और इसे सभी कतारबद्ध लाइव अपडेट्स को लेना चाहिए और उन्हें वास्तव में लागू करना चाहिए। इसे केवल तभी कॉल किया जाता है जब hasPendingDataUpdates() true लौटाता है।
पायथन उपयोगिताएँ
Katana के यूआई में लाइव रेंडरिंग अनुभव को बेहतर बनाने में मदद करने के लिए कई उपयोगिताएँ हैं, जो नीचे प्रस्तुत हैं:
यह API आपको LiveRenderAPI.SendCommand() और LiveRenderAPI.SendData() फ़ंक्शन के साथ चल रहे लाइव रेंडर में एक कस्टम कमांड (स्ट्रिंग) या लाइव अपडेट भेजने की अनुमति देता है। इसमें लाइव रेंडर सबसिस्टम द्वारा उपयोग किए जा रहे टर्मिनल ऑप्स की सूची को क्वेरी और संशोधित करने के लिए कई फ़ंक्शन भी हैं। इन टर्मिनल ऑप्स का उपयोग यह निर्धारित करने के लिए किया जाता है कि कोई स्थान कब बदला गया है, न कि वर्तमान दृश्य ग्राफ़ (जैसा कि आपके नोड्स द्वारा उत्पन्न होता है) में परिवर्तन करने के लिए। यह प्रभावी रूप से RendererInfo::fillLiveRenderTerminalOps() को कॉल के दौरान पास किए गए ऑप्स को बदलने का एक तरीका है।
लाइवरेंडरएक्शन्स
plugin_apis/python/BaseLiveRenderAction.py में क्लास का उपयोग करके, आप अपने स्वयं के कस्टम मेनू आइटम के साथ रेंडर > लाइव रेंडरिंग मेनू का विस्तार कर सकते हैं। बस BaseLiverRenderAction क्लास (जो स्वयं QtGui.QAction से व्युत्पन्न है) से व्युत्पन्न करें और सदस्य फ़ंक्शन को ओवरराइड करें। आपका क्लास तब Katana के किसी भी पायथन API का उपयोग कर सकता है, जिसमें LiveRenderAPI भी शामिल है, जिससे यह रेंडर प्लग-इन को कस्टम कमांड या अपडेट भेज सकता है। LiveRenderActions के इंस्टेंस को $KATANA_RESOURCES/UIPlugins निर्देशिका में रखा जाना चाहिए ताकि यह सुनिश्चित हो सके कि वे केवल UI सत्रों के दौरान ही लोड होने का प्रयास करें।
कॉलबैक
रेंडर प्लग-इन को लाइव अपडेट या लाइव रेंडर कमांड भेजने से पहले, Katana क्रमशः onLiveRenderUpdate या onLiveRenderCommand नामक कॉलबैक ट्रिगर करेगा। इन कॉलबैक को वह कमांड या अपडेट विशेषता भेजी जाएगी जो रेंडर प्लग-इन को भेजी जानी है। यह मुख्य रूप से निगरानी के लिए है, जिससे आप रेंडर प्लग-इन को भेजे जा रहे डेटा का निरीक्षण कर सकते हैं, लेकिन एक अपवाद उठाकर संदेश को भेजे जाने से रोकना भी संभव है। हालाँकि, इससे Katana के संदेश लॉग में एक त्रुटि संदेश ट्रिगर होगा।
गोचास
एकल नमूना अद्यतन
जब कोई रेंडर शुरू होता है, तो जियोलिब मोशन ब्लर आदि की अनुमति देने के लिए मल्टी-सैंपल विशेषताएँ उत्पन्न करता है। हालाँकि, Katana यूआई में, विशेषताएँ आमतौर पर केवल एक ही सैंपल का उपयोग करके प्राप्त की जाती हैं और लाइव रेंडर अपडेट Katana यूआई से आते हैं। इसका मतलब है कि लाइव अपडेट के दौरान भेजी जाने वाली विशेषताओं में आमतौर पर केवल एक ही टाइम सैंपल होता है।
गैर-स्थायी अद्यतन
जब कोई रेंडर शुरू होता है, तो दृश्य उत्पन्न करने वाला ऑप ट्री Katana द्वारा डिस्क पर लिखा जाता है और रेंडर प्रक्रिया द्वारा पढ़ा जाता है, जो अपने स्वयं के Geolib3 रनटाइम का उपयोग करती है। रेंडर प्लग-इन को दृश्य ग्राफ़ और उसकी विशेषताओं को क्वेरी करने के लिए एक SceneGraphIterator तक पहुँच प्रदान की जाती है। हालाँकि, यह दृश्य अपरिवर्तनीय है। जब Katana से एक लाइव रेंडर अपडेट पास किया जाता है, तो यह Geolib3 रनटाइम को अपडेट नहीं कर सकता। इसका अर्थ है कि SceneGraphIterators हमेशा मूल दृश्य लौटाएगा, भले ही रेंडर प्लग-इन द्वारा लाइव अपडेट प्राप्त किए गए हों। इसलिए यह आवश्यक है कि लाइव अपडेट विशेषताओं में वह सभी जानकारी हो जो रेंडर प्लग-इन को चाहिए, क्योंकि आप अतिरिक्त जानकारी प्राप्त करने के लिए SceneGraphIterator का सुरक्षित रूप से उपयोग नहीं कर सकते।
हम चाहते हैं कि खेद व्यक्त करते हैं
कृपया हमें बताएँ कि