Real-Time Physics Simulation Forum

Bullet software makes distinguishment between classes and structs. The btCollisionObject is a struct at the moment, and for structs I allow direct data access. Yeah - for simple structs with no member functions, I would also leave the member variables exposed - but btRigidBody is a CLASS (admittedl...

Good point! :-) But seriously - doing that vast number of objects seems quite do-able with GPU-based physics - the performance shouldn't be hard to achieve once we figure out how to get all of the algorithmic steps wedged into the slightly peculiar restrictions of the shader processors. I think we h...

From reading the demo programs, it seems that the only way to perform some operations on btRigidBody objects is to access the raw member variables of the base class (eg, the Demos/OpenGL/DemoApplication.cpp reads and writes 'm_worldTransform'). This is kinda nasty because it means you can't tell whe...

No problem!

http://continuousphysics.com/Bullet/php ... .php?t=500

In the sample programs, you have a lot of application program functions that start with the string 'glut' - that's not a wise move. The entire point of having all actual GLUT functions beginning with 'glut' is precisely to avoid the risk of some GLUT function coincidentally havintg the same name as ...

I guess the other property you need is density.

There is a nice table of densities in Wikipedia:

http://en.wikipedia.org/wiki/Density

I just did a checkout from SVN - and the 'trunk' version is missing a file LinearMath/btQuickProf.h: No files missing: it was a typo in DemoApplication.h, QuickProf.h -> Quickprof.h I'm surprised that my Mac OS X build just worked fine?! It has been fixed in SVN. I'm on travel, and the hotel connec...

Even if you didn't clamp it, the fact that the computer doesn't have infinite precision should mean that roundoff error will eventually allow the velocity to reach zero. But since that could take quite a while and there are performance optimisations to be had by stopping things from moving unnecessa...

I just did a checkout from SVN - and the 'trunk' version is missing a file LinearMath/btQuickProf.h:

In src/BulletCollision/CollisionDispatch/btConvexConvexAlgorithm.cpp and in the CcdPhysicsDemo, there are references to:

m_ccdSweptShereRadius

Is that a typo? I presume it should be 'm_ccdSweptSphereRadius'.

There are a bunch of global variables exported by src/BulletDynamics/Dynamics/btRigidBody.h : extern float gLinearAirDamping; extern bool gUseEpa; extern float gDeactivationTime; extern bool gDisableDeactivation; extern float gLinearSleepingTreshold; extern float gAngularSleepingTreshold; It's not g...

Bullet doesn't work with 'time' only with time differences (timesteps) which are small, so no need for doubles there. That's reasonable. We just need to be alert for absolute times that might creep into the API at a later time. It's another one of those things were people debug their programs over ...

The problem with having btScalar switchable between float and double is that you'd incur double precision costs throughout practically all of the math in the entire package. In truth, it's only distance and time that really needs doubles. Velocities, accellerations, forces, masses, impulses, torques...

no, it's not a problem. Unless you enable profiling (btQuickprof.h) there is no symbols in the library, it is all inline headerfiles. You can safely ignore it. I might add some large methods in a cpp, to avoid this warning. Thanks, Erwin One of the other problems with empty libraries is that people...

Yeah - actually, I hadn't noticed that - but double precision positioning is very important for me too. If you are working on large areas of operation, the precision of a float drops off alarmingly quickly. A positional accuracy of one part in about 4 million is the best you can hope for with roundo...