getIntersection Performance

[ExBemined]

Hi,

 

We are suffering from some poor performance in our physics update, and the profiler pointing at the PhysicsScene::getIntersection function. There are only about 150 physical objects in the scene and they are not touching each other, but still this function is finding like 20000 intersections, since for each shape (and some physical objects have like 10 shapes on the same body) it's finding all objects that overlap with it, even objects that do not have any physical body. In fact like 99% of the intersections it finds are for non physical objects but are simple shapes overlapping visual meshes often belonging to the same objects. It's taking a long time to process all this data, and then even more time is taken to then quicksort them.

 

Is there some way we can improve this? I saw that objects with disabled bodies are being ignored in the add_shape function while objects with no body are still being process, so I tried adding dummy bodies to these visual objects and it did seem to improve the performance a bit, but not it was still rather heavy. Are there any tricks with parenting or spatial partitioning we can try to fully get rid of this overhead? We are still using Unigine 2.2.1 at the moment and I cannot test if it improved in 2.3, due to project deadlines we probably can't upgrade until the end of this month. So we need to boost up the performance in 2.2 a bit for now.

[silent]

Hi Michiel,

 

20k intersections for 150 physical obejcts is indeed very large number. Maybe it's better to create simplified geometry for the other meshes and configure properly intersections / collisions masks to avoid intersections with high-poly geometry in scene.

More detailed information we can give you only after checking the whole test scene.

 

Thanks!

[ExBemined]

Hi,

 

20k sounds a lot yes, but with 150 physical objects that each have multiple shapes (some big objects like a 150 meter long ship can consist of 20 or more shapes), and Unigine does these intersections for each shape individually with all objects in the scene. Some objects also consist of multiple separate ObjectMesh objects because of moving parts, and also a number of ObjectBillboards were intersecting with the physical shapes. So that all seems to add up.

 

However I discovered that the main issue here is that the spatial tree was messed up. Somehow all 150 objects ended up in the same leaf with an infinite (well, 1000000000 units) bounding box. So it ended up doing bounding box checks against practically every object in the scene rather than just the ones nearby. Some objects seem to end up with a bounding box set to inf, messing up the spatial tree. Is this a known issue and is there a way we can avoid this?

 

Unfortunately I can't simply give a test scene as most of these objects are spawned dynamically from script (or even from custom plugins).

[silent]

Hi Michiel,

 

I'm afraid, we never met such issue. If you can prepare some test scene when you will have more free time - it surely will help us in debugging. Right now (based only on a text description), I'm afraid it's not possible to find out what happens.

 

Sorry for the inconvenience caused.

[ExBemined]

Creating a test scene would take some time because we would need to isolate the problem, also I'm not sure if it's reproducible there as I suspect one or more ObjectExterns are causing this problem which require custom plugins. After digging a bit deeper I noticed that the reason those bounding boxes became infinite is that some objects report they have infinite size to fool the frustum culling and checks for not updating objects far away because the extern object is handling this internally. However with an infinite bounding box, the spatial tree seems to always split on the z-axis (WorldNode::get_plane checks for biggest axis of the BB to determine splitting axis, but with all axis being the same infinite size, it keeps picking z).

 

Are there any alternatives for setting bounding box to 1000000000 units to make sure extern objects are always rendered? Perhaps that would solve the problem, as from the code I suspect it will work correctly when objects have correct positions and bounding boxes.

[unclebob]

Hi Michiel,

 

I think we could fix infinite bounds (except for some large nodes like ObjectWaterGlobal) and add some kind of forced render queue. Just like engine.world.addUpdateNode / addUpdateNodes which allow you to force update custom nodes even if they're not visible. Is that be enough?

 

Can't give any ETA though.