CcdPhysicsDemo question

[bittwiddler]

Hi. I've downloaded the 2.62 library and I'm going through the demos to try and understand where to start. I would like to use the library where possible to compute collisions between a collection of tetrahedrons but I would like the ability to come in at each timestep (before the collision check) and add in my own forces (self gravity, and a few others) and check on a few things. Is the CcdPhysicsDemo code still the recommended starting point or can anyone recommend another I should look at? I guess I'm just having a hard time finding out where I can insert my own computations in there without causing a problem

Thanks for any help

[Erwin Coumans]

Hi. I've downloaded the 2.62 library and I'm going through the demos to try and understand where to start.

Can you use the more recent Bullet 2.64 version?

I would like to use the library where possible to compute collisions between a collection of tetrahedrons but I would like the ability to come in at each timestep (before the collision check) and add in my own forces (self gravity, and a few others) and check on a few things. Is the CcdPhysicsDemo code still the recommended starting point or can anyone recommend another I should look at? I guess I'm just having a hard time finding out where I can insert my own computations in there without causing a problem

If you want to customize the physics simulation loop, you probably need to derive your own class from btDiscreteDynamicsWorld, and override the 'internalSingleStepSimulation'. See Bullet/src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld (cpp/h).

Hope this helps,
Erwin

[bittwiddler]

Just downloaded the latest one.

I'll check out btDiscreteDynamicsWorld in just a few minutes. Does it sound like what I would like to do will work in the bullet framework? I don't want to delve too much in the library if it's going to be a dead end. In that case I'll just use the collision detections in my own program

[Erwin Coumans]

Can you discuss a bit what do you exactly want to achieve?

It would probably be best to use BulletDynamics, it will greatly simplify the use of the collision detection.

It should be straightforward to insert your code into the following code (just derive the class btDiscreteDynamicsWorld),
without getting into deep internals.

Code: Select all

void	btDiscreteDynamicsWorld::internalSingleStepSimulation(btScalar timeStep)
{
	startProfiling(timeStep);

	///update aabbs information
	updateAabbs();

	///apply gravity, predict motion
	predictUnconstraintMotion(timeStep);

	btDispatcherInfo& dispatchInfo = getDispatchInfo();

	dispatchInfo.m_timeStep = timeStep;
	dispatchInfo.m_stepCount = 0;
	dispatchInfo.m_debugDraw = getDebugDrawer();

	///perform collision detection
	performDiscreteCollisionDetection();

	calculateSimulationIslands();
	
	getSolverInfo().m_timeStep = timeStep;
	
	///solve contact and other joint constraints
	solveConstraints(getSolverInfo());
	
	///CallbackTriggers();

	///integrate transforms
	integrateTransforms(timeStep);

	///update vehicle simulation
	updateVehicles(timeStep);

	updateActivationState( timeStep );

}

Hope this helps,
Erwin

[bittwiddler]

Can you discuss a bit what do you exactly want to achieve?

Sure. Some of this may exist already but I'm not sure what all is in the library. I'm working on collisions of aggregate tetrahedrons where I have to account for self gravity, friction, and electrostatic forces to hold the larger bodies together. Essentially think of something like asteroid collisions with each asteroid composed of a series of various-sized tetrahedrons. Working with the library appeals to me since your collision detection code is far better than mine and the ties into the visualization tools are very useful

[Erwin Coumans]

Ah, interesting.

Bullet allows to only use the collision detection, there is no dependency on the BulletDynamics, and its design is modular. However, it might be easier to start with this internalStepSimulation, and later decide to only use the collision detection.

Note that some values/parameters inside the Bullet SDK are tuned to work best with object sizes ranging 0.2 (20 centimeter) to 100 meter, if your units and gravity are meters. Especially extreme object size and/or mass rations can give problems/inaccuracies. So colliding an object of 0.20 meter against a 1 000 000 meter asteroid will likely cause issues. So if you don't get good results, you might want use other units (kilometer etc), so that the range sticks within 0.2 units and 100 (this is a rough estimate).

Thanks,
Erwin

[bittwiddler]

Thanks - I'll keep an eye on that. At the moment it's not a big deal as I can keep them within the same order of magnitude in size.

If you have a second I've got a couple other questions regarding the physics that I was going to check on:

Is angular momentum conserved in the collisions? I was going to keep an eye on both momentums anyway but it's useful to know any limitations up front

Are all collisions 100% elastic and is it possible to vary this on an object by object basis?

Off the top of your head do you know of any limitations on the speeds of the collisions and their detections? While I have a lot of variations I may need to have some things moving at around 5000 m/s

Thanks for all the help

[Erwin Coumans]

Thanks - I'll keep an eye on that. At the moment it's not a big deal as I can keep them within the same order of magnitude in size.

If you have a second I've got a couple other questions regarding the physics that I was going to check on:

Is angular momentum conserved in the collisions? I was going to keep an eye on both momentums anyway but it's useful to know any limitations up front

Most angular momentum is conserved, but there are several approximations, damping and even added momentum due to penetration depth correction. In short, it is an approximation that might be reasonable for games, but not for other applications. All of this can be improved however.

Are all collisions 100% elastic and is it possible to vary this on an object by object basis?

The restitution can be tweaked per object (rigidbody->setRestitution()), and you can also override the 'combiner' function that calculates the resulting restitution and friction values. See CustomMaterialCombinerCallback usage in Demos/ConcaveDemo/ConcavePhysicsDemo.cpp for an example.

You can also implement your own contact and friction solving function, but this is much more advanced/internal. See 'USER_DEFINED_FRICTION_MODEL' inside CcdPhysicsDemo.

Off the top of your head do you know of any limitations on the speeds of the collisions and their detections? While I have a lot of variations I may need to have some things moving at around 5000 m/s

By default, Bullet uses discrete collision detection, the physics mainloop using continuous collision detection is work in progress (btContinuousDynamicsWorld, derived from btDiscreteDynamicsWorld).

However, you can do a continuous collision detection query yourself, passing in the start and end transform for both objects. It will give the time of impact fraction, between 0 (starts in collision) and >= 1 (no collision during the interval) Some support of this is provided in btCollisionWorld (and hence also in the derived class btDiscreteDynamicsWorld). You can do pair-wise time of impact manually, see the demos ContinuousConvexCollision (assuming constant linear and angular motion from 'start' to 'end' transforms), or pure linear motion (GjkConvexCastDemo).

Hope this helps,
Erwin

[bittwiddler]

Yep, all that helps and gives me a bunch of things to experiment with. I'll work on it some this afternoon and see if I have any problems. At least in the first phases of my program the limitations shouldn't be a problem. Once I get more familiar with everything maybe I'll be able to offer some alternative slower but more accurate momentum and collision methods.

Thanks for all the help

[bittwiddler]

I used this as an example to start from and I'm progressing along. I do have a few questions about different things, though

Compound shapes are containers of other shapes used to combine them together into one large object. My understanding from what I have read is that the center of mass of the compound shape is the exact physical center and is not a function of the component density. Is that still correct? Is there a behavior where there are transitory compound shapes that exist so I can join the objects together and move them about but then they break apart when the constraints (self gravity, shear force) that join them are overcome?

What defines the colors of the shapes right now? I looked in the demos and the collision shapes but didn't see what was setting them. Eventually I may tie in with something like Ogre so this may be a moot issue

Is btTetraHedronShape a wire frame only? It would work great for one of my objects if it were solid but it seems to be drawn as just the wires

Finally, I've got a question about something I noticed in CcdPhysicsDemo when I was fiddling with it. In initPhysics I went in and changed line 338 so the shapes were btSphereShape(CUBE_HALF_EXTENTS) and not btCylinderShape. Leaving everything else as it was then they all collapse in a straight line on the Y (?) axis. If I then go in and change the define in initPhysics so I use a ground plane and not a big box to sit everything on then the balls collapse and spread out all over the ground as you would physically expect. Why does the box behave differently from the plane?

[Erwin Coumans]

My understanding from what I have read is that the center of mass of the compound shape is the exact physical center and is not a function of the component density.

The rigid body local transform equals the center of mass. This means you have to build the collision shapes to match the center of mass. For most basic shapes there is no additional work needed. Right now, calculating a more accurate inertia tensor, or shifting the collision shapes to match the center of mass is up to the user. So it is possible, but requires manual work. This might be automatic in the future.

What defines the colors of the shapes right now?

The rendering of collision shapes happens in Bullet/Demos/OpenGL. Color reflects activation state (sleeping, active etc).

Is btTetraHedronShape a wire frame only? It would work great for one of my objects if it were solid but it seems to be drawn as just the wires

It is solid, ignore the debug rendering.

Hope this helps,
Erwin

[bittwiddler]

The rigid body local transform equals the center of mass. This means you have to build the collision shapes to match the center of mass. For most basic shapes there is no additional work needed. Right now, calculating a more accurate inertia tensor, or shifting the collision shapes to match the center of mass is up to the user. So it is possible, but requires manual work.

So it is the center of mass and not the physical center of space that dictates how the collisions behave? I can work with that and tweak the inertial tensor if needed. I was mostly concerned that if I put heavy objects on one side of the physical center and light ones on the other that it wouldn't behave realistically. I hadn't finished my test to check that condition, though

Is there a reason I cannot break apart a compound shape into it's subsequent components to simulate a collision?

The rendering of collision shapes happens in Bullet/Demos/OpenGL. Color reflects activation state (sleeping, active etc).

I did seem to remember hearing that somewhere but couldn't find it written down anywhere

It is solid, ignore the debug rendering.

Ah, thanks. I thought the experiments I tried showed that it was solid but wanted to make sure

Thanks for the help

[bittwiddler]

Any thoughts on the last question about the difference between the plane and the box? I would have thought both should behave the same