Understanding Morrowind's Asset Issues

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
sgtwisky
Posts: 18
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: 96
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.
sgtwisky
Posts: 18
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: 18
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: 2666
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.
User avatar
FiftyTifty
Posts: 63
Joined: 15 Oct 2014, 21:02

Re: Understanding Morrowind's Asset Issues

Post by FiftyTifty »

There are possibilities, like implementing robust dynamic batching which doesn't throw out all the built data each frame. Another one would be Cluster Mesh Rendering, which is prime for games with few materials (i.e, not PBR). There's an interesting thread on Unity's forums showcasing it: https://forum.unity.com/threads/cluster ... ue.916334/

This is all exotic, for sure. But to mitigate draw calls, exotic stuff is needed.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Understanding Morrowind's Asset Issues

Post by AnyOldName3 »

We've already got a robust dynamic batching that doesn't throw out all the built data each frame (object paging), but even within one Nif, there can be tens of different incompatible combinations of state that prevent things being merged. We don't atlas textures yet, so implementing that will increase the number of things we can merge, but Project Atlas is already a mod that you can install to do it ahead of time.
User avatar
Tes96
Posts: 232
Joined: 29 Feb 2012, 03:45
Location: Off-grid

Re: Understanding Morrowind's Asset Issues

Post by Tes96 »

Has anybody considered hiring a couple virtual assistants who are highly experienced in asset design and programming? It would be a costly donation but I think getting some professionals on board would help.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Understanding Morrowind's Asset Issues

Post by AnyOldName3 »

Do you mean a word other than virtual? I'm pretty sure you can't rent AI experienced in asset design and programming. Anyhow, if we brought in external help that wasn't already familiar with OpenMW, unless we had them for a long time (which we don't remotely have the money to do - maybe we could hire contractors for a couple of hours when they'd need weeks to familiarise themselves), they'd eat up more time being mentored by existing team members than they'd end up contributing. If we had enough money to reach the threshold where they'd be committing enough time that they'd be able to learn enough to do things on their own, it could be much better spent on removing existing commitments for existing team members. I'd get a lot more done on OpenMW if it was my day job. As for asset replacement rather than programming, we'd still end up with a bunch of content that Bethesda owned part of the copyright to.
User avatar
Tes96
Posts: 232
Joined: 29 Feb 2012, 03:45
Location: Off-grid

Re: Understanding Morrowind's Asset Issues

Post by Tes96 »

So is time basically what's holding this project back? Like you mentioned about doing this in your free time because of your day job. So it's not an issue of the team not being able to figure out what to do and how to do it, but rather finding the time to do it?
Post Reply