Asymmetric / Type B IES files in Enscape: limitation and workaround
After running into this issue and then browsing the forums a bit, it looks like this may be a known/accepted limitation rather than a brand-new bug: Enscape does not appear to fully support some asymmetric IES distributions, especially Type B theatrical/flood-style files with partial photometric webs.
I still wanted to document what I found, because the failure mode is not obvious at first. Revit can show a plausible photometric web, while Enscape renders something quite different.
Summary
A manufacturer-provided Type B IES file displays as a plausible photometric web in Revit, but Enscape renders the illumination as if the web is being mirrored/folded across one or more axes.
Instead of one continuous asymmetric wash, Enscape can produce separated lobes and sometimes a hard axis-aligned seam.
The workaround that produced a usable result was to convert the same photometric data into a Type C approximation, then rotate/counter-rotate the resulting web to move the problematic seam away from the useful part of the beam.
Example file characteristics
The example file is an LM-63-2002 IES file using Type B photometry.
Relevant main data line:
60 -1.00 1.730 45 23 2 1 1.015625 0.682292 0.000000
The important value is:
2 = Type B photometry
The file uses a partial angular web:
vertical angles: -90° to +90°
horizontal angles: 0° to 90°
This kind of asymmetric/partial Type B web seems to be where Enscape struggles.
For reference on the IES format and photometric types:
- AGi32 / Photometric Toolbox LM-63 format overview: IESNA LM-63 Format
- Sébastien Lagarde’s IES format notes: IES light format: Specification and reader | Sébastien Lagarde
Observed behavior
In Revit, the photometric web preview can be oriented so the distribution looks plausible relative to the fixture.
In Enscape, however, the actual rendered illumination does not match that preview. It appears as though the Type B web is being mirrored or folded in a way that loses the intended asymmetry.
Since new forum accounts can apparently only embed one image, I have performed the ancient ritual of compressing multiple pieces of evidence into one blessed mega-image:
Image guide:
- A — Original Type B IES. Revit’s displayed web looks like a single asymmetric lobe, but Enscape renders multiple separated regions of illumination.
- B — Axis/seam artifact. A hard line appears tied to the photometric coordinate system. Additional tests were done to check whether this was caused by the fixture model/geometry, but the artifact tracked with the photometric web orientation instead.
- C — Intermediate Type C approximation. Not perfect, but much closer, suggesting the source candela data is usable when presented differently.
- D — Final workaround result. Type C approximation plus baked Y-axis tip/counter-rotation produces the expected continuous cyc-style wash.
Expected behavior
The rendered illumination should correspond to the same photometric distribution shown by Revit’s IES preview.
For an asymmetric flood/cyc/theatrical-style fixture, the expected result is one continuous directional wash, not split mirrored lobes. The result in D is much closer to the expected behavior.
Workaround
To work around the limitation, I converted the same source data into a Type C approximation.
The workaround involved:
- Reading the original Type B candela data.
- Reorienting/flipping the data to match the desired fixture orientation.
- Remapping the distribution into a Type C-style
0°..180°vertical web. - Mirroring the useful asymmetric lobe into a full Type C horizontal web.
- Resampling to a regular angular grid.
- Baking a 90° rotation into the IES web, then counter-rotating the light source in Revit.
This is not a certified photometric conversion. It is a rendering workaround. The goal was not to create a legally/photometrically authoritative file; the goal was to get Enscape to render something closer to the actual fixture behavior.
Workaround conversion pseudocode
for each source IES file:
read IES header
read main photometric line
read ballast / watts line
read vertical angles
read horizontal angles
read candela table
# Source file is Type B.
# Original vertical angles are approximately -90..+90.
# Original horizontal angles are a partial web, approximately 0..90.
# Convert Type-B-style vertical angles into Type-C-style 0..180 angles.
source_vertical_type_c = original_vertical_angles + 90
# Flip vertical candela values because that matched the fixture orientation
# seen in Revit during testing.
for each horizontal candela row:
flipped_row = reverse(original_row)
function sample_source(horizontal_0_to_90, vertical_0_to_180):
clamp horizontal to 0..90
interpolate between source horizontal planes
interpolate between source vertical angles
return candela
function type_c_approximation(type_c_horizontal, type_c_vertical):
relative_angle = (type_c_horizontal - 180) mod 360
if relative_angle is between 0 and 90:
return sample_source(relative_angle, type_c_vertical)
else if relative_angle is between 270 and 360:
return sample_source(360 - relative_angle, type_c_vertical)
else:
return very_small_value
output_horizontal_angles = 0, 2.5, 5.0, ... 360
output_vertical_angles = 0, 2.5, 5.0, ... 180
set output photometric type = 1 # Type C
for baked_y_rotation in [+90 degrees, -90 degrees]:
for each output horizontal angle H:
for each output vertical angle V:
direction = spherical_to_vector(H, V)
# Bake a Y-axis rotation into the photometric web.
# To rotate the emitted distribution by +90, sample the
# unrotated approximation at -90.
source_direction = rotate_y(direction, -baked_y_rotation)
source_H, source_V = vector_to_spherical(source_direction)
candela = type_c_approximation(source_H, source_V)
write candela to output table
write new IES file with:
same descriptive header
TILT=NONE
photometric type = 1
new horizontal / vertical angle counts
new angle lists
generated candela table
The pseudocode is included mostly to explain the logic, not because anyone should have to manually do this by hand. An AI/code assistant can turn it into a usable script
pretty easily, assuming you are willing to test the results against your fixture orientation.
What I think this means
I do not think the Type C workaround is the “correct” photometric answer. It is more like translating the IES into a dialect Enscape is willing to speak to make some pretty pictures.
The interesting part is that the same underlying candela data becomes much more believable once it is presented to Enscape as Type C and moved away from the troublesome axis.
same basic distribution data
+ different photometric coordinate presentation
= dramatically different Enscape behavior
That suggests the limitation is in Enscape’s handling of asymmetric Type B photometric axes/symmetry, not in the source data itself.
Practical impact
For normal architectural lights this may never show up. Most downlights, troffers, pendants, etc. are Type C already.
But for theatrical, flood, projector-like, or asymmetric specialty fixtures, Type B files are common. Those are exactly the fixtures where orientation matters the most. If Enscape folds or mirrors the web incorrectly, the rendered result can be very misleading even though Revit’s preview looks reasonable.
Closing thought
This may already be known behavior, but if so, it would be helpful for Enscape’s documentation to say more explicitly what kinds of IES asymmetry are and are not supported.
Also, for transparency: this writeup, the conversion pseudocode, and the test-script logic were written with help from Codex. If your slop senses were tingling, congratulations: they are calibrated and functioning. I did the Revit/Enscape testing and sanity-checking against how the fixture should behave in the real world. Codex did a lot of the heavy lifting on parsing, generating, and iterating the IES files. I probably would not have gotten to this workaround without that help.
The useful question is probably not “is my exact workaround correct?” It is:
What level of asymmetric / Type B IES support should users expect from Enscape?
Right now, the answer seems to be: enough for some cases, but not enough for this one.