IES Lighting Simulation App
-- Test a Fixture Before You Buy
IES Lighting Simulation App: Test a Fixture Before You Buy
The full workflow for checking a luminaire has not changed in decades: open DIALux, build the 3D scene, set the parameters, wait for the render. Thirty minutes on a good day, half a day when the scene gets busy. We built the IES lighting simulation app to shorten the first pass, not the last one. Upload a photometric file, set the pole, and see where the light lands in minutes, on a phone or in a browser.
This page walks through what the app does with that file, what the numbers mean, and the line it refuses to cross.
What an IES file is, and why the app will not guess without one
An IES file is the standard photometric data format published by the Illuminating Engineering Society. It carries three things a datasheet never does: the luminous intensity distribution across C-planes and gamma angles, the total luminous flux, and the luminaire's physical dimensions. The intensity distribution is the payload, because it is what determines the shape of the light on the road.
Without that file, any tool can only estimate from wattage and total flux, and those estimates get the spot shape wrong. Two fixtures with identical lumen output throw completely different patterns, one batwing and one cosinusoidal, and the difference decides whether light lands on the roadway or in the windows across the street. The app refuses to run without the file. We publish standard IES files for every solar street light and LED lens we make; any reputable manufacturer will do the same, and the file is usually a download away on their site.
What to prepare before the first run
| Input | Where it comes from | Typical values |
|---|---|---|
| IES file | Luminaire manufacturer | One file per fixture |
| Pole height | Design drawings | 6–12 m |
| Pole type | Design drawings | Conical or stepped |
| Ground type | On-site observation | Asphalt, concrete, or grass |
| Luminaire tilt | On-site or design | Set in the Lighting panel |
The five panels
The app runs on bottom navigation with five panels, and each maps to one step of the check:
- Map (optional). Attaches the project's geographic location so the final report carries location metadata.
- Upload. Selects the IES file from local storage, parses the header, and shows the key metrics: model, luminous flux, wattage.
- Lighting. Sets pole height, pole type, and luminaire tilt angle, then renders the scene in real time through Three.js. Rotate and zoom freely to inspect the distribution from any angle.
- Illuminance. Calculates ground lux on a grid, draws isolux lines that behave like topographic contours, and reports minimum, maximum, and average lux plus uniformity (minimum divided by average).
- Report. Assembles the scene screenshots, lux charts, and parsed IES metadata into a document that exports to PDF or shares on the spot.
Reading the numbers: lux and uniformity
Illuminance arrives in lux, lumens per square meter. The app's numbers only mean something against a target, so these are the reference ranges we use in early screening, subject to the project's governing standard:
| Area | Typical average target |
|---|---|
| Main roads | 20–30 lx |
| Secondary roads | 10–15 lx |
| Residential streets | 5–10 lx |
| Pedestrian sidewalks | 5–10 lx |
| Plazas and squares | 10–20 lx |
Uniformity, the minimum-to-average ratio, carries as much weight as the average. Road lighting practice generally looks for 0.3 to 0.4 or better. A road that averages 25 lx but dips to 5 lx between poles is a worse driving environment than one averaging 18 lx with a 0.45 ratio, because the eye is forced to re-adapt at every dark band, and drivers arrive at the end of the corridor fatigued. That is the failure mode a uniformity number catches and an average alone hides. For a deeper treatment of why the simulation step exists at all, our lighting simulation reference covers the method, and the selection guide shows how we use it when quoting.
When the 3D result looks wrong
Three settings cause almost every bad-looking scene, and they are worth checking in order:
- The IES file belongs to a different luminaire model than the one on the quote.
- The pole height in the scene does not match the site.
- The luminaire tilt does not match the real installation, and tilt moves the spot more than most people expect.
Comparing two fixtures side by side
Upload them in sequence and compare on the same pole height: spot shape and effective coverage area, lux values, uniformity, and what the 3D preview shows. In front of a client, the first question is always the spot shape, because it is the one thing a photograph settles in seconds.
Where the app stops
The app is a screening and demonstration tool. It does not replace DIALux for compliance sign-off. When a project needs formal municipal approval, our engineering team produces the full DIALux verification report, and we say that in the proposal rather than letting the app's output imply more than it is. What the app does well is the first pass: it filters out the wrong optic in seconds, in front of the client, before anyone books the rendering time. If you want the quick version, the live tool runs in the browser; if you want the hardware those optics ship in, start from the all-in-one solar street light line.
What this page does not cover
This page covers the app's workflow and metrics. It does not cover the road lighting standard your project must certify against, which is a local code question, and it does not replace the photometric laboratory testing that verifies a luminaire's published IES file in the first place.