EXT_lights_ies #2200

tblutNV · 2022-09-05T07:05:55Z

This extension adds support for referencing and storing IES light profiles and using them as point lights. IES light profile files are used as-is, similar to how PNG and JPEG images are used.

There are still some open questions regarding a valid MIME type for IES light profiles and if any additional properties are required to cover the needs of most users.

We don't want to force applications to fully support KHR_lights_punctual in order to implement this extension. Therefore, we choose to not extend KHR_lights_punctual, but rather make this a standalone extension. However, we are open for discussing the possibility to make extending punctual lights optional. The main benefit would be that spot lights could be enhanced with light profiles as well.

{
    "nodes": [
        {
            "extensions": {
                "KHR_lights_punctual": {
                    "type": "point",
                    "color": [ 1.0, 0.8, 0.6 ],
                    "extensions": {
                        "KHR_lights_ies": {
                            "profile": 0,
                            "useProfileIntensity": true, // if "true" then ignore the light's intensity
                            "multiplier": 1.2, // non-negative intesity scale factor
                            "orientation": [0.707, 0, 0, 0.707] // rotation of the light profile
                        }
                    }
                }
            }
        }
    ]
}

An addition here could be the useProfileIntensity property to allow to either use the light profile's intensity or the punctual light's intensity.
In the case of using the punctual light's intensity the light profile's candela values must be scaled to the [0, 1] range: candelaValues /= max(candelaValues). These values can then be multiplied by the light's intensity and color.

Alternative Proposal for Storing IES Data

Based on the discussion and feedback received in the PBR TSG meeting on 8/29/2022, an alternative proposal is to store the relevant parts of the IES files directly in JSON. Metadata can be stored in the extras property with the keys being the field names as defined in the IES format specification in glTF-like camel case.

{
    "extensions": {
        "KHR_lights_ies": {
            "lights": [
                {
                    "photometricType": 1, // 1: "Type C", 2: "Type B", 3: "Type A"
                    "candelaMultiplier": 1.0, // balast_factor * multiplier, must be applied to all candelaValues
                    "verticalAngles": [ 0, 22.5, 45, 67.5, 90 ], // in degrees
                    "horizontalAngles": [ 0, 45, 90 ], // in degrees, cc or ccw depending on photometricType
                    "candelaValues": [ // in candela (lm/sr), column-major (vertical values first)
                        100000, 50000, 25000, 10000, 5000,
                        100000, 35000, 16000, 8000, 3000,
                        100000, 20000, 10000, 5000, 1000
                    ],
                    "extras": {
                        "test": "Test ABC",
                        "testlab": "Lab ABC",
                        "manufac": "Manufacturer ABC"
                    }
                }
            ]
        }
    }
}

We omitted the TILT data as we don't believe that it is relevant for most rendering applications.

We're looking forward to further discussions!

lexaknyazev · 2022-09-05T18:56:36Z

With regards to the topic of storage, i.e., external/embedded ANSI/IES LM-63 data vs JSON-inlined parameters, I think we need to consider the following two issues.

ANSI/IES LM-63 Lifecycle

The extension spec currently does not require any specific revision of ANSI/IES LM-63. This is quite an important detail since ANSI/IES LM-63 files contain the version string inside. Supporting all 5 versions is probably not feasible while supporting only the latest would make lots of readily available ANSI/IES LM-63 files incompatible with this extension. The reasonable middle-ground may be supporting both 2019 and 2002 version strings while explicitly excluding external tilt files from the latter.

It's worth noting though that the latest (2019) revision says the following:

This Standard will eventually be replaced by a new XML-based file format, ANSI/IES TM-33-18, Standard Format for the Electronic Transfer of Luminaire Optical Data (see Informative References). However, both Standards are valid until this transition is complete and this Standard has been deprecated.

We don't have a precedent of making and ratifying a new glTF extension that exclusively relies on a soon-to-be-deprecated external specification.

ANSI/IES LM-63 Scope

With external tilt files out of the way, there are still lots of ANSI/IES LM-63 fields that may or may not be relevant for glTF use. Normatively referencing an external spec generally means that implementations have to follow it even if some of its parts are not needed for glTF applications in practice. For example, ANSI/IES LM-63 data must always contain four required keywords (TEST, TESTLAB, MANUFAC, and ISSUEDATE), support both feet and meters, enforce max line length and CRLF line breaks, etc. Proper implementations would have to reject data not conforming to those rules even when deviations have no practical effect on glTF.

We should identify all glTF-relevant ANSI/IES LM-63 fields and keywords and evaluate whether providing them directly in JSON makes the new functionality more accessible for implementors. Alternatively, we should evaluate availability of open-source ANSI/IES LM-63 parser implementations, including test coverage for malformed inputs.

@tblutNV please comment on the applicability of the fields marked with ? below.

Field	ANSI/IES LM-63	glTF JSON
Version	`IESNA:LM-63-2002` or `IES:LM-63-2019`	not needed
TEST	required	not needed
TESTLAB	required	not needed
TESTDATE	optional	not needed
NEARFIELD	optional	?
MANUFAC	required	not needed
LUMCAT	optional	not needed
LUMINAIRE	optional	not needed
LAMPCAT	optional	not needed
LAMP	optional	not needed
BALLAST	optional	not needed
BALLASTCAT	optional	not needed
MAINTCAT	optional	not needed
DISTRIBUTION	optional	not needed
FLASHAREA	optional	?
COLORCONSTANT	optional	?
LAMPPOSITION	optional	?
ISSUEDATE	required	not needed
FILEGENINFO	optional	not needed
OTHER	optional	not needed
SEARCH	optional	not needed
MORE	meta	not needed
TILT	NONE or INCLUDE	not needed
TILT: lamp to luminaire geometry	1 or 2 or 3	enum / not needed
TILT: number of tilt angles	integer	not needed
TILT: angles	list of decimals	array of numbers / not needed
TILT: multiplying factors	list of decimals	array of numbers / not needed
number of lamps	integer	?
lumens per lamp	decimal	?
candela multiplier	decimal	number
number of vertical angles	integer	not needed
number of horizontal angles	integer	not needed
photometric type	1 (C) or 2 (B) or 3 (A)	enum
units type	1 (feet) or 2 (meters)	not needed
width	decimal	?
length	decimal	?
height	decimal	?
ballast factor	decimal	?
file generation type	`1` (2002) or decimal (2019)	not needed
input watts	decimal	?
vertical angles	list of decimals	array of numbers
horizontal angles	list of decimals	array of numbers
candela values	list of lists of decimals	flat array of numbers

lkettnerNV · 2022-09-12T20:04:59Z

lexaknyazev W.r.t. to the IES fields, we ignore in fact all fields in the meta data, the TILT section, number of lamps, lumen per lamp, units type, width, length, height, and input watts. We respect the ballast factor (it is multiplied on top of the candela multiplier). This should cover the questionmarks in the table.

A good observation is indeed that the IES standard does not include previous versions, most notably seen with the magic header. We would actually want to support all versions: IESNA91, IESNA:LM-63-1995, IESNA:LM-63-2002, IES:LM-63-2019.

lkettnerNV · 2022-09-12T20:14:00Z

More comments regarding a JSON encoding instead of referencing the IES file.

One could think of removing the photometric type altogether. They are basically just different orientations. In fact, we don't support type A, which is very rare (and can be converted to Type C in a suitable tool).

One could also think of reducing or eliminating the symmetry groups, basically unrolling the data to the full sphere (simplifying the use of the data at the cost of more storage). That can work from out perspective.

However, resampling to a different, e.g., equidistant set of angles would not be a good idea. A renderer will do that typically too, so we get two re-samplings that do not know of each other, and it can harm the original data in ways that would make it not possible for us anymore to rely on the new encoding alone.

lexaknyazev · 2022-09-13T05:17:29Z

We would actually want to support all versions: IESNA91, IESNA:LM-63-1995, IESNA:LM-63-2002, IES:LM-63-2019.

IIRC, there was also a 1986 version that did not have a version identifier inside at all. Supporting all of them would complicate implementations as there were a few breaking changes over time.

How would the extension normatively reference older revisions? Looks like they are not offered in the IES store.

aidinabedi · 2022-09-14T18:09:26Z

Hello! A quick curious question on a minor detail:

What's the reasoning behind introducing orientation in the schema?

At first glance it seems a bit redundant, when reading the following in the overview (am I missing something?):

The light profiles are referenced by nodes and inherit their transform. This also allows changing the light profile's orientation.

lkettnerNV · 2022-09-14T19:23:50Z

Indeed, we should adjust the wording in the description. We propose the additional orientation on the lightprofile since you want to orient it independently of the lumiere, there are for example ill oriented light profiles out there that you want to align.

aidinabedi · 2022-09-15T11:11:55Z

We propose the additional orientation on the lightprofile since you want to orient it independently of the lumiere, there are for example ill oriented light profiles out there that you want to align.

If there are ill-oriented light profiles out there, shouldn't that be solved in the data itself? Seems strange that glTF should handle bad external files (regardless if it's a light profile, texture, or raw binary). Unreal also supports IES but doesn't provide additional orientation (our philosophy is "garbage in, garbage out").

BruceCherniak · 2022-10-31T15:32:09Z

I have begun a draft PR for the file-format independent json representation here #2221

…standards and how the coordinate system relate

tblutNV · 2022-11-07T20:40:52Z

I updated the extension name from KHR_lights_ies to EXT_lights_ies. The commits also include some minor additions, clarifications and implementation details based on the feedback we received.

…made description of the coordinate system mapping more specific

extensions/2.0/Vendor/EXT_lights_ies/README.md

extensions/2.0/Vendor/EXT_lights_ies/schema/lightProfile.schema.json

extensions/2.0/Vendor/EXT_lights_ies/README.md

sebavan · 2023-10-26T20:46:03Z

Sorry for necro posting, but I am wondering if there are any demo assets available ?

I am evaluating whether to implement the extension as I love the intent and it would be great to have samples I could rely on for the tests.

Initial draft of KHR_lights_ies

e387172

UX3D-nopper added the extension label Sep 6, 2022

fire mentioned this pull request Sep 14, 2022

Add IES light profile import for realistic light projectors godotengine/godot-proposals#715

Open

Change extension prefix to EXT and clarify many things about the IES …

795994e

…standards and how the coordinate system relate

tblutNV changed the title ~~KHR_lights_ies~~ EXT_lights_ies Nov 7, 2022

Extend list of optional fields

c47c2c1

Reorganized some things, removed redundant orientation property, and …

c53cb14

…made description of the coordinate system mapping more specific

emackey requested a review from lexaknyazev December 1, 2022 19:41

lexaknyazev reviewed Dec 5, 2022

View reviewed changes

Update readme and schema

10301d5

lexaknyazev reviewed Jan 24, 2023

View reviewed changes

extensions/2.0/Vendor/EXT_lights_ies/schema/lightProfile.schema.json Outdated Show resolved Hide resolved

extensions/2.0/Vendor/EXT_lights_ies/README.md Outdated Show resolved Hide resolved

fix missing rename, "wavelength" -> "color channel"

9aa8a06

lexaknyazev approved these changes Jan 25, 2023

View reviewed changes

emackey approved these changes Feb 1, 2023

View reviewed changes

emackey merged commit f7708e7 into KhronosGroup:main Feb 1, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EXT_lights_ies #2200

EXT_lights_ies #2200

tblutNV commented Sep 5, 2022 •

edited

lexaknyazev commented Sep 5, 2022 •

edited

lkettnerNV commented Sep 12, 2022

lkettnerNV commented Sep 12, 2022

lexaknyazev commented Sep 13, 2022

aidinabedi commented Sep 14, 2022 •

edited

lkettnerNV commented Sep 14, 2022

aidinabedi commented Sep 15, 2022 •

edited

BruceCherniak commented Oct 31, 2022

tblutNV commented Nov 7, 2022

sebavan commented Oct 26, 2023

EXT_lights_ies #2200

EXT_lights_ies #2200

Conversation

tblutNV commented Sep 5, 2022 • edited

Alternative Proposal for Storing IES Data

lexaknyazev commented Sep 5, 2022 • edited

ANSI/IES LM-63 Lifecycle

ANSI/IES LM-63 Scope

lkettnerNV commented Sep 12, 2022

lkettnerNV commented Sep 12, 2022

lexaknyazev commented Sep 13, 2022

aidinabedi commented Sep 14, 2022 • edited

lkettnerNV commented Sep 14, 2022

aidinabedi commented Sep 15, 2022 • edited

BruceCherniak commented Oct 31, 2022

tblutNV commented Nov 7, 2022

sebavan commented Oct 26, 2023

tblutNV commented Sep 5, 2022 •

edited

lexaknyazev commented Sep 5, 2022 •

edited

aidinabedi commented Sep 14, 2022 •

edited

aidinabedi commented Sep 15, 2022 •

edited