Speed Up

[jhooks1]

What are some possible ways we could speed up the OpenMW engine by making the code more efficient? Does anything need to be rewritten (besides the rendering refactor task)? I get 130fps in Beshara with nothing going on, but with the new animation method framerate goes way down. Physics will also introduce slowdown.

[Star-Demon]

Well - since we have a lot of linked lists in data - maybe we could convert some to trees or heaps after loading them from ESP. That would give us chances to move towards nicer searching and sorting techniques.

[gus]

You could use a profiler to discover which function are slow (or i might do it, as i've already done some optimisation task)

[Zini]

Well - since we have a lot of linked lists in data - maybe we could convert some to trees or heaps after loading them from ESP.

Irrelevant for the fps. Might affect the load speed though. And more elaborate scripts (not used in vanilla MW). Some of the used containers are indeed suboptimal. There is a issue for this problem in the tracker. But this can wait.

What are some possible ways we could speed up the OpenMW engine by making the code more efficient? Does anything need to be rewritten (besides the rendering refactor task)? I get 130fps in Beshara with nothing going on, but with the new animation method framerate goes way down. Physics will also introduce slowdown.

There are various things that could be done to increase the speed in some areas. We have barely started with optimisation. Scripting can definitely be speed up to some degree. And the exterior rendering performance too. We are currently rendering with the maximum possible range without any long range performance optimisations and only very basic batching.

However if you get fps problems in an interior cell, then we have a real problem. Animation should not be that expensive. If it is really the animation that reduces the framerate that much, then the problem is most likely found within the animation system. Doing some profiling would be a good start. It least it should tell us if we are CPU or GPU bound.

[jhooks1]

With animation running on all npcs before, it wasn't too bad (~37fps). For the new features however (see recent posts in NPC animation), what I needed to do wasn't really supported by OGRE. I had to make multiple separate base_anim meshes, each with separate submesh buffers, and that is what is slowing us down. It is the only possible way that I know of right now to implement these npc animation features correctly within OGRE. Someone else may be able to find a more efficient way to do this with OGRE, I can't see one right now

EDIT: Actually the texture, color, and index buffers can be shared but it doesn't really improve performance that I can see (just implemented it)

[WeirdSexy]

Out of curiosity, how powerful are the machines are you guys using to test on?
For example, I'm running a 4GHz e8500 (intel dual core), 4 Gigs ddr2 ~800MHz 4-4-4-12, and an overclocked ATI RHD 4870 1GB.

[gus]

You should download AMD profiling tools (code profiler and GPU profiler). They are really good. Do you want me to have a go with the profiling tools? (right now i'm doing nothing, as K1ll has not show up yet).

WeirdSexy: i have a core i3 330M and a 5650 Mobility.

[Zini]

@WeirdSexy: Specs vary widely. We have people working on netbooks and people working on powerful desktop systems. Mine has an Intel Quad clocked at 2.8 GHz, a GTX 285 and 8 GB RAM. A bit older but still fairly powerful.

@jhooks: In the worst case we have to rewrite the Ogre animation system. But did you try to ask on the OGRE forum about the problem? They might have some useful input there.

[Star-Demon]

Intel Core i7, 6 gigs ram, XFX Radeon HD5850

I mentioned data because, if we store it in game as it's stored on disk, that means that, for something we'll be iterating through constantly - it's going to eat up time and space because it's just another process that is occurring 60 times a second. Just thinking about it - I figure that those pile up fast in a game.

I've never used a profiler. Sounds neat. I'd like to learn more about it.

EDIT: I noticed that 0.11.0 did not run very well (think I mentioned it when I brought up the launcher...)

Perhaps we should go back to work done for that release and see what parts of the animation system could be optimized.

[Zini]

f we store it in game as it's stored on disk, that means that, for something we'll be iterating through constantly

We don't constantly iterate over anything. We iterate over all the references in a cell exactly once when the cell becomes active. And that's it.