The renderer — a believable rig in a browser, on the hardware you actually have
FlexViz draws a lighting rig in a browser tab: beams, gobos, colour and the way they land on surfaces. The target is optical credibility, not photorealism — a designer should recognise their rig and trust what the beams are doing, without anyone pretending a browser is a render farm. The part that takes the most work is not the picture, it is keeping that picture honest across the machines it has to run on.
- BELIEVABLE, NOT PHOTOREAL
- The goal is a rig you recognise and beams you can trust, not a render that survives being paused and pixel-peeped. That choice is what keeps it interactive.
- THE WHOLE PROFILE, NOT THE FIRST FOUR CHANNELS
- Whatever the GDTF carries is made visible: colour wheels, colour mixing, gobo wheels including the selected index and its rotation, iris, zoom and frost. A fixture does not quietly lose half its personality on the way into the browser.
- GEL COLOUR YOU CAN STILL SEE
- Filter transmission is handled optically rather than physically. Lee Congo Blue takes roughly 98% of the light out; rendered literally it would be correct and useless — a beam that has technically been drawn and is practically invisible. FlexViz darkens it hard and then stops, so the beam stays readable and the colour stays recognisable. It is a deliberate departure from physical accuracy, made in the one place where being right would cost you the picture.
- STAND-INS WHEN A PROFILE HAS NO MESH
- A GDTF profile that ships without geometry does not become an anonymous box. A small library of generic fixture models steps in — PAR 64, a Source-Four-style profiler, an ARRI-L10-style Fresnel, audience blinders — so the plan still reads correctly.
- IT RUNS WHILE YOU WORK
- Rendering is not a separate step you wait for — the scene is live while you patch, rig and move fixtures. Rigs of 80 or more fixtures are not currently a problem. «ZU BESTÄTIGEN: Sobald aus der Beta belastbare Zahlen da sind, hier eine harte Angabe setzen — ‚N Fixtures bei M fps auf Gerät X'. Das ist der Satz, den Leute zitieren.»
- WEBGPU ONLY WHEN IT ACTUALLY RENDERS
- A browser reporting WebGPU support is a statement about an API, not about a working pipeline. FlexViz requests the adapter and then draws an invisible test frame with it. If that frame does not come back, the browser's claim is ignored and rendering moves to WebGL2 — before you are standing in front of a client wondering why the viewport is black.
- WEBGL2 IS A REAL PATH, NOT AN ERROR PAGE
- The fallback is a working renderer, not a warning. It runs well on an Intel 4th-generation Core integrated graphics controller at 1.20 GHz — a 2013 laptop chip. If the machine in the production office is older than the show file, it will still draw the rig.
- WHERE THE TWO DIFFER
- Beams are the one visible difference. The WebGPU path raymarches them; on WebGL2 that costs more performance than it returns, so the beams are drawn differently and look somewhat different. Everything else — the rig, the patch, the plan, the colour — is the same scene either way.
- MEASURED, NOT ASSUMED
- Renderer performance is tracked with frametimes and p95 rather than impressions, and changes are kept or reverted on that evidence. Currently I'm tracking numbers on it, they'll appear soon.
Depends on
A current browser. There is no hard minimum beyond that — a reasonably current GPU gets you the WebGPU path, and the WebGL2 path is not a consolation prize: it runs well on an Intel 4th-generation Core integrated graphics controller at 1.20 GHz, which is a chip from 2013.
Not yet
No photorealism, and no attempt at one — this is not a Depence rebuild in a browser. Beams do not look identical on both backends: the WebGL2 path skips raymarching because the cost is not worth it there. The exact performance envelope — how many fixtures at what framerate on what hardware — is what the private beta is currently establishing, so this page does not yet make a promise it cannot back.
Open your own MVR against this and tell me where it breaks.