Real-Time Physics Simulation Forum

I think you could do the same as you do with linear velocity. Calculate the rotation needed from the current rotation to the target rotation, and apply the angular forces needed to get it there in a single timestep. Not sure how to do that exactly, but it doesn't seem very bullet specific. I guess.....

I've only seem post about how you shouldn't update rigidbodies manually. I'm sure there is a way, but you probably also have to look into collision cache etc. At least bullet doesn't seem to be designed to update rigidBodies manually. But it would be nice if someone could explain what steps you need...

Another way is to use the internal tick callback, and update the position in there. That way bullet can still do variable timesteps, but the update for your object is still called exactly each 1/60 timestep or whatever your internal timestep is set to.

Maybe you should check 359 for(int j=startJ; j<endJ; j++) 360 { 361 for(int x=startX; x<endX; x++) in the cpp source file to see the values of startJ, endJ, startX and endX. If your character is smaller than 1 tile, then it should be: endJ=startJ+1 endX=startX+1 or else it will be processing more ti...

yes it does unfortunately I don't know the answer to your original question, sorry

I probably misunderstand, but you say "The reason is that I would like now to run my simulation at a higher frequency than the bullet world update step size." Why not just decrease the step size in bullet? It's the third parameter in stepSimulation (fixedTimeStep).

indeed.

I was kinda surprised that it wasn't a 4x4 matrix cause that would be 'easier' to apply, but probably the dot product + translation method is faster when compiled. I wouldn't dare to question speed related choices in bullet, they are probably well thought out
Anyway good luck with it!

btVector3 btTransform::operator* ( const btVector3 & x ) const inline Return the transform of the vector. Definition at line 100 of file btTransform.h. try rigidBody->getWorldTransform() * vector then... But indeed it's not a 4x4 matrix internally as I thought, but it stores a 3x3 matrix for rot...

I thought you would only move the big red cube, and the blue one just rests on that? Why make the small cube kinematic then? In that case I would say: make the red cube kinematic (or extreme large mass), and set the velocity manually. Then the small cube should be a normal rigidbody that rests on it...

can you set velocity on a kinematic object?

pointPositionWorld = pointPositionLocal * rigidBody->getWorldTransform(); this is the correct code. The transform is a matrix that is setup to rotate, scale and position vectors in a certain way. The results of a 'vector * matrix' is a vector that has been transformed by that matrix. So that is exa...

I don't think the blue cube will move along if you make the big cube a kinematic object and just update the position. (I assume with 'The small blue cube shouldn't move, thanks to friction.' you mean that it should be dragged along with the bug cube because it rests on it?) Not sure what the best wa...

The transform also holds rotation. Could even contain scaling (it's a full 4x4 matrix I think). So if you apply it to local points your get the world coordinates of those points.

I don't think there is an easy way to find the contacts with a body, besides looping trough the pair collision cache.
Maybe there is another way of solving your problem too, but going to the pair collision cache should work I think.

Well I never used the Character controller, but what I can see from the code is that in the function playerStep, it seems to already use the elapsed time to calculate movement. So my guess would be that setWalkDirection should be called with something independent of the elapsed time in that frame. B...