So bullet has a upper speed limit

[Granyte]

I just found out bullet object stall if their linear velocity reach 60000000.0
After they they act just like kinematic and won't ever come back they are like frozen for ever they won't rotate move or anything

any one know why or how to avoid this?

[Basroil]

I just found out bullet object stall if their linear velocity reach 60000000.0
After they they act just like kinematic and won't ever come back they are like frozen for ever they won't rotate move or anything

any one know why or how to avoid this?

Well, one option is to increase your linear damping, another to use double precision (won't get rid of a speed cap, but will increase it quite a bit). Assuming you're using meters or close in your calculations though... it's not a good idea to model relativistic speeds in a simplified engine like bullet

[Granyte]

i'm already using double precision it was already imposed by the constrain of the project

http://granyte.blogspot.ca/

increase the linear damping what does it does how does it work I never played with that parameter?


also ya I expected some quirk like tunneling at those speed but they are not a issue when something is going that fast for what I need it to do
how ever I never expected the rigid body to start acting like a kinematic object

[drleviathan]

Here's an idea: scale your content such that its units are in kilometers instead of meters. In this scenario a speed of 1m/sec becomes 0.001 and an acceleration of 1g becomes 0.0098 m/sec^2.

[Granyte]

tried it in this scenario since we cannot push double precision to the gpu
the renderer cannot give decent result with objects this small

beside the object turn into a kinematic at exacly 60000000.0 of linear velocity almost as if it was a specifically chosen value

[Basroil]

tried it in this scenario since we cannot push double precision to the gpu
the renderer cannot give decent result with objects this small

Just scale the transform before sending to your rendering engine You only mentioned velocities went to crap, so we can assume that positions are just fine, and then all you have to do is scale your position by some number.

[Granyte]

that would require scaling meshes, impacts points when transfering back and forth also i think at this point how well would bullet react with part that have gimpatc meshes of size 0.006 that have like 20 constrain attached would not precision become an issue?

[Basroil]

that would require scaling meshes, impacts points when transfering back and forth also i think at this point how well would bullet react with part that have gimpatc meshes of size 0.006 that have like 20 constrain attached would not precision become an issue?

Like I hinted at before, you need something more dedicated to what you want than a generalized physics engine like bullet. When dealing with planets and stars, there are already existing frameworks that leverage simplified models with far more accurate integration methods (and more robust to boot). For example,the chance that two stars straight out collide and destroy each other is infinitesimally small, and everything can be modeled as a more or less a point rather than a sphere. That opens up the realm of "easy" gpu calculations, and it'll be many times faster than bullet to boot.

If you have mixed physics (galaxy+ lone ship), you should be using partitioned physics, since even a deathstar sized ship isn't going to alter the motions of a star in any render-able way

[Granyte]

The galaxy is in it's own realm and each solar system is a separated world

planets and stuff are kinematic handled manually by my self

I use bullet only to simulate collisions and motions for ships and other game play related object and when traveling inside a single solar system I still need some rather insane speeds to make traveling between world take less then an hour I guess my last solution would be to remove the body form the world and translate it manualy but then I would have to make my own collision detection against worlds other really large object that can actually pull players out of warp

[Erwin Coumans]

Could it be you are hitting this heuristic check in void btCollisionWorld::updateSingleAabb(btCollisionObject* colObj)?

Code: Select all

	//moving objects should be moderately sized, probably something wrong if not
	if ( colObj->isStaticObject() || ((maxAabb-minAabb).length2() < btScalar(1e12)))
	{
		bp->setAabb(colObj->getBroadphaseHandle(),minAabb,maxAabb, m_dispatcher1);
	} else
	{

just replace the test with if(true) and see if that helps. Bullet hasn't been tested with very high velocity and scale, so you might still run into other issues.
Thanks,
Erwin

[Granyte]

Could it be you are hitting this heuristic check in void btCollisionWorld::updateSingleAabb(btCollisionObject* colObj)?

Code: Select all

	//moving objects should be moderately sized, probably something wrong if not
	if ( colObj->isStaticObject() || ((maxAabb-minAabb).length2() < btScalar(1e12)))
	{
		bp->setAabb(colObj->getBroadphaseHandle(),minAabb,maxAabb, m_dispatcher1);
	} else
	{

just replace the test with if(true) and see if that helps. Bullet hasn't been tested with very high velocity and scale, so you might still run into other issues.
Thanks,
Erwin

thanks that was indeed my issue I just broke 65000000 bullet units per seconds