Break apart Node into Components and Systems

[kanerogers]

Overview

Well this is going to be really fun.

When attempting to integrate legion I discovered that Node, the core structure in Hotham is completely incompatible. This is because, in essence Node is doing what legion wants to do - hold all the data and behaviour of the system in one place. Specifically, it's because Node looks like this:

struct Node {
  parent: Weak<Node>, // not 'static + Sized + Send + Sync !
  children: Vec<Rc<Node>>, // 'static + Sized + Send + Sync !
}

The solution is to break Node apart into its various Components (structs) and Systems (functions).

In essence, this is far closer to the actual representation of a gltf file: a discrete set of components with loose references to each-other, rather than an OOP-style graph structure like I've currently got.

Onwards!

TODO

• Create Transform component
• Create transform system
• Create Skin component
• Create Joint component
• Create skinning system
• Create Mesh component
• Create render system
• Create prepare_frame function
• Create XrContext resource
• Make Renderer a resource
• Make VulkanContext a resource
• Separate VulkanContext from Renderer

[kanerogers]

Found some good resources for "flattening" scene graphs and animations here, here and here.

[kanerogers]

Still having issues trying to reference another entity from inside an entity:

cannot borrow `*world` as mutable because it is also borrowed as immutable
mutable borrow occurs here

[kanerogers]

Got this to work with for_each_unchecked:

#[system]
#[write_component(Transform)]
pub fn animation(world: &mut SubWorld) -> () {
    println!("Running system..");
    let mut query = <(&mut Transform,)>::query();
    unsafe {
        query.for_each_unchecked(world, |t| {
            let (mut transform,) = t;

            let local_matrix = get_local_matrix(transform);

            if let Some(parent) = transform.parent.as_ref() {
                let parent = world.entry_ref(*parent).unwrap();
                let parent_transform = parent.get_component::<Transform>().unwrap();
                transform.global = parent_transform.global * local_matrix;
            } else {
                transform.global = local_matrix;
            }
        })
    }
}

[kanerogers]

legion is actually helping to put a bit of structure on the whole engine. Looking at this kind of structure to start with, we'll see how it goes:

• resources -> anything that would be used as a resource by a system
• systems -> systems and their states
• schedule_functions -> one time functions executed in a schedule
• components -> components used by systems

[kanerogers]

Difficult problems to solve:

• How do we bring a Mesh from gltf into the world? It has many entities. What's a good "container" for those entities? A World? Could each "model" exist as its own world initially, then it get added into the world?
• Remember that entity insertion order is critical for maintaining parent/child relationships
• How can parent/child relationships be preserved when moving from "the model world" into "the actual world"?
• Is there a need to group these entities together? I keep thinking about parent/child relationships, but the whole point of parent/child relationships is that once the relationship is established, you shouldn't need to think about it again.
• How do we do double/triple buffering?