Not really sure if that’s the most appropriate title. I did a search, but could only find things in relation to stacking and jittering.
Anyway here is my problem. I’m just doing some testing, so ignore the atrociousness of the colors and what you’re looking at. Basically it’s just a series of stacked cylinder type objects.
That’s how they start. When the game starts simulating them, they all deflate such that the colliders all start intersecting with each other. I want them to remain roughly in the same area, since they are perfectly stacked to one another… so that I can sleep them and then later they can react to physics.
Is this something to do with scale? The rigidbody physics quirks and stuff are still much a big mystery to me.
Upping the sleep velocity is AFAIk mostly for performance reasons if you have a higher solver iteration count, which can become costly if you have a lot of stacked objects not going to sleep properly.
They aren’t awakened until something hits them, which is what Raziaar specificied. So yes it solves the problem; I seem to remember the docs specifically recommending this somewhere. In any case, Min Penetration For Penalty is the parameter that affects how much objects can intersect. The problem with making this a tiny value is that the amount of jitter increases.
Sleeping doesn’t work simply because once they come out of sleep they’ll still collapse onto each other and compress down into about three-fourths or half their total height.
I upped the solver iteration count and that did seem to help a lot. By increasing the scale of the game as well, it’ll help I think.
Once I get all the game mechanics in place I’ll have to do a lot of tweaking to get everything to feel just right, I imagine.
At least I know now what could cause them to fall into each other.
They will; I was under the impression that the primary goal was to get them to appear normally, and later when something hit them, it didn’t matter so much. Looks like it’s been pretty much taken care of though.
So I have this script that is generating these “chips” in a specific order and stacking them up. Very simple really.
Now… it stacks them fine… as you can see when I do a Debug.Break() after it finishes stacking them.
But when the simulation resumes… some of them completely switch spots.
Do you think I just need to do a lot more tweaking with those settings mentioned earlier?
Increasing the iteration count doesn’t seem to help… it actually makes it a bit worse by making some of the top ones bounce up.
If I increase the gap between them(right now it being the exact distance) at start, it makes it worse and increases the chance of them switching spots.
For example…
Pause
Resume
EDIT: I think maybe it all has to do with my gravity. It seems that the default scene settings, which I’m working with, have gravity feeling very sluggish falling down. So I upped the gravity by 10 times so instead of -9.81 it’s -90.81
I’m still very new to how scale and other settings affect the physics, and what proper scales I should be working at to get realistic feeling for my craps game.
That’s probably your big problem. Keep the gravity unchanged, and adjust the scale instead.
If you want the objects to appear to be falling quicker, make them smaller. This will increase their acceleration and velocity relative to their body size.
Modelling these chips at their actual size may cause other problems, though, since the physics engine doesn’t seem to like working with small objects. One method I’ve used for small objects is to model them on a larger scale, and then increase the time scale rather than gravity.
Yes, I was worried that was my problem. Though scaling down to actual size I can see different kinds of problems.
Thank you.
Yeah, I was thinking it might crop up other problems.
I will look into increasing the timescale. Haven’t played around with it much, so I don’t know how exactly changing the timescale will affect things, but I intend to find out.
Hey guys. A little update. Still in the same vein, but a different part of the problem… sort of.
Here’s my problem. I have these tokens stacked. During the course of game play, they can get knocked out of position by a dice or something… whatever doesn’t matter. I am saving the rotation and position values on the tokens so that they know where they belong.
I have a method that lerps the tokens back into position, but before doing so it turns the detectCollisions off on the rigidbody of the token. That way when they’re moving, they won’t collide with anything, especially since they have to stack nicely again as they were before.
When they get into position, I sleep them and turn their detectCollisions back on.
This all works great… until the end. They’ll move back into position and then they’ll suddenly shift down in the world in a bizarre way. I don’t know why they are doing this, because they are supposed to be sleeping and not detecting collisions or anything until they are back how they were before being disturbed. EXACTLY how they were.
It doesn’t always do this, but it typically does.
Here is a series of pictures depicting what i’m talking about.
Okay, here we go.
The tokens have been disturbed and moved wherever… doesn’t matter.
I disable their detectCollisions and lerp them back to their original position…
Here is a successful lerping… everything is working nicely and they are sleeping.
I disturb them again…
They are all lerped back into position but the whole stack seems to have shifted down in the Y axis… NOT where they are supposed to be.
The tokens were initially at their proper spots before all of them suddenly shifted down.
As you can see here, the green ones are stuck beneath the surface. Sometimes they ALL go beneath the surface.
Any help would be greatly appreciated.
Oh and if I do another lerp again, same method as before… they move back up into proper positions… because the tokens know they are not where they were supposed to be.
But sometimes when they move back into proper position they suddenly snap again and no matter what I do will they get into the proper position.
So something is wigging out, and I don’t know what. I don’t think it’s my code… I think it’s something to do with the physics(even though they’re sleeping) or the game engine doing something weird… because some of the time it works properly.
Give me a little bit and I’ll quickly have a video up demonstrating my problem.
EDIT: Okay here is a quick youtube video demonstrating my problem. It should be fairly self explanatory. Ignore the fact that the chips do not act like chips… I realize that… the scale I have is huge… i’m simply testing components.
EDIT: Dammit… it seems like it could be caused by my improperly set gravity again… which I forgot to change right now. But why it works sometimes and not others, I don’t know exactly.
What I usually do is turn off useGravity for stacked objects. All my stackable objects are put in an array held in a master script. This script iterates through them every frame and checks their rigidbody velocity. If it’s above a certain value, I turn their gravity back on. Whenever they’re restacked, I turn their gravity off again.
The above appears to work perfectly, so long as the velocity value it checks for isn’t large enough for box floating.
And then of course set them back where they were once they’re lerped in place. This actually works now.
Your gravity idea seems to work too for me(though introducing a strange problem). I simply set the gravity to false and then set it back when they’re back in position and it all works. Very interesting.
Thanks!
Though I’m sure your response is more geared towards my previous posts… and I think your idea is actually a really good one. Is there no big performance hit for checking the velocities of all the objects every frame?
There is, but only if you’ve got thousands of objects. When the number of stackable objects is in the dozens or a hundred or two, the effect will be negligible. If it ever got too bad, you could also put in code for determining which ones to check. Basically grouping them in nodes, giving each node a large trigger collider, and only checking the stackables of that node if there’s a moving object inside the trigger.