Watching the debug renderer is often helpful. Objects are drawn in different colours, to indicate their state, e. g. white = active, green = sleeping, red = deactivation disabled.
The SDK will, sooner or later, include a Bullet demo. But I think this will not be the collection of samples I have done so far - those are intended as a step-by-step tutorial, each introducing a different part of the Bullet module. The sample for the SDK should be one application and not a bunch of scripts, and it should be representative. So are still looking for a representative scene/sample/…
My current plans are to add the samples (or a download link for the samples.zip) to the manual pages, but having it on the first post of this thread is also a good idea.
The API documenation is generated from the Panda3D source code, using Doxygen. Each class and each method can have a “description”, places in the comment block before the class/method. It does not matter if the method is implemented in the .I or .cxx file. So basically it is modifying the source code in CVS. If you want to write class/method descriptions you can also send me the text blocks for each class/method, and I will copy/paste them to the code for you. Any help is highly appreciated here. So far none of the classes/methods have documentation on them.
The cone/twist constraint is a special kind of spherical constraint (old name: BulletDistanceConstraint, new name: BulletSphericalConstraint, original name: btPoint2PointConstraint). Another common name for this type of constraint would be “ball and socket joint”. The cone/twist constraint allows setting limits on how far the ball rotates inside the socket.
Oh, so it’s another name for “point to point” onstraint. OK then. I’m not sure what the TransformStates are used for. The position part of TransformState is for setting the location of the point relative to to center of the bullet node, and the hpr values are the default angles?
I’ve written something up for BulletHingeConstraint and BulletVehicle: pastebin.com/7GsGKiXN
Everything I know got in there, even the obvious things like getCurrentSpeedKmHour(), you might want to leave such ones out if Panda has some documentation policy… At least BulletWheel will follow tomorrow. Let me know if I can do something in a better way!
I added the class/method descriptions to the Panda3D code in CVS. The next build of the API documentation should contain them. Thank you very much for the contribution.
Now, before I type anything for the BulletWheel: what file should I use to make a patch that you can apply directly? The header file for class description and the rest in the .I one?
I almost feel the pain imagining you copying over all that stuff into the source file…
To copy the descriptions took about 5 minutes. If you want to use patch files this is fine too. The class description is in the .h file, the methods in the .I and .cxx files.
In case anyone else was trying to do something similar, my solution so far is simply to compare the difference in velocity of an object each step with its velocity the previous step (divided by duration of step). In other words, get it’s accelleration, which allows me to determine if it has been hit hard enough to take damage. It works quite well for characters, because they naturally take damage when falling too hard or being hit by vehicles etc. I’m not sure how efficient it is though.
I have another unrelated question that I hope you guys can help with. I want to build an environment similar to the layout in GTA1 (but nowhere near as big). The world will be divided into a grid, as seen in my terrible illustration, each block having its own height value.
I think it will be relatively easy to create one big bullet collision shape from these points using Bullet’s Triangle Mesh shape OR a whole lot of Box Shapes (maybe with some planes for the ground). Which method would create the most efficient collisions?
On the rendering side of things I have the same question (sorry, I know this isn’t really bullet related). Would you recommend using the “card maker” for all the faces, or is there a more efficient way (again, efficiency of graphics resources, not creation time)?
Using box shapes would be more efficient, without doubt. You should generally only use triangle meshes as a last resort. Triangle meshes are generally very inefficient compared to other methods, and they are very prone to all kinds of artifacts and glitches.
You can use a single plane for the ground. A plane (or rather, a half-space) is probably the most efficient and effective solid out there.
For buildings that are not box-shaped, eg with a slanted roof, I would recommend using a convex solid.
Hey. I have a sandbox game right now and I want to allow people to load their own objects in the game. My question is, should they model their collision geometry, or should I let the game generate one itself (for example by using the bounding box)?
So…
Collision detection: lots of simple objects are better than one complex.
Rendering: Fewer complex objects are better, BUT you don’t want to render things that aren’t on screen. So I could make each city block (roughly the size of the overhead view) a single piece of visible geometry, so that the other blocks aren’t rendered?
I’ve recently tried to install last build (Windows, #293) and the glaring difference to the build I currently use (#264) is that triangle mesh collision shapes aren’t scaled appropriately (in my case they’re much smaller than visible object).
I have recently changed the way the scene graph synchronisation works. Scale - a concept usually unknown to physics engines - is supported to a higher degree now. However, there still might be cases where scale is not propoerly synchronized. If I am lucky I can check your problem this evening, if not it will be end of the weekend.
For now I can give a little information which might bring some light into what is going on: mesh.addGeom accepts a Geom, which does NOT know anything about scale. The scale is a property of the GeomNode (scene graph), not the Geom. Scale is applied the first time when you insert the BulletRigidBody into the scene graph.
A general advice (I know I have posted this a dozen times already): When using physics it is always better to avoid scale whereever possible. In particular for static environment (castle) it should not be a problem to prepare the geoemetry with the right scale baked into the vertices offline. The only resonable use for scale would be if you have one model of a box, and want to have three boxes inside your game with different sizes. Even then I would consider making three differently scaled models offline. I will try to support scale as good as possible for the Bullet module. But I doubt that it will be a perfect and all-embracing support.