Transform Processor

[ghost]

A transform system is a pretty common way to handle the scene graph. Basically it takes a Local Transform and a Parent entity and calculates the Global Transform. This allows objects that are attacked to the parent entity to follow it around. An object without a parent global transform is it's local transform, but it is stored as a separate value.

The Parent systems might be ok to handle separately as they can be used to do neat things like handle deletes in a clean way. Deleting the parent entity should delete all child entities.

[kvark]

it also can be done by the system that updates transformations: if it finds an entity parent alive, it updates the current entity model matrix. If the parent is dead, it removes the current entity.

[kvark]

Possible approaches to making sure the parent transform is up to date when processing a child:

1. ignore that. Worst thing is 1 frame latency within the transformation
2. enforce the children entities always having higher indices from the parents, so just iterating them as usual gives you proper results
3. do recursive walk over the tree - this may be slow, and not canonical to ECS

[lukebitts]

Is the engine going to use some kind of spatial structure? I ask this because in my own entity/component project I wanted to do frustrum culling and it was really annoying to keep the spatial tree in sync with creation and destruction of entities.

[kvark]

@lukebitts we can start with simple parent-child relationships and culling on per-entity level. If we get a spatial structure, it's going to be its own component storage, so part of the syncing headache is going to be addressed automatically by the ECS. It's not completely clear as to how exactly this will work in the long-term, but short-term we are all set.

[OvermindDL1]

The Spatial Structures in mine were just other Systems that listened to and worked with position and other components. Many often did add another specific component to the entities for meta-data (octree and such).

[fHachenberg]

Can such a "transform processor" be understood as a very simple kinematic simulator? In which cases does one use the transform processor and in which cases does one for example let the physics engine solve rigid body joint constraints instead? What kind of scene graph functionality do you have in mind for amethyst?

[kvark]

I see the Transform Processor role to simply resolve hierarchical parent-child links and keep the world transformation per entity up to date.

Doing any sort of physics integration should be left out to a different processor. That, in theory. Problem would be that the physics would need to work on those world positions, may be modify them, and then we'd need to propagate the changes back to the local positions...

So, I guess we can't have both at the same time, and it's fine.

On Sep 16, 2016, at 5:13, Fabian Hachenberg notifications@github.com wrote:

Can such a "transform processor" be understood as a very simple kinematic simulator? In which cases does one use the transform processor and in which cases does one for example let the physics engine solve rigid body joint constraints instead? What kind of scene graph functionality do you have in mind for amethyst?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.