Performance Issues (strange Pstats results)

Scripting Issues
1

I am digging the performance issues we hav and I found very strange results.

Basically, we are rendering a city with over 10k objects.
The FPS is as we expected poor when we look at the city as a whole.

But looking down and therefore seeing only 10 or 20 objects, doens’t really improve the FPS and that is strange.

The last screenshot is “looking down” and its results are very strange.
I have a hunch that the “cached transform states” is not very good but I don’t know what the number should be.

Any idea ?

2

  1. Eek! You have quite some transforms/state changes. Try calling flattenLight() on your scene to apply all the transforms, that would speed up your game a bit. Or, just re-export your models from your modeling program in the right dimensions and don’t scale or rotate them in-game.

  2. Hmm. That might help, but probably not enough.
    You have 2757 geoms. Thats quite a number of batches to send to the GPU. I believe (but I’m not sure) culling is done on the GPU, so zooming in wouldn’t really help limit that batching bottleneck.
    Try reducing your geom count to, say, 300. It is said that above 350 geoms your FPS will drastically reduce.
    Panda3D has special functions for that. yourNodePath.flattenStrong() (a heavier form of flattenLight) will reduce that node and its children to just one node. Try flattening parts of your city or even your entire city, and see if that makes a difference.

  3. There’s a leak in your code. (“Show code” takes about 100 ms, which is quite much) You can enable PStats to track your tasks so you can see more easily where that leak is. See this page for more info on that:
    www.panda3d.org/manual/index.php/Measu … ith_PStats

3

Thanks, I’ve turn on the task Profiling.

But The task profile is very strange…the “General” task takes 100ms…the rest are negligible …
See Below :

What is this General Task ?

4

Wow, you have quite some tasks.
I have no clue what “General” is. Maybe someone else can give clarifications on that?

Besides that, did my other suggestion(s) work?

5

I think the “General” was created by you. And you are doing lots of computation in that time frame. Too much. You either need to rewrite your algorithm, do it less often, or resort to C++ (which is not that hard.)

6

@treeform : it is a bit strange, the task is not present anymore in svn. I suppose someone from the team have seen my post and discretely removed it.

@pro-soft : thanks for the tip but I cannot use it as is. the building in the city are constantly destroyed/created. So, if I flatten I need to have a way to rebuild the hierarchy, and keep the ability to destroy only what needs to be destroyed.

7

in this case you can simply keep a copy of your city. use a working-copy where you build/destroy. and a render-copy which gets updated everytime you destroyed or build something and then flattened again.
geomipterrain’s autoflatten works simmilar.

8

could you elaborate a bit ? i am not sure I completely understood what you said.

A copy of the whole scene graph is hidden, and when a building is added, this copy become the real scene graph which is flattened, is that it ?

9

you basically have the following:

  1. your city like you have it right now, each building a seperate node.
  2. some code which creates a copy of this city , or parts of if and flattens those copies.

only the flattened nodes of number 2 will be rendered. number 1 is not rendered at all.

this way you can send fewer,larger chunks of data to your graficcard which can improve preformance a lot. and still beeing able to manipulate each and every single building.

oh and don’t worry about updating your “copy 2”. flatten really is a fast operation :slight_smile:
for a city you could flatten several blocks of houses together. or maybe even larger regions, depending on your game. just experiment a little. you should aim for less than 300 geoms/geomnodes on-screen. overall-count doesn’t really matter that much.

10

i have a suggestion which i dont know if it works for your application.

you seperate the graphics changes from the gamestate changes (save that a change happened, but dont show it). You only update the parts of the graphics changes that are in or close to the camera’s lens frustum. And/Or if every building is changed every frame, only update it every 2nd frame etc (aka split the scene into 60 chunks, update 1chunk per frame).

And another hint: look at sim city, i would not suspect that every building is updated every frame. This also can cause problems, think of a building having 2 states (like poor/well going) and due to some factors these inputs create a change every frame. If you update the graphics every frame you would have flickering objects, while if you update only every second (or even less) it would look normal.