Low speed/performance, FPS below 20

Hi.
I’m having some performance issues on my game, with frame rate dropping below 20 fps.
I’ve been searching around trying to find some tips that could fix the problem, but I’m still not sure about what is slowing down my game.

The game has about 36k polygons, which I don’t know if it’s a little or a lot. There’s quite a bunch of textures, all PNG format (I guess format only affects loading time), some of them are quite big, maybe 1024x1024. Again, I don’t know if that’s huge or small. The whole pack is 60MB. I’m running it on Ubuntu, using an NVidia 9500GT with 512MB. I’m using hardly any physics, and the logic is not too tough.

How do I interpret the debug output? I see the rasterizer is at 55%, what does that mean?

Some things I tried:

  • Put several textures together in one big texture
  • Lowering frequency for some “always” logic bricks
  • Render static shadows, and reduce the number of lights to 2
  • Use the “generate display lists” option, but it mostly breaks the game, and I see no improvement.
  • Disable the layer that has the lights. No improvement at all.

Any ideas?

Attachments



use invisible collision meshes.

try to optimize the logic system, maybe some python.

last resort solution - run the game in a lower resolution, in a window that is.

Hello
disable/optimize GLSL shadows, maybe?!
Bye

post the .blend?

It means that your computer is putting a lot of effort into displaying the graphics. Other than things you’ve already mentioned as possible sources, you could try creating some occluder planes (possibly inside walls).

To utilize this, it iis my understanding you should make sure your enviornment is broken up into lots of different pieces. For example, if you have a row of houses which is hidden behind a wall. If the row is a single object, I believe the entire row must be hidden for it to dissapear (increasing performance). But if each house is a different object, it can be “removed” independently, allowing you speedup if every house but one is hidden (vs no speedup in the other scenario).

Somebody who has experimented with this feature more should check me.

Hi. Thanks for your replies!

@Teo: I’ll check the physics, though there’s little to check there. Will an improvement in the logic give me higher fps? I’m not really sure about that, since I think it’s the GPU what’s saturated. Windowed mode is not an option for me, I have to do fullscreen :frowning:

@OTO: I tried that already, disabling GLSL, and… well, the game didn’t look that bad, but all my transparencies where gone!

@lipsonfire: Sorry, can’t share the file, my boss would kill me. And it’s also quite big.

@J09: That sounds good. But I thought openGL was in charge of that, at polygon level: polygons hidden behind other polygons are not drawn. Are you sure Blender hides “objects”? There’s not much stuff I can break, but I’ll give it a try.

I think just because you can’t see them, they’re not drawn (however, I’m sure theres a technical definition of “drawn”).

Anyways, I’ve prepared an example .blend file to demonstrate how occluding meshes can be used to increase the framerate in high poly scenes.

I’ve included notes in the blend files, but it verifies what I said earlier about the entire object having to be hidden.

Attachments

occluder_testing.blend (641 KB)

@mrzeon: That’s a nice looking environment you have there. :slight_smile:

As said above, the rasterizer is what’s outputting the image to the screen.

Your scene specification should run ok, not sure what the problem is. You could try some of these things…

Some causes of high rasterizer usage:

Extensive shader usage

High poly count

High object count

Possible optimizations:

Are those shadows being calculated reltime using spot lights? Realtime shadows are very intensive and should be used sparingly. If a light source never moves then you can bake it’s shadows to a texture and apply the texture. This saves a lot of processing.

The cactus and sign in the left image in your post look very good, but appear to be very smooth. How many polys (triangle) are in your scene? If you aren’t already then you should try to minimise the number of polys. One option is to retopo your complex objects to a basic shape and then bake normals from the more complex shape to simulate smoothing/detail. Baking ambient occlusion will simulate self shadowing.

Blender has effective view frustrum culling to cull faces out of view, but even objects/faces that are occluded behind other geometry in the view are handled by the rasterizer. ie. They are behind other objects but are still rendered, then rendered over by foreground objects. Occlusion culling using invisible simple occlusion meshes hidden inside other meshes will tell the rasterizer not to render any object that is behind them.

Possibly not rasterizer related, but the flag that you have could be affecting performance if it’s a soft body. If it’s not going to be affected by dynamic objects brushing past it then you can simulate movement by using shape keys.

As far as I can understand it, “Generate display lists” is used to speed up rendering of many instances of the same object. If most of the objects in your scene are unique then this will probably have little effect.

This is a far from exhaustive list of optimizations, but might shed a little light on the possibilities available to you.

Good luck. :slight_smile:

Edit:

I might be wrong about this, but from my tests, I believe it to be at least partially true.

To clarify about the high object count… this used to be a real problem in BGE, but is much reduced by recent optimizations of the scene graph. Many objects will slow down your game/walkthrough, but if you have large high-poly objects that are rarely in complete view then you should experience an increase in frame rate by breaking them up. This enables the view frustrum culling to cull the sections of the large object that are outside the view. If the large object is completely in view then face culling will avoid rendering of the faces that are out of view, but view frustrum culling works better on whole objects. If the large object is broken up then view frustrum culling should be more efficient.

Edit 2:

Thinking a little more, I’d say that 55% rasterizer usage was pretty low for a game with hardly any logic/physics. What is your physics/logic usage? You should certainly turn off collision for everything that the player won’t come into contact with. eg. Those posts, tables, chairs and the cactus outside should have collision boxes so the complex meshes aren’t being used. The sign, tops of arches, upper floor of the building, wall ornaments, behind the bar, etc. will never be hit.

@J09: Thank you, great test! It was fun to play with. My first reaction was to ask why when you cover all of them it still doesn’t go over 30 fps. Then I changed the 1-4 positions of the occluding plane to left-right motion, so I could have better control, and saw two things:

  • Partially covering a monkey doesn’t make it disappear, and fps doesn’t change. So polygons are not hidden, though objects are.
  • The reason why it didn’t go over 30 fps was because position 4 didn’t cover all three monkeys completely (I think you have to cover the whole bounding box). A little more to the right, and you get 60 fps.

@FunkyWyrm
Thanks for your help! Some things you’re asking me are already in my first post. Shadows are baked, the poly count is 36k, which I don’t know if it’s ok or a lot. No soft bodies.
Occlusion culling, what tha… ok, found my way. That’s sounds good! Specially to hide stuff inside the house when being outside.
There are some high poly count models around because I need them. The camera will be at fixed positions, and these objects need to look nice. I’ll try to optimize them though :slight_smile:

Edit:
The player is not able to move around, so physics are only applied at a very specific part of the game. The physics engine is doing about 15%.
I already lowered the poly count from 36k to 30k, but I see no difference :frowning:

You’re welcome.

Correct.

Correct again! I’m not sure why I didn’t think of that, but it makes a lot of sense, and worked when I tried it. Good catch!

@mrzeon, if you upload the example I can run it through some profiler and see how much CPU time it spends on each line of code, in some cases this points directly to the cause, other times its spread over a large area and not much can be done to optimize.

Sorry, as I said before, I can’t share the file :frowning: I really appreciate your help. Is there any way I can do that test by myself?

36k on a 9500 GT is a lot.

Have you taken full advantage of the BGE’s new occlusion culling at all, well placed occluders can prevent rendering of many objects behind walls and can really speed up the game.

@JohnnyThunder
Yup, that’s what I thought. I lowered the poly count down to 19k, and I still see no improvement, which doesn’t make any sense. I’m still getting <20 fps most of the time. Object count is 471, and again, I don’t know if that’s a lot. Maybe my textures are too big?

@Cyborg Dragon
I’m gonna try that now, see if I can make good use of occluders.

Thanks for your help, guys.

Hi again, guys.

I discovered that my dunes outside the building were pulling the framerate down about 10 fps!!
There must be something I’m missing here. Removing those 90 polygons was more effective than the other 18.000 I removed from the rest of the scene. Ok, they were 90 big polygons, but still it doesn’t make any sense!
I thought maybe the textures for the ground where too big, so I disabled them. But that didn’t do anything. White dunes are also bad. I noticed they were one big object surrounding the building, so I split them into smaller objects hoping that they could be hidden more often, but that didn’t work either.

Now I’m back at 30 fps, which is acceptable. It’s not that I care much about the dunes, but I would like to know why this could be happenning…

People often focus too much on poly count,
Other things to be aware of…

  • Alpha materials even if you cant see alpha with them (ztransp/alpha/texface alpha)
  • Face sorting enabled - big speed hit, only use when you have to.
  • Fill rate - shading many pixels can be slow even its low poly
  • Context switching, multiple materials/images/settings can slow down rendering too.

mrzeon, ideasman42 ( Campbell Barton ) is one the main Blender GE coders ( and has worked on the Blender OpenSource teams for BBB and Yo Frankie, as well as going to work on the Durian team ).

The community have also recently trusted him with $$$ to develop run-time dynamic loading, where he has really done an amazing job.

If you pm him, and he says that he’ll keep your .blend safe ( for his eyes only ) in order to optimise, I’d believe him :slight_smile: As a return, you’ll get advice on how to optimise your game, and if it requires changes to the GE, the community will benefit as a whole.

Mal