- RenderFormer त्रिकोण mesh-आधारित scene में global illumination प्रभावों को भी सीधे लागू करने वाली एक neural rendering pipeline है
- हर scene के लिए अलग training या fine-tuning प्रक्रिया की आवश्यकता नहीं होती
- rendering को sequence-to-sequence transformation के रूप में परिभाषित किया गया है, जो triangle tokens को सीधे pixel patch tokens में बदलता है
- पूरी pipeline transformer-आधारित है और इस पर केवल न्यूनतम पूर्व constraints लागू किए गए हैं
- rasterization या ray tracing का उपयोग किए बिना image तैयार की जाती है
परिचय
- RenderFormer एक neural pipeline है जो triangle-आधारित scene representation से सीधे image render करती है
- यह global illumination effects पूरी तरह लागू की गई images आउटपुट करती है
- इसकी संरचना ऐसी है कि हर scene के लिए अलग training या fine-tuning की आवश्यकता नहीं होती
दृष्टिकोण
- पारंपरिक physics-based rendering तरीकों के विपरीत, यह rendering को sequence-to-sequence transformation problem के रूप में फिर से परिभाषित करता है
- triangle और reflection properties वाले token sequence को output token sequence में बदला जाता है, जहाँ प्रत्येक token एक छोटे pixel patch में रूपांतरित होता है
pipeline संरचना
- RenderFormer 2-चरणीय संरचना से बना है
- view-independent चरण: triangles के बीच illumination transfer phenomenon को मॉडल करता है
- view-dependent चरण: ray bundle को दर्शाने वाले tokens को pixel values में बदलता है। इस दौरान पिछले चरण का triangle sequence guide की भूमिका निभाता है
- दोनों चरण transformer architecture पर आधारित हैं
- training के दौरान केवल न्यूनतम पूर्व constraints दिए जाते हैं
तकनीकी विशेषताएँ
- rendering के समय rasterization, ray tracing जैसे पारंपरिक तरीकों का बिल्कुल उपयोग नहीं किया जाता
- transformer की sequence transformation capability का सक्रिय रूप से उपयोग किया जाता है
निष्कर्ष
- यह मौजूदा neural rendering तकनीकों की तुलना में, बिना अतिरिक्त तैयारी या scene-विशिष्ट adjustment के लचीली और उच्च-गुणवत्ता वाली images बनाने का एक तरीका है
1 टिप्पणियां
Hacker News राय
सबसे प्रभावशाली बात इसकी स्पीड है। उसी सीन में RenderFormer 0.076 सेकंड में काम पूरा कर देता है, जबकि Blender Cycles को 3.97 सेकंड लगते हैं (या ऊँची सेटिंग्स पर 12.05 सेकंड)। फिर भी structural similarity index (SSIM) 0.9526 है, यानी फर्क लगभग न के बराबर है। पेपर में Table 2 और Table 1 देखने की सलाह है। इसका असल मतलब यह है कि 3D designers वेब या native app में on-device transformer model के जरिए instant render preview कहीं बेहतर quality में देख सकते हैं। हाँ, ये नतीजे A100 GPU पर PyTorch optimization के बिना मापे गए हैं, इसलिए आम user GPU पर इतनी स्पीड नहीं मिलेगी, लेकिन फिर भी मौजूदा rendering की तुलना में पर्याप्त speedup संभव लगता है। या अगर यह web-based system हो, तो backend में A100 जोड़कर browser तक result image stream करने का तरीका भी संभव है। लेकिन सीमाएँ भी साफ़ हैं। सीन जितना complex होगा, accuracy उतनी गिरेगी, और खासकर complex shadows (particles या hair सहित) में error की संभावना ज़्यादा है, इसलिए final render अभी भी पारंपरिक तरीके से करना होगा ताकि AI-based image/video में अक्सर दिखने वाले artifacts से बचा जा सके। फिर भी अगर speedup काफ़ी बड़ा हुआ, तो movie-length preview rendering की ज़रूरत वाली बड़ी animation studios में music या story review जैसे कामों के लिए इसका इस्तेमाल हो सकता है
मुझे नहीं लगता कि researchers ने जानबूझकर तथ्यों को तोड़ा-मरोड़ा है, लेकिन उस स्तर के GPU पर Blender Cycles पेपर के सभी सीन 4 सेकंड के अंदर render कर सकता है। पेपर में इस्तेमाल किए गए सीन खुद ही low complexity वाले हैं, और Blender को 4,000 बार sample करने के लिए सेट किया गया है, जबकि व्यवहार में कुछ सौ samples में ही लगभग final quality मिल जाती है और उसके बाद का असर बहुत कम होता है। यानी GPU resources बेवजह खर्च हो रहे हैं। साथ ही Blender की शुरुआती render preparation को rendering time में शामिल किया गया है, जबकि transformer initialization time शायद बाहर रखा गया है। मैं यह भी जानना चाहूँगा कि दोनों सिस्टम में दूसरा frame render होने में कितना समय लगता है। मेरा अनुमान है कि Blender वहाँ कहीं तेज़ होगा। फिर भी पेपर के results दिलचस्प हैं, बस Blender settings और timing comparison में थोड़ा सूक्ष्म फर्क है
जो सीन दिखाए गए हैं, उनके हिसाब से 76ms तो उल्टा लंबा समय लगता है। हाँ, आगे चलकर यह बहुत तेज़ होगा, ऐसा लगता है, लेकिन इसे अभी से पारंपरिक renderers से बेहतर कहना जल्दबाज़ी होगी
पेपर में time comparison कुछ हद तक भ्रामक है। ray tracing में error samples की संख्या के square root के अनुसार घटती है। पेपर में reference image बनाते समय unrealistically high sample count इस्तेमाल किया गया है, जबकि असली offline renderers इससे 10~100 गुना कम sampling करते हैं। पेपर जैसे high-sample images quality comparison के लिए ठीक हैं, लेकिन उन्हीं से time comparison करना आम बात नहीं है। नतीजे इतने कठोर नहीं हैं, इसलिए ऐसे दूसरे rendering algorithms से तुलना करना ज़्यादा fair होगा जो मिलते-जुलते approximate results देते हों। आजकल real-time path tracer और denoiser का combo consumer GPU पर 16ms के भीतर इससे कहीं अधिक complex सीन render कर सकता है। खास तौर पर transformer model में triangles और pixels दोनों के लिए समय quadratic लगता है। हो सकता है हालिया machine learning research में इसमें सुधार हुआ हो, लेकिन पारंपरिक path tracer की O(log n triangles), O(n pixels) scaling को हराना मुश्किल होगा (व्यवहार में तो adjacent pixels की coherence के कारण pixel count बढ़ने पर भी असर कम पड़ता है)
इसकी स्पीड को लेकर किए जा रहे दावों पर मुझे हैरानी है। मैंने पेपर सरसरी तौर पर देखा, लेकिन यह साफ़ नहीं हुआ कि Blender Cycles ने A100 का CPU इस्तेमाल किया या CUDA kernels चलाए। अगर single frame है, तो renderer startup time का कुछ हिस्सा इसमें शामिल हो सकता है। अगर sequence render हो, तो प्रति frame समय काफ़ी कम हो जाएगा। और जैसा दूसरे लोगों ने triangle complexity यानी O(n^2) scaling का ज़िक्र किया, उसका असर भी निश्चित रूप से पड़ेगा
पेपर में कहा गया है कि "Attention layer की runtime-complexity token count, यानी इस मामले में triangles की संख्या, के अनुपात में quadratic बढ़ती है। इसलिए सीन में triangles की संख्या को अधिकतम 4096 तक सीमित किया गया है"
deep learning का इस्तेमाल global illumination render images की denoising में भी बहुत सफल रहा है। तरीका यह है कि पारंपरिक ray tracing से rough global illumination image बनाई जाती है, फिर neural network output image का noise हटा देता है। संबंधित लिंक: Open Image Denoise
मेरा एक दोस्त film industry में सचमुच physically based renderers develop करता है, और इस उद्योग के workflows व किस्से सुनना हमेशा दिलचस्प होता है। सोच रहा हूँ कि अभी ऐसी प्रतिभा को कौन-कौन सी कंपनियाँ hire कर रही हैं। क्या AI कंपनियाँ भी training environments बनाने के लिए rendering engineers रखती हैं? अगर कोई experienced rendering research/industry engineer को hire करना चाहता हो, तो मैं अपने दोस्त को connect करा सकता हूँ, क्योंकि वह social media पर नहीं है
मुझे यह अजीब लगा कि किसी भी उदाहरण में camera के पीछे की objects नहीं दिखाई गईं। यह इन examples की सीमा है या approach की, पता नहीं, लेकिन reflection और lighting को देखते हुए camera के पीछे का हिस्सा बहुत महत्वपूर्ण होता है
यह फिर एक बार "the bitter lesson" को सच साबित करने जैसा है। अब graphics rendering में भी वही रुझान लागू होता दिख रहा है। Nerf ने ray tracing-based priors को, और Gaussian splat ने rasterization-based priors को आंशिक रूप से इस्तेमाल किया था, लेकिन यह तरीका उन domain priors या specialist knowledge को छोड़कर सिर्फ data और attention के दम पर समस्या हल करने की कोशिश करता है। लगता है आखिरकार भविष्य इसी दिशा में है
यह बात प्रभावशाली है कि GPU को केंद्र में रखकर rendering और compute का एक cyclical loop पूरा हो गया है
output ठीक-ठाक है, लेकिन थोड़ा blurry लगता है। neural network और classical renderer के बीच render time comparison थोड़ा और देखना अच्छा होता
animation में (खासकर Animated Crab और Robot Animation) AI art वाले विशिष्ट artifacts दिखते हैं, जहाँ object या camera के move करने पर model के आसपास अप्राकृतिक swirling जैसा असर होता है
पेपर में time comparison पर कुछ चर्चा है। Blender Cycles (path tracing) की तुलना में, कम से कम 4K triangles तक के सीन में neural तरीका काफी तेज़ है। लेकिन इससे अधिक complex सीन पर यह शायद ठीक से फिट न बैठे (क्योंकि attention runtime triangles की संख्या के square के साथ बढ़ती है)। पेपर लिंक: RenderFormer paper PDF. मेरे हिसाब से neural method को सिर्फ indirect lighting के लिए इस्तेमाल करना, और base image पारंपरिक rasterizer से बनाकर सिर्फ Global Illumination को neural तरीके से जोड़ना, एक व्यावहारिक रास्ता हो सकता है
शायद मैं ठीक से समझ नहीं रहा, लेकिन अगर ये सीन आखिरकार अनुमानित तरीके से ही render हुए हैं, तो फिर यह तरीका ज़्यादा सरल direct methods की तुलना में क्या लाभ देता है? (अगर यह तेज़ भी नहीं है, तो इसे इस्तेमाल करने की ज़रूरत क्यों पड़े?)
दरअसल यह तरीका ऊपर से दिखने से ज़्यादा दिलचस्प प्रभाव दे सकता है। उदाहरण के लिए, सीन को एक input weight blob मानकर उसमें noise जोड़ा जा सकता है, या अलग-अलग सीन को interpolate (mix) करके अप्रत्याशित results निकाले जा सकते हैं
आखिर में मुझे यह "Cool Research" के ज़्यादा करीब लगता है। practical use कम है, क्योंकि triangles बढ़ने पर cost quadratic बढ़ती है। इसलिए पेपर में भी इसे प्रति सीन 4096 तक सीमित रखा गया है
जैसा दूसरे comment में कहा गया, यह तरीका वास्तव में तेज़ है। global illumination सीधे तरीकों से वाकई बहुत धीमा होता है
यह मुझे काफ़ी नया और रोचक research लगा। transformer सिर्फ natural language ही नहीं, बल्कि कई तरह के continuous data inputs और token correlations वाले domains में भी लागू हो सकते हैं, इसलिए भविष्य में non-text domains में इनके उपयोग पर और research देखने की उम्मीद है। जानना दिलचस्प होगा कि Hacker News users को transformer के लिए कौन से non-text domains सबसे रोचक लगते हैं
यह बहुत चतुर और दिलचस्प विचार है। triangle-set आधारित scene description को 2D pixel array में बदलने वाला transformer train किया गया है, और उसका नतीजा यह है कि वह मौजूदा global illumination renderer के output से लगभग मिलता-जुलता image तुरंत बना देता है। पिछले 5 साल की research को देखें तो यह कि ऐसा संभव है, अब चौंकाने वाली बात नहीं रहनी चाहिए, फिर भी यह बहुत प्रभावशाली है। transformer architecture वाकई बेहद versatile है। speed भी बेहद तेज़ है, Blender output से लगभग मिलता-जुलता है, model करीब 1B parameters का है, fp16 है या 32 यह स्पष्ट नहीं, लेकिन file 2GB की है, जो काफ़ी बड़ी है। मैं कुछ और realistic scene demos भी देखना चाहूँगा, लेकिन यह बात भी अच्छी लगी कि इसे अभी अपने Mac पर download करके खुद चलाया जा सकता है