Currently things that would typically be components in e.g. Unity are treated as first-class objects. Things like renderables and lights. So a scene can contain a light or a renderable for instance. Both a light and a renderable have transforms built-in to them.
There is currently no way to group a bunch of renderables into a single object, what would typically be a GameObject or entity in other engines. This results in things like the GLTF lantern model just being 3 renderables with 3 separate transforms in the scene, but no way of parenting them to a common transform.
It would seem a good idea to keep the asset::Light and asset::Renderable structs the way they are for the renderer, since it is highly optimised with these structs in mind. However, for the "front-end", that a game or the editor might want to use, it would seem a good idea to have some form of hierarchy support with a more component-based approach.
Suggestions:
A SceneNode that contains a transform, parent and list of children. Identified by a Uuid
A component registry that tracks which components have been assigned to which SceneNode
Converting Light and Renderable to components that can be attached to a SceneNode
It is important to make sure that common use cases are both performant and easy to implement. I.e. updating a transform and its hierachy, iterating through components, iterating through nodes.
Currently things that would typically be components in e.g. Unity are treated as first-class objects. Things like renderables and lights. So a scene can contain a light or a renderable for instance. Both a light and a renderable have transforms built-in to them.
There is currently no way to group a bunch of renderables into a single object, what would typically be a GameObject or entity in other engines. This results in things like the GLTF lantern model just being 3 renderables with 3 separate transforms in the scene, but no way of parenting them to a common transform.
It would seem a good idea to keep the asset::Light and asset::Renderable structs the way they are for the renderer, since it is highly optimised with these structs in mind. However, for the "front-end", that a game or the editor might want to use, it would seem a good idea to have some form of hierarchy support with a more component-based approach.
Suggestions:
It is important to make sure that common use cases are both performant and easy to implement. I.e. updating a transform and its hierachy, iterating through components, iterating through nodes.