Do_physics performance issues

C++ coding using Panda3D
1

Hi all,
This seems to have been spoken of here:

But it still seems to be an issue for me, whenever I use the do_physics method from the python side, there’s a considerable drop in frame rate. I’m using the Panda3D version 1.10.15
Here is what I do on the C++ side:

PUBLISHED:   
void start_physics() {
bullet_task = new GenericAsyncTask("cpp_bullet_task", &do_world_physics, physics_world);
    AsyncTaskManager::get_global_ptr()->add(bullet_task );
   }
private:
      static AsyncTask::DoneStatus do_world_physics(GenericAsyncTask *task, void *data) {
        BulletWorld *bw= (BulletWorld *)data;
        ClockObject *co = ClockObject::get_global_clock();
        bw->do_physics(co->get_dt(), 10, 1.0 / 180.0);
        return AsyncTask::DS_cont;
      }
private:
    PT(GenericAsyncTask) bullet_task ;

Or just:

    BLOCKING void do_phys_stuff()
    {
        ClockObject *co = ClockObject::get_global_clock();
        physics_world->do_physics(co->get_dt(), 10, 1.0 / 180.0);
    }

And on the python side:

cpp_object.start_physics()

Or:

taskMgr.add(self.updatePhysiWrldTst, 'updatePhysiWrldTstNom')
...
def updatePhysiWrldTst(self,task):
    cpp_object.do_phys_stuff()
    return task.cont

I could just simulate things from the python side, but if the c++ side is considerably faster, then it would be great if this seemingly persistent issue is resolved. Am I doing something wrong?

Thanks in advance.

2

I can think of no reason why the C++ call would be faster than the Python call, other than confounding factors such as multithreading use. Where does PStats show the performance goes?

3

Sorry for the late response. Well most of the issue arises with “app”, according to pstats, whenever I use the c++ module I wrote:

pstats1
pstats1545×212 5.02 KB

and

pstats2
pstats2519×177 3.77 KB

But perhaps as you say, the Python call would be enough for my particular uses.

4

You need to double-click App to expand out what part of App is taking up time.

5

Alright, here, as deep as Pstats can take me:

pstatsA
pstatsA550×184 4.64 KB

pstatsB
pstatsB559×240 5.28 KB

pstatsC
pstatsC552×225 5.9 KB

pstatsD
pstatsD546×174 4.19 KB

6

Based on that, it looks to me like the problem is likely less the Python call and more just whatever physics is being simulated.

Looking at your code, do you really need sub-steps of so fine a resolution? Right now your sub-step-size is set to be just 180th of a second each. i.e. Aiming to run at 180 physics updates per second.

So if your game is running at 60fps, you’ll get three physics steps each frame, if I’m not much mistaken.

Otherwise, what does your physics world look like? Do you have lots of objects, or complex physical relationships? (e.g. Lots of stacking, or lots of joints between physics objects, or a bunch of soft-bodies, etc.?)

1 Like
7

I’m basically doing some simple tests to familiarize myself with bullet’s c++ implementation in Panda3D, so the world is very simple, just a cube falling down towards a triangle-mesh. What you recommended however seems to fix the issue, changing this:

physics_world->do_physics(co->get_dt(), 10, 1.0 / 180.0);

To this:

physics_world->do_physics(co->get_dt());

greatly increased the frame-rate. I however was following the manual’s example when I included it in my code. Thank you!

1 Like
8

I thought that might have been the case.

Hmm… Interestingly, this seems to reveal a discrepancy in the C++ and Python examples within the manual: The Python version first shows “do_physics” being used with only the delta-time, and then goes on to mention the use of a time-step. However, the C++ version–despite appearing to have the same text around it–only shows “do_physics” being used with a time-step.

My pleasure! :slight_smile:

1 Like