render quality विकल्पों, queue behaviour और hidden renders को समझें
जानें कि Fire Render quality और 360 बटन jobs को कैसे queue करते हैं, render pending रहने के दौरान Gallery क्या दिखाती है, और render delete करने पर वास्तव में क्या होता है।
Fire Render मोडल में HD (Free लेबल के साथ), FHD और 4K विकल्प मिलते हैं। तीन अतिरिक्त 360 बटन (HD 360, FHD 360, 4K 360) केवल तब दिखते हैं जब org के लिए 360-tours feature सक्षम हो; इनके outputs panoramas होते हैं जिन्हें बाद में 360 tours में जोड़ा जा सकता है। शुरू करने पर, design पहले save होता है (camera + lighting snapshot), फिर job queue होता है: सफल होने पर '<quality> Render added to the queue. Check Gallery under the Render tab.' दिखता है। Gallery progress poll करती है और completion percentage, queue position और ETA दिखा सकती है; जब free HD स्लॉट व्यस्त हो, तो waiting render लाइन में अपना अनुमानित स्थान दिखाता है (साथ में नोट कि कौन-सा project/design स्लॉट रोके हुए है) और उसे Gallery से cancel किया जा सकता है। जैसे ही कोई polled render पूरा होता है या उसकी enhancement status बदलती है, Gallery तुरंत refresh होती है। बड़ी बात: render pending रहने के दौरान उसका Gallery thumbnail एक साधारण 3D screenshot होता है जो render के saved camera से locally बनाया जाता है - clients अक्सर इस flat, unlit preview को failed या low-quality render समझ लेते हैं। पूरा होने पर ray-traced image उसकी जगह ले लेती है, और completion alert में 'View Image' और 'Open post processing' मिलते हैं; यदि optional upscale step विफल हो, तो भी alert missing 4K file के बजाय enhanced image का लिंक देता है। यदि subscription expired है, तो 'Your subscription has expired' संदेश के साथ शुरू करना रोक दिया जाता है। प्रत्येक render का info पैनल name, timestamp, aspect ratio, quality, attempts की संख्या, total render time और उपयोग की गई सटीक lighting settings दर्ज करता है - किसी भी 'render looks wrong' ticket पर सबसे पहले यहीं देखें।
जब कोई user render gallery से renders delete करता है, तो backend soft hide करता है: वह remove_from_visible के ज़रिए उन render records पर visible=false सेट करता है। render row, उसके parameters (camera, quality, samples), उसका attempts history और output image file सब storage में बने रहते हैं। एक अपवाद fair-use HD queue में अभी इंतज़ार कर रहा render है (held, अभी शुरू नहीं हुआ): उसे delete करने पर वह cancel भी हो जाता है, इसलिए वह कभी promote और render नहीं होगा। support के लिए दो नतीजे। Recovery: यदि किसी client ने गलती से render delete कर दिया, तो उसे restore किया जा सकता है — engineering visibility वापस बदल सकती है, और enterprise APIs get_all_of_design / get_by_id hidden renders भी लौटाते हैं क्योंकि वे visibility पर filter नहीं करते, इसलिए output file path हमेशा प्राप्त किया जा सकता है। Billing: hide करना refund नहीं है; usage अवधि में पूरे हुए renders से गणना होती है, visibility चाहे जो हो, इसलिए deleted-but-completed render भी usage statement पर दिखता है — जब client "remove it from my bill" के लिए कहे तो यह अपेक्षा स्पष्ट रूप से बताएं। दूसरा साइड privacy-sensitive clients के लिए मायने रखता है: gallery से delete करने पर image storage से purge नहीं होती, इसलिए output image को वास्तव में हटाने के लिए in-app delete के बजाय engineering request चाहिए।