Performance question.

[aymar]

I have a paged "infinite" world, and the game loads/unloads pages as the character walks around.

I'm having a big issue with performance, whenever there's a lot of static objects in the same page, it takes seconds to load it, which causes the game to completely freeze for seconds.

I'm loading the objects into v1::Entities, and attaching each of them to their respective SceneNode, which are direct children from Root.

Is there a way to speed this up? I see lots of possibilities, but I'd like to know if there's one more promising than the others...

• Using Item instead of v1::Entity.
• Creating a single SceneNode for the whole page, which is child to Root, and then attaching the objects' SceneNode to this SceneNode (idk if this would really help).
• (Maybe) A way to load static objects asynchronously.
• Or any other thing you guys can think of...

Thanks a lot.

[al2950]

Although I do not think this is your issue, any reason why you are using v1::Entities instead of Items ?

From your post I believe you are describing a stall rather than a performance issue, as in normal play performance is fine, but it stalls when loading a 'page'?

If this is true and you are using the HLMS, the stall might be down to HLMS generating and compiling shaders on the fly. There are a couple of solutions to this,

1) I have a pre-load black screen where your render a single frame of all objects, forcing HLMS to generate all require shaders before you start playing

2) Save and load the GPU program microcache. This is what I do and it works very well.

Code: Select all

Ogre::GpuProgramManager::getSingleton().loadMicrocodeCache(inputStream)

//save any micro cache if dirty, if its not dirty and you try and save it will effectively save a blank file
if (Ogre::GpuProgramManager::getSingleton().isCacheDirty())
{
	Ogre::GpuProgramManager::getSingleton().saveMicrocodeCache(outputStream);
}

[aymar]

You're right, what I'm having is more of a stall issue rather than poor performance. Performance-wise the app runs great (except for a few places where it renders too many objects and shadows, but that's expected and I can work on that).

I'm already saving/loading GPU programs cache. Do you have any other advices?

I'm using v1::Entities because I was already using them back when we were using Ogre 1.x, and for its skeleton, since we need to edit a few bones' animations on the fly (arms holding weapon should point up or down depending on the camera angle, as well as the neck bone).

But maybe I should use a mix of items (for non-animated objects) and v1::Entities (for animated ones). Although it would probably be kind hard to maintain such code...

The general structure of my SceneNodes are like it was supposed to be?

If I pre-load all objects beforehand, would that make a difference since I'm already saving/loading the microcache? I would expect it to stall in different places (first time it stalls on object_1, than it saves its HLMS, then, the second run do not stalls on object_1, but instead it stalls on object_2), but that's not what's happening apparently.

Thanks a lot.

[al2950]

It might be worth profiling then to get an idea where the stall is. But another place you could look at is adding/removing scene nodes. I assume when a page comes into 'view' you load all scene nodes for that page. I am also going to assume all meshes & textures are already loaded from disk at this point? I guess if you have a crazy amount of scene nodes this would cause a stall. Ogre 2.x is optimised for iterating through scene nodes, not adding/removing, so I guess if this is your issue you should implement some form of sceneNode streaming. To begin with you could keep it very simple and only load x sceneNodes per frame?

[dark_sylinc]

It's as al2950 said, most of the second-measured stalls are caused by shader compilation, using a cache solves it.

Mesh loading may cause some stalls. If you're loading too many meshes (particularly if skeletally animated with huge animations) it may cause those stalls too. Loading the meshes at startup can solve that problem. Maybe using the threaded resource loading system from 1.x could help at that, but it has always been really poor.

Like al' said, you need to profile. Aside from an actual profiler, one ridiculously stupid trick is to hit break with the debugger during those stalls, and see where is the code currently spending its time. Do this a couple times. It will give you a pretty rough but good idea of what is causing the stalls.

[syedhs]

To begin with you could keep it very simple and only load x sceneNodes per frame?

Yes I am also using something similar.. however I divide the world into grids of certain but fixed dimension and then load only n maximum objects per frame - it results in much less frame stutter. However the stutter is still there,and I think the only way to solve it is to have texture streaming features inside Ogre.

You can also load & decode the texture in separate thread and pass it into Ogre as complete as possible. There is another - ensure that textures are all DXT1/DXT5 and they are all power of two textures. Non-power of two textures are significantly slower to load.

Mesh with animation is also very slow to load - so preload them if possible.

Oh btw, the above observations are correct for Ogre 1.x - I am no sure about Ogre 2.x