On Demand Render - FAQ
Quick summary
On-Demand Rendering is an alternative rendering pipeline for cases where pre-rendering every possible image or frame is too expensive. Instead of generating all outputs in advance, Cylindo renders the requested image when it is needed.
ODR is best suited to highly configurable products, dynamic scene use cases, and selected 360 viewer experiences where customers can accept a few seconds of latency in exchange for more flexibility and lower upfront rendering cost.
It is not a replacement for the traditional pre-rendered pipeline. Pre-rendered delivery remains the right fit for high-volume, performance-sensitive, high-resolution use cases.
Answers to common questions
What is On-Demand Rendering in simple terms?
On-Demand Rendering lets the platform create an image only when someone requests it, instead of pre-rendering and storing every possible image ahead of time.
This makes it possible to support products and scenes that would otherwise be too costly or too complex to render in advance, especially when the number of possible combinations is very large.
Why is ODR relevant for Cylindo’s customers?
To support highly configurable products where full pre-rendering is impractical
To enable dynamic scene-based experiences such as Modular Designer and selected viewer scenarios
To reduce upfront rendering cost for customers
To create more flexible commercial models based on usage or capacity
To expand Cylindo into visualization scenarios that do not fit well with the traditional pre-rendered pipeline
What customer problem does ODR solve?
ODR solves the problem of combinatorial explosion. Some products have so many possible variations, frames, materials, or scene combinations that pre-rendering everything becomes too expensive or operationally unrealistic.
In those cases, ODR allows us to render only the combinations that are actually requested.
What are the main use cases today?
360 viewer experiences for products where pre-rendering every frame is too expensive
Dynamic scene generation in Modular Designer
Customer demos for complex configurable products that would otherwise be difficult to support with pre-rendering
Is ODR replacing pre-rendered images?
No. ODR is a complementary pipeline, not a full replacement.
Pre-rendered images are still the better choice when the experience requires very fast response times, high image resolution, broad frame coverage, or a polished interaction model that depends on instant image delivery.
How does ODR work at a high level?
A client requests a specific configuration, frame, or scene output
The request is passed through CAPI into the ODR pipeline
The system prepares the render using the relevant assets, camera, lighting, and requested output settings
A render instance generates the image server-side
The result is returned to the client and may be cached for reuse
What performance should we set expectations around?
The documented target has been approximately 12 seconds per image, with prototype results averaging around 7 seconds in the tested setup. Actual end-to-end timing depends on startup time, traffic, infrastructure, and the specific render request.
The key enablement message is that ODR is designed for flexibility, not instant response. Customers should expect a short wait, not an immediate pre-rendered-like transition.
What image quality and resolution does ODR support?
The current working position is 1K resolution for ODR. This is the recommended and aligned setup because it provides the best balance between quality and response time in the current implementation.
Higher resolutions such as 2K or 4K are not the current focus and are considered impractical for this version due to render-time and cost trade-offs.
Do not position ODR as a 4K replacement. For now, it should be described as a lower-resolution, server-side rendering option optimized for flexibility and supportability.
Can customers zoom in the viewer?
No, zoom is currently disabled for ODR products in the viewer.
This is a deliberate product decision tied to the current 1K rendering approach. The viewer should not imply a higher-resolution experience than the rendered output can support well.
How does the viewer behave when users click through multiple options quickly?
The system is designed to avoid wasting rendering capacity on obsolete requests. If a user makes several rapid changes, only the latest relevant request should be rendered while older duplicate or superseded requests are discarded.
This helps prevent queue buildup and keeps the experience more stable under active interaction.
Does ODR use caching?
Yes. Finished configurations can be cached so that subsequent requests for the same combination do not need to be rendered again.
This improves repeat performance and is an important part of making ODR viable for practical usage.
How does infrastructure scale?
The current documented setup starts with four servers per customer for rendering requests. This can be scaled up if needed, but higher throughput requires more infrastructure and comes with cost implications.
One important limitation is that, in the documented setup, one running instance handles one request at a time. That means concurrency planning matters.
What happens if a customer needs more frames or more throughput?
That is possible in principle, but it is not free. More frames and faster throughput require additional infrastructure capacity and should be treated as a scoped commercial and technical discussion rather than a default capability.
For the current viewer implementation, the default has been kept intentionally conservative to preserve performance and supportability.
Which products are a good fit for ODR?
Products with very large numbers of configurations
Products where pre-rendering every combination would be too expensive
Products used in dynamic scene-building workflows (For example: Modular Designer)
Use cases where 1K output is acceptable
Experiences where a few seconds of wait time is acceptable to the customer
Which products are not a good fit for ODR?
Products that require a premium high-resolution viewer experience today
Use cases where instant interaction is critical
Products whose complexity causes scene instability beyond rendering alone
Legacy setups that would require disproportionate migration effort without clear business value
Does ODR support group products?
Yes. Group product compatibility has been validated and is considered supported in the current direction.
Are all materials compatible?
Not automatically.
Newer materials created in CMS are described as fully compatible with the ODR pipeline. Older material setups may require manual conversion by the material team so that the rendering output behaves correctly.
In order to check for a specific customer’s compatibility of materials, navigate to their material gallery and check on the compatibility for Post tool, Only full compatibility Materials are supported on the ODR pipeline.
Materials with highly limited or limited compatibility might display differently on the ODR pipeline.
A manual conversion needs to be assessed for customers who have non compatible materials.
Do ODR and legacy pre-rendered versions live together in the same product?
The current internal guidance is to avoid mixing the two approaches in ways that create conflicts. For existing products transitioning to ODR, separate product versions may be required, with the legacy version sunset as part of a managed migration plan.
What production or technical constraints should we mention carefully?
1K is the current supported quality target
Zoom is disabled
There is unavoidable latency compared with pre-rendered delivery
Concurrency is constrained by available rendering instances
Material conversion may be needed for older assets
Some complex products may need new scene setups rather than direct migration
Very high mesh counts can still create instability regardless of rendering mode
What should we say if someone asks about 4K?
Say that ODR is not currently positioned for 4K delivery. The present focus is 1K because that is where the quality, performance, and infrastructure trade-off is currently supportable.
If a customer requires 4K, the default recommendation should still lean toward traditional pre-rendered delivery unless a future ODR capability is specifically planned and validated.
What should we say if someone asks whether this is for every customer?
No. ODR is best positioned for selected customers and use cases where configurability and rendering flexibility matter more than immediate delivery speed.
It is especially relevant when the cost of full pre-rendering is the core obstacle to moving forward.
How is this different from a standard render service?
ODR is built into Cylindo’s broader visualization platform. It uses existing product configuration structures, camera setups, lighting setups, asset pipelines, and delivery workflows instead of acting as a standalone rendering utility.
That means the value is not just “we can render on a server,” but “we can render specific configurable product experiences inside the platform customers already use.”