Generic question Irrlicht OGL performance

[eagletree]

I've been developing the mechanics of our game for a long time now. In the last few months, as I've added vehicle, AI and character mechanics (code and classes), the performance has gotten worse and worse. Most of the time on the two slower machines I test with, it's unusable. I assumed I had inefficiencies in my code or that the physics engine was creating problems. I've corrected many issues and found no performance gains, then disabled physics and other scene nodes one at a time to see where the problem was. Yesterday I put in a profiling class just to see where it's losing it plus spent time in "Instruments" to see specific calls. Basically, "all" of the time is taken up down in drawAll. Since I've toyed with replacing meshes and textures with no changes, I'd presumed it wasn't something obvious like that, now I am wondering if it actually is.

If I load a level, a player character, one AI, and one vehicle, it's usable, I get around 130 FPS, that drops off quickly though and that won't support our game scenario anyway. I load 5 vehicles I'm down to 30 FPS, 15 Animated AIs, it's at 60 FPS. This is on an 8GB dual quad Xeon with ATI Radeon 5700 (for comparison, this runs the Movement tutorial at up to 2146 FPS). Both those two examples will be at 1 or 2 FPS if on my older laptop, or below 10 on my 8G mac mini. I haven't tried it on windows yet as I don't have a box, I didn't think that would matter during development. But in general, it's like something is very wrong, the only improvement I've been able to make is to turn off shadow volumes which doubles the FPS, still not fast enough though, as we would need many times the performance we are currently seeing.

Things I've tried besides the shadow volumes.
1. Removed all biped bone initialization
2. Removed all Animation
3. Disabled all physics (bullet physics, not irrBullet, just using the SDK)
4. Disabled all shaders
5. Eliminated level and used a Plane shape with no scene node
6. numerous other things I can't remember, it's been over months now that I've been trying things

None of these make any difference and the profiling bears that out. The vast majority of time is spent in an openGL routine with a name like GLDrawArray_exec.

The questions:
1. Are my expectations too high (e.g., 15 low poly AIs on screen (was planning 30), 5 nice looking vehicles, and not in the same level)?
2. Are there common systemic mistakes people like myself make that could make so much difference in performance (textures meshes faulty event receiver etc)? In that manner, it seems like I've tried everything, but maybe not.
3. Is the mac just the wrong platform to develop on, one of our beginning assertions is that it would run on Unix, Mac and Windows?
4. Other ideas?

A few details: Bullet Kinematic Character Controller (AI and Player), Bullet RayCastVehicle, .X meshes for bipeds (about 60 bones), large tri mesh level but pretty simple and boring textures, obj models for moon and one large scenery object.

Edit, some statements above would lead the reader to think I'm trying 5 vehicles and 15 AIs, my mechanics demo levels are 1 player + 5 vehicles, and separate one for 15 AIs, 1 player, 1 vehicle. Vehicles, when activated, are a fairly intense render hit and we weren't thinking we could have AIs and multiple vehicles in the game at once if the vehicles were activated. Another mistake is in number 4 above. I disabled custom shaders and dropped to built-in using EMT_SOLID and a normal light scene node as a test. Didn't mean to imply there was no light or material processing.

[hybrid]

It's not easy to answer with just those figures you gave us. What's the actual polycount of each mesh, in which way are they animated? Shadow volumes are usually a large drawback, you should disable them during development usually. Later on you can assess also different methods for shadow drawing. Best help for improving the render speed is making use of vertex buffers. Try enabling the hadware mapping hint to EHM_STATIC for non-animated meshes, and EHM_DYNAMIC for animated ones. You can even make the indices static for all meshes, but that's only supported by opengl.

[eagletree]

What's the actual polycount of each mesh,

I put in some counts, the player/AI meshes (each is two separate meshes) are 636 Indices with a vertex count of 570 and 6924 Indices with a vertex count of 6848 (this came as a surprise, I've been saying our bipeds are low-poly, on the face of it, that doesn't seem too low-poly), and for reference, the static mesh for the level came out with a index count of 28980 vertex count of 4991 (I'm waiting for a smaller level from the modeler). The vehicles are made of several meshes and I'll have to put more displays in to snap that information. I'm guessing they are lower poly though as I've seen their wireframe in the modelers presentations. To make sure I'm giving you what you asked for, I got this iteratively with getIndexCount() and getVertexCount() on the mesh buffers.

in which way are they animated?

The player/AIs are animated with EJUOR right now, will be frame from blender when the modeler catches up. I had disabled all of that to see if it was causing an issue. I couldn't see any change.

Shadow volumes are usually a large drawback, you should disable them during development usually. Later on you can assess also different methods for shadow drawing.

I hear you on this, I realized I might have to bite the bullet and learn something about how the shadows are done. But since I don't get enough of a performance boost to accommodate the scenarios of our game, I have been doing all my tests with shadow volumes on. I'll start doing my performance measurements without them. Thanks.

Best help for improving the render speed is making use of vertex buffers. Try enabling the hadware mapping hint to EHM_STATIC for non-animated meshes, and EHM_DYNAMIC for animated ones. You can even make the indices static for all meshes, but that's only supported by opengl.

I went through and explicitly set the hardware hints this morning. It's nebulous without doing a larger number of tests, but in 10, I averaged from 10 FPS down to 0 improvement depending on the demo level. The interesting one was the vehicle heavy demo, it showed a 7 FPS improvment, the vehicles have no animations, just using IAnimatedMesh for the shadow volumes.

I'll study up on what you mean by making the indices static. We are pretty hard over on limiting proprietary methods or products in this game, so openGL is a basic design constraint. What I'm hearing implied here is that there are possibly errors I'm making and this thing may be doable. If it is, I'll be happy to fight with it as long as it takes, so I appreciate very much the response.

[hybrid]

The thing with vertex/index buffers is that you need to know which parts of the mesh are changing. For the world mesh, neither vertices nor indices are changed. So you can simply call setHardwareMappingHint(EHM_STATIC) on that mesh scene node. For animated meshes, the indices are usually unaltered, but the vertex positions are changed during animation. So you can set the whole mesh to EHM_DYNAMIC (or even EHM_STREAM), which means that the data is changed regularly. The GPU will still try to optimize things for this situation. But since indices are kept, you can give a second parameter EBT_INDICES, and set thos to EHM_STATIC. This would mean, that the index buffer is kept on the GPU unchanged. This can sometimes make an improvement, but not always.
For animated meshes, it's also a question of how many bones are used for the animation, and how many animation frames. You can, of course, determine the major bottlenecks by removing parts from the scenery and measure frame rate. Just make sure that you really measure the very same situation and for long enough.

[eagletree]

Thanks again. Your reply set me off on a new afternoon of study. I've really tried to keep mesh buffers as a black box except where the physics required I pull out the data. It looks like it's time to understand them better. I found many threads on Mapping Hints and have played around it. You've given me a direction and I've picked up a few FPS today. That's a winner for a day.

When I solve my issues, I'll post what I wasn't doing, back to this thread.

Edit: I did have one more question. It sounds like setHardwareMappingHint should apply to all buffers of a mesh unless you explicitly iterate through the buffers, yet reading the 1.7.3 changes.txt, it suggests this will not be true until that is released. I'm currently treating the EHM_STATIC as if it's global to all buffers on 1.7.2, is it?

[hybrid]

Yes, as with all flags, when applied to the mesh it's pushed down to each buffer uniformly. Otherwise you have to alter a buffer manually. But this will also be true for 1.8+ versions.