Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upTransform Processor #53
Comments
ghost
added
diff: easy
type: feature
note: help wanted
labels
May 11, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kvark
May 11, 2016
Member
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.
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kvark
May 11, 2016
Member
Possible approaches to making sure the parent transform is up to date when processing a child:
- ignore that. Worst thing is 1 frame latency within the transformation
- enforce the children entities always having higher indices from the parents, so just iterating them as usual gives you proper results
- do recursive walk over the tree - this may be slow, and not canonical to ECS
|
Possible approaches to making sure the parent transform is up to date when processing a child:
|
LucioFranco
referenced this issue
May 14, 2016
Closed
Default Amethyst Processors and Components for ECS #60
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
lukebitts
May 19, 2016
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.
lukebitts
commented
May 19, 2016
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kvark
May 19, 2016
Member
@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.
|
@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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
OvermindDL1
Jun 19, 2016
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).
OvermindDL1
commented
Jun 19, 2016
|
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). |
ebkalderon
added
the
pri: important
label
Sep 9, 2016
LucioFranco
changed the title from
Transform System
to
Transform Processor
Sep 11, 2016
ebkalderon
added this to the 1.0 milestone
Sep 14, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
fHachenberg
Sep 16, 2016
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?
fHachenberg
commented
Sep 16, 2016
|
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? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
kvark
Sep 16, 2016
Member
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.
|
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.
|
ghost commentedMay 11, 2016
A transform system is a pretty common way to handle the scene graph. Basically it takes a
Local Transformand aParententity and calculates theGlobal Transform. This allows objects that are attacked to the parent entity tofollowit 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.