In XML3D 4.x it was necessary to use two nodes to define a light: The <lightshader> element defines a (reusable) light configuration and the used light model (e.g. urn:xml3d:lightshader:point). The <light> element in turn instances a light configuration and therefor determines the light's position using the scene's transformation hierarchy.
Users found it cumbersome to declare two nodes to define a single light. The design is also questionable since the XML3D's data concept allows sharing light configurations anyway (using a generic <data> node).
Consequently, we remove the <lightshader> element from XML3D. Instead, the light parameters are defined as children of the <light>, using the src attribute of the <light> pointing to any internal or external resource that defines the parameters or any other combination the data compositing of XML3D allows for. The light model is defined using the `model attribute of the <light> element.
We have kept the URN style of the model because we want to allow programmable light shaders in the future, which will be referenced via URL as well.
In summary, the <light> is becoming more similar to a <mesh> node. This is intentional because we want to be able to define emissive geometry as lights in the future. Then, a light is a "specialized" geometry node that emits light only. To make the light more similar to a mesh, we will introduce an iterator concept to the light node which will allows to define multiple emitters in a single light element. We will file a separate issue for this functionality.
In XML3D 4.x it was necessary to use two nodes to define a light: The
<lightshader>element defines a (reusable) light configuration and the used light model (e.g.urn:xml3d:lightshader:point). The<light>element in turn instances a light configuration and therefor determines the light's position using the scene's transformation hierarchy.Users found it cumbersome to declare two nodes to define a single light. The design is also questionable since the XML3D's data concept allows sharing light configurations anyway (using a generic
<data>node).Consequently, we remove the
<lightshader>element from XML3D. Instead, the light parameters are defined as children of the<light>, using thesrcattribute of the<light>pointing to any internal or external resource that defines the parameters or any other combination the data compositing of XML3D allows for. The light model is defined using the`modelattribute of the<light>element.Example:
We have kept the URN style of the model because we want to allow programmable light shaders in the future, which will be referenced via URL as well.
In summary, the
<light>is becoming more similar to a<mesh>node. This is intentional because we want to be able to define emissive geometry as lights in the future. Then, a light is a "specialized" geometry node that emits light only. To make the light more similar to a mesh, we will introduce an iterator concept to the light node which will allows to define multiple emitters in a single light element. We will file a separate issue for this functionality.