KHR_lights_punctual extension proposal #1223

MiiBond · 2018-01-25T22:25:13Z

No description provided.

donmccurdy · 2018-01-25T22:53:57Z

extensions/Khronos/KHR_lights/README.md

+
+#### Directional
+
+Directional lights are light sources that emit from infinitely far away in the direction of the -z axis. This light type inherits the orientation of the node that it belongs to. Because it is at an infinite distance, the light is not attenuated. It's intensity is defined in lumens per metre squared, or lux (lm/m^2).


... are light sources that emit from infinitely far away in the direction of the -z axis.

I think this could be phrased more clearly, but struggling with it. What about: "... are light sources infinitely far away in the direction of the -z axis, emitting light in the direction of the +z axis".

donmccurdy · 2018-01-25T22:57:43Z

extensions/Khronos/KHR_lights/README.md

+| Property | Description | Required |
+|:-----------------------|:------------------------------------------| :--------------------------|
+| `innerConeAngle` | Angle from centre of spotlight where falloff begins. | No, Default: `0` |
+| `outerConeAngle` | Angle from centre of spotlight where falloff ends. Must be greater than innerConeAngle. | No, Default: `PI / 2.0` |


Let's specify explicitly that each angle is in radians.

In three.js, neither angle may exceed PI / 2. I only have some old screenshots to go by, but Unreal appears to have the same requirement. So probably we should specify a min/max here.

In that case, maybe the default outerConeAngle value should be less extreme than 90º?

pjcozzi · 2018-01-31T13:59:50Z

Fixes #945

takahirox · 2018-02-01T05:09:28Z

extensions/Khronos/KHR_lights/README.md

+|:-----------------------|:------------------------------------------| :--------------------------|
+| `color` | RGB value for light's color in linear space. | No, Default: `[1.0, 1.0, 1.0]` |
+| `intensity` | Brightness of light in. The units that this is defined in depend on the type of light. `point` and `spot` lights use luminous intensity in candela (lm/sr) while `directional` lights use illuminance in lux (lm/m^2) | No, Default: `1.0` |
+| `type` | Declares the type of the light. | :white_check_mark: Yes |


Perhaps you're missing name property here?
In examples/lights.gltf light has name property.

Yes, yes I am. Thank you.

Wait, actually, I think this is just a problem with my example. My intension was for lights to use the name of the node that they are attached to so the name in the examples shouldn't be there.

About removing name entirely. I wish it weren't there on meshes or cameras, because in my mind the node is a mesh or a camera, it doesn't contain them, and so one of the two names must be thrown away in loading. But since both do have names in the current spec, it would be more consistent to keep one here. I'm undecided on this..

Ah, you're right. I guess that's why I had it there. It is pretty odd to have a name on both the node and the light objects but, as it's consistent, I guess I'll put it back.

najadojo · 2018-02-02T17:08:10Z

I'd really like to see light properties be animatable. Could be an extension of animation/channel/target where a property name (i.e. color, intensity) is given and the output applies to the light's field. Is this for khr_light or a theoretical khr_animatable_property?

willeastcott · 2018-02-02T18:42:24Z

extensions/Khronos/KHR_lights/README.md

+
+### Adding Light Instances to Nodes
+
+Nodes can have lights attached to them, just like any other objects that have a transform. Only lights of types `directional`, `point`, and `spot` have position and/or orientation so only these light types are allowed. These lights are attached to a node by defining the `extensions.KHR_lights` property and, within that, an index into the `lights` array using the `light` property.


I'm unsure why cameras are defined entirely on a node, but lights have to have this extra indirection of using instances. What's the reason for the difference? Certainly in PlayCanvas, lights are not instanced. Maybe other engines do this, but I'm not sure what the point of that would be since light are very light weight. Same deal for cameras. Personally, I'd just define directional, points and spots as valid for a node extension and ambient for the scene extension, and not have the top level array.

I'm not sure I follow. Lights are defined on a node exactly the same way cameras are.
Perhaps my use of the word "attached" is what's confusing you? If so, maybe I can rephrase this to something like "light properties are referenced by a node"?

Really? Are you sure? Cameras are wholly defined in the node JSON, right? Lights seem to define a light index on the node with the actual light defined in an array stored in the extensions object in the top-level glTF object. So I was curious as to the reason why they are defined differently in this way.

Cameras are defined in an array, just like meshes and lights at the top-level of the glTF object.

Haha. How did I get confused about that?? I withdraw all my previous comments. I should have checked the PlayCanvas glTF parser code to make sure before diving in. D'oh.

recp · 2018-02-06T07:50:05Z

extensions/Khronos/KHR_lights/README.md

+                    1.0,
+                    1.0,
+                    1.0
+                ],


Does this mean the extension will only support RGB color for lights (not including RGBA)? I don't know if alpha channel has a mean for lights but I used vec4 (RGBA) to specify light color in my shaders :-S

Yeah, I'm not aware of a use case (or, at least not a common use case) for alpha in a light's colour.

recp · 2018-02-06T08:05:20Z

extensions/Khronos/KHR_lights/README.md

+                "spot": {
+                    "innerConeAngle": 0.785398163397448,
+                    "outerConeAngle": 1.57079632679,
+                },


since type specifies it is "spot" why it used here again? Obviously it simplifies to access the data after getting type but it could be better name : "cone" (because we already know spot has cone shape):

"cone": { "innerAngle": 0.785398163397448, "outerAngle": 1.57079632679, }

it also reduces a few bytes :) it is just feedback.

I think keeping the name spot for the options related to "spot" lights is clearest, and probably consistent with what we'd want for future light types. No preference on keeping Cone in the name or not, though.

Yeah, I've debated removing "Cone" from the property names too but I kind of like the explicit description.

ghost

A few small suggestions for making everything more consistent. Overall, this is looking great!

ghost · 2018-02-13T05:40:19Z

extensions/Khronos/KHR_lights/README.md

+
+Many 3D tools and engines support built-in implementations of light types. Using this extension, tools can export and engines can import these lights. 
+
+This extension defines five light types: `ambient`, `directional`, `point` and `spot`.


This should read four now that hemispherical lights have been removed.

ghost · 2018-02-13T06:46:43Z

extensions/Khronos/KHR_lights/schema/light.schema.json

+    "$schema": "http://json-schema.org/draft-04/schema",
+    "title": "light",
+    "type": "object",
+    "description": "An ambient, hemisphere, directional, point, or spot light.",


This description should no longer mention hemispherical lights.

ghost · 2018-02-13T06:48:04Z

extensions/Khronos/KHR_lights/schema/light.schema.json

+        },
+        "intensity": {
+            "type": "number",
+            "description": "Intensity of the light source in lumens.",


It should probably be clarified that the intensity either has units of candela or lux, depending on the light type.

ghost · 2018-02-13T06:48:24Z

extensions/Khronos/KHR_lights/schema/light.schema.json

+            "description": "Specifies the light type.",
+            "enum": [
+                "ambient",
+                "hemisphere",


"hemisphere" should be removed here.

ghost · 2018-02-13T06:50:02Z

extensions/Khronos/KHR_lights/schema/light.spot.schema.json

+        "innerConeAngle" : {
+            "type" : "number",
+            "description" : "Angle in radians from centre of spotlight where falloff begins.",
+            "default" : 0.785398163397448


Either this default should be updated to what the spec says (0), or vice-versa.

ghost · 2018-02-13T06:50:12Z

extensions/Khronos/KHR_lights/schema/light.spot.schema.json

+        "outerConeAngle" : {
+            "type" : "number",
+            "description" : "Angle in radians from centre of spotlight where falloff ends.",
+            "default" : 1.570796326794897


Either this default should be updated to what the spec says (pi/4), or vice-versa.

All good finds. Thanks!

takahirox · 2018-02-21T19:22:38Z

extensions/Khronos/KHR_lights/README.md

+```
+
+For light types that have a position (`point` and `spot` lights), the light's position is defined as the node's world location.
+For light types that have a direction (`directional` and `spot` lights), the light's direction is defined as the 3-vector `(0.0, 0.0, 1.0)` and the rotation of the node orients the light accordingly.


Does this mean the direction in a world space will be "light node's world rotation matrix * Vector3(0.0, 0.0, 1.0)"?

donmccurdy · 2018-02-25T02:02:01Z

extensions/Khronos/KHR_lights/schema/examples/lights.gltf

+      ],
+      "extensions": {
+        "KHR_lights": {
+          "light": 0


This suggests a scene may only contain a single ambient light; is that intended?

Ah, just saw the comment above.

donmccurdy · 2018-02-25T02:07:39Z

extensions/Khronos/KHR_lights/README.md

+
+Lights define light sources within a scene.
+
+`ambient` lights are not transformable and, thus, can only be defined on the scene. All other lights are contained in nodes and inherit the transform of that node.


Thinking through implications here:

In the current syntax, this also means a scene may contain no more than 1 ambient light.

If we were to support animating light properties in the future (e.g. intensity, color) ambient lights will be in a slightly awkward position, such that they have an index in the lights array, whereas all other animated properties are targeted by node. If the same ambient light is reused in multiple scenes the animation syntax must clarify which instance of the ambient light is targeted.

Given issues above, and for consistency, would it be better to allow ambient lights' use in nodes like other lights, but say (either a strict requirement or implementation note + validation warning) that the node must be an immediate child of the scene and have the identity transform?

^IMO these concerns are resolved.

donmccurdy · 2018-02-25T02:18:02Z

Added a couple comments, my remaining concern is that ambient lights might be in an awkward spot for future animation support... I don't have a strong opinion whether animation should be included in this extension or a separate future version, but let's discuss @najadojo's suggestion enough to ensure this syntax lends itself to animation in the future, even if we don't add it right away..

Ideal animation syntax, based on existing spec, would simply add new allowed values to channel.path:

{
    "sampler": 0,
    "target": {
        "node": 25,
        "path": "intensity"
    }
}

Unfortunately, attaching ambient lights to the scene throws a slight wrinkle into that syntax. I think we may want to keep them in nodes, despite not taking a transform?

MiiBond · 2018-02-26T21:25:54Z

I'm not that familiar with animations as they are. Does an animation have to target a node? What about the property of a material?

donmccurdy · 2018-02-26T21:32:09Z

Animations may (currently) target: node + path, where node is a node index, and path is one of: rotation, scale, translation, weights. We haven't discussed animation on materials yet, but I would expect animation to affect only a particular instance of a material rather than all uses if we did.

willeastcott · 2018-02-26T21:32:16Z

Well, animations can target morph target weights at the moment. So the target string can already apply to non-node properties. You could have 'ambientColor' as a target, say, if ambient was a 'scene' property. I was thinking 'target' should really be a specific path to a specific property.

donmccurdy · 2018-02-26T21:33:48Z

For morph targets, the target must still provide a node index — weights on all morph targets within that node are animated.

lexaknyazev · 2018-10-03T17:10:21Z

Last JSON nits.

In the core glTF, all top-level arrays are optional. Do we want to keep it the same for this extension (and for similar extensions in general)? I.e., should this example be valid?

{
  "asset": {
    "version": "2.0",
    "extensionsUsed": ["KHR_lights_punctual"]
  },
  "extensions": {
    "KHR_lights_punctual": { }
  }
}

Similar question about the lack of light property inside node.

{
  "asset": {
    "version": "2.0",
    "extensionsUsed": ["KHR_lights_punctual"]
  },
  "nodes": [
    {
      "extensions": {
        "KHR_lights_punctual": { }
      }
    }
  ]
}

And the last one about undefined spot object for spot light. In the example below, the second light gets values for spot properties implicitly from the schema, while the first is under-defined:

{
  "asset": {
    "version": "2.0",
    "extensionsUsed": ["KHR_lights_punctual"]
  },
  "extensions": {
    "KHR_lights_punctual": {
      "lights": [
        {
          "type": "spot"
        },
        {
          "type": "spot",
          "spot": { }
        }
      ]
    }
  }
}

donmccurdy · 2018-10-03T17:58:25Z

First reactions —

require top-level lights array — No preference.
require light in node extension entry — I'd prefer light be required; this feels like a distinct case from mesh or camera being optional.
undefined spot object — Agree this should be defined. Inheriting implicit defaults from the schema, like with {}, seems best I think?

donmccurdy · 2018-10-03T18:01:25Z

Are we ready to merge this, keeping "draft" status? We can then delegate any final tweaks to the JSON schema.

donmccurdy · 2018-10-15T14:40:04Z

I've marked 'light' and 'lights' as required; stricter schema seems preferable. I don't think the core spec provides a precedent one way or another, since the extension should not be used if there are no lights.

Added a note that when the spot property is omitted, its default values should be used:

When the spot property is omitted, a spot light must use default values for innerConeAngle and outerConeAngle.

The alternative would be to make it required, when type=spot, I suppose?

UX3D-nopper · 2018-10-15T14:41:56Z

Hmm, think it should not be required. Assume it becomes into core glTF, we need to change the schema. Am 15.10.2018 um 16:40 schrieb Don McCurdy:

…

I've marked 'light' and 'lights' as required; stricter schema seems preferable. I don't think the core spec provides a precedent one way or another, since the extension should not be used if there are no lights. Added a note that when the |spot| property is omitted, its default values should be used: When the |spot| property is omitted, a spot light must use default values for |innerConeAngle| and |outerConeAngle|. The alternative would be to make it required, when type=spot, I suppose? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1223 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AakPaBONJCj6WBMqw2ouF_Sro1k-N_nJks5ulJ5igaJpZM4RtlU7>.

-- *UX3D GmbH* GPU Software Solutions Norbert Nopper Managing Director Görresstrasse 17 80798 Munich, Germany T: +49 (0)89 215 44 258 2 F: +49 (0)89 215 44 258 8 [email protected] <mailto:[email protected]> www.ux3d.io

emackey · 2018-10-15T14:48:39Z

Assume it becomes into core glTF, we need to change the schema.

Moving anything from an extension to core is a breaking change to schema. It should be no problem to require it in the extension, while leaving lights optional in future core.

lexaknyazev · 2018-10-15T16:47:09Z

The alternative would be to make it required, when type=spot, I suppose?

That's how camera.type is defined but there're required fields in perspective and orthogonal.

donmccurdy · 2018-10-23T15:52:38Z

As discussed earlier, I've marked the 'spot' property as required when type='spot'.

dakom · 2018-10-30T06:27:06Z

I'm a bit confused by the status of WebGL implementations as a reference point. Loading the PointLightTest.gltf:

Babylon.js: https://sandbox.babylonjs.com/

Three.js: https://gltf-viewer.donmccurdy.com/

Both of those can be adjusted by changing some settings, but I couldn't get them to match eachother, and neither of them seem to match the reference output from Blender:

Any tips to get the blender reference, in webgl?

Similarly... are they calculating the falloff the same way? I couldn't quite tell from peeking at the code:

https://github.com/BabylonJS/Babylon.js/blob/master/src/Shaders/ShadersInclude/pbrLightFunctions.fx#L37

vs.

https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderChunk/bsdfs.glsl#L3

donmccurdy · 2018-10-30T15:37:24Z

My viewer was not up to date with this extension, but should be now. Note that three.js implementations will have to enable the physicallyCorrectLighting mode to get the right results:

three.js:

babylonjs:

unreal:

ux3d:

Looks like the BabylonJS Sandbox has other light in the scene (my viewer disables them if the incoming model has its own lighting) which is likely the difference between the screenshot above and what you saw.

I would advise trying to match the implementations above rather than Blender's output, for now. See KhronosGroup/glTF-Blender-IO#24.

dakom · 2018-10-30T15:52:15Z

Oh wow, thank you for the explanation and update!

Part of what was driving me mad was wondering why the blender output has those harsh specular highlights... so if I understand correctly, we do not want those highlights in either the blender output or the renderers above (i.e. blender is currently wrong)?

bghgary · 2018-10-30T16:07:17Z

BabylonJS Sandbox has other light in the scene

The default IBL is what is causing the difference for the sandbox. You can turn it off by typing this in the dev console:

BABYLON.Engine.LastCreatedScene.environmentTexture = null

dakom · 2018-10-30T16:26:40Z

woohoo, great - now seeing the same output as above. Thanks y'all!

MiiBond added 4 commits January 10, 2018 11:11

First draft of khr_lights

31ca6c2

Updates to clarify units

524fd6b

Removing hemisphere light

8cb0c17

Update spotlight property description

bd8938e

donmccurdy reviewed Jan 25, 2018

View reviewed changes

MiiBond added 2 commits January 25, 2018 15:21

Adjustments to light descriptions for directional and spotlights

07a8fec

Clarifying usage of ambient lights and colour space of lights

2113228

pjcozzi added the extension label Jan 31, 2018

takahirox reviewed Feb 1, 2018

View reviewed changes

willeastcott reviewed Feb 2, 2018

View reviewed changes

MiiBond added 2 commits February 5, 2018 09:21

Adding base node properties to lights

e7ae552

Removing name properites from lights in KHR_lights example.

0610717

recp reviewed Feb 6, 2018

View reviewed changes

recp mentioned this pull request Feb 6, 2018

glTF 2.0: New KHR_lights extension #945

Closed

Adding light's name property back in for consistency

72096c4

ghost suggested changes Feb 13, 2018

View reviewed changes

Fix typos in schemas

e495b9e

This was referenced Feb 15, 2018

glTF KHR_lights update mrdoob/three.js#13340

Closed

Rough update to KHR_lights support to match current spec mrdoob/three.js#13341

Merged

takahirox reviewed Feb 21, 2018

View reviewed changes

donmccurdy reviewed Feb 25, 2018

View reviewed changes

Don McCurdy added 3 commits October 3, 2018 08:47

Remove space in filename.

d9313cf

Remove space in filename.

fa6d985

+z -> -z

2d240ec

Don McCurdy added 3 commits October 15, 2018 07:31

Make 'light' required on node.

93ae7df

Make 'lights' required on top-level extension.

e4989c1

Use default values when 'spot' property is omitted.

03f63e0

Make spot property required when type is 'spot'.

f49c51e

lexaknyazev approved these changes Oct 23, 2018

View reviewed changes

jsantell mentioned this pull request Oct 23, 2018

Allow users to bring their own lights google/model-viewer#34

Closed

pjcozzi merged commit fee5e56 into KhronosGroup:master Oct 31, 2018

This was referenced Nov 2, 2018

Implement KHR_lights_punctual facebookincubator/FBX2glTF#138

Closed

Implement KHR_lights_punctual facebookincubator/FBX2glTF#139

Closed

donmccurdy mentioned this pull request Jan 9, 2019

Is there a model corresponding to KHR_lights_punctual somewhere? KhronosGroup/glTF-Sample-Assets#78

Open

donmccurdy mentioned this pull request May 26, 2019

KHR_lights_punctual model KhronosGroup/glTF-Sample-Models#210

Closed

syoyo mentioned this pull request Jun 29, 2020

No data in Light vector -> std::vector<Light> lights syoyo/tinygltf#272

Closed

Popov72 mentioned this pull request Nov 13, 2020

Misc issues (2) BabylonJS/Documentation#62

Closed

rawnsley mentioned this pull request Sep 15, 2021

Light intensity comparison with other render engines google/filament#4625

Closed


		#### Directional

		Directional lights are light sources that emit from infinitely far away in the direction of the -z axis. This light type inherits the orientation of the node that it belongs to. Because it is at an infinite distance, the light is not attenuated. It's intensity is defined in lumens per metre squared, or lux (lm/m^2).


		### Adding Light Instances to Nodes

		Nodes can have lights attached to them, just like any other objects that have a transform. Only lights of types `directional`, `point`, and `spot` have position and/or orientation so only these light types are allowed. These lights are attached to a node by defining the `extensions.KHR_lights` property and, within that, an index into the `lights` array using the `light` property.

+.0,
+.0,
+.0
+                              ],


		Many 3D tools and engines support built-in implementations of light types. Using this extension, tools can export and engines can import these lights.

		This extension defines five light types: `ambient`, `directional`, `point` and `spot`.


		Lights define light sources within a scene.

		`ambient` lights are not transformable and, thus, can only be defined on the scene. All other lights are contained in nodes and inherit the transform of that node.

KHR_lights_punctual extension proposal #1223

KHR_lights_punctual extension proposal #1223

Conversation

MiiBond commented Jan 25, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pjcozzi commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

najadojo commented Feb 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

donmccurdy Feb 25, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

donmccurdy commented Feb 25, 2018 • edited Loading

MiiBond commented Feb 26, 2018

donmccurdy commented Feb 26, 2018 • edited Loading

willeastcott commented Feb 26, 2018

donmccurdy commented Feb 26, 2018

lexaknyazev commented Oct 3, 2018

donmccurdy commented Oct 3, 2018

donmccurdy commented Oct 3, 2018

donmccurdy commented Oct 15, 2018

UX3D-nopper commented Oct 15, 2018 via email

emackey commented Oct 15, 2018

lexaknyazev commented Oct 15, 2018

donmccurdy commented Oct 23, 2018

dakom commented Oct 30, 2018

donmccurdy commented Oct 30, 2018 • edited Loading

dakom commented Oct 30, 2018

bghgary commented Oct 30, 2018 • edited Loading

dakom commented Oct 30, 2018

donmccurdy Feb 25, 2018 •

edited

Loading

donmccurdy commented Feb 25, 2018 •

edited

Loading

donmccurdy commented Feb 26, 2018 •

edited

Loading

donmccurdy commented Oct 30, 2018 •

edited

Loading

bghgary commented Oct 30, 2018 •

edited

Loading