एक टिकट बनाएं
अनुसरण करें

Q100311: एक रेंडरर प्लग-इन में लाइव रेंडरिंग को लागू करना

सारांश

यह आलेख बताता है कि एक रेंडर प्लग-इन में लाइव रेंडरिंग कैसे लागू किया जा सकता है और निम्नलिखित विषयों को शामिल किया गया है:

  • अधिवेशन में भाग लें
  • RendererInfo प्लग-इन फ़ंक्शन
  • रेंडर प्लग-इन फ़ंक्शन
  • पायथन यूटिलिटीज
    - LiveRenderAPI
    -
    LiveRenderActions
    - कॉलबैक
  • gotchas
    - एकल नमूना अद्यतन
    - गैर लगातार अपडेट

LiveRendering की एक सामान्य व्याख्या के लिए , कृपया रेंडर टाइप्स पर कटाना ऑनलाइन हेल्प सेक्शन में इसका विवरण प्राप्त करें , साथ ही साथ रेंडरिंग के स्टार्टिंग और स्टॉपिंग लाइव रेंडरिंग सब-सेक्शन और लाइव रेंडरिंग पर सेक्शन देखें।

रेंडरर प्लग-इन के अन्य हिस्सों का विस्तृत विवरण, और रेंडरएपीआई के अन्य कार्यों के प्रलेखन जो सीधे लाइवरेंडरिंग से संबंधित नहीं हैं, कटान ऑनलाइन सहायता के रेंडरर प्लग-इन अनुभाग में पाए जा सकते हैं।

अधिक जानकारी

अधिवेशन में भाग लें

Katana का लाइव रेंडरिंग सिस्टम दृश्य ग्राफ में विशेषताओं द्वारा संचालित है। दक्षता के नाम पर, रेंडर को अपडेट करने के लिए केवल विशेषताओं को रेंडर प्लग-इन के लिए भेजा जाता है। यह निर्धारित करने के लिए एक विशेषता सम्मेलन है कि ये कौन सी विशेषताएँ हैं, जो निम्नानुसार हैं:

liveRender। <updateGroup> <AttributeName>

<updateGroup> - यह एक GroupAttribute है जो एक ही अद्यतन में एक साथ समूह विशेषताओं के लिए उपयोग किया जाता है।

<विशेषतानाम> - यह मॉनिटर करने के लिए शीर्ष-स्तरीय विशेषता का नाम है। LiveRender.geoXform.xform विशेषता के ऊपर की छवि में लाइव रेंडर सिस्टम को शीर्ष-स्तरीय xform विशेषता में कोई भी परिवर्तन भेजने के लिए निर्देश दे रहा है। ध्यान दें कि यह एक StringAttribute है जिसका मान आमतौर पर अद्यतनसमूह से मेल खाता है यह विरासत कारणों से है, लेकिन आमतौर पर आंतरिक रूप से उपयोग नहीं किया जाता है। यदि एक ही अपडेट समूह में कई विशेषताओं को निर्दिष्ट किया जाता है, तो वे सभी रेंडरर को भेजे जाएंगे जब उनमें से कोई भी परिवर्तन होता है।

RendererInfo प्लग-इन फ़ंक्शन

 void  fillLiveRenderTerminalOps( OpDefinitionQueue &  terminalOps , 
                               const FnAttribute::GroupAttribute& stateArgs )

यद्यपि, नोड ग्राफ़ में उपरोक्त विशेषता सम्मेलन को स्थापित करना संभव है, यह आमतौर पर लाइव रेंडर शुरू होने पर विशेषताओं को स्वचालित रूप से सेट करने के लिए RendererInfo प्लग-इन में fillLiveRenderTerminalOps () फ़ंक्शन का उपयोग करने के लिए अधिक उपयोगी है। फ़ंक्शन को एक तर्क दिया जाता है जिसे टर्मिनलऑप्स कहा जाता है जो कि एक std :: deque है जिसमें कोई भी या अधिक std नहीं होता है :: op ऑब्जेक्ट (एक std :: string) के रूप में जोड़ी ऑब्जेक्ट्स, और op ऑर्गमेंट्स (एक GroupAttribute के रूप में)।

उदाहरण के लिए। नीचे दिए गए कोड मॉनिटर / लाइट / लोकल / 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()));

कई जियोलिब 3 ऑप्स हैं जो कटाना के साथ जहाज हैं जो यहां उपयोगी हैं:

LiveRenderFilter

यह इंगित करने के लिए उपयोग किया जाता है कि लाइव रेंडरिंग के लिए कौन सी विशेषताओं की निगरानी की जानी चाहिए। एकल LiveRenderFilter द्वारा कई विशेषताओं की निगरानी की जा सकती है और सभी को एक एकल GroupAttribute के रूप में भेजा जाना चाहिए उनमें से कोई भी परिवर्तन होना चाहिए। यह ऊपर वर्णित लाइवरेंडर विशेषता सम्मेलन को स्थापित करने का मानक तरीका है

OpArgs

- attributeNames (StringAttribute) - विशेषताओं के नाम परिवर्तन के लिए निगरानी की जानी चाहिए चाहिए और एक ही अद्यतन जब भी एक के रूप में बदल जाता है प्रस्तुत करना प्लग में करने के लिए भेजा।

- स्थान (StringAttribute) - पहले स्थान को परिभाषित करने वाली CEL अभिव्यक्ति जहाँ यह op लागू होता है। फिर इसे सभी बाल स्थानों पर लागू किया जाएगा।

- बहिष्करण (StringAttribute) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की एक सूची, जहाँ यह op नहीं चलना चाहिए।

- typeAlias (StringAttribute) - (वैकल्पिक) 'टाइप' विशेषता के लिए एक नाम जो रेंडर प्लग-इन के लिए भेजा जाएगा। यदि सेट नहीं है तो इसके स्थान का उपयोग किया जाएगा।

- प्रकार (StringAttribute) - (वैकल्पिक) यदि सेट किया जाता है, तो op केवल इस प्रकार के स्थानों पर चलेगा।

- collectUpstream (IntAttribute) - (वैकल्पिक) यदि गैर-शून्य प्रत्येक माता-पिता के स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मूल्यों को लाइव रेंडर अपडेट में भी शामिल किया जाएगा।

LiveAttribute

यह op उन मानों को संग्रहीत करता है जो एक हेरफेर के दौरान व्यूअर मैनिपुलेटर्स द्वारा उत्पन्न किए जा रहे हैं (जैसा कि हेरफेर के पूरा होने के लिए प्रतीक्षा करने के लिए विरोध किया गया है और पैरामीटर को अंतिम रूप दिया गया है)। यह ऑप एक विशेष मामला है जिसे विशेष रूप से लाइव रेंडरिंग मॉड्यूल द्वारा देखा जाता है।

OpArgs

इस ऑप के लिए आर्ग्स लाइव रेंडर सिस्टम द्वारा स्वचालित रूप से सेट किए जाते हैं और इसे मैन्युअल रूप से सेट नहीं किया जाना चाहिए।

LocalizeXform

एक स्थान के xforms को उसके सभी पूर्वजों से xform.matrix नामक एक विश्व-अंतरिक्ष मैट्रिक्स में समतल करता है।

OpArgs

- बहिष्कार (StringAttribute) - दृश्य ग्राफ़ स्थानों का वर्णन करने वाली एक CEL अभिव्यक्ति, जो op पर लागू नहीं होनी चाहिए।

- addMaterialHash (IntAttribute) - (वैकल्पिक) लाइव रेंडरिंग के पुराने संस्करण के लिए विरासत व्यवहार। यदि गैर-शून्य है, तो 'भौतिक' विशेषता का हैशेड मान 'भौतिक' के रूप में संग्रहीत किया जाएगा।

- outputAttrName (StringAttribute) - (वैकल्पिक) नए स्थानीय xform विशेषताओं को संग्रहीत करने के लिए उपयोग करने वाला नाम। मौजूदा विशेषता को अधिलेखित करने के लिए 'xform' की कमी।

LocalizeLiveAttributeXform

दर्शक में हेरफेर के दौरान स्थान का वास्तविक xform गुण (पेन-अप तक) नहीं बदलता है। इसके बजाय LiveAttributes.xform के तहत LiveAttribute op का उपयोग अस्थायी xform को संग्रहीत करने के लिए किया जाता है। यह ऑप लोकलाइज़एक्सफ़ॉर्म की तरह काम करता है, लेकिन इस लाइवएट्रिब्यूट कन्वेंशन के बारे में पता है, इसलिए अगर लाइव एट्रिब्यूट्स.एक्सफ़ॉर्म का उपयोग एक्सफ़ॉर्म के बजाय किया जाएगा यदि यह मौजूद है। यह हेरफेर के दौरान स्थानों को अपडेट करने की अनुमति देता है। स्वाभाविक रूप से इस ऑप को LiveAttribute op के बाद लागू किया जाना चाहिए।

OpArgs

- addMaterialHash (IntAttribute) - (वैकल्पिक) लाइव रेंडरिंग के पुराने संस्करण के लिए विरासत व्यवहार। यदि गैर-शून्य है, तो 'भौतिक' विशेषता का हैशेड मान 'भौतिक' के रूप में संग्रहीत किया जाएगा।

LocalizeLightListLiveRenderFilter

यह Op विशेष रूप से प्रकाश सूचियों के साथ उपयोग के लिए मानक LiveRenderFilter सेशन का एक विशेषज्ञता है। यह LiveRenderFilter ऑप के समान व्यवहार करता है सिवाय इसके कि यह प्रत्येक स्थान पर लाइटलिस्ट विशेषता के बारे में अतिरिक्त जानकारी पैदा करेगा। इस जानकारी में प्रकाश का मार्ग शामिल है, चाहे प्रकाश जोड़ने को वर्तमान स्थान के लिए सक्षम किया गया हो, और क्या यह मूल स्थान पर सक्षम है। यह जानकारी रेंडर प्लगइन को "लाइटलिंक" अपडेट के रूप में भेजी जाएगी।

OpArgs

- attributeNames (StringAttribute) - विशेषताओं के नाम परिवर्तन के लिए निगरानी की जानी चाहिए चाहिए और एक ही अद्यतन जब भी एक के रूप में बदल जाता है प्रस्तुत करना प्लग में करने के लिए भेजा।

- स्थान (StringAttribute) - पहले स्थान को परिभाषित करने वाली CEL अभिव्यक्ति जहाँ यह op लागू होता है। फिर इसे सभी बाल स्थानों पर लागू किया जाएगा।

- बहिष्करण (StringAttribute) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की एक सूची, जहाँ यह op नहीं चलना चाहिए।

- typeAlias (StringAttribute) - (वैकल्पिक) 'टाइप' विशेषता के लिए एक नाम जो रेंडर प्लग-इन के लिए भेजा जाएगा। यदि सेट नहीं है तो इसके स्थान का उपयोग किया जाएगा।

- प्रकार (StringAttribute) - (वैकल्पिक) यदि सेट किया जाता है, तो op केवल इस प्रकार के स्थानों पर चलेगा।

- collectUpstream (IntAttribute) - (वैकल्पिक) यदि गैर-शून्य प्रत्येक माता-पिता के स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मूल्यों को लाइव रेंडर अपडेट में भी शामिल किया जाएगा।

CoordinateSystemLiveRenderFilter

यह मानक LiveRenderFilter op का एक और विशेषज्ञता है। यह समन्वय प्रणालियों के साथ उपयोग के लिए है। यह LiveRenderFilter सेशन के लिए समान रूप से व्यवहार करता है, सिवाय इसके कि यह पहले यह जांच करेगा कि क्या वर्तमान स्थान globals.coordinatesystems / root / world / पर विशेषता में सूचीबद्ध है और केवल निष्पादन जारी है यदि यह सत्य है।

OpArgs

- attributeNames (StringAttribute) - विशेषताओं के नाम परिवर्तन के लिए निगरानी की जानी चाहिए चाहिए और एक ही अद्यतन जब भी एक के रूप में बदल जाता है प्रस्तुत करना प्लग में करने के लिए भेजा।

- स्थान (StringAttribute) - पहले स्थान को परिभाषित करने वाली CEL अभिव्यक्ति जहाँ यह op लागू होता है। फिर इसे सभी बाल स्थानों पर लागू किया जाएगा।

- बहिष्करण (StringAttribute) - (वैकल्पिक) बहिष्कृत स्थान प्रकारों की एक सूची, जहाँ यह op नहीं चलना चाहिए।

- typeAlias (StringAttribute) - (वैकल्पिक) 'टाइप' विशेषता के लिए एक नाम जो रेंडर प्लग-इन के लिए भेजा जाएगा। यदि सेट नहीं है तो इसके स्थान का उपयोग किया जाएगा।

- प्रकार (StringAttribute) - (वैकल्पिक) यदि सेट किया जाता है, तो op केवल इस प्रकार के स्थानों पर चलेगा।

- collectUpstream (IntAttribute) - (वैकल्पिक) यदि गैर-शून्य प्रत्येक माता-पिता के स्थान पर प्रत्येक मॉनिटर किए गए विशेषता के मूल्यों को लाइव रेंडर अपडेट में भी शामिल किया जाएगा।

रेंडरर प्लग-इन फ़ंक्शन

 int  startLiveEditing() 
 int  stopLiveEditing() 

जब लाइव रेंडरिंग सक्रिय हो तो आपको सूचित करने के लिए कटना से इन दो कार्यों को बुलाया जाता है और स्थानों के अपडेट की उम्मीद की जानी चाहिए

 int  processControlCommand( const  std::string &  command ) 

यह फ़ंक्शन Katana UI से प्लग-इन रेंडर करने के लिए संचार का एक तरीका है। UI python LiveRenderAPI.SendCommand () फ़ंक्शन के माध्यम से एक स्ट्रिंग के रूप में एक कमांड भेज सकता है , जिसे आप जिस भी उद्देश्य से चाहते हैं, उसके लिए रेंडर प्लग-इन में संभाल सकते हैं।

 int  queueDataUpdates(FnAttribute::GroupAttribute updateAttribute) 

जब एक मॉनिटर की गई विशेषता बदल जाती है, तो यह नया मान इस फ़ंक्शन के माध्यम से प्लग-इन रेंडर करने के लिए पारित किया जाएगा। उत्तीर्ण विशेषता में तीन बाल विशेषताएँ होंगी:

  • प्रकार - अद्यतन का प्रकार (यह विशेषता समूह में ऊपर सूचीबद्ध <updateGroup> है )
  • स्थान - यह अद्यतन करने के लिए दृश्य ग्राफ़ स्थान।
  • विशेषताएँ - परिवर्तित विशेषताओं का मूल्य। ध्यान दें कि यदि स्थान हटा दिया गया है, तो इसमें हटाए गए नाम की विशेषता होगी

ध्यान दें कि यह फ़ंक्शन एक समर्पित थ्रेड में कहा जाता है जो विशेष रूप से लाइव रेंडर अपडेट प्राप्त करने के लिए है।

 bool  hasPendingDataUpdates() 

यह फ़ंक्शन रेंडरबूट प्रक्रिया को बताता है कि क्या लाइव रेंडर अपडेट हैं जो कतार में लगाए गए हैं (जो कि लागू होना चाहिए)।

 int  applyPendingDataUpdates()  

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

पायथन यूटिलिटीज

Katana के यूआई में लाइव प्रस्तुतिकरण के अनुभव को बेहतर बनाने में मदद करने के लिए कई उपयोगिताओं हैं, जो नीचे प्रस्तुत की गई हैं:

LiveRenderAPI

यह API आपको LiveRenderAPI.SendCommand () और LiveRenderAPI.SendData () फ़ंक्शन के साथ एक कस्टम कमांड (स्ट्रिंग) या लाइव अपडेट को लाइव लाइव रेंडर पर भेजने की अनुमति देता है। लाइव टर्मिनल सबसिस्टम द्वारा उपयोग किए जा रहे टर्मिनल ऑप्स की सूची को क्वेरी और संशोधित करने के लिए इसमें विभिन्न कार्य हैं। इन टर्मिनल ऑप्स का उपयोग यह निर्धारित करने के लिए किया जाता है कि वर्तमान दृश्य ग्राफ में परिवर्तन के कारण स्थान बदल जाता है (जैसा कि आपके नोड्स द्वारा उत्पन्न होता है)। यह प्रभावी रूप से RendererInfo :: fillLiveRenderTerminalOps () में कॉल के दौरान पारित किए गए ऑप्स को बदलने का एक तरीका है।

LiveRenderActions

Plugin_apis / python / BaseLiveRenderAction.py में कक्षा के उपयोग के माध्यम से अपने स्वयं के कस्टम मेनू आइटम के साथ रेंडर> लाइव रेंडरिंग मेनू का विस्तार करना संभव है। बस BaseLiverRenderAction वर्ग (जो स्वयं QtGui.QAction से प्राप्त होता है) से प्राप्त करें और सदस्य कार्यों को ओवरराइड करें। आपकी कक्षा तब लाइवरेंदरएपीआई सहित कटाना के अजगर एपीआई में से किसी का भी उपयोग कर सकती है, यह प्लग-इन रेंडर करने के लिए कस्टम कमांड या अपडेट भेजने की अनुमति देता है। LiveRenderActions के उदाहरणों को KATANA_RESOURCEs / UIPlugins निर्देशिका में रखा जाना चाहिए ताकि यह सुनिश्चित हो सके कि वे केवल UI सत्र के दौरान लोड करने का प्रयास करते हैं।

कॉलबैक

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

gotchas

एकल नमूना अद्यतन

जब एक रेंडर शुरू होता है तो जियोलिब मोशन ब्लर आदि के लिए अनुमति देने के लिए मल्टी-सैंपल एट्रिब्यूट जेनरेट करता है। हालांकि कटाना यूआई में, एट्रिब्यूट्स आम तौर पर केवल एक सैंपल का उपयोग करके पुनर्प्राप्त किए जाते हैं और लाइव रेंडर अपडेट कैटाना यूआई से आते हैं। इसका मतलब यह है कि लाइव अपडेट के दौरान जो विशेषताएँ भेजी जाती हैं, उनमें केवल एक ही समय का नमूना होता है।

गैर लगातार अपडेट

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

क्या यह लेख उपयोगी था?
/

We're sorry to hear that!

Please tell us why.
0 में से 0 के लिए उपयोगी रहा

टिप्पणियां