PStats >> opaque time? FPS Performance issues!


For a couple of week, my FPS rate is really showing a crappy 7 to 9 FPS…

I tried to optimize my code in C++, but clearly the issue is not with the code performance itself, and it’s certainly due to the way I use (misuse) Panda resources.

To try and clarify things I switched off any collisions.

[b]Using Pstats shows a frame time in the range of 70ms

With roughly:

App/render_frame 8ms
Draw of 38ms
cull of 20ms[/b]

Digging into Draw: draw:window1:dr_0:opaque time of 16ms (apparently times x 2 buffers)

then somewhere else Munge 8ms (munge?? :open_mouth:)

Bottom line: I don’t have a clue on what most of these values refer to, and the correct way to trace and improve performances.

Would someone be kind enough to provide some guidance?

Many thanks.

Additional infos:

2900 nodes/geomnodes
1646 geoms
463k vertices
457 tranformStates
556 renderStates
1059 primitives batches
16 Mb graphic memory
0 occlusion test
0.30Mb data transferred

1646 geoms is way too much. Try using flattening to reduce this number.

Hi rdb,
Thanks, will try to flattenStrong all this stuff.

Actually a few weeks ago I had them flattened, but then I read a recommendation that to use the same eggfile for collisions flattening was not at all recommended… hence I removed this and started a long journey to octreefy…
So it seems that one can’t get both candies at the same time!

Another point is that some of these geometries belong to animated actors, that I monitor through exposed_joints can I safely flatten them ??

BTW. What’s this opaque time means


Optimization is a balance between too many Geoms (there’s a fixed cost for each Geom) or too few (which could result in too many offscreen vertices being sent to the GPU unnecessarily). The ideal balance point depends on your graphics hardware, but it’s usually in favor of fewer Geoms rather than more. As a rule of thumb, you should aim for 300-600 Geoms in your frame at any given time.

Collisions are completely different. For collisions the balance point is usually much, much lower in favor of many individual pieces. This is one reason the CollisionNode is a different system than the GeomNode.

Animated actors, and animation in general, causes problems for flattening. You can work around these to a certain extent. You can even flatten together multiple Actors into a single Actor, and still control their animations independently. But once you flatten together two nodes, you can no longer set their transforms (i.e. pos or hpr) differently, and you can no longer set their state (texture, color, hide/show) differently.

Exposed joints are not really a problem for flattening.

“opaque time” is just the time to render all of the geometry in your opaque bin, which is to say, your normal, non-transparent geometry.


Thanks David for your clear explanation!

BTW. I meant control_nodes (and obviously not exposed_nodes) to monitor programmatically my actors’joints and this is why I don’t feel confident to flatten the actors.

Control nodes are also not a problem for flattening. However, note than an individual Actor is, by default, already flattened into a single node, so there’s not much to be gained by further flattening, unless you are combining multiple Actors together.