Closed McNopper closed 6 years ago
McNopper
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago "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
commented
7 years ago Should this extension also address the use case of pre-computed lighting? Perhaps an additional optional texture map in materials?
McNopper
commented
7 years ago 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
commented
7 years ago 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
]
}
]
}
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
commented
7 years ago We are implementing this extension in three.js with https://github.com/mrdoob/three.js/pull/11551. Would this article be an appropriate introduction to the lighting model described here? I am making the following assumptions:
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
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago Current KHR_lights specifcation: https://github.com/UX3D-nopper/glTF/tree/master_lights_blinnphong/extensions/Khronos/KHR_lights
lexaknyazev
commented
7 years ago @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
commented
7 years ago 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
commented
7 years ago Okay, continued with the light extension description.
UX3D-nopper
commented
7 years ago Exactly define Spotlight falloff_angle for glTF 2.0: see https://github.com/KhronosGroup/glTF/issues/824
andreasplesch
commented
7 years ago clarify directional light direction: https://github.com/UX3D-nopper/glTF/tree/master_lights_blinnphong/extensions/Khronos/KHR_lights#directional for discussion see #1063.
McNopper
commented
7 years ago It is -z, as stated here (see GL_POSITION section):
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glLight.xml
Will improve the specs tomorrow.
andreasplesch
commented
7 years ago 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.
There may have been a good reason in the old spec. for this statement ? One aspect is probably that the glTF assets may often be loaded into scenes which already have their own global lights. So glTF may use the extension to indicate a preferred lighting but a glTF author should not have the expectation that the lights are actually used. Maybe there could be a distinction between global lights and node scope lights.
McNopper
commented
7 years ago Well this section needs to be kicked out.
Originally, we wanted to finish the spec before SIGGRAPH, but we got stuck with more important stuff. We will continue on this soon.
McNopper
commented
7 years ago If somone imports a glTF file, there is no "must" how to use the asset. If your engine/viewer does not need/want to use e.g. the lights, they can be skipped. It is the same discussion with material and so on.
andreasplesch
commented
7 years ago Ok, understood, the spec. is not concerned with rendering or author expectations, just the transmission.
McNopper
commented
7 years ago Yes, e.g. with the PBR Metallic-Roughness material, in most cases people will use the real-time rendering approach. But if you want to render the scene using a "real" path tracer, there is no conformance blocker doing this.
Also, if you do not use the animations like e.g. in Microsoft Paint, this is okay as well.
As you said, it is the transmission and the format which is defined. Not, how to use or render an asset.
andreasplesch
commented
7 years ago What about:
"extensions" : {
"KHR_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
}
}
]
}Very similar to the original, this gets rid of one level of hierarchy since this extension is only about lights, and avoids the polymorphism.
McNopper
commented
7 years ago Tomorrow, we will have the first glTF 2.0 workgroup meeting after SIGGRAPH.
I personally do not have a strong opinion, how finally the light spec looks like. For me/us is more important, that it is specified.
Tomorrow, if we discuss about the lights extension, I will bring your suggestion onto the table. I guess others do have an opinion on this as well. As soon as there any news/information, I will update the lights spec.
pjcozzi
commented
7 years ago Hi all, please check out the #1075 pull request by @McNopper and @andreasplesch.
UX3D-nopper
commented
7 years ago Can we please restart/continue the discussion for dynamic PBR lights?
This is the current export for the above scene:
"extensions" : {
"KHR_lights_pbr" : {
"lights" : [
{
"color" : [
1.0,
0.0,
0.0
],
"name" : "Point",
"positional" : {
"radius" : 5.0
},
"profile" : "PBR",
"strength" : 4.0,
"type" : "point"
},
{
"color" : [
0.0,
1.0,
0.0
],
"name" : "Spot",
"positional" : {
"radius" : 10.0,
"spot" : {
"innerAngle" : 0.10471975623447705,
"outerAngle" : 0.3490658402442932
}
},
"profile" : "PBR",
"strength" : 30.0,
"type" : "spot"
}
]
}
}, Quick update — we expect to move forward with an unlit KHR_materials_cmnConstant extension but are tabling the Blinn-Phong and Lambert materials for the time being: see https://github.com/KhronosGroup/glTF/pull/1150#issuecomment-345831909.
That being the case, per offline discussion, let's move forward with PBR lights for glTF 2.0, and similarly hold off on classic lights. Classic lights can be revisited if a clear need and community support come together in the future.
The proposal above looks good to me at a glance; I'll do some testing to compare this against three.js's implementation.
donmccurdy
commented
6 years ago Point — I assume radius is the distance at which the light's intensity reaches 0. What range of values do we accept? Can radius be infinite (e.g. -1 or 0) or does the point light always attenuate to zero at some finite distance?
Spot — THREE.SpotLight uses a penumbra for percentage of the cone that is attenuated, rather than innerAngle, but converting is trivial. Unreal uses innerAngle/outerAngle as you've done here, it looks like Unity only has an outer angle unless someone knows otherwise?
three.js, Unity, Unreal, and Maya all use the term intensity rather than strength, so I might suggest changing that.
Ambient light and environment maps should be discussed; I will leave that to others. See https://github.com/KhronosGroup/glTF/issues/946 on KHR_environments.
donmccurdy
commented
6 years ago Also, are Blender's strength values in Watts? I assume there is some conversion that must be defined, a value of 30 sounds very high for THREE.Light.intensity...
andreasplesch
commented
6 years ago Here is x3d/vrml lighting for comparison:
http://www.web3d.org/documents/specifications/19775-1/V3.3/ Part01/components/lighting.html#Lightingequations
Here is how it translates:
On Dec 14, 2017 2:51 PMZt, "Don McCurdy" notifications@github.com wrote:
Point — I assume radius is the distance at which the light's intensity reaches 0. What range of values do we accept? Can radius be infinite (e.g. -1 or 0) or does the point light always attenuate to zero at some finite distance?
Radius is positive and does not have an upper limit. It would depend on the engine if it can represent infinity and if it treats infinity distinct from the largest float. Json may not allow infinity as a number value ?
Spot — THREE.SpotLight https://threejs.org/docs/#api/lights/SpotLight uses a penumbra for percentage of the cone that is attenuated, rather than innerAngle, but converting is trivial. Unreal uses innerAngle/outerAngle https://docs.unrealengine.com/latest/INT/Engine/Rendering/LightingAndShadows/LightTypes/Spot/ as you've done here, it looks like Unity only has an outer angle https://docs.unity3d.com/ScriptReference/Light.html unless someone knows otherwise?
InnerAngle/outerAngle are called beamWidth/cutoffAngle but equivalent.
three.js, Unity, Unreal, and Maya all use the term intensity rather than strength, so I might suggest changing that.
Also intensity.
Distance attenuation is given by three positive parameters which are combined to a factor capped at 1: 1/max(attenuation[0] + attenuation[1] ×r + attenuation[2] × r^2, 1) where r is distance to light. This may be similar to the constant, linear and quadratic factors ?
Ambient light and environment maps should be discussed; I will leave that to others. See #946 https://github.com/KhronosGroup/glTF/issues/946 on KHR_environments.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KhronosGroup/glTF/issues/945#issuecomment-351817609, or mute the thread https://github.com/notifications/unsubscribe-auth/AF4p60srYF49tV6U_M5tSYvPiB9Ka8sVks5tAXxagaJpZM4NTDog .
tehbelinda
commented
6 years ago I'd also like to propose including area lights in the KHR_lights_pbr extension, for example something like:
"KHR_lights_pbr" : {
"lights" : [
{
"color" : [
1.0,
1.0,
1.0
],
"intensity" : 100.0,
"name" : "Area",
"positional" : {
"height" : 1.0,
"width" : 1.55
},
"profile" : "PBR",
"type" : "area"
}
]
}I renamed strength to intensity as per donmccurdy's suggestion however since the unit is still unclear, here are some notes on what other systems use
According to Blender docs, strength is measured in Watts, except for sun/mesh lights which use Watts/m^2 https://docs.blender.org/manual/en/dev/render/cycles/nodes/types/shaders/emission.html
Intensity in Three.JS is measured in Lumens https://github.com/mrdoob/three.js/issues/6259, further evidence is in https://github.com/mrdoob/three.js/pull/6255 that intensity is in lumens when physicalFalloff is set to true.
You can see my experiment with this so far in the Blender exporter and Three.js at https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/136
donmccurdy
commented
6 years ago Unreal also uses lumens as the unit.
Distance attenuation is given by three positive parameters which are combined to a factor capped at 1...
I believe the intention with PBR light is to not expose these three parameters directly, but to define them with physically-correct attenuation and only allow control of the intensity and other parameters.
JarkkoPFC
commented
6 years ago Yeah, for PBR area lights attenuation arises naturally from solid angle they cover. It's also better to use photometric units (Lumen-based) to define light brightness because radiometric units (Watt-based) are not very useful in renderers where SPD's are collapsed to RGB-triplets.
pjcozzi
commented
6 years ago From #446.
Is this still an issue with this new extension? If so, is it important enough to address?
@tfili said
Trying to use the same light positioned with multiple nodes doesn't work (Think directional light used as car headlights).
We'll probably have to duplicate techniques to do this.
@pjcozzi said
The issue is that
nodeis only defined for atechniqueparameter, not formaterialparameter. However,material.parameterwould have to be changed from number/array/string to an object to support this. This creates another level of indirection that I don't think is warranted for this corner case, but can be considered post 1.0 based on community feedback.
MiiBond
commented
6 years ago Hi guys. I'm looking at implementing KHR_lights in the Babylon glTF loader and am not sure from the above discussion what the current state of the spec is. @UX3D-nopper has this: https://github.com/UX3D-nopper/glTF/tree/master_lights_blinnphong/extensions/Khronos/KHR_lights
But, if the plan is to go with only a PBR lights extension for now, are we calling it KHR_lights_pbr or just KHR_lights? Is anyone working on a formal description of the extension besides @UX3D-nopper ?
I'm more than willing to contribute but I'm not sure what spec to start with. Should I be making pull requests against the above spec?
UX3D-nopper
commented
6 years ago This discussion somehow get stuck, why we did not put any more effort in the specification. Think current status is, that people are still evaluating the lighting in their engine.
MiiBond
commented
6 years ago Okay, I'll continue implementing this in Babylon.js and then post my thoughts here. We (Adobe) definitely want this extension ASAP and I think it'll be a prerequisite for using the KHR_environment extension for IBL (which is how we're interested in using the environments extension).
UX3D-nopper
commented
6 years ago We are already using this extension and will adapt changes, as soon as the glTF community agreed on something.
donmccurdy
commented
6 years ago I'm more than willing to contribute but I'm not sure what spec to start with.
This issue contains the most recent discussions, so currently I would recommend looking here rather than other repos or branches.
pjcozzi
commented
6 years ago Rock on @MiiBond - will be cool to have this moving again!
MiiBond
commented
6 years ago Okay, let's get this conversation going again. I've thrown together a spec, based on the one written by @UX3D-nopper : https://github.com/MiiBond/glTF/tree/khr_lights_v1/extensions/Khronos/KHR_lights
And implemented support in Babylon.js for loading the lights. https://github.com/MiiBond/Babylon.js/tree/gltf_khr_lights_support
I've assumed that we are only concerned with PBR lights for the moment so I've removed all attenuation settings. I've also left transformable lights to inherit the transform from their node. This means that, technically, directional lights can have a position and point lights can have a rotation but I think it's fine to just let runtimes ignore those values, if they want. In practice, these full transforms could be useful when incorporating shadow-casting anyway.
The properties for spot lights still need some work as the innerAngle/outerAngle isn't physically-based.
I'd love to hear some feedback.
donmccurdy
commented
6 years ago 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
commented
6 years ago 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.
Thoughts?
donmccurdy
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago It would be great if the extension could support IES profiles or does this go beyond the scope of this extension?
MiiBond
commented
6 years ago That would be cool. However, like area lights and hemisphere lights, this is probably something best left to a further extension.
As the lights have to be extracted from the KHR_materials_common extension, here is a first try by example:
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.