mrice

cybermax
mrice:
it is very strange that Your system dont have any instability. If the constraint is under big pressure(heavy object(s)), it is unstable. A similar problem I had with ODE, but instability created much earlier.

It depends on what you consider instability. I'd say that's the nature of using an iterative constraint solver, probably made worse by single-precision math. I haven't seen any change in behavior caused by simulating a large number of constraints though. The general “solution” would be to do more iterations and/or simulate a smaller timestep. Simplifying mass distribution and inertia tensors might also help. And the easiest thing to do is to only simulate objects which need to be simulated..

cybermax
mrice: I see your video and its cool, can you give us more info(sim time, object,constraints count etc…). Do you have problem with many constraints - unstable, object vibration????

About 50k explicit objects and 250k constraints. Sim time averaged 2 minutes/frame, but could be alot faster, gimpact collisions were used much more than needed (due to laziness)

I havent seen any instability with constraints. I'm mostly on linux, but the only difference I know of is that bullet on linux doesn't use the Sony vector math library.

cybermax
I dont remember exactly but I think that problem was If I have many object collision with others, like a column formation. Firstly I saw little vibration then reaction forces were increase … in other words, It wasnt stable.
.

Could be that gimpact is configured by default to use a SAT algorithm which doesn't appear to work very well. This test [audenmedia.com] has many stacked concave gimpact shapes.

almatea
and it seems that gimpact body can not be a part of btCompound

You'd have to work around that..