Understand render quality options, queue behaviour and hidden renders
Learn how the Fire Render quality and 360 buttons queue jobs, what the Gallery shows while a render is pending, and what deleting a render actually does.
The Fire Render modal offers HD (labelled Free), FHD and 4K. Three additional 360 buttons (HD 360, FHD 360, 4K 360) appear only when the 360-tours feature is enabled for the org; their outputs are panoramas that can later be combined into 360 tours. On firing, the design is saved first (camera + lighting snapshot), then the job is queued: success shows '<quality> Render added to the queue. Check Gallery under the Render tab.' The Gallery polls progress and can show a completion percentage, queue position and ETA; when the free HD slot is busy, a waiting render shows its estimated place in line (with a note on which project/design is holding the slot) and can be cancelled from the Gallery. The Gallery refreshes as soon as any polled render completes or its enhancement status changes. Big gotcha: while a render is pending, its Gallery thumbnail is a plain 3D screenshot generated locally from the render's saved camera - clients regularly mistake this flat, unlit preview for a failed or low-quality render. The ray-traced image replaces it on completion, and a completion alert offers 'View Image' and 'Open post processing'; if the optional upscale step fails, the alert still links the enhanced image rather than a missing 4K file. If the subscription is expired, firing is blocked with a 'Your subscription has expired' message. Each render's info panel records name, timestamp, aspect ratio, quality, number of attempts, total render time, and the exact lighting settings used - the first place to look on any 'render looks wrong' ticket.
When a user deletes renders from the render gallery, the backend does a soft hide: it sets visible=false on those render records via remove_from_visible. The render row, its parameters (camera, quality, samples), its attempts history, and the output image file all remain in storage. The one exception is a render still waiting in the fair-use HD queue (held, not yet started): deleting it also cancels it, so it will never be promoted and rendered. Two support consequences. Recovery: if a client deleted a render by mistake, it can be restored — engineering can flip visibility back, and the enterprise APIs get_all_of_design / get_by_id still return hidden renders because they do not filter on visibility, so the output file path is always retrievable. Billing: hiding is not a refund; usage is calculated from completed renders in the period regardless of visibility, so a deleted-but-completed render still appears on the usage statement — set that expectation explicitly when a client asks to "remove it from my bill". The flip side matters for privacy-sensitive clients: deleting from the gallery does not purge the image from storage, so genuinely removing an output image requires an engineering request rather than the in-app delete.