openmw.org

As is mentioned on the first page of the thread, not every group of meshes can be merged into just one draw call, so a chunk can need several. If it covers a larger area, there's a bigger chance that it'll contain more meshes that can't be merged yet, for example because it contains parts of two towns which use different textures.

I think that's a spambot. That's word-for-word exactly what you said back here in the middle of the first sentence.

I disapproved the post, should be gone now

Adding this brief discussion with AnyOldName3 about the viability of LOD, since there is some talk that may be good to reference later. AnyOldName3 is in normal typeface and myself in bold, with minor editing for flow:

Spoiler: Show

I am wracking my brain trying to think how OpenMW can possibly balance good visuals and performance with a 50+ cell view distance solely under the object paging system, and as far as I can see it's not possible, even if each object has its own LOD and is atlased as optimally as possible.

AON3: For fifty cells, wouldn't you be at a point where you'd be doing the whole of Imperial City with a billboard? NiLodNode that only appears from a few km out with a billboard in it would do, no?

Yes, but right now it's not even possible to do the whole city with a billboard. Right now at least there's no communication between the object paging and LOD that would allow a consolidated mesh to appear at the appropriate time.
If we take Fort Pelagiad as an example, maybe in the future we'll be able to define via NiLODNode when all the composite wall pieces disappear and when a single mesh of the entire fort can appear. But this raises a crucial issue, that said LOD for the consolidated mesh and individual pieces is only applicable in Fort Pelagiad, and not any other area the imperial Fort tile set is used.

AON3: There's no particular reason why you'd need to still have the individual objects around at that distance. Hopefully some post-1.0 CS magic will make it easy to say this cluster of meshes gets replaced with this one simple mesh from a big distance and maybe even have the CS generate the big mesh for you.
The LOD factor is an argument for chunk generation, so it's supposed to be picking whichever LOD level is appropriate for each chunk. Provided that none of the meshes straddle a chunk border, and that the system works as designed, you can NiLodNode the base meshes to disappear (or set a minimum object size that makes them disappear) and place another mesh in the world with a NiLodNode that keeps it invisible until it's so far away the base meshes would have disappeared (or you wouldn't be able to see overlap).
I think the gist of the situation is that other games would have the editor have a button to bake this kind of thing, or wouldn't allow such long viewing distances in the first place.
The later BGS games don't do a great job as people are always running into issues where their mods desync from their LOD or previs or precombines and things start acting funky.
There's hopefully another solution that could work here, but we'd need to steal it from somewhere else.
There are plenty of modern games like Valheim that let you make some pretty serious landscape and object modifications yet also allow decent view distance, so they must be doing something to make that possible.

Yes, it seems clear another solution is necessary.
Also, while later BGS games apparently cause problems for people with various mod setups, I'd like to know more about how their systems work to get such high performance. For now, it's impossible for OpenMW to have these numbers:


AON3: Skyrim has LOD meshes a little like MGE XE, but there're custom rules and things like that. For example, there's something to figure out if something's a tree and replace it with a generic tree billboard from a certain distance despite the tree mesh not containing a NiLodNode. The tool to generate the LOD wasn't bundled with the game or Creation Kit, but xEdit has a LodGen mode for Skyrim like it does the earlier games, and that produces roughly/exactly the same thing as the vanilla LOD data with the vanilla game data.
Doing all the trees in that screenshot in one draw call is obviously way better than we can do right now.

OpenMW will almost certainly need to have a system that allows exceptions like that. Trees is the easy example.
What's more, to get trees of that size at that distance would require a object paging min size of something like 0.005, which would render way, way, way more objects than necessary.
There would need to be an exception for trees to render at the full viewing distance, regardless of the min size for everything else.

AON3: Ideally Object Paging's chunk generator would be able to see a mesh was used a bazillion times in the same chunk and its most distant LOD level was a billboard, and then batch all those together into one draw call, but I'm reasonably sure it can't.

Is it impossible to have the object paging system use differing minimum sizes for differing objects? To my knowledge, later games specifically tag trees to be treated differently, and quite a few other objects as well. Utilizing this information, you could have say a min tree paging size, and a minimum landscape paging size, etc.

Also, do cells meaningfully change in relative size between the game versions? Could it be possible that the later games are reducing load by simply have larger cells overall?

I'm really on board with avoiding baking things in as far as LODs and optimizations go. That is obviously a poor experience for everyone with largely moderate performance benefit, and that can be demonstrated with previs and precombine data in Fallout 4, which constantly breaks and is hard to properly generate for modders and users.

Problem is that Trees in the original game do not have any special markers indicating that it's a tree, which is why we treat everything in a generic way.

The closet thing we have at this point is OP for generic things and Groundcover for things we can instance (lots of little things littered everywhere) without collision, for example.

The plan is to further refine both systems.

The biggest issues with size are:

• It's not a great match for impact on the scene of this object being removed for a variety of reasons. Theoretically, there should be better metrics we can use to judge what to skip and what to keep. CMAugust got pretty good results by looking at meshes and making a judgement call, so the algorithm exists, it just hasn't been ported from the human brain to any of the platforms we support.
• We don't know the size until we've loaded the mesh, so we have to load everything then discard it with the current approach. Ideally we'd amortise this cost by going back in time and making Bethesda add the information to the Nif header or something so it happened once in the late 90s/early 2000s and never on user's machines. We can't do that, so computing it ahead of time (or at least caching it once OpenMW's loaded the mesh once on a particular machine) is a sensible compromise.