Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glTF 2.0: New KHR_lights extension #945

Closed
McNopper opened this issue May 7, 2017 · 68 comments

Comments

Projects
None yet
@McNopper
Copy link
Contributor

commented May 7, 2017

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 McNopper changed the title glTF 2.0: KHR_materials_lights extension glTF 2.0: New KHR_materials_lights extension May 7, 2017

@McNopper McNopper changed the title glTF 2.0: New KHR_materials_lights extension glTF 2.0: New KHR_lights extension May 7, 2017

@pjcozzi pjcozzi added the extension label May 10, 2017

@McNopper

This comment has been minimized.

Copy link
Contributor Author

commented May 16, 2017

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

This comment has been minimized.

Copy link
Member

commented May 16, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented May 16, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented May 16, 2017

"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

This comment has been minimized.

Copy link

commented May 24, 2017

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

@McNopper

This comment has been minimized.

Copy link
Contributor Author

commented May 25, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2017

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.

grafik

@donmccurdy

This comment has been minimized.

Copy link
Member

commented Jun 19, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Jun 23, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

@lexaknyazev

This comment has been minimized.

Copy link
Member

commented Jul 4, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2017

Okay, continued with the light extension description.

@UX3D-nopper

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2017

Exactly define Spotlight falloff_angle for glTF 2.0:
see #824

@donmccurdy

This comment has been minimized.

Copy link
Member

commented Jan 12, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2018

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

This comment has been minimized.

Copy link
Member

commented Jan 13, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2018

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

This comment has been minimized.

Copy link

commented Jan 19, 2018

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

@MiiBond

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2018

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

@MiiBond

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2018

@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

This comment has been minimized.

Copy link
Member

commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 24, 2018

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

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

+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

This comment has been minimized.

Copy link

commented Jan 25, 2018

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

This comment has been minimized.

Copy link

commented Jan 25, 2018

+1 for innerConeAngle.

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

@pjcozzi

This comment has been minimized.

Copy link
Member

commented Jan 31, 2018

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

@recp

This comment has been minimized.

Copy link

commented Feb 6, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 6, 2018

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

This comment has been minimized.

Copy link

commented Feb 6, 2018

@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

This comment has been minimized.

Copy link

commented Feb 12, 2018

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

This comment has been minimized.

Copy link

commented Feb 14, 2018

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:

@MiiBond

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2018

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

@donmccurdy

This comment has been minimized.

Copy link
Member

commented Feb 25, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 25, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2018

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.

@UX3D-nopper UX3D-nopper closed this Aug 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.