Hi everybody ! I’m picking up Babylon.js after a long time off, so I’m a bit lost.
I got a small 3D board game project where players simply stack pearls on vertical piles.
I’m using models I made in Blender, and basic geometry for PhysicsShape.
But when I keep stacking pearls, they eventually start to glitch down into the ones below on the pile. It feels like it could be related to my assets being heavy because it happens less without textures.
I set up a basic playground here : https://playground.babylonjs.com/#89YSX9#1
You have to click on the vertical piles to spawn pearls on top of them. When it’s getting a bit crowed some of them start to glitch and it looks like that :
Sometimes they even collapse into the one below until they overlap.
(on line 38 in the playground, you can pick which version of the asset to import, the textured version can need 15 sec or so to load)
Thanks to whoever will read this, I’ll take any help and advice. ^^
I hope it’s not a too silly question, but I couldn’t find a similar case in my research.
I think this is semi-related to falling through ground. But in your case, it’s the size and normal of the faces colliding.
Try using a Box-shaped physics body since that will totally be sufficient for your use case. Or, if the “hole” is necessary, try using CSG2 to create it.
Edit: another method might be to implement an invisible box at the bottom of each “pole” and create a linear constraint between it and each pearl LOCKED in X and Z. PhysicsBody in ground with 0 mass (or box to pearl constraint with collisions enabled) and each pearl non-zero mass and box physicsBody. Pole is NOT a physics body. With this setup, physics calculations are super simplified (being all boxes and linear constraints).
It’s still possible to have spheres glitch into each other by rapidly clicking the middle of any pole, but I think this is a separate issue that can be solved by not spawning bodies inside/overlapping one another.
I have the similar issue here falling through ground. Also in your PG, after a couple of pearls the FPS drops a lot and then glitching happens even more.
Using a mesh shape will be less performant that spheres, cylinder or converhull. I’m not surprised to see glitches and bad performances with many bodies.
I would use a compound of more simple shapes instead.
@HiGreg
Slider or linear constraint would be a neat fix, thanks for the tip ! I didn’t think of an invisible anchor. It would skip the slight pearl-pole collision, but I think it’s the best bet.
@regna
Can you explain how the deterministic lock step affects the issue ? Because I tried your PG and swapped to the textured assest to try and see any change, and the pearls pop out of line before falling on the poles. Do you have any clue why ?
@Cedric yeah, I tried to stick with really basic geometry, that’s why I made a very plain pearl shape with about 50 vertices as collider for the actual pearls. But I still wanted the pole to thread through them, so I couldn’t use a box or converhullShape. Linear constraints might do the trick though.
Just to make sure, it is a performance issue ? When I compare to some projects I’ve seen, I didn’t find my scene to be over complex geometry wise and regarding the amount of objects, so I thought I might have a missunderstanding somewhere on how I went about this.
I’m not an expert, but if I’m correct about face normals and collosions, then that is not DIRECTLY related to “performance.” However, if deltaTime increases from a delay in processing a step (aka "performance), even for one step, then the impulse applied by the physics engine from collisions increases the delta velocity and therefore the predicted delta position beyond the collided’s faces.
So in summary, maybe tangentially related to performance. Under this theory, restricting step size seems like it restricts the size of the calculated delta position and recognizes a collision.
Would you call that a synchronization issue between the babylon engine et the havok physics engine ? I think I’ve seen some issues mentioning it when I was looking.
Not directly. But synchronizing them and having a fixed timeStep helps. Though I think having a fixed physics time step is the relevant solution. I’m not familiar enough with the relationship between physics timeStep and engine tineStep to really say for sure. Particularly what happens to the next timeStep, of either, to know how either one “catches up.”
The fast-loading placeholder (red) asset and slower-loading textured asset have different orientations. The hole is correcly vertical for the red ball but is slanted for the textured ball: https://playground.babylonjs.com/#89YSX9#5
I’m confused. I see that the pearl with the texture are tilted, but I don’t understand why. Because if you get the asset (from where it is imported here and drop it in the sandbox, it shows the pearl specimen I’m using to i the instantiate pearls with .clone() is correctly oriented.
if I take care to not have pearl intersections, then every is fine. frame rate starts dropping with intersections. so, I would try to avoid that situation by doing some book keeping and avoid pearl creation where it would create intersection.
another solution that might be possible depending on your design is to avoid using physics and stack pearl on top of the over. adding free fall should no be more than 1 or 2 lines of code.
What do you mean by pearl intersection ? Like when they collide on the ones below as they drop ? Apart from that, I thought pearls geometry should not be intersecting, since they always spawn in a free space.
I ended up fixing it in the playground by setting the pearl motion type to “STATIC” after a 1000ms delay (line 102).
I don’t like that I don’t understand why physics glitch on a fairly simple scene (I remember seeing showcases with a lot more going on) and end up kind of disabling them, but it does the trick.
the issue seems more on intersection. like double click (or clicking multiple times quickly) will result in intersection that can be difficult to resolve, generate many contact points and slows down rendering. I’d suggest to now allow spawning pearls faster that 1 every second or 2.
EDIT: after some tests, I think freezing pearl like you did might be a better idea.
