Real-Time Physics Simulation Forum

Oh hey, you're right! And btDiscreteDynamicsWorld::saveKinematicState() is called once per step rather than per substep. This means idea (1) would NOT solve your original problem, and also reintroduces the original mystery: Why would the first constraint relax so much? I understand you tried differe...

So, shouldn't that swapped order be the default implementation actually ? Yes, I would think so, since it would fix the problem you were seeing while introducing minimal undesired behavior changes. However, I doubt Erwin would accept such a change if a PR was created. There is already a large backl...

...what are the consequences of adding/moving that btDiscreteDynamicsWorld::synchronizeKinematicMotionsStates() call prior to stepping the simulation... ? It isn't that we would be calling btDiscreteDynamicsWorld::synchronizeKinematicMotionsStates() before stepping the simulation. Rather, we would ...

The following code makes verts a copy of the data: auto verts = element->vertices(); and is equivalent to: std::vector<Vertex> verts = elements->vertices(); Note, the vertices() method is declared const (it does not modify the class instance's data members) which is why it returns a const reference ...

I made a quick audit of the logic that provides that feature --> by inspection it looked like it should work. I also checked the recent commit logs and didn't see any recent changes that would have affected that.

The problem is: for each substep constraints are solved prior to moving kinematic objects. If you examine the implementation of btDiscreteDynamicsWorld::stepSimulation() you'll see for each substep: btDiscreteDynamicsWorld::internalSingleStepSimulation() is called before btDiscreteDhnaicsWorld::sync...

I believe the general treatment for drag approximations is more of an infinite series: drag_force = c0 * speed^0 + c1 * speed^1 + c2 * speed^2 + ... and the empirical exercise is to measure what are the proper values for the various coefficients: c0 , c1 , c2 , ... Your calculation of drag has c0 an...

You're using the AABB of the Box for the buoyancy intersection. The AABB of a Box is much larger than the Box itself. It is the bounding box around sphere that contains the Box no matter its orientation. In other words... when the Box tumbles arbitrarily it will always be inside its bounding sphere....

Also curious is: the distance traveled along the x-axis does not agree with your speed and timestep: time = 0.05 sec rate = 250 m/sec distance = rate * time = 250 m/sec * 0.05 sec = 12.5m I wonder if you're bumping up against a maximum speed limit, especially since your total speed is so steady. May...

Alas, physics simulations require approximation and abstraction in order to run in real-time on real-life hardware. The discrepancy between how you think it should work, and how it actually works, is a manifestation of that truth. The fact of the matter is: it is possible to get the effect you want,...

Sorry about that. I updated the link to what I hope is a publicly shared google photo. Yes, I guess I misunderstood your problem. I still might not understand it but I'll take another swing (let me know if this is in the right direction). If the vehicle is being steered directly... and you're trying...

Yes, I believe I made an error in my derivation. Let me try again from scratch... I tried again on paper and took a photo . Fig1 shows the leaning motorcycle. Fig2 shows the balance of forces which apply torque on the center of mass with focal point where the tire touches the road. Fig3 shows the ve...

I have fixed a few bugs in your code, and added a bunch of comments: btRigidBody *car = common.brickCars[a]->body; btTransform worldTransform = car->getWorldTransform(); worldTransform.setOrigin(btVector3(0,0,0)); btVector3 up = btVector3(0,1,0); // When we set 'normal' to be 'up' we are assuming th...

Yes, the center of mass (COM) defines the local-frame origin which means: in order to shift the COM relative to the geometry you must shift the geometry instead. For this reason: btRigidBody::setCenterOfMassTransform() can only be understood to mean "set the COM transform in the world-frame&quo...

Yeah you don't want to use btRigidBody::setCenterOfMassTransform() . That sets the world_transform of the object's center of mass and doesn't change the center of mass in the object's local-frame. The center of mass in the object's local-frame is, by definition, the origin of the shape geometry. Con...