Distant Land: where to next?

Everything about development and the OpenMW source code.
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Re: Distant Land: where to next?

Post by CMAugust »

If you can remember what those points were, this is the place to put them; both memory and a quick search failed me just now. Plus it's convenient to have it alongside the other dev insights in this thread.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

I suppose that he refers this thread, but it actually does not contain too many ideas which are not implemented. Actually, they were discussed:
1. Texture atlases.
2. Pre-made mesh LODs (either in NIFs themselves or in separate files).
3. Billboards for trees.
All three techniques seem to require a lot of CPU time and content creator intervention, so probably it is better to do not use them "on the fly".
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

The caching of mesh size to skip loading it (and also potentially offsets to find any NiLODNodes) would reduce CPU time when generating chunks. There'd be difficulties knowing when the cache had been invalidated as obviously we wouldn't be able to use something reliable like a hash of the mesh as the key as we'd need to load it to generate the hash, so we'd need to do some thinking, but once we reach the realm of content-aware archive formats, it'd be something we could get for free.

As for the CPU cost of atlassing, depending on the architecture of the approach, it could turn out to be effectively free. A glTexSubImage2D call into a small texture object with zeroes for the two offsets has the same cost as one into a larger texture with nonzero offsets, so there's no inherent reason for it to be slow. Even if it was, if we ended up doing it in the distance only (where we're ending up with lots of tiny chunks) we wouldn't even need to use to full qualityt mip level.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

AnyOldName3 wrote: 13 Dec 2020, 17:54 The caching of mesh size to skip loading it (and also potentially offsets to find any NiLODNodes) would reduce CPU time when generating chunks.
There is already a size cache in ObjectPaging.
As for LODs, ObjectPaging works with scene graph nodes, not with NIF files, so it handles LOD nodes during node copying, as any other optimizations.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

You're missing the point, though. When distant chunks are being generated, objects above the min size are still getting loaded and then ignored because they're below the min size, but it only has to be that way because there's no way for the scene graph to know a node's too small to actually be useful until it's actually loaded it. Caching the size in memory doesn't skip the step where it needs loading one at startup to know the size.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

AnyOldName3 wrote: 14 Dec 2020, 17:00 You're missing the point, though.
And I still missing it.
With on-the-fly paging we do not have info about mesh sizes, so we need to initially load meshes, calculate their sizes and then cache result do do not load them again. It is possible to calculate size manually or via separate tool and then write it to every mesh (via NiStringExtraData, for example), but it is error-prone and is not friendly for content creators.
With static paging there is no need to cache object sizes since OpenMW will load complete chunks directly from disk instead of creating them from scratch.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

We can't do static paging as nothing's static, so I don't see why you keep bringing it up. We can cache our dynamic pages to disk, though, but there are potential concerns that, because nothing's static, we'll end up with tens of versions of each page, and not have any good way of invalidating the cache as, with nothing being static, we can't tell what'll get used again. As a middle-ground, though, we could cache intermediate results, like the size of each mesh, letting us skip a lot of the work of loading meshes and regenerating chunks that stays the same between different versions of each page, without needing to waste disk space caching variant-specific things we might never need again.
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Re: Distant Land: where to next?

Post by CMAugust »

It should also be possible to run osg:simplify on a chunk and cache that. But akortunov (who is the only one that has tried osg:simplify) favors it as an offline solution and not real-time. Any other thoughts on that?
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

Whenever I've used offline geometry simplification on what I'd count as good meshes (i.e. manifold with no discontinuities), it's required quite a bit of parameter tweaking to get good results. I'd be unsurprised by osg::Simplify giving unacceptable results, especially if it's trying to work in real time.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

CMAugust wrote: 14 Dec 2020, 23:08 It should also be possible to run osg:simplify on a chunk and cache that. But akortunov (who is the only one that has tried osg:simplify) favors it as an offline solution and not real-time. Any other thoughts on that?
osg::Simplify does not provide a really good result and it requires a lot of CPU time.
Post Reply