Softbody response varies greatly with timestep

[SynapticBytes]

I am testing my bullet plugin with a multifaceted, amorphous rocky blob shape. I drop it onto the top of a set of stairs, then let it roll down and bounce into a wall at the bottom.

I am wondering why, simply changing the simulation timestep greatly changes the response of the object. At a timestep of 1/180th of a second, it is like a very bouncy blown up balloon, with little give. At 1/120th, it's more like a soft squishy ball. At 1/60th, it's like a ball of slime than collapses flat when it hits the top of the stairs, and then just oozes its way down.

I know I could fiddle with the many parameters to get behaviour closer to what I want, at the timestep I want, but is it expected there is such a vast difference in response just by turning up the simulation time?

Thanks.

[Basroil]

I am testing my bullet plugin with a multifaceted, amorphous rocky blob shape. I drop it onto the top of a set of stairs, then let it roll down and bounce into a wall at the bottom.

I am wondering why, simply changing the simulation timestep greatly changes the response of the object. At a timestep of 1/180th of a second, it is like a very bouncy blown up balloon, with little give. At 1/120th, it's more like a soft squishy ball. At 1/60th, it's like a ball of slime than collapses flat when it hits the top of the stairs, and then just oozes its way down.

I know I could fiddle with the many parameters to get behaviour closer to what I want, at the timestep I want, but is it expected there is such a vast difference in response just by turning up the simulation time?

Thanks.

Try changing iterations by the same amount (2x, 3x) and you should see similar effects. But if you go to 5-6x (substep frequency or iterations), it should start leveling out. If that is indeed what you see, it's just that the error between the points is too great for a default simulation parameter set. If you only see timestep dependence, it might be one of the more annoying issues.

[SynapticBytes]

Try changing iterations by the same amount (2x, 3x) and you should see similar effects. But if you go to 5-6x (substep frequency or iterations), it should start leveling out. If that is indeed what you see, it's just that the error between the points is too great for a default simulation parameter set. If you only see timestep dependence, it might be one of the more annoying issues.

Thanks for the reply.

I take it your mean the solver iterations? I keep max substeps for the stepSimulation at 5 currently, Haven't noticed any difference in varying from this. At 1/120th, I had position iterations at 22. At 1/60th, I upped it to 44, 60 and finally 100. It got better at volume preservation each time, with 100 being about equivalent to the 1/120th & 22 setting, but with 100 solver iterations, performance is grinding down. I set the cluster/velocity/drift iterations to 0, as they don't seem to have a predictable effect.

I guess it's all a matter of trade-offs. I was hoping I could get the softbodies working reasonably on a mobile platform, but with the performance running even on my desktop, looks like it may not happen, although I have yet to try seriously finding if there is anywhere I can get performance improvements. Very hard to profile a .dll running in an interpreted environment.

*EDIT*

Still, even while changing the parameters lets me get a reasonable result at a lower simulation step speed, there is still a significant volume preservation difference at higher step speeds. I guess that's just the way it is, and you have to fiddle with the speed and the many parameters until you get values you like at the speed you want. I was hoping step speed would more just be a smoothness difference rather than a complete physics response difference.

[Basroil]

I was hoping step speed would more just be a smoothness difference rather than a complete physics response difference.

Nope, speed determines how much error you have (along with iterations, solver type, etc), so you'll end up with different responses based on that. It's not like FEM where you can theoretically have nodal accuracy and the points between are just changed, the errors between frames keep piling up so lower error per frame can become a huge difference in a short period of time. You just need to find the "good enough" point for your simulation, sometimes default settings are enough, sometimes you need 1kHz and 500 iterations (though I've personally never needed that much)