What is the future way to create compound impostors?

[binki]

When I look at the docs for [Scene.createCompoundImpostor](http://doc.babylonjs.com/classes/2.5/Scene#createcompoundimpostor-parts-options-rarr-any), it says that it’s deprecated without any explanation about what I should be using instead. [in the source](

https://github.com/BabylonJS/Babylon.js/blob/a39bc290e505bd2ced0fa1c3fa5bf346b84d88bf/src/babylon.scene.ts#L3089) I see the same thing—a mark of deprecation with no explanation.

 

Is there an example of how to create compound impostors? E.g., can I get two or more spheres to be tied together as if there were such a thing as a rigid joint constraint without using the deprecated function or physicsBody hacks?

[binki]

FWIW, here’s my attempt at unrolling the code from createCompoundImpostor: http://www.babylonjs-playground.com/#2HLXWU#0 But as you can see, the sphereChild doesn’t collide with the ground like I expect it to.

[Sebavan]

@RaananW will be your man on this one :-)

[binki]

Oh, seems like the code requires you to write to `AbstractMesh.physicsImpostor` because it just does. If it is really required to write to `AbstractMesh.physicsImpostor`, why doesn’t `new PhysicsImpostor()` just do that for you? It’s sort of confusing in the same way that requiring you to call `PhysicsImpostor.forceUpdate()` is.

Another question: why does making a compound impostor require this parent-child relationship? Shouldn’t all of the impostors be siblings instead of arbitrarily choosing one as the parent? I can sort of see that there should be a parent (as the compound impostor thing sort of eats the child impostors), but it seems weird that one of the child Mesh object has to be the root of the compound grouping. Is there a way to group the spheres without any of them being the parent and using some non-Mesh grouping thing (or something like `AbstractMesh` as a grouping thing?) to group them together in a more logical way?

Is there a way to set a mesh’s parent without having to remember things like “I need to call `parent.physicsImpostor.forceUpdate()` whenver I do this”?

[binki]

Oh, my updated playground: http://www.babylonjs-playground.com/#2HLXWU#2

[RaananW]

hey!

Sorry, I am busy as always!

So, compound impostors are now being implementing using babylon's parenting system.

an object with an impostor that has a child with an impostor, will be a compound of them both. Does it make sense?

The thing with the force update - it is not needed, when you create your impostors after setting the parent attribute. So, updating your playground - http://www.babylonjs-playground.com/#2HLXWU#3

Hope it helps, and I do hope I actually answered the question...

[binki]

Thanks for the comments.

 

I still find it confusing that I have to choose one of the meshes to be the parent just to get a compound impostor. Is there a non-mesh grouping object I could use as the parent instead of a mesh with an impostor attached?

 

Also, it is confusing that the parenting system requires an exact sequence in setting the physicsImpostor on the parent and child (i.e., child must be set first). Shouldn’t it not matter and you be able to recompose arbitrary groups of meshes into/out of compound impostor groupings? The parent/child of BabylonJS without physics is a lot less constrained than when using physics. But if you start using impostors and expecting things to work when you parent things, suddenly you have to follow rules such as the sequence you set impostors. It seems like the type system/API makes it easy to do things that won’t work with the new way ;-).

 

Maybe some of these issues could be resolved with documentation updates.

[Wingnut]

Hi guys!  This is some heavy thinking, here.  Binki, I feel your pain and curiosity.  Here's my take.

The best compound impostor... is made-of various other impostors... which are cooperating (grouped).  But, think about that.  When two sphereImpostors are linked/jointed together, they are in battle.  So, to build a compound impostor, it is more sane to "sum" the area of the two shapes, and attach a box impostor of THAT general size.  Since ONE of the two shapes will be ONE "extent" of this new "summed low-detail boxImpostor", we might as well use it as the "master" of the compoundImpostor.  I think this is why ONE of the shape-parts... is used as the master.  It is considered a boundingBox extent (one edge/corner of the new derived bounding area).

OR, I could be completely wrong!  

Has anyone ever wondered... what would happen... if child mesh overlapped parent mesh? (both physics-active) 

You know how those darned impostors HATE being inside one another, and prefer to "spit-out" each other?  Coooool.  Would one impostor be put into constant "barf it out" mode, while the parenting says... "you ain't going nowhere, overlapped child impostor".  Parent-child wars!  CPU mega-chow!

Pretty soon your browser's immune system would start breaking-down, and then... blue screen of death! 

err... okay, maybe not that.  Good questions/thinkings, Binki!   Gotta think about... "What IS compounding?"  When the sphere impostor is attached to the box impostor... don't you lose the best features of both?  Really, they should be distance-jointed together, so sphere keeps its sphere-ness physics, and box keeps its box-ness physics.    Even then... that joint... hurts the box and the sphere.  They are both hands-tied... so they can't roll with the flow. 

Over in another thread, I think @Hans and I discovered that we shouldn't ever scale the parent, but that's all I have learned.  (I hope you weren't expecting anything wonderful from me)  heh

 

[RaananW]

On 2/5/2017 at 2:48 AM, binki said:

Thanks for the comments.

 

I still find it confusing that I have to choose one of the meshes to be the parent just to get a compound impostor. Is there a non-mesh grouping object I could use as the parent instead of a mesh with an impostor attached?

 

Also, it is confusing that the parenting system requires an exact sequence in setting the physicsImpostor on the parent and child (i.e., child must be set first). Shouldn’t it not matter and you be able to recompose arbitrary groups of meshes into/out of compound impostor groupings? The parent/child of BabylonJS without physics is a lot less constrained than when using physics. But if you start using impostors and expecting things to work when you parent things, suddenly you have to follow rules such as the sequence you set impostors. It seems like the type system/API makes it easy to do things that won’t work with the new way ;-).

 

Maybe some of these issues could be resolved with documentation updates.

Being the one who implemented this, I can tell you I think you are (partly) right. 

There were a few architecture decisions that had to be made while implementing the compound system. 

I understand what you are saying, I'll try thinning of a solution.