Any longterm plans for integration with the TransformSystem? Also ignoring inside hits?

Are there any longterm plans for rigidbody/colliders to better coexist with the transform system's array of components like parent/child relationships, extra euler rotation or pivot components etc? or will it always be strictly rotation and translation?

Also just wanted to ping about being able to ignore self hits regarding raycasts, just wanted to make sure this was still on the roadmap?

 

Ignoring self hits on casts is definitely on still on the roadmap. Its pencilled in as part of the work needed to make the custom collectors usable.

Physics itself only considers translation and rotation for performance but I'm sure the Build and Export Physics World systems could be customised to support/update other components. Do you have an specific common usecases in mind? I'm particularly interested in the parent/child relationship and how you would see this in relation to the physics simulation,.For example, would parent/child relationship just map to a compound collider? A full hierarchy in a compound might not perform as well as a flat setup though. Alternatively should a parent and child be separate bodies but have a Fixed Joint added between them?
Our primary focus is in supporting the community to be able to make these sort of additions for themselves as cleanly as possible.

 

A common use case for this is when you have destructible triggers or kinematic bodies and you want to drive their motion by directly manipulating the transform of the parent. For example, if you had 10 coins that players could pick up that you wanted moving in a circular pattern at the center of the map, what you might do is parent each coin to an invisible entity at the center and then rotate that invisible entity. As a slightly more complex example, Mario Kart's triple green shell comes to mind, where the shells spin around the player like a shield.

 

There's not much of a public roadmap so I was more just wondering rather than having a specific need, hierarchies and what the transform system offers are just nice to have in terms of general purpose usability as well as understanding.

Though currently for characters and their respective body part colliders, I use ComponentDataFromEntity pretty extensively to link them to their visual representations.. but would this scale better than a hierarchy type of system? It takes a little more doing to manually chain to their respective visual representations, and just feels a little strange though maybe i just need to get used to the flattened nature of things.

 

agreed with "destructible triggers or kinematic bodies and you want to drive their motion by directly manipulating the transform of the parent", e.g. torch fire in botw.

 

We've made the following change for the next release (no ETA on it yet):

In order to lead to more predictable behavior and allow for repositioning instantiated prefabs, static bodies are no longer un-parented during conversion. For best performance, it is still recommended that static bodies either be root-level entities, or that static shapes be set up as compounds. Dynamic and kinematic bodies are still un-parented.​

This means that if you have some non-dynamic body we can ingest it when it is nested in a hierarchy, it is just less optimal for performance.

 

in my test of current version, non-body (only PhysicsShape trigger added) child would be considered as compounds, thus, its (dynamic) parent's center of mass would change, hope this would be fixed in new version.

 

Thanks for reporting, we'll get it fixed!

 

By static bodies does this mean things that are intended not to move during runtime(related to StaticOptimize?)

 

The physics world has two trees in its bounding volume hierarchy: a static tree and a dynamic tree. The dynamic tree is basically all bodies with a PhysicsVelocity, while the static tree is everything else. So in the case of physics, "static" could be something with StaticOptimize, or a trigger volume you move around. The point though is that loading, unloading, or moving around such static bodies requires rebuilding the static tree, so it should ideally happen infrequently.

 

Please don't remove the unique feature of parenting a PhysicsBodies still uses localspace for collisions, at least give the option to still use this if you ever change it. : )