Two rendering platforms can tout their software to render ‘in real time’ yet denote different things. One can mean that a designer's viewport updates as they adjust a material while the other allows a customer’s phone to redraw a 3D model as they rotate it in their hand. The two have different performance targets, optimization work and hardware constraints. If you scope a project around the wrong one, you'll likely end up budgeting hardware or mapping out a timeline for a problem you don't have. This article breaks down how both serve different purposes, then covers how real-time rendering works and what shipping one to a customer takes.
What is real-time 3D rendering?
It refers to any rendering method that is fast enough to redraw a scene as you interact with it, typically at a rate that feels immediate to an end user. Instead of waiting minutes or hours for a single image, you see the effect of rotating the camera or swapping a material happen almost instantaneously.
Live viewport vs. deployed real-time: two different things
Real-time rendering can take two forms in product design projects and they often get mixed up because they are backed by a similar technology. However, they serve completely different purposes with one being a tool for use and the other, a product you ship.
The first is a live preview inside your design software. It is the viewport you watch while building materials and lighting and which runs on your workstation. It never has to be in contact with a customer's hardware. The second is a deployed, customer-facing experience. It can be in the form of a web configurator on a product page, an AR view through a phone camera, or a VR walkthrough. This version runs on a device and over a connection you don't control, and very likely in front of someone who will close the tab if it stutters.
A viewport that runs smoothly on an RTX-equipped workstation tells 3D designers nothing about how the same asset performs on a customer's three-year-old laptop or mid-range phone. Most real-time projects that stall in development do so at this gap, in which a team demos a beautiful live preview internally then discovers the same file brings a mobile browser to a crawl. The two builds are related but not interchangeable. One common scoping mistake is treating them as one project instead of two.
Rasterization vs. ray tracing vs. AI denoising: how real-time rendering works
Most engines still lean on rasterization where rendering data gets projected into 2D screen space and filled in pixel by pixel, using shortcuts tuned for speed over physical accuracy. GPUs have been built around this technique for decades, which is why it's still the default and why it's cheap to run at high frame rates.
Ray tracing calculates how light bounces around a scene and used to be too slow to run interactively in the past. Modern GPUs make sure that is no longer a problem with dedicated hardware that accelerates ray-tracing calculations, while denoising and image-reconstruction techniques can reduce the amount of computation needed for a clean final frame. NVIDIA's RTX hardware, for example, uses RT Cores for ray tracing and Tensor Cores for AI-based workloads. DLSS is also an AI-powered upscaling technique that can also render at a lower internal resolution and reconstruct the image at a higher output resolution, trading some image fidelity for performance.
For deployed web experiences, rendering operates through a browser graphics API such as WebGL or the newer WebGPU. This is typically through a framework like Three.js that handles the scene, camera, and lighting setup without hand-written graphics code. It takes careful optimization to get that scene to the browser efficiently. CAD data and textures typically ship as glTF or its binary form, GLB. Draco compression can then shrink that file further by re-encoding the mesh data efficiently before it can reach the customer. For a configurator with several material or color options, the glTF extension KHR_materials_variants lets a single file store multiple material sets and switch between them instantly. A single file can therefore contain multiple material sets rather than requiring a separate model file for every color a customer picks.
Many modern real time renderers run a hybrid workflow that uses rasterization for speed then ray tracing layered on top for the reflections and shadows that rasterization can't do well enough for the eye on its own.
What real-time rendering gets you (and what it's measurably worth)
The foremost benefit is iteration speed. A material or lighting change shows up the moment you make it and this shortens review cycles and closes the gap between a design decision and seeing whether it works.
Real-time is what makes several customer-facing formats possible beyond internal review. Configurators can apply a color or finish instantly instead of switching between a fixed set of pre-rendered photos, while sales tools can let a rep spin a product on a tablet mid-meeting without a folder of static images. Additionally, AR try-on takes the same principle further, placing a product in a customer's actual space through their phone camera and updating the render as the camera feed changes.
There have been recent practical applications for AR’s commercial use case. A Shopify case study reported that pet-products retailer Gunner Kennels added AR to let shoppers place a life-size 3D model of a dog kennel next to their pet before buying, and the company's return rate dropped 5%. A five-point drop sounds modest until it's set against the scale of online retail returns. NRF and Happy Returns projected that 19.3% of online sales would be returned in 2025—it’s a high enough rate that against total U.S. e-commerce sales, implies well over $200 billion in returned merchandise. For a product where size is difficult to judge from a photograph, letting shoppers see the product at life size before checkout addresses a big source of purchase uncertainty: will the product fit?
Real-time rendering trade-offs: polygon budgets, file size, and hardware limits
Real-time has a quality ceiling that offline rendering doesn't. Given unlimited time, a render can resolve the subtle caustics and (photorealistic material behaviors) that a 60fps (about 16 milliseconds) frame budget can't fit. Senior designers should consider these constraints before committing a project to one approach over the other.
Shipping a real-time experience to a customer adds constraints a design-tool viewport never has to deal with:
| Constraint | What it means | What to measure |
| Level of detail (LOD) | Multiple versions of the same model at falling polygon counts, swapped automatically as the camera moves further away | LOD count and performance gain |
| File format and weight | glTF/GLB packages geometry, materials, and textures for the browser; Draco compression shrinks it further | Asset size and load time |
| Platform-specific export | iOS AR requires a USDZ file alongside the GLB; Android and web use GLB directly | Formats and device compatibility |
| Hardware dependency | The experience has to run on whatever device the customer owns | Frame time, memory, and device performance |
A CAD export straight out of a design tool can easily carry a few million triangles. Getting that down to a fraction of its original complexity for a mobile configurator is a deliberate simplification pass that is usually done by hand for anything with fine detail like knurling, stitching, or ventilation. This is because automatic decimation tends to flatten the particular details a customer is trying to inspect.
Where real-time rendering fits in a product design workflow
Real-time shows up at more than one stage of the same project and no two stages are the same.
CAD comes in first, brought into a rendering tool with a live viewport. From there, materials and lighting get adjusted and judged in real time during live review, before anything is finalized. Tools like KeyShot provide this kind of live render view, making it useful for evaluating materials and lighting during design review.
The stage that gets skipped under deadline pressure is optimization. It consists of decimating the same asset into LOD tiers, retexturing it, and converting it into glTF/GLB plus USDZ if AR is part of the plan. If designers skip this step, they might later find that the asset that impressed everyone in review either fails to load on mobile or loads so slowly that customers abandon it before it finishes. After optimization, the asset then gets published into a configurator, AR viewer, or VR experience where those performance constraints can be tested against the target platform.
Real-time vs. offline rendering: is real-time enough on its own?
For iteration and interactive customer experiences, yes. For a hero marketing image or a print-quality still, usually not, because that's where the visual limitations of real-time rendering become most apparent. An offline render has no frame budget to hit, so it can resolve fine reflections and lighting nuances that a 60fps scene has to compress or skip. Most 3D design teams combine real time and offline rendering workflows in the same project: real-time for review and interaction, and offline for the final images that need to pass full resolution and close scrutiny.
FAQ
What is the difference between pre-rendered and real-time rendering? Pre-rendered images are calculated once offline, with no limit on how long the computer takes. This is why they can resolve details a real-time frame can't. Real-time rendering recalculates the image on every frame dozens of times a second, which caps how much detail it can resolve in exchange for letting someone interact with the scene live.
Does a real-time viewport mean a 3D model is ready for a web configurator or AR? No. A model that runs smoothly in a designer's viewport may still need substantial optimization for a browser or mobile device. CAD geometry, textures, materials, file size, and LODs all affect performance. The same source asset can therefore require a separate optimization pass before it is ready to ship.
Can CAD models be used for real-time rendering? Yes, but CAD data usually needs to be converted and optimized first. CAD models are built for engineering precision and can contain far more geometry than a real-time experience needs. The model may need simplification, materials and textures, and conversion to a format such as glTF or GLB for web delivery.
What affects real-time 3D rendering performance? Polygon count is only one factor. Texture size, material and shader complexity, lighting, the number of objects in a scene, file size, and device capability can all affect performance. For a deployed experience, the useful test is whether the asset loads quickly and stays responsive on the devices customers are actually using.
Want to see what real-time rendering looks like during the design process? Try KeyShot free and explore how materials, lighting, and camera changes update interactively in the viewport.
Header image: KeyShot bicycle render concept by David Borovic
