My convex hulls are restless (JBullet)

[wasp]

I'm working on a Tetris clone using the Java port of bullet (don't hate). Due to the fact that standard Tetris rules are incompatible with cool physics effects, I've had to improvise. Instead of clearing lines, I cut a swath through them, leaving fragments behind. These fragments are ConvexHulls. The full pieces are compound shapes each made from one or two box primitives. This produces a very cool effect, and makes gameplay even more interesting.

My main issue is that the fragments do not stabilize. They continue bounce ad nauseum, and it totally ruins the effect. The fragments all have their restitution coefficient set to 0.01, just like everything else.

My other issue is that ConvexHull is not exactly the right collision type for the fragments. Since the fragments are formed from effectively concave objects, the fragments are often also concave. What sort of collision shape should I use instead? It appears that the convex decomposition library has not been ported to Java.

I look forward to hearing from someone. Thanks, all!

[sparkprime]

Why not just use compound shapes full of boxes for your fragments? If a box is cut in half you can use a convex hull for that.

For the jitter, you have to give more information, at least

* gravity
* step size
* box size

[wasp]

Why not just use compound shapes full of boxes for your fragments? If a box is cut in half you can use a convex hull for that.

The boxes cannot be guaranteed to be cut in half. The swath that is cut through it is always at an angle (though sometimes the angle is nearly zero).

For the jitter, you have to give more information...

My gravity is standard. Each tetris piece has an area of 4 and a mass of 1, so I calculate the area of each fragment and find it's proper mass based on that. It appears that my timestep is 1/30 with a maximum of 10 substeps, but that's just what the example that I started with used.

Also, I arbitrarily remove any fragments with mass less than 0.1.

Thanks for the help. Please tell me if there's any more info that would be useful.

[sparkprime]

That's why I said convex hulls instead of more boxes -- any convex object when cut with a flat plane will yield another convex object so you can turn your boxes into hulls at this point (or just start with hulls if you feel like it).

1/30 is a bit low but your objects are also quite large so you probably ought to get away with 1/30. You can try increasing it by 2x or 3x to see if the jitter goes away. You can also try damping them and/or use a zero restitution (there is still a bit of bounce sometimes even with zero restitution).

[wasp]

That's why I said convex hulls instead of more boxes...

Ok, I got ya this time. That solution has been on my mind, but it complicates the geometry and would require fairly extensive rework of my classes. I'm trying to avoid it, but I'll do it if I have to. I'm a programmer, lazy to the end!

1/30 is a bit low... You can try increasing it by 2x or 3x to see if the jitter goes away.

I tried switching to 1/15, then 1/10, but the jitter remained. The only difference seemed to be that everything moved twice/thrice as fast (because of how I have it set up).

You can also try damping them and/or use a zero restitution (there is still a bit of bounce sometimes even with zero restitution).

I tried zero restitution for all objects, but the fragments remained bouncy. I perceived a slight decrease in jitter, but it may have been my imagination.

Thanks for all the help. If anyone has any fresh ideas, I'll be glad to hear them.

[sparkprime]

sorry i meant try 1/60 or 1/90

you could also try changing the number of internal simulation steps for the solver m_solverSteps or something it's called

what collision shapes are you using for the environment around these blocks? classes, sizes, etc

[wasp]

sorry i meant try 1/60 or 1/90

I tried 1/60, and it seemed a bit less jittery, but this is not a workable solution because slowdowns were very noticeable even under moderate load. My system is rather rudimentary, and cannot skip frames.

you could also try changing the number of internal simulation steps for the solver m_solverSteps or something it's called

Correct me if I'm wrong, but wouldn't this produce excess load the same as decreasing step size?

what collision shapes are you using for the environment around these blocks? classes, sizes, etc

Everything else is box primitives. I have two walls and a floor, plus two frictionless z-retaining walls to prevent movement on the z-axis and rotation about the x- and y-axes. All are static.

I hope that helps.

[sparkprime]

It could actually be those retaining walls causing the jitter, if things are getting 'jammed' between the two surfaces. Try using the standard technique for restricting to 2d -- I can't remeber what it is but I think it involves constraining all the objects using 6dof. The documentation is pretty clear about how to do that iirc. It's either in the manual or FAQ or something.

[wasp]

I removed the retaining walls, and it eliminated the jitter! Now I just need to figure out how to stop pieces from falling off.

I find it curious that I only ran into problems when using fragments.

Thank you for all the help. You're going in my special thanks section!