glTF 2.0: New KHR_lights extension

[McNopper]

As the lights have to be extracted from the KHR_materials_common extension, here is a first try by example:

{
  "lights": [
    {
      "ambient": {
        "color": [
          1,
          1,
          1
        ]
      }
    },
    {
      "directional": {
        "color": [
          1,
          1,
          1
        ]
      }
    },
    {
      "point": {
        "color": [
          1,
          1,
          1
        ],
        "constantAttenuation": 1,
        "linearAttenuation": 0.5,
        "quadraticAttenuation": 0.25
      }
    },
    {
      "spot": {
        "color": [
          1,
          1,
          1
        ],
        "constantAttenuation": 1,
        "fallOffAngle": 40,
        "fallOffExponent": 0,
        "linearAttenuation": 0.5,
        "quadraticAttenuation": 0.25
      }
    }
  ]
}

Directional, point and spot are obvious for PBR and non-PBR materials.

Regarding ambient and for PBR, this needs to be further discussed and explained. But I suggest to treat the value as if an environment map is used, which does have just this color.

[McNopper]

In general, a node will have no or one entry of a light with its index.
Exception is, that no ambient light is allowed to be assigned to a node.

An ambient light can only be assigned to a scene.
In opposite, for a scene, only the ambient light can be assigend.

Is this approach accepted?

[lexaknyazev]

An ambient light can only be assigned to a scene.

Lgtm. Ambient light has no transform to apply.
Also, add required light.type string property (as camera.type).

[McNopper]

I will implement this extension. If it works out fine, I will create a schema and bring it back to the glTF working group.

[McNopper]

"extensions" : {
        "KHR_lights" : {
            "lights" : [
                {
                    "color" : [
                        1.0, 
                        1.0, 
                        1.0
                    ], 
                    "name" : "Directional", 
                    "type" : "directional"
                }, 
                {
                    "color" : [
                        1.0, 
                        1.0, 
                        1.0
                    ], 
                    "name" : "Point", 
                    "point" : {
                        "quadraticAttenuation" : 1.0
                    }, 
                    "type" : "point"
                }, 
                {
                    "color" : [
                        1.0, 
                        1.0, 
                        1.0
                    ], 
                    "name" : "Spot", 
                    "spot" : {
                        "fallOffAngle" : 0.7853981852531433, 
                        "fallOffExponent" : 19.200000762939453, 
                        "quadraticAttenuation" : 1.0
                    }, 
                    "type" : "spot"
                }, 
                {
                    "color" : [
                        0.0, 
                        0.0, 
                        0.0
                    ], 
                    "name" : "Ambient_Scene", 
                    "type" : "ambient"
                }
            ]
        }
    },

This is the current export. Moved the color 'up', as it does appear in all light types.

[stevenvergenz]

Should this extension also address the use case of pre-computed lighting? Perhaps an additional optional texture map in materials?

[McNopper]

Yes, pre-computed lighting should also go into materials like e.g. occlusion. I suggest to create another extension for this, where all light maps come in.

[UX3D-nopper]

As promised in yesterdays call, this is the current syntax of the lights export by example:

{
    "accessors" : [
        {
            "bufferView" : 0, 
            "componentType" : 5121, 
            "count" : 6, 
            "max" : [
                3
            ], 
            "min" : [
                0
            ], 
            "type" : "SCALAR"
        }, 
        {
            "bufferView" : 1, 
            "componentType" : 5126, 
            "count" : 4, 
            "max" : [
                1.0, 
                0.0, 
                1.0
            ], 
            "min" : [
                -1.0, 
                0.0, 
                -1.0
            ], 
            "type" : "VEC3"
        }, 
        {
            "bufferView" : 2, 
            "componentType" : 5126, 
            "count" : 4, 
            "max" : [
                0.0, 
                1.0, 
                -0.0
            ], 
            "min" : [
                0.0, 
                1.0, 
                -0.0
            ], 
            "type" : "VEC3"
        }
    ], 
    "asset" : {
        "generator" : "Khronos Blender glTF 2.0 exporter", 
        "version" : "2.0"
    }, 
    "bufferViews" : [
        {
            "buffer" : 0, 
            "byteLength" : 6, 
            "byteOffset" : 0, 
            "target" : 34963
        }, 
        {
            "buffer" : 0, 
            "byteLength" : 48, 
            "byteOffset" : 6, 
            "target" : 34962
        }, 
        {
            "buffer" : 0, 
            "byteLength" : 48, 
            "byteOffset" : 54, 
            "target" : 34962
        }
    ], 
    "buffers" : [
        {
            "byteLength" : 102, 
            "uri" : "04_lights.bin"
        }
    ], 
    "cameras" : [
        {
            "name" : "Camera", 
            "perspective" : {
                "aspectRatio" : 1.703595982340029, 
                "yfov" : 0.5033799409866333, 
                "zfar" : 100.0, 
                "znear" : 0.10000000149011612
            }, 
            "type" : "perspective"
        }
    ], 
    "extensions" : {
        "KHR_lights" : {
            "lights" : [
                {
                    "color" : [
                        1.0, 
                        1.0, 
                        1.0
                    ], 
                    "name" : "Directional", 
                    "type" : "directional"
                }, 
                {
                    "color" : [
                        1.0, 
                        0.0, 
                        0.0
                    ], 
                    "constantAttenuation" : 1.0, 
                    "name" : "Point_Constant", 
                    "type" : "point"
                }, 
                {
                    "color" : [
                        0.0, 
                        1.0, 
                        0.0
                    ], 
                    "linearAttenuation" : 0.1, 
                    "name" : "Point_Linear", 
                    "type" : "point"
                }, 
                {
                    "color" : [
                        0.0, 
                        0.0, 
                        1.0
                    ], 
                    "name" : "Point_Quadratic", 
                    "quadraticAttenuation" : 0.1, 
                    "type" : "point"
                }, 
                {
                    "color" : [
                        1.0, 
                        0.0, 
                        0.0
                    ], 
                    "constantAttenuation" : 1.0, 
                    "fallOffAngle" : 0.1745329201221466, 
                    "fallOffExponent" : 0.0, 
                    "name" : "Spot_Constant", 
                    "type" : "spot"
                }, 
                {
                    "color" : [
                        0.0, 
                        1.0, 
                        0.0
                    ], 
                    "fallOffAngle" : 0.3490658402442932, 
                    "fallOffExponent" : 64.0, 
                    "linearAttenuation" : 0.1, 
                    "name" : "Spot_Linear", 
                    "type" : "spot"
                }, 
                {
                    "color" : [
                        0.0, 
                        0.0, 
                        1.0
                    ], 
                    "fallOffAngle" : 0.5235987901687622, 
                    "fallOffExponent" : 128.0, 
                    "name" : "Spot_Quadratic", 
                    "quadraticAttenuation" : 0.1, 
                    "type" : "spot"
                }, 
                {
                    "color" : [
                        0.0, 
                        0.0, 
                        0.0
                    ], 
                    "name" : "Ambient_Scene", 
                    "type" : "ambient"
                }
            ]
        }
    }, 
    "extensionsRequired" : [
        "KHR_materials_common", 
        "KHR_lights"
    ], 
    "extensionsUsed" : [
        "KHR_materials_common", 
        "KHR_lights"
    ], 
    "materials" : [
        {
            "emissiveFactor" : [
                0.0, 
                0.0, 
                0.0
            ], 
            "extensions" : {
                "KHR_materials_common" : {
                    "ambientFactor" : [
                        1.0, 
                        1.0, 
                        1.0
                    ], 
                    "diffuseFactor" : [
                        0.800000011920929, 
                        0.800000011920929, 
                        0.800000011920929, 
                        1.0
                    ], 
                    "shininessFactor" : 12.298039215686275, 
                    "specularFactor" : [
                        0.5, 
                        0.5, 
                        0.5
                    ], 
                    "type" : "commonPhong"
                }
            }, 
            "name" : "Plane"
        }
    ], 
    "meshes" : [
        {
            "name" : "Plane", 
            "primitives" : [
                {
                    "attributes" : {
                        "NORMAL" : 2, 
                        "POSITION" : 1
                    }, 
                    "indices" : 0, 
                    "material" : 0
                }
            ]
        }
    ], 
    "nodes" : [
        {
            "camera" : 0, 
            "name" : "Correction_Camera", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                0
            ], 
            "name" : "Camera", 
            "rotation" : [
                0.5730898976325989, 
                0.0, 
                -0.0, 
                0.8194926381111145
            ], 
            "translation" : [
                0.0, 
                12.0, 
                30.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 0
                }
            }, 
            "name" : "Correction_Directional", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                2
            ], 
            "name" : "Directional", 
            "rotation" : [
                0.2588190734386444, 
                0.0, 
                -0.0, 
                0.965925931930542
            ], 
            "translation" : [
                -8.0, 
                4.0, 
                8.0
            ]
        }, 
        {
            "mesh" : 0, 
            "name" : "Plane", 
            "scale" : [
                10.0, 
                10.0, 
                10.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 1
                }
            }, 
            "name" : "Correction_Point_Constant", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                5
            ], 
            "name" : "Point_Constant", 
            "translation" : [
                -8.0, 
                4.0, 
                -0.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 2
                }
            }, 
            "name" : "Correction_Point_Linear", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                7
            ], 
            "name" : "Point_Linear", 
            "translation" : [
                0.0, 
                4.0, 
                -0.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 3
                }
            }, 
            "name" : "Correction_Point_Quadratic", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                9
            ], 
            "name" : "Point_Quadratic", 
            "translation" : [
                8.0, 
                4.0, 
                -0.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 4
                }
            }, 
            "name" : "Correction_Spot_Constant", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                11
            ], 
            "name" : "Spot_Constant", 
            "rotation" : [
                -0.2588190734386444, 
                0.0, 
                -0.0, 
                0.965925931930542
            ], 
            "translation" : [
                -8.0, 
                4.0, 
                -8.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 5
                }
            }, 
            "name" : "Correction_Spot_Linear", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                13
            ], 
            "name" : "Spot_Linear", 
            "rotation" : [
                -0.2588190734386444, 
                0.0, 
                -0.0, 
                0.965925931930542
            ], 
            "translation" : [
                0.0, 
                4.0, 
                -8.0
            ]
        }, 
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 6
                }
            }, 
            "name" : "Correction_Spot_Quadratic", 
            "rotation" : [
                -0.7071067690849304, 
                -0.0, 
                0.0, 
                0.7071067690849304
            ]
        }, 
        {
            "children" : [
                15
            ], 
            "name" : "Spot_Quadratic", 
            "rotation" : [
                -0.2588190734386444, 
                0.0, 
                -0.0, 
                0.965925931930542
            ], 
            "translation" : [
                8.0, 
                4.0, 
                -8.0
            ]
        }
    ], 
    "scene" : 0, 
    "scenes" : [
        {
            "extensions" : {
                "KHR_lights" : {
                    "light" : 7
                }
            }, 
            "name" : "Scene", 
            "nodes" : [
                16, 
                14, 
                12, 
                10, 
                8, 
                6, 
                4, 
                3, 
                1
            ]
        }
    ]
}

[UX3D-nopper]

Also, regarding the ambient light and PBR, here is a quick render from Blender:
From my side, we can keep ambient light with PBR, but we should not use it as a factor for the later environment light.

[donmccurdy]

We are implementing this extension in three.js with mrdoob/three.js#11551. Would this article be an appropriate introduction to the lighting model described here? I am making the following assumptions:

• constantAttenuation applies a factor multiplier to the intensity of the light uniformly, at all distances.
• linearAttenuation applies a factor multiplier to intensity per unit distance, such that intensity will reach 0 at distance 1 / linearAttenuation.

I am not sure I understand the difference between quadraticAttenuation and fallOffExponent. I assume we want to modify intensity by a factor 1/d^power, where physically realistic lighting would have power=2. Is that power defined by quadraticAttenuation or fallOffExponent, and what is the other value?

[UX3D-nopper]

fallOffAngle is also known as spotCosCutoff (with angle vs "cos" encoding) and
fallOffExponent aka spotExponent:
http://www.lighthouse3d.com/tutorials/glsl-12-tutorial/spot-light-per-pixel/

So, quadraticAttenuation is defined as mentioned in your article.

The fallOff* parameters are just for the spot light.

[donmccurdy]

I see, thanks! My only concern then is with the fallOffExponent value. Three.js has switched from supporting that to using a penumbra angle instead, which seemed more realistic. Blender's SpotLamp documentation describes this as well; Maya offers both a dropoff and penumbra.

Also, if both are just for the spotlight, should naming be spot____?

[UX3D-nopper]

The fallOffExponent probably exists since years and other encoding would be probably much better. I am flexible on this but we should ask the others in next weeks call.

Also regarding the naming, we should discuss this.

[UX3D-nopper]

Current KHR_lights specifcation:
https://github.com/UX3D-nopper/glTF/tree/master_lights_blinnphong/extensions/Khronos/KHR_lights

[lexaknyazev]

@UX3D-nopper
Couple notes:

• A conforming implementation of this extension must be able to load light data defined in the asset, but it is not obligated to render the asset using those lights.

  This sounds a bit misleading to me. Does it mean that conforming implementation could just ignore lights?

• Current schema implies polymorphism (which is usually an issue for loaders) and prevents some schema-validation cases, like "type": directional" with defined falloffAngle. Maybe, we could use nested objects like in camera and material?

• What if ambient light is referred from node, or spot light is referred from scene? Extension spec should either explicitly disallow such cases or provide some guidance.

[UX3D-nopper]

Regarding point one, this is from the old spec. I agree, we could just kick it out.

Also agree on second point. Maybe name is "positional", as point and spot share the same attenuation parameters. Nested inside "positional" we have a "spot", where the "falloff" is defined?

Also agre, this has clearly be specified, that these lights can only place either in nodes or scenes.

[UX3D-nopper]

Okay, continued with the light extension description.

[UX3D-nopper]

Exactly define Spotlight falloff_angle for glTF 2.0:
see #824

[donmccurdy]

About the additional proposed light types, area and hemisphere — I haven't worked much with either and won't argue one way or another on their usefulness, but a couple concerns:

• area: Unreal doesn't appear to offer this as a lighting type. Unity does, but says: "Since the lighting calculation is quite processor-intensive, area lights are not available at runtime and can only be baked into lightmaps." Will these be problems in terms of support for the extension and suitability for a runtime format?
• hemisphere: neither Unreal nor Unity implements this, unless it can be done with their ambient lights? I do see a gradient option for the ambient lighting in Unity, maybe that's equivalent... Again, want to verify this can be widely supported.

[MiiBond]

Yeah, I'm okay with getting rid of hemisphere for the reasons given. And, yeah, I didn't include area lights because they aren't widely supported either.

We still need to work out physical units for each light type as well. I'm inclined to go with what Babylon defines.

i.e.

• Point and spot lights both use luminous intensity in candela (lm/sr)
• Directional lights use illuminance in lux (lm/m^2)

Thoughts?

[donmccurdy]

three.js supports intensity in candela, or power in lumens. Unreal uses intensity in lumens for point and spot lights, Unity uses some arbitrary units... your suggestion of candela sounds right to me.

I understand lux for area lights but (and I hope this isn't a dumb question 😅) can lm/m^2 be applied in a physically correct way for a directional light with infinite area?

Many of the three.js lighting assumptions are based on this paper from SIGGRAPH: https://seblagarde.files.wordpress.com/2015/07/course_notes_moving_frostbite_to_pbr_v32.pdf

It is silent on directional lighting, treating the sun as a disc area light with finite area. Probably more physically correct, but less widely supported as mentioned.

---

Aside, I didn't mean to say "glTF should not support area lights" or anything like that earlier. But since they're not widely supported in runtime formats, might make more sense as part of some experimental KHX_lights_cinematicextension, rather than this initial runtime PBR-focused extension.

[MiiBond]

Yeah, I don't think directional lights can ever be treated in a truly energy conserving manner. By definition, they exist at an infinite distance and have a precise direction so attenuation and spread are both meaningless. But, they are an excellent approximation of a point or spot light at a very far distance. As long as the coverage area is relatively small compared to that distance, the approximation holds.

So yeah, I think lm/m^2 measured at an object's surface is perfectly fine.

And I'm in agreement about less-supported lights being better included in a further extension. Area lights, hemisphere lights, etc.

[MiiBond]

For spotlights, we should probably discuss the properties. I think I would expect just an angle for the light cone and then some sort of value to control the falloff at the edge of the spotlight. Physically, this falloff would be affected by the shape of the sheath around the light and even the amount that the light scatters through the atmosphere. It would probably get pretty complicated to try to define some simple, physically-based, properties for these things.

Maybe this is why UE4 elects to use the innerAngle/outerAngle properties. It gives artists control over the look of the light without allowing them to make something that's completely physically implausible.

[awefers]

It would be great if the extension could support IES profiles or does this go beyond the scope of this extension?

[MiiBond]

That would be cool. However, like area lights and hemisphere lights, this is probably something best left to a further extension.

[MiiBond]

I suppose maybe we should discuss whether flags for casting shadows should be included as part of a light. Certainly I'm not suggesting that we include details about shadow techniques or settings but what about a simple boolean?
i.e.
castShadow: true

There will be a large amount of variance in the final rendering between engines but this would at least allow the glTF to inform the engine whether or not to render a shadow.

The default would be false.

[MiiBond]

@sebevan mentioned in my Babylon.js pull request (BabylonJS/Babylon.js#3579) that spotlights that don't include an outerConeAngle could default to a gaussian falloff, starting from the innerConeAngle. Anyone have any thoughts on this?

[donmccurdy]

As far as I can tell from docs, Unity doesn't have any concept of an innerConeAngle: https://docs.unity3d.com/ScriptReference/Light.html ... anyone know differently? If Unity can't support it, is that enough of a problem to consider excluding it?

spotlights that don't include an outerConeAngle could default to a gaussian falloff

The comment on BabylonJS suggests inner should be optional, not outer, right? Do any engines implement gaussian falloff for spot lights? Asking engines to support two different falloff modes seems like a stretch if we want consistent implementations.

I think I'd vote to leave shadows out of scope on this extension.

[MiiBond]

Does Unity not have a property to adjust the way the light falls off? All I can see in the docs is the spotAngle and Unity is crashing on startup for me right now...

• Unreal supports these properties as well as additional properties for the source radius and source length to further adjust the look of the spotlight.
• Three.js has the angle and penumbra with which you can convert to inner/outer angles.
• Babylon.js, like Unity, only has an angle.

I'm okay with simplifying spotlights to only have a single angle property if it helps this extension get accepted sooner. However, being able to control the falloff a bit more explicitly would be my preference, even if a couple of engines just approximate the behaviour.

[MiiBond]

Okay, so after talking on the call this morning, it sounds like we're okay with innerConeAngle and outerConeAngle as two separate properties. Babylon.js is interested in adding support for the extra angle, leaving just Unity as being a major engine that doesn't support it.

For engines that don't support two angles, it would be expected that they would use outerConeAngle as the principal angle, leaving innerConeAngle to implicitly be 0.

[donmccurdy]

+1 for innerConeAngle.

Also, we plan to omit area lights from this extension, to ensure that the extension will have broad support. Area lights can be added in a future extension, perhaps alongside hemisphere lights or IBL, for more advanced lighting. Community members are welcome to initiate that discussion in a new PR or use custom vendor extensions for your needs in the meantime.

[aras-p]

leaving just Unity as being a major engine that doesn't support it.

New rendering pipelines (both "HD" and "Lightweight") in Unity 2018.1 (beta out now) support inner & outer spotlight cone angles.

Unity does, but says: "Since the lighting calculation is quite processor-intensive, area lights are not available at runtime and can only be baked into lightmaps."

The "HD" rendering pipeline in Unity 2018.1 does support realtime area lights (shadows from them would still be "punctual" though), largely implemented via Linearly Transfomed Cosines approximation.

[awefers]

+1 for innerConeAngle.

@MiiBond As for the "castShadow" property, it would be nice to extend this beyond lights to meshes.

[pjcozzi]

Thanks everyone for the great discussion here! Reviews are very welcome on the pull request for this by @MiiBond.

[recp]

I implemented COLLADA 1.4 and 1.5 lights in AssetKit I want to provide single interface for both COLLADA (1.4 and 1.5+) and glTF (2.0+) so I need to convert the extension to existing data structure which is (speaking for spot light for now):

typedef struct AkSpotLight {
  AkLightBase base;
  float       constAttn;
  float       linearAttn;
  float       quadAttn;
  float       falloffAngle;
  float       falloffExp;
} AkSpotLight;

or as alternative I can update/upgrade this structure for new glTF design if it is possible to convert COLLADA structure to glTF's inner / outer angle or vice-versa. I couldn't see attenuation properties in proposed PR (#1223).

Actually it explicitly says:

Engines that don't support two angles for spotlights should use outerConeAngle as the spotlight angle (leaving innerConeAngle to implicitly be 0).

this solves the problem of converting falloffAngleto inner/outer angle design; I will upgrade my importer and render engine to use inner/outer angle, but what about other properties? e.g. attenuations (linear, quadratic, constant), fallOfExponent...

I found a good tutorial which explains dual cone spot: http://ngreen.org/articles/quick-n-easy-dual-cone-spotlights-glsl.html

and this: https://msdn.microsoft.com/en-us/library/windows/desktop/bb174697(v=vs.85).aspx

seems like attenuations (linear, quadratic, constant) and fallOfExponent properties are not used here too if I didn't miss them.

@McNopper's first proposal (or following ones) fits with my importer and renderer, if glTF will use new design I would like to know how to convert old design/structure ( single cone ) to new design/structure ( dual cone ) to provide single and better interface to users.

I need to convert between them because some tools may use single cone (with linear, quadratic and constant attenuations) and some tools may use dual cone (inner / outer angle), is it possible to do that without losing any lighting information?

[donmccurdy]

The current KHR_lights proposal would remove those attenuation properties and (implicitly) expect physically-correct values to be used. So it is possible to convert glTF lights to your representation with explicit attenuation values, but physically impossible attenuations could not be represented in the glTF KHR_lights proposal.

I implemented COLLADA 1.4 and 1.5 lights in AssetKit I want to provide single interface for both COLLADA (1.4 and 1.5+) and glTF (2.0+)

The lights extension is still open for feedback, so we're glad to have more opinions on lights. But in general, beyond just lights, note that COLLADA will have many features that will never be included in glTF, and that is by design. So keeping a single interface may be difficult long-term.

[recp]

@donmccurdy thanks for your comments,

I'm updating my data structures for glTF if necessary and sometimes this makes API more clear and fantastic. So I'll implement PBR in my importer and renderer after OIT transparency stuff finished. And I want to update my lights structures too for new design. Dual cone seems better alternative but I never used it before.

So after updated my structures to glTF I need to convert COLLADA values to glTF structures. Or I need to create another Spot light type which I'm reluctant to do so.

You said "it is possible to convert glTF lights to your representation", is it possible to do the opposite? Also how can I convert glTF to my representation as alternative, any formula?

--

note that COLLADA will have many features that will never be included in glTF, and that is by design.

I'm aware and happy for that, I like both specs.

So keeping a single interface may be difficult long-term.

You are right, but single interface makes things easier for tools and engines. Maintaining single interface also makes codes re-usable in importer. For instance I'm not sure how many tools support COLLADA 1.5 because some libraries provides two interface... With single interface, tools/engines can support new version of COLLADA and glTF more quickly I think. Also I'm considering to provide some sub tools e.g. mesh optimizer... single interface will make things more easier for that, I hope.

Currently while writing new render engine I'm only using single interface to load COLLADA 1.4, 1.5 and glTF 2.0 (not all features for now), so I can focus on render stuff instead of implementing different APIs/interfaces in render side.

In the future some conflicts may occurs but COLLADA (and AssetKit) has technique/profile/extra elements which makes it very extensible. In the future any conflicts can be resolved with technique="gltf or collada" or profile="gltf or collada"... These are my thoughts, I hope I can achieve what I think :)

[DRx3D]

I know I am very late to this discussion, but I just recently found out about adding lights to glTF. I looked through this issue but did not find anything related to an answer. Perhaps it is in this issue or another issue, if so, please point me that way.

My question is what is the use case for including lighting in a glTF file. If the glTF file is to contain an efficient delivery of the model to the GPU, adding lights increases the size of the model to the limit of the lights and the scene manager needs to deal with something not directly under its control.

If the glTF file contains an entire scene (or subscene), then isn't the nice partitioning effect of having interchangeable and reusable model files lost?

[dakom]

Can I put in a request for documentation on how to use the lights data in a webgl shader? Especially helpful would be if there was a webgl reference implementation, like these but to handle lights:

• https://github.com/KhronosGroup/glTF-WebGL-PBR/tree/master/shaders
• https://github.com/shrekshao/minimal-gltf-loader/tree/master/src/shaders

[MiiBond]

Updated three.js implementation of KHR_lights.
mrdoob/three.js#13341

[donmccurdy]

Can I put in a request for documentation on how to use the lights data in a webgl shader?

@dakom Good suggestion, I think that would be put in glTF-WebGL-PBR if we add it. Filed an issue.

If the glTF file contains an entire scene (or subscene), then isn't the nice partitioning effect of having interchangeable and reusable model files lost?

I don't think any determination has yet been made that glTF assets should represent a single model, rather than a scene, or (if so) where that line should be drawn. This might be better to raise in a new issue, perhaps. Lights existed in glTF 1.0 (not sure whether this issue was raised then), this PR is primarily updating the syntax for glTF 2.0 and PBR models.

[donmccurdy]

Also — I'm sure it's mentioned somewhere in this thread already, but a proposal for KHR_lights is now open, and it would be great to have feedback directed there: #1223

[UX3D-nopper]

range should be default -1.0. If -1.0, there should be no range restrictions. If range >= 0.0, the the range restriction should apply.
If we keep it like this, we have a division by zero.