Speed Up

[Star-Demon]

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.

I understand - but what about NPC behavior? Object and other physics updates? Game systems that get updated once a frame? We don't have all of this now, but you have a large game with big systems in it, maybe even systems that don't use callbacks as opposed to frames to count time (idk why, I'm taught to think in frames because of fighters and my education) and it really piles up, in my mind. I'm trying to stay conscious of all of it.

You're right in that we don't have this problem right now, but it's something that gets me thinking - all of these processes occurring 1 one frame need to be done 60 frames in a second. Not to mention what's being rendered on screen right now, how much of it there is, etc.

Here's a question - How much do you think we could render on the screen at once? We should find out - out of curiosity.

I really hope the slowdown has nothing to do with OGRE...that'd be disastrous. I hope it's just some minor changes needed to animation system. There's been so much hard work on it 'd hate to see a big part of it scrapped.

[Zini]

but what about NPC behavior? Object and other physics updates

Physics is done by Bullet. Each physics object stored in bullet holds a MWWorld::Ptr that points to the Reference. Basically outside of the physics system everything is O(n) here (with n being the number of references in the active cells. You can't expect anything better. Actually moving around objects is a bit more expensive, but since we only have minimal physics (only actors move), this won't cost us much. And the actual physics calculations seem to be a lot more expensive currently. Most likely a Bullet issue. gus is looking into it right now.

When a NPC enters an active cell (or rather when a cell with the NPC becomes active; the other direction is not implemented yet), it registers itself with an action manager. This class will handle all the NPC's behaviour by iterating over all NPCs in active cells once per frame. Note that we already have cut it down from all reference to the NPCss. It doesn't get any more efficient.

You're right in that we don't have this problem right now, but it's something that gets me thinking - all of these processes occurring 1 one frame need to be done 60 frames in a second.

We aren't doing much besides rendering and physics. The rest is already fairly cheap (which doesn't mean it can't be improved in some places). There isn't really that much happening per frame besides rendering and physics.
Only cell changes are expensive, but we will have to accept that at least for 1.0.

Here's a question - How much do you think we could render on the screen at once? We should find out - out of curiosity.

Impossible to say, since we have barely started with rendering optimisation.

I really hope the slowdown has nothing to do with OGRE...that'd be disastrous. I hope it's just some minor changes needed to animation system. There's been so much hard work on it 'd hate to see a big part of it scrapped.

Ogre is open and modular. If we can't make the animation system work for us, will will plug it out and replace it and that will not affect the rest of Ogre. That would mean substantial more work, but it is hardly a disaster.

[Star-Demon]

I'd call substantial more work a disaster.

That explains as lot though - thanks.

[jhooks1]

Just posted a message to the OGRE forum, but it has to be approved by a moderator before it is posted.

Hopefully they can suggest some animation related things to improve performance. I have a feeling they may need to look at code in the animation branch to really tell what is going wrong though.

[jhooks1]

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66907

Will look into hardware skinning

[jam]

this is probably gonna be of no help, and im not gonna pretend to be an expert with this stuff at most i know the basics of C++ and a few other languages, but i remeber reading about something similar on the wolfire blog and here was there answer.

http://blog.wolfire.com/2010/09/SIMD-optimization

different engine but im pretty sure it still applies

[jhooks1]

So far I have tried the vertex_program Ogre/HardwareSkinningOneWeight in a custom material file I made. I get the custom material in createMaterial() and use material->copyDetailsTo() to get the data in. So far, no improvement. I think we have to write our own cg vertex_program to get improvements.

EDIT: I suspect that if we get hardware skinning working, the fps could go up to 17fps. I disabled all parts attached to base_anim, thus no materials attached, and got 17fps. I think there is a bigger problem going on here.

[Zini]

EDIT: I suspect that if we get hardware skinning working, the fps could go up to 17fps. I disabled all parts attached to base_anim, thus no materials attached, and got 17fps. I think there is a bigger problem going on here.

I do not like the sound of that. Seems you are in for a heavy profiling session.

[jhooks1]

Just tried out the Suran, house of earthly delights in Morrowind. With everything going on, animation, ai, etc I average about 100fps. When I try the same cell in OpenMW, animation turned off, I am getting 50fps.

[Zini]

Physics again?

Edit: About the performance difference between OpenMW and MW: That is not surprising. Since 0.11 we are doing batching, but it is still pretty crude. From what I remember of the composition of MW interior cells and Morrowind.esm our current batching code would be particular inefficient in interiors.