Havok physics bodies going through collider

I'm instantiating 4096 cubes above a large static collider. 90% of the cubes fall right through the collider, the 10% that are remaining are floaty/bouncing around like crazy.

If I reload the scene, the behaviour seems to be gone. The cubes land on the collider fine, and eventually stop bouncing around.

With Unity's DOTS physics package, the cubes land on the collider just fine but I end up with a way poorer performance. I'm 100% sure the problem exists between the keyboard and the chair. Very new to DOTS.

Not sure if it's relevant. I'm using the ConvertToEntity flag workflow for everything.

EDIT: Everything is fine when using sphere colliders instead of box.

EDIT2: Setting the Bevel Radius to 0 when using box colliders seems to fix the issue. That's good enough for me.

 

Hi @ADNCG , I'm curious to learn more about your problem, could you please share more details (ideally a small project with repro)?
Did the same scene work properly with UnityPhysics simulation type while cubes were falling through static collider (cube/plane/mesh?) with HavokPhysics? Did you only change the bevel radius to fix it and what was the problematic value?

Thanks in advance!

 

Sure thing, https://github.com/NCEEGEE/CubeCollisionIssue

Yes exactly, the cubes are falling through a box collider when simulating with Havok. Behaviour seems fine with Unity's simulation.

Yeah, setting bevel radius to 0 seems to have fixed the issue. You can reproduce the issue with a value of 0.1. You want to modify the prefab named "Pixel". This is the prefab used for the cubes. I put one in the scene for convenience.

 

Thank you! Investigating...

 

Hi @ADNCG, sorry for the delayed response. The bevel radius of 0.1 is too big, because you're scaling the shapes with factor 0.1 in GameController.SpawnPixel() and that makes bevel radius same size as box edge (0.1 and 1 * 0.1).

BTW, performance should improve significantly if you start using Burst and doing entity manipulation in parallel jobs on worker threads. UnityPhysicsSamples could help: https://github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/UnityPhysicsSamples .

 

Ah, I wrongfully assumed the bevel radius would be multiplied by the scale. I see how that makes no sense now since scale could be uneven on different axes.

I'm sorry it turned out to be a user issue and not something that could advance your work. I appreciate the reply.

I'll get right on that. Thank you for sharing!

I've already downloaded that project. I've been comparing the planet scene/project setup to mine to attempt understand why my computer runs the planet scene at 60 fps just fine with 10k entities, but my project has a very hard time running 10k entities. I mean just the physics simulation without my extra logic. I assume it's because there are a lot more collisions to process since everything is cluttered, but I was wondering if something comes to mind that could help?

 

One of the things to note at the planet demo is that all shapes in there are spheres (from the physics point of view). It makes calculations a lot faster. Not saying that's the reason, but it could be.

 

Yeah the planet gravity demo uses spheres and there isn't that many collision really. You boxes are quite small and often overlapping. Its more expensive to calculate penetration information than separating distance information. The bevel radius adds a numerical tolerance to the physics shape helping keep away from the penetration state while adding a little curving to the corners and edges. A zero bevel radius gives you the original box shape but means you are more likely to get into the penetration state.
You could actually simulate all your cubes are spheres if you don't want need them to rotate. If they had a mass but infinite inertia (i.e. can have linear movement but no angular movement), then it wouldn't matter too much if the collision representation was a sphere. The downside is that they will look to be overlapping in the corners but you might not notice that much and the performance gain could be preferable.

 

@milos85miki @petarmHavok @steveeHavok Thank you Havok team, you guys are amazing. I appreciate the time you took on an already packed schedule I'm sure.