Hm. I can’t find any docs on it.
I played around with it, but I can’t get it to work.
There has to be some other way.
Assuming that torque is set up in the bodies coordinate system, i. e. roll is (0, R, 0), then you can use:
torque = render.getRelativeVector(bodyNP, torque)
bodyNP.node().applyTorque(torque)Any panda bullet c++ doc in the pipe?
Thanks, it works great!
New problem, when I apply a forward force, I need it to move in the direction the node is rotated towards.
For that, you should be able to jsut copy and paste my code few replies up.
@ennox, why i need to reverse vector in x axis in my situation?
i am using render coordinate system, i assume bullet world has same?
Same solution as for torque:
force = Vec3(0, Fy, 0)
force = render.getRelativeVector(bodyNP, force)
bodyNP.node().applyForce(force)@GrizzLyCRO
Don’t have access to a machine with Panda3D right now. Will have a look at your problem the next days.
I tested your case now that I am back at home, and everything seems to be right. The default coordinate system is Z-up, which means x-axis points right, y-axis forward, and z-axis up. Setting a velocity (+vx,0,0) moves the body to the right, and this is what I get when modifying my 01_Basics sample.
Ok, thanks for checking, and sorry for wasting your time 
Not wasting any time - this module is still new, and bugs can be everywhere. So we have to check everything. I have to say thank you for testing so much.
I think I found the problem in your code now:
rel= self.ship.NP.getRelativeVector(render,force)and here is the documentation on the getRelativeVector method:
What you set up is a force or velocity vector in NP’s coordinate system, i. e. (0,1,0) is forward from NP, and (1,0,0) is right from NP.
What you need is a force or velocity in the global coordinate system, aka “render”. So you need to transform the vector the other way round:
rel= render.getRelativeVector(self.ship.NP,force)This way you should not have to apply -1 to the rel vector.
By the way: setting velocity on dynamic objects each frame is not recommended. Either use forces (or impulse), or make the object kinematic.
Thanks for explanation
What are reasons why setting velocity is not recommended?
Here is my situation.
Top down space shooter, control mode is more arcade like.
Player is always in center of screen, and you move towards mouse cursor (if moving only in front direction).
Move mode is that you either move or dont move, there is no acceleration.
Whenever you move mouse, ship instantly rotates so that mouse is in its front (.lookAt()).
I want ships to be able to “push” around each other, so i can’t .setKinematic(1) on them.
I will use force/impulse for “bullets”.
Because velocity (like position too) is a property which is owned by the physics engine. A physics engine collets forces, and applys them to bodies in order to determine their new state (position, velocity, …). It is ok to now-and-then set position or velocity by hand. But from then on you should let the engine determine the way the object moves around.
Setting position or velocity every frame is possible, but it makes much of the work done by the physics engine useless. And you won’t get determinism.
Just look at the example of a box falling down because of gravity. Each frame the engine will accelerate the box a little bit in down direction. Thus the down velocity will slowly grow. This is what we all know from a falling object.
Now we set the velocity of the box to (0,0,0) each frame. The engine will still apply gravity each step, and so after the step the box will have a small down velocity. And the engine will move it downwards a little bit. The box now moves downwards too, but not the realistic way. It will move down with a small but halfway constant velocity. Even worse, it the down velocity will be dependent on the timestep duration.
Many of the things a physics engine tries to compute as realisitc as possible will be affected (e. g. the way such an object is pushed around or bounces off an obstacle).
I don’t want to say that it is not possible to set velocity each frame, or that it makes no sense now and then, but you should expect weired effects if you do so.
Hi EnnOx,
After a few months of unactivity I’ve digged again into the reported issue of “bullet nodes lagging behind” as I previously reported in summertime.
I found out that the issue is related to using panda threadings through task_chains. (the phenomenon stops if all the tasks are serial)
have a look at: [Questions on proper use of panda task-chain threading)
So the good news is that the cause of the symptom is identified, the bad news is that for a very realistic app including a lot of processing, one can’t afford having all the tasks (video, game logic, network exchanges, physical simulation, …) running one after the other. Especially if one is using a new generation multicore CPU…
I’m just curious of getting your views of the subject!
Regards
jean-claude
Good work, and seems reasonable since I never have seen any lag myself. “Normal” Panda3D users, that is single threaded python, won’t have this problem, right?
I disagree. The effects might be narrowed down to a specific configuration, but I don’t see the cause yet. More digging is required. See below.
Ok. Here are my views:
1.) I assume that node transforms are the only data affected. Or is adding/removing nodes or changes in node state (i. e. render state ↔ debug geometry appears/disappears) affected too?
2.) The Panda3D Bullet module does not care about threading. That is, there is not a single line in this module handling locking etc. Threading has never been a design concern here. I’m not surprised that multithreading makes trouble. I agree that good multithreading support would be nice to have (given that modern computers all have several cores).
3.) However, the Bullet module does not directly mess around with PandaNode data; it uses the public methods to get/set transforms. These methods should be safe to use from different threads (assuming all physics stuff runs in one thread, and other thing like rendering or AI run in other thread; not talking about splitting up physics over different threads).
4.) If I remember right your scene setup is already quite complex. You have Panda3D actors (animated), Bullet rigid body nodes linked to different bones, and other stuff too. I think it is necessary to reduce complexity to further narrow down the effects, and eventually find the cause. A single primitive would be good, controlled not by an actor but by code.
5.) The Bullet debug renderer can’t lag behind. No panic, I’m not saying that you are wrong. It’s just wording, but wrong wording is missleading. The debug renderer shows the current state of the physics scene. The whole scene is displayed in one go, no single nodes. What might “lag” is that scene graph changes are not applied in time to the physics scene, or that the geometry created by BulletDebugNode is not renderer in time by Panda3D.
What you need to do next is to describe your situation precisely. So far I assume you have the following situation:
a.) There is an actor with a bone. A Bullet rigid body (kinematic) is linked to the bone (how? who is parent/child?)
b.) The bone is moved by the animation.
c.) The bone transform is pushed to the Bullet body.
d.) The debug renderer is updated, and shows the new position of the body.
e.) There is no lag in direction Bullet->Panda, i. e. debug rendering of collision shapes moving “earlier” than the Panda3D nodes.
I think the last point is not given. We probably just didn’t discover situations where this happens.
Next, you need to find out precisely where the lag happens. My assumption is that the bone transform is changed, but it takes a few frames until this change is propagated to Bullet, which happens inside Bulletworld.do_physics, more precsely the sync_p2b methods executed before the timestep is executed.
I don’t want to promise that we can add threading support to the Bullet module. At least not easily. The module was designed to allow Python users to have basic Bullet functionality. For C++ users it might be better to directly use the Bullet library, and handle synchronisation themself. If performance is a main concern you will get better results this way.
For the record, Panda 1.8 enables true threading by default.
Hi ennOx
thanks for your answer, I’ll try to dig a bit more on the subject asap.
It’s indeed difficult to trim down the problem since the issue seems related to the duration of cyclic threads execution.
Anyway as of yesterday night, my best explanation is the following:
Consider 3 task_chains to be ran in thread mode:
> task_chain_1 (t1) (master task_chain) takes care of regular stuff +
is in charge of getting actor animation. So t1 is the task that activates
the kinematic nodes (in this case the hands and feet of the actor)
> task_chain_2 (t2) encompasses all audio/video processing
> task_chain_3 (t3) manages bullet_sim (doPhysics) and Ctraverser collision (pusher...)Now what happens is that t1 appears to be running roughly every 0.01s, t3 roughly every 0.2s (as per my reported
spy result of [Questions on proper use of panda task-chain threading) )
When activated t3 will then exercise mgr->do_physics with the appropriate dt (ie roughly 0.2s) to advance bullet sim.
So this seems to explain that the catch up of t3 with t1 (which drives the display) only happens
every 20 frames… hence the perceived lag (ie debug geometries running behind for a while
and then getting synchronized in a cyclic way).
(In order to work properly the sync should have happen at frame level dictated by t1)
Jean-claude, is your problem that your renderer is running 50% slower than your physics sim and thus ~every other rendered step is perceived as freezing?
Time---->
Render1->Render2->Render3->Render4->
Physics Step1–>Physics Step2–>
So render2 and render3 all display information from physics step1 and all of a sudden render4 jerks into physics step3?
Zhao
Hi Zhao,
Actually the simulation shows a rendering frequency faster than the physical sim frequency, hence a gradual lag of bullet debug nodes geometries display during r2 -> rn-1, and then a resync @rn and so on…
r1 r2 r3 r4 … rn-1 rn // task_chain_1 (including frame rendering)
p1 … p2 // task_chain_3 (bullet, …)
In other words, bullet physics world is ‘sync’ing’ with other panda app evolutions only at meeting points p1, p2, p3,…
Yes, your example is the same as mine, except while I only had 1.8r’s per physics step, you have many more r’s per physics step
I had a similiar situation with a toy model once. In my case, I advanced the physics two steps ahead of the renderer. And linearlly interpolated the position transforms during each render step as needed. It’s also a bit easier if you fix the physics dt.
e.g.,
r', x = (t - t0)/(t1-t0)*(x1-x0) + x0
p0, x=x0, t=t0 p1 x=x1, t= t1
Perhaps, the bullet bindings or bullet itself is not doing this interpolation for you and you’ll have to update the transforms by hand.