RFC: Native Photometric Lighting for Bevy

[holg]

RFC: Native Photometric Lighting for Bevy

Summary

A proposal to add per-fragment photometric light profiles to Bevy — evaluating real measured luminaire distributions (IES/LDT/TM-33) directly in the PBR shader, rather than approximating with cubemap cookies or multiple spotlights.

Live demo (WebGPU required): https://iesna.eu/photometric_wip.html
Controls: 1-5 switch modes, H toggles heatmap, [/] switch LDT profiles, WASD/arrows camera

The Problem

No real-time engine properly supports photometric light profiles:

• Unity/Unreal: Bake IES into a cubemap cookie — projective, not angular. Loses accuracy at grazing angles, breaks for area lights, doesn't support LDT or TM-33.
• Current Bevy workaround (eulumdat-bevy): Approximates with 5+ SpotLights per luminaire. Works for previews, but fundamentally wrong for asymmetric distributions (road lights, wall washers).

Architectural visualization, digital twins, and lighting design tools need accurate photometric rendering. Bevy's ECS architecture and WebGPU backend are well-suited for this.

Proposed Approach

Per-fragment angular intensity lookup

Instead of projecting from the light's perspective (cubemap cookie) or approximating with multiple spots, sample a 2D intensity texture at every fragment:

1. CPU (load time): Parse IES/LDT file → resolve symmetry, C-plane rotation, Type B→C conversion → generate R16Float equirectangular texture (C-plane × gamma)
2. GPU (every frame): In point_light(), convert light-to-fragment direction to (C, gamma) in luminaire local space → sample the texture → modulate intensity

// In point_light() — the core addition
let frag_dir = normalize(P - light.position);
let local_dir = inverse_rotation * frag_dir;
let gamma = acos(-local_dir.y);                    // 0 = nadir
let c_angle = atan2(local_dir.x, local_dir.z);     // azimuthal
let uv = vec2(c_angle / TAU + 0.5, gamma / PI);
let intensity = textureSample(photometric_texture, sampler, uv).r;

Format support

Format	Standard	Status
IES (LM-63)	ANSI/IES, all versions 1991-2019	WIP prototype
LDT (EULUMDAT)	European standard	WIP prototype
TM-33 (ATLA S001)	Modern XML/JSON replacement	Planned

ECS design

Compositional — not a new light type:

commands.spawn((
    PointLight { intensity: 15000.0, ..default() },
    PhotometricLight { profile: asset_server.load("luminaire.ldt") },
    ColorTemperature::new(3000.0),  // Kelvin → sRGB on CPU
));

Comparison Table

Feature	Unity	Unreal	Bevy (current)	Bevy (proposed)
IES profiles	Cubemap cookie	Cubemap cookie	Multi-spot approx	Per-fragment lookup
LDT (EULUMDAT)	No	No	Multi-spot approx	Per-fragment lookup
Evaluation method	Projective	Projective	N spots	Angular, per-fragment
Area light + photometric	No	No	No	LTC + angular modulation
Color temperature	Component	Property	Manual RGB	ColorTemperature component
Lights per luminaire	1	1	5+	1

Implementation Status

WIP Prototype

• ColorTemperature component (Kelvin → linear RGB, Planckian locus approximation)
• PhotometricProfile asset type (R16Float equirectangular texture)
• IesLoader / LdtLoader — basic parsing, symmetry expansion, needs validation
• GPU pipeline scaffolding (descriptor buffer, bind group entries, shader code) — not yet validated end-to-end
• Extraction wiring (photometric index packed into GpuClusteredLight::flags upper 16 bits)
• Feature flag: pbr_photometric_lights

The heatmap visualization in the demo shows the correct CPU-side sampling. The GPU shader path needs further work to match.

Prerequisites (PRs open)

• Skip dynamic cluster resizing when GPU clustering is active #23439 — Skip dynamic cluster resizing when GPU clustering is active
• Enable partial bindless on Metal and reduce bind group overhead (#18149) #23436 — Enable partial bindless on Metal, reduce bind group overhead

Composes with

• Move PointLight to LTC #23400 — LTC PointLight (merged into our experimental branch — photometric modulation × LTC area light evaluation)

Phased Roadmap

1. ColorTemperature — standalone, small PR
2. Asset loaders (IES/LDT) — medium PR, no rendering changes
3. GPU photometric sampling — core PR, shader + bind groups + extraction
4. LTC area lights + photometric — builds on Move PointLight to LTC #23400
5. Spectral pipeline — long-term (multi-band rendering, SPD textures)

Questions for Discussion

1. Should photometric profiles reuse the existing light texture (cookie/decal) system, or be separate? We chose separate — cookies are projective (local_from_world * pos), photometric is angular (inverse_rotation * normalize(dir)). Different parameterization.

2. Where should format parsing live? Currently in bevy_light. Could be a separate bevy_photometric crate.

3. How to handle the C-plane orientation ambiguity? IES and LDT define C0 differently, and manufacturers don't always follow the convention. Our current approach: no automatic rotation, user rotates via Transform.

4. Binding budget on Metal/WebGPU — photometric adds 3 bindings to group 1 (slots 8-10). Our Enable partial bindless on Metal and reduce bind group overhead (#18149) #23436 PR frees headroom for this.

References

• Design document (full technical detail in the eulumdat-rs repo)
• ANSI/IES LM-63-2019 — IES file format standard
• EULUMDAT specification — European luminaire data format
• LTC paper — Heitz, Hill, McGuire 2016
• Live demo (WebGPU required)

[mate-h]

This is an excellent writeup and I like to overall vision. It will definitely unlock more use cases for bevy like architecture visualization! I have a couple of questions, suggestions.

ColorTemperature: I think this should be a feature of bevy_color rather than an ECS component on the lights. and then you pass the resulting sRGB color to the light. As for how to design that API is up for debate since color temperature is not really a "color space" so it would have to be some simple utility struct / function. As for how to approximate color temp, can potentially be complex algorithmically. maybe Bevy repo is not the best place to maintain this sort of code, and the code-saving approach would be to pre-compute a 1D lookup texture and put it behind a feature flag as an embedded asset (similar to the STBN LUT), or have users copy it into their assets folder and supply it with an example. unless there is a need to dynamically compute this value (i.e. user customization, changing some kind of parameterization) I really don't see the value of maintaining Planckian locus approximation algorithm in-tree.

As for the photometric feature, I wouldn't gate it with a feature flag, instead rely on pipeline keys, shader defs to gate it . that is whether the user added that PhotometricLight component or not. And definitely we need the amount of additional bindings minimized. It's not entirely clear to me from this write-up why we need three additional bindings. to me 1 for the LUT and pack the remaining data into the existing light structs.

Spectral rendering pipeline: wow I am intrigued by the prospect of supporting full spectral rendering in bevy. This could be huge for simulating light dispersion for volumetrics and thin-film interference for materials. However it might clash with the overall vision for Bevy and this would need a wider scale discussion because would affect the whole PBR pipeline, introduce many challenges. It might be helpful to further specify what the real use case is for spectral rendering specifically in the cotext of archiviz and photometric light textures. Most cases I think can work around having to do a full spectral rendering pipeline.

[holg]

Thanks for the thorough feedback — great questions!

ColorTemperature:

The RFC proposes kelvin_to_linear_rgb() as a pure function in bevy_color and a thin ColorTemperature
component that calls it during extraction. The algorithm is ~30 lines of well-established math
(Planckian locus approximation). A 1D LUT would add more complexity (embedded asset, loading,
sampling) than the algorithm itself.
Worth noting that color temperature in lighting goes beyond a simple RGB tint — it relates to color rendering quality (CRI, TM-30 metrics) and spectral characteristics.
Two luminaires at identical CCT can render surfaces very differently depending on their spectral power distribution. A low-CRI sodium lamp and a high-CRI LED at the same 3000K make a red surface look brown vs red. The Kelvin→RGB function is the practical first step, but proper color rendering simulation requires per-light spectral metadata in the shader: which feeds into the binding architecture below.

For the feature, i agree, it must not be the feature it can be gated in many other ways, maybe even further on how bindings are processed, in general set the PHOTOMETRIC_LIGHTS shader def when any entity with PhotometricLight is extracted, similar to how LIGHT_TEXTURES is gated, or even further bindings, bcs

Bindings:

The three bindings serve physically distinct, non-reducible purposes:

1. Descriptor buffer — per-light inverse rotation matrix (to transform world-space light-to-fragment
   direction into luminaire-local Type C coordinates), texture index, peak intensity, and in the future
   CCT/CRI parameters for per-fragment color rendering simulation.
   This is the fundamental difference from cubemap cookies:
   the angular evaluation happens per-fragment in the luminaire's coordinate frame,
   not projected from the light's perspective.
   This per-light data cannot be packed into GpuClusteredLight without increasing its size for all lights, not just photometric ones.
   The separate buffer only costs memory for lights that actually use profiles.
2. Texture array:
   the measured 2D angular intensity distributions (R16Float equirectangular, one per unique profile, shared across lights).
   This is the photometric data.
3. Sampler: for the texture lookup.

Reducing bindings means losing either the per-luminaire angular evaluation or the color rendering fidelity,
which is the trade-off cubemap cookies make.
The WIP Demo
tries to visualizes why projective sampling produces different results from angular sampling,
particularly for asymmetric road luminaires at steep angles.

(For full spectral rendering, potentially more bindings would be needed, not fewer.)

Spectral rendering:

Sure the full spectral rendering pipeline is a separate long-term effort, not part of this proposal.
The photometric profile work operates in RGB.
However, as discussed in the bindings section, even within an RGB pipeline, per-light spectral metadata is needed to correctly simulate color rendering differences between light sources.
This isn't future data: CRI is available in all three format families:

• IES (LM-63 [CRI] keyword)
• EULUMDAT (color_rendering_group)
• TM-33/ATLA (TM-30 Rf/Rg metrics, the whole spectral data SPD).

The descriptor buffer is designed to carry this metadata alongside the angular distribution.
So regarding full spectral data vs CRI-based spectral data, CRI is doable quite more easily and most important:
the data is already available in every IES/LDT file. (unlike TM-33 where there is almost no data available)
That said, if it were that easy it would have been done across render engines already:
currently only specialized lighting design tools like Relux (where i worked for 13yrs), DIALux and AGI32 handle this correctly.

[mate-h]

Wow it's fascinating to read about this topic and thanks for the detailed response. I will have to do a bit more research to fully understand the terms and specifications you are referencing. I can see you are speaking from a lot of experience. I agree with all the points you made and this response filled in a lot of missing details for the proposal. Especially if that kelvin to RGB approximation is simple / short definitely better to keep the code rather than a LUT. You have my sign off! 👏
Feel free to tag me for reviews one the you figure out GPU side of the problem.

[holg]

Thanks,
i'll do my best, the next days i will be busy otherwise, i might think about starting with some small PR like color_temperature.
it would need some specific testing scene(s) as well and there are still much more design things in my mind, like luminous emitting area, which is not defined in any of these formats, but in L3D and as subset of it GLDF (for which again i have OpenSource/crates as well available...)