Questions about joints, usage and design of Bullet...

[snake5]

Hi, everyone. This seems to be my first post here, in the forum. Unfortunately I have to start posting here with lots of questions that just haven't gone away by themselves.
I wouldn't classify myself as a complete beginner in physics but there are some new and completely unclear topics in 3D physics and in this library that I couldn't explain with the help of the user manual or wiki. The forum also lacks a FAQ section which I would have looked at before making this post. Another reason for asking is the amount of totally unsuccessful queries in Google that have led me to quite unrelated posts on the forum.

If someone knows a very good source of information that I might not have looked at yet, you can ignore the rest of this post and just point me to it. Otherwise, here are the questions:

-where can I find an in-depth comparison (insertion/removal/query/raycast/optimal body counts and sizes...) of broadphase algorithms?

-which broadphase would work better for levels that have at least 10000 static bodies, nearly 5000 dynamic bodies, most-sleeping?

-how much performance can be gained from using one huge triangle mesh for all of the static bodies?

-what kinds of transforms should I pass to the cone twist constraint's constructor? Are the current transforms of properly positioned bodies good enough?

-how does the cone twist constraint know around which point should the bodies be rotated?

-why does the joint store references to bodies, not pointers?

-how to set group/mask bits after the creation of a rigid body/collision object?

-why are bodies storing material data, not shapes (with the exception of per-triangle material shapes)? What about storing an array of materials in the body and indices in shapes/triangles - any chances I could get this either myself or through a library update without much effort?

-why can't a body have an array of shapes? Isn't this way of storing multiple shapes more memory/cache-efficient?

That's about it, for now...

EDIT: Added some space between lines to make the questions easier to read.
EDIT2: Updated the state of questions.

[snake5]

I really hate to bump topics but this one hasn't received a single though about any of the questions. If you can answer any of those questions, please do so as I'm really stuck with my problems and source code isn't really helpful for me too this time...

[NaN]

an in-depth comparison (insertion/removal/query/raycast/optimal body counts and sizes...) of broadphase algorithms

That would be awesome. If you plan to do it, please share your results. I also recommend to look at/hack the demos to get an idea about the limitations/performance.

From my personal use case 1,000-10,000 static objects and a few rigid bodies 8-32, 4-32 ray casts bt32BitAxisSweep3 and btDbvtBroadphase are interchangeable.
Using btBvhTriangleMeshShape for static geometry is the fastest method followed by btCompoundShape.

Some numbers:
http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=6397

[snake5]

Thanks, NaN, that's really useful.

If you plan to do it, please share your results.

I don't have the time to do it - that was the point of asking. I could experiment with everything else as well but if I have to deliver a game soon, I'd rather use the available information.

[winspear]

-which broadphase would work better for levels that have at least 10000 static bodies, nearly 5000 dynamic bodies, most-sleeping?

Look at the wiki here..

http://bulletphysics.org/mediawiki-1.5. ... Broadphase

I think the broadphase algorithm depends on a lot of things like
1. how you plan to load each scene in a level
2. if you want to add and remove physical objects on the fly or not
3. whether your scene world is dynamically changing etc..
4. What kind of static bodies that you use? Boxes, spheres are computationally inexpensive while tri-meshes, concave meshes are expensive.

Look also at the benchmarking done at the end of that wiki page.
It looks like the dynamic aabb's prove to be more efficient as the number of boxes increase but then again this test was done only with boxes and does not prove much.

Thanks
V

[snake5]

Thank you for the reply! I'll try to answer to those questions and hope that they are of any help to everyone who could suggest something.
1. how you plan to load each scene in a level
I can do nearly anything that's necessary for the broadphase to work fast enough.
2. if you want to add and remove physical objects on the fly or not
It depends on how I make ragdolls. If it's possible to use ragdolls as the way to determine the place where the bullet hits the body, I could avoid creating bodies. If there's a better approach, I could create ragdolls only when they're necessary.
>>Btw, could anyone tell me what's the most efficient (in both running speed and development time) approach to make/use ragdolls with Bullet? I'll check the demo soon but if there are better suggestions, I'll be happy to hear them.
3. whether your scene world is dynamically changing etc..
It would probably be mostly static. Only some bodies at some parts of the level could move. Stacking is also minimal.
4. What kind of static bodies that you use? Boxes, spheres are computationally inexpensive while tri-meshes, concave meshes are expensive.
Only triangle meshes.

So the best way to go about it is to try a few sample scenarios with both algos and decide for yourself since everyone's requirement is different.

Hmm... looks like I could do that.

Ok then, the broadphase problems are pretty much solved. The most important question now is the one about cone twist constraints, with questions about design following after that.

[snake5]

I looked at the Ragdoll Demo and it looks like custom, local transforms are passed to the constructor of cone twist joints. My guess is that those transforms move/rotate bodies to positions in which the connection point is at [0;0;0] and the rotations are locked between both bodies if the limits are equal to 0. Am I right? Or is it the inverse of those transforms that the constructor requires?

[VicariousEnt]

Searching for some ConeTwistConstraint answers myself and came across this thread. Its not too old so I'll answer what I can with my experience thus far. Alot of these questions I figured out by reading source, testing demos and trail and error. Most of these could be easily answered by comments in the headers. I'd love to see more comments in Bullet, it would make life much easier. The parameter descriptions, function purposes (if not obvious), gotchas, etc.

-what kinds of transforms should I pass to the cone twist constraint's constructor? Are the current transforms of properly positioned bodies good enough?

-how does the cone twist constraint know around which point should the bodies be rotated?

The transforms you supply in the constructor works the same as with the other constraints. The AFrame transform is a local space offset from RigidBodyA that defines the point at which the constraint is bound\rotates around. Likewise BFrame is the local space offset from RigidBodyB that that body will rotate around. Once activated, the constraint will try and keep the world space representations of those 2 points together. If you want to bind a single body to a static or dynamic point\anchor, use the constructors without the B rb or BFrame references. The AFrame behaves the same, but after construction set the BFrame only with a world space position as needed to set and\or move your anchor point in the world. Really wish that last one was in the comments, its not very obvious. I had to figure that one out by searching for the code that allows you to pick up dynamic objects in all of the demos.

-why does the joint store references to bodies, not pointers?

References are generally safer then pointers. Internally they end up being the same thing but its usually better to use references in C\C++ whenever possible. If you want to reuse an existing constraint with a different rigidbody, use new "in place of" on the constraint. There is no memory allocation in Bullet's constructors so this is safe to do during runtime.

-why are bodies storing material data, not shapes (with the exception of per-triangle material shapes)? What about storing an array of materials in the body and indices in shapes/triangles - any chances I could get this either myself or through a library update without much effort?

Techincally its the btCollisionObject that stores the material data, but it is inheirted by the rb. I'd guess it was put there instead of in the base shape class so that that information wasn't duplicated in btCompoundShapes, though it could have been usefull to have seperate material values for those.

-why can't a body have an array of shapes? Isn't this way of storing multiple shapes more memory/cache-efficient?

You can. Again, see the btCompoundShape class.

My turn now. Anybody know how to add a little resistance to the twisting action in btConeTwistConstraint? None of the parameters in its setLimit call or setDampening really does what I'm looking for. This constraint works great but I find the twisting action to be a little too prominent and loose\fluid in my simulation (ragdoll). I'd like to dampen it or add some resistance or friction. I can't see a good way to do this without fiddling with motors which sounds like it would be problematic.

[VicariousEnt]

Oh one other thing. Maybe its too minor to bother adding to the issue tracker or fixing it may cause other issues, but the twist limit debug rendering doesn't work when the rigidbodies its attached to are set to Static. The 2 swing span limits render fine, its just the twist limit. Looking though the code I'd say its because btConeTwistConstraint::m_twistAngle only gets initialized from a call to btConeTwistConstraint::calcAngleInfo() which probably doesn't happen untill the RBs have been activated.