In physics v1 a Mesh has a property .physicsImpostor which allows to store associated PhysicsImpostor. Can physicsAggregate to be added as a property as well? This would simplify the migration process a lot.
I know that on JavaScript I can assign this property anyway, even if the initial class doesn’t have it, but this would be an “interface violation” in this case.
As an alternative I can store it in the .metadata property, but this makes migration not that smooth.
Before opening an issue to keep track of this. can you give more explanation on your use case? what can 't be done now that will be able possible with that?
It’s not like something cannot be done. Previously the mesh itself had a property .physicsImpostor , so I got used to keeping impostors attached to mesh this way. So, during any scene interactions I could easily get a corresponding impostor from any mesh and vice versa. Now I am migrating everything to physics v2.
Since the mesh doesn’t a .physicsAggregate property I need to redo a logic regarding how I will store and access corresponding aggregates from meshes. So, having a .physicsAggregate property in mesh would make migration from V1 to V2 easier and V2 could look more consistent with V1.
It’s not like a critically needed feature. It’s just something what would be nice to have. And it doesn’t seem like something hard to implement (I may be wrong).
we are trying to not add anymore data to mesh for 2 reasons:
But the Mesh already has .physicsBody property: https://doc.babylonjs.com/typedoc/classes/BABYLON.AbstractMesh#physicsBody
How does adding .physicsAggregate property hurt?
Yes and this is not something we want to continue. Adding a link to the new physic api will add more dependencies (as v2 is in a new file)