glTF
glTF copied to clipboard
KhronosGroup
KHR_lights_area
here is a quick proposal for a rect area light (expanded to include sphere and circle per requests below.) This specification does not determine its implementation, just its specification and intended behavior.
Real-time rect area lights are though generally implementing using the 2016 SIGGRAPH LTC method described here: https://eheitzresearch.wordpress.com/415-2/
Three.js area light:
- Docs: https://threejs.org/examples/webgl_lights_rectarealight.html
- Example: https://threejs.org/docs/#api/en/lights/RectAreaLight
One extra thought: Maybe this should have been build upon the existing KHR_lights_punctual extension and just add another light type to it called "rect"?
In Playcanvas we decided to go with shape property, which can be specified for current Directional, Spot or Omni lights, and these are the shapes we support:
* @description Infinitesimally small point light source shape.
export const LIGHTSHAPE_PUNCTUAL = 0;
* @description Rectangle shape of light source.
export const LIGHTSHAPE_RECT = 1;
* @description Disk shape of light source.
export const LIGHTSHAPE_DISK = 2;
* @description Sphere shape of light source.
export const LIGHTSHAPE_SPHERE = 3;
So it'd be great to make this extension more generic than only supporting rect area lights?
example of some types: http://playcanvas.github.io/#graphics/area-lights.html
In Playcanvas we decided to go with shape property, which can be specified for current Directional, Spot or Omni lights, and these are the shapes we support:
It increases the complexity a fair bit but disk and sphere are useful light types. Capsule is the other light area type that I know UE4 supports.
@mvaligursky based on your feedback I have converted this from just a "rect" light extension to one that covers "sphere", "disk" and "rects."
While this generalization makes sense, I do worry that it increases the implementation burden on 3D engines for supporting this extension, and thus may make it harder to get buy-in.
But I think it is important to be responsive to feedback and to go with the decision-making flow of this group.
We have a similar custom extension that we use in BRIO for functionalities in ray tracing. This spec would be really good to have a standardized approach.
Only change I'd recommend here is to change the type field to shape.
@kowsheek thanks for the support -- I've made that change! It is a good one.
Started a survey here on whether to expand to sphere and disk based on @mvaligursky's suggestion: https://twitter.com/BenHouston3D/status/1368966602205630464
I don't think a sphere is an area light. It's a sphere light. Or a gaussian sphere light or whatever. Area must be flat. Or you're in for capsule too. I'd limit this to a few basic flat shapes. Polygonal or spheres and capsules and whatnot, could be obtained using a different extension lights_mesh and use a node that points to a mesh so the shape is free.
I would love to push it forward! I think getting rect area lights in would be incredibly valuable to many different applications.
Are there any news on this feature? Is there anything that prevents this from being pushed further? I'd love to help!
What is the community's "2024" thoughts on an area light extension?
With @julienduroure fantastic glTF Blender exporter additions, glTF is a first-class citizen. Emissive geometries can somewhat fulfill the need for area lights, yet there are many reasons not to rely solely on these in a pathtracer, as well as the orthogonality in handling "materials as lights". True area light definitions would be a real benefit to the glTF spec.
What is the community's "2024" thoughts on an area light extension?
With @julienduroure fantastic glTF Blender exporter additions, glTF is a first-class citizen. Emissive geometries can somewhat fulfill the need for area lights, yet there are many reasons not to rely solely on these in a pathtracer, as well as the orthogonality in handling "materials as lights". True area light definitions would be a real benefit to the glTF spec.
Would be great to have when exporting from Blender to Unreal (or vice-versa), keeping those lights intact.