What is the status on performance?

[mistermoonshine]

So I've been following the project for several years now and one thing that's always stood out to me is how bad OpenMW runs, and also that nobody seems to talk about how bad OpenMW runs. I download every new version hoping it's the one that fixes the performance even a little bit but I am always disappointed. Yes it's possible to get 100 FPS completely vanilla but nobody wants to do that; throw in a couple of texture mods and a town overhaul and I'm still looking at vanilla-like framerates in the 20s. Not to mention the water shader literally halves the already very low framerate just by being enabled with all the settings turned off. I downloaded the build with shadows and I couldn't get a framerate in the double digits, though I suspect that is because of all the shadows being cast on Vurt's grasses.

I realize the project is open source and the developers are doing it in their spare time, but as an avid fan after all these years I just would like to know if anything is being planned about making the game run better. Please don't take offense, I am just wondering and feeling slightly concerned.

[AnyOldName3]

There are a few potential optimisations we're thinking of, but nothing too groundbreaking (although it's always possible that something will have a much bigger effect than we predict).

The biggest potential optimisations I can think of off the top of my head are:

• Multithreaded physics. Lots of people are CPU-bound, and one of the biggest tasks is physics simulation. Using a multithreaded build of Bullet might make that much faster.
• Switch to OSG 3.6. Right now, we're using (a fork of) OSG 3.4.1 for releases on most platforms as there are crashes with the latest OSG version. Newer OSG versions added support for Vertex Array Objects instead of just Display Lists, both of which are ways of getting meshes onto the GPU and drawing them. Theoretically, VAOs might be significantly faster than display lists, and that would make the draw thread faster.
• Hardware skinning. Animating meshes currently happens on the CPU, and GPUs can do it much faster, so doing it on the GPU might be very helpful, especially as it means we won't have to copy all animated meshes onto the GPU once a frame.

[akortunov]

I suspect that is because of all the shadows being cast on Vurt's grasses.

If you plugged-in a grass mod directly, you did a really weird thing. Grass mods are supposed to work with MGE's distant land generator.
If you use them directly, performance drop is awful since every single bush is rendered separately in both Morrowind and OpenMW.

About optimizations, I see additional possibilities:
1. Batching rendering for statics.
2. Occlusion planes support.
3. Distant Statics support.
4. Dynamic vegetations support.

The latter two are needed to prevent people from abusing the engine and complaining about performance issues after that (people tends to use the huge viewing distance, grass mods, mods with animated trees, etc).

[AnyOldName3]

I'm pretty sure we can't do occlusion planes without at the minimum the game data containing occlusion planes, which it doesn't.

[akortunov]

I'm pretty sure we can't do occlusion planes without at the minimum the game data containing occlusion planes, which it doesn't.

Of course, we can do only engine-side part of work here. I suppose modders will add occlusion planes to statics meshes, if there will be a real performance boost.

[psi29a]

I wish there was a mod to add +1 to a post, it would down on comments like mine.

Adding things to the engine that aren't immediately evident are OK, it can be the basis for mods/games in the future. My only question is, something for post 1.0 or would this have any benefit before 1.0?

[Ravenwing]

I thought all the devs were leaving after 1.0

I wish there was a mod to add +1 to a post, it would down on comments like mine.

Adding things to the engine that aren't immediately evident are OK, it can be the basis for mods/games in the future. My only question is, something for post 1.0 or would this have any benefit before 1.0?

Same for the +1

As to adding features that require effort by modders, it would be incredibly handy to allow mods to change config options automatically. I don’t think this applies to occlusion planes, but some features would create bugs or deoptimize the game without an accompanying mod. This would make installation so much easier than asking everyone to dig around in config settings. Just a thought!

I think my situation would be most aided by the update to latest OSG as I’m not physics limited, but limited by cull traversal (IIRC). I’ll have to subscribe to that on GitHub so I can see where y’all are at.

Overall SUPER excited about all of these things!

[mistermoonshine]

If you plugged-in a grass mod directly, you did a really weird thing. Grass mods are supposed to work with MGE's distant land generator.
If you use them directly, performance drop is awful since every single bush is rendered separately in both Morrowind and OpenMW.

The performance drop isn't that bad actually, using Vurt's grasses with collisions disabled. I have all Vurt's flora overhauls including trees and grasses and still can get 60-80 FPS in the wilderness. It's only in towns where the framerate drops significantly.

[AnyOldName3]

I'm pretty sure upgrading OSG won't improve the cull traversal (unless they add a new threading model which allows the cull traversal to use multiple threads, which I doubt will come any time soon and would probably require big changes to OpenMW, too). It's the draw stage that it might improve, and it's not certain that it will even help, especially on Nvidia hardware, where deprecated display lists are still supposed to be faster than VAOs.

Regarding occlusion planes, it looks like OSG doesn't support them at all via occlusion queries with osg::OcclusionQueryNode (as those just check against the previous frame once every few frames, not against an existing depth buffer at cull time). It might sort of support them via osg::OccluderNode, but I can't find any code where those actually do anything - I can sort of find documentation saying that nothing behind one should be rendered, but I think there's no code to actually do that.

If we wanted, we could try interspersing the scene graph with osg::OcclusionQueryNodes right now, and we'd probably see an increase in framerate, but it would come at the expense of pop-in as it compares against the previous frame, not an intermediate occlusion-geometry-only frame. I've tested the official OSG example for this, and even that exhibits pop-in.

The tasks for supporting occlusion planes are as follows:

• Do a lot of dicking around with OSG such that before the main cull traversal, we have one which collects and renders occlusion geometry to an intermediate framebuffer. The simplest option would be to have a node which first culls with one nodemask to collect only occlusion geometry and then culls with the normal nodemask to collect everything else. When occlusion geometry gets culled, it could secretly draw itself to the intermediate framebuffer without telling OSG, but that might require it to happen in another OpenGL context.
• Write an improved occlusion query node (or maybe even just a cull callback) which performs an occlusion query against this intermediate framebuffer using the node's bounds during culling, and only traverses its children if it passes.
• Create a way for modders to add occlusion geometry to stuff. Possible options include:

[*]Adding an extra record type to OMWAddons for positioning occlusion planes, just like one would position a static. This is how Skyrim and Fallout 4 do it, and would obviously need to be post-1.0.
[*]Interpreting something in Nif files as an occlusion plane. This can probably be made backwards compatible by using a NiStringExtraData node, as those can go anywhere and contain anything (although they might be called something different in Morrowind - I just know the Skyrim name).
[*]Interpreting whole Nif files with some property (e.g. file name, having a certain NiStringExtraData) as occlusion geometry. They could then be positioned in the scene like any other static.[/list][/list]

It's not impossible to have it before 1.0, but as there might be a fair amount of work involved, 1.0 might be really close by the time it's done, in which case it's best to delay it so there are no concerns of backwards compatibility with the ESP format to get in the way of implementation choices.

[AnyOldName3]

WHOEVER TOOK OVER FROM LGRO, WHY CAN'T I DO NESTED LISTS ANY MORE?