Understanding Morrowind's Asset Issues

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Post Reply
sgtwisky
Posts: 14
Joined: 02 Aug 2017, 03:14

Understanding Morrowind's Asset Issues

Post by sgtwisky »

I have been poking around the forums and reading up a little on some of Morrowind's performance problems. One of them as I understand it, is how its assets were designed. The way they were designed causes a ton more draw calls then the way a modern game would design assets (even though they often are more detailed).

buildings for instance, are built from many objects instead of being a single object or model. So each small object that is part of a larger object needs its own draw call. So what might take one or two draw calls in another game, might require many more in Morrowind (and by extension OpenMW).

Is this the primary reason? And are there other reasons that Morrowind assets are poorly optimized (at least by modern day standards)? Just been really curious about this the last couple weeks, and figured that if anyone would answer this question it would be the dev's dealing with the issues that Morrowind had backed in.
User avatar
wazabear
Posts: 51
Joined: 13 May 2020, 19:31
Gitlab profile: https://gitlab.com/glassmancody.info

Re: Understanding Morrowind's Asset Issues

Post by wazabear »

Good question! This has actually been my main area of interest as of late, and I'm working on some experiments that should hopefully bring good news.

Sounds like you got the big picture. Besides just static objects the way body slots work in Morrowind add to the draw-call nightmare, it's one of the reasons later titles like Skyrim have such a simplified body part system. The draw bottleneck is *really, really* bad and cannot be underestimated. Even major projects like Tamriel Rebuilt haven't taken this as seriously as they should and only recently have taken steps (still not enough) to mitigate the number of draw calls in their scenes. A typical draw call budget (take Skyrim) is roughly 2 thousand at the high end for an exterior. For perspective, some areas in TR reach over 4 thousand.

This issue is amplified a *ton* in OpenMW when water shader and shadows are enabled. This is because the engine essentially needs to re-render the entire scene to generate each shadow map and reflection/refraction texture. If you press F3 twice you should see a `drawables` count in the bottom left box. Go anywhere in the game and take note of that number with water shader disabled. Enable the water shader in that exact scene and compare that `drawables` number, it should almost double! Also, compare the yellow `draw` bar, it will likely increase a ton as well.

It's a shame as a lot of good work has gone into things like async physics, but until OpenMW solves the draw bottleneck performance will suffer. OpenMW has added paging for distant objects and active grid which slightly mitigates this bottleneck by merging together objects at runtime but it is nowhere near enough. Now, you've probably heard assets, assets, assets when it comes to the draw-call fiasco, but this doesn't mean OpenMW is helpless. Realistically I don't see thousands upon thousands of base game and modded assets being remade to be draw-call friendly, so the engine needs to be smart about how it renders things

In simplest fashion, the current process looks like this:
1) (from cpu) have a list of objects to render in the scene
2) (from cpu) cull objects, e.g. objects not in the cameras view
3) (from cpu) for every object that was *not* culled, upload relevant *per-object* data like vertices, materials, lights, etc...
4) (from GPU) render object with the data uploaded just previously

Now, consider the following approach
1) (from cpu) have a list of objects to render in the scene
2) (from cpu) upload the entire list to the GPU, along with large shared buffers of materials, lights, etc... for *every* object
3) (from GPU) cull objects just like before, this time directly on the GPU
4) (from GPU) render objects, using data from the shared buffers

As you can see in the first example we need to continuously communicate with the GPU, essentially every time we want a new object drawn. We need to tell it what to draw (e.g. triangles), and how to draw it (e.g. what lights effect it or what texture it uses), each of these are usually separate operations which need round trips from the cpu to GPU. This adds a ton of overhead, and is especially bad in OpenGL. With the second example, however, notice how we make just 2 major communications to the GPU which is largely *independent on number of unique objects*. That is giving the GPU an uber-list of unculled objects and huge pool of data (materials, lights, etc...). In the end we still have the same number of raw objects, but the process is almost entirely on the GPU.
Fade away and radiate
sgtwisky
Posts: 14
Joined: 02 Aug 2017, 03:14

Re: Understanding Morrowind's Asset Issues

Post by sgtwisky »

Thanks for the detailed response. Its good to hear there are still methods of offloading some of the work from the CPU. :)
sgtwisky
Posts: 14
Joined: 02 Aug 2017, 03:14

Re: Understanding Morrowind's Asset Issues

Post by sgtwisky »

Was thinking about this some more, and had another question.

Is it in theory possible to multi-thread draw calls?

My assumption is that its not. I can imagine too many edge cases. Like what happens if 2 or more draw calls are finished and sent to the GPU on the same CPU cycle. Another issue I could see is draw calls needing to be completed in a specific order. Weather its due to shader draw calls after the initial call or because of other external factors. Pretty far out of my depth of knowledge here but it seemed interesting so I figured I would throw it out there lol.
User avatar
AnyOldName3
Posts: 2158
Joined: 26 Nov 2015, 03:25

Re: Understanding Morrowind's Asset Issues

Post by AnyOldName3 »

OpenGL only lets you interact with a context from one thread. There's not actually too much that needs drawing in a specific order, so a far-future hypothetical Vulkan port would be able to get some kind of performance boost, but it wouldn't be a silver bullet on its own.
AnyOldName3, Master of Shadows
Post Reply