VWD and Texture Size

Thanks for sharing that article, junkacc.  I think it does a great job of clearly explaining the performance issues of distant lands and statics and discussing the methods of optimizing performance.

Q1) The "Oblivion - Meshes.bsa" contains about 10,000 files in the \Data\Meshes directory.  I did a search and found only 130 items that end in "_far.nif".  These _far.nifs were all architecture for the major cities: IC, Bravil, Bruma, Cheydinhal, Kvatch, Skingrad, Daedric and generic castle, etc.  Noticably, there are no rock or terrain meshes.  Which explains why RAEVWD makes such a difference.  Also of note is that the RAEVWD core subpackage only contains 142 _far.nifs and most of those are only for the main cities.  RAEVWD starts getting visibly better once you add in the subpackages for Wilderness Architecture, Aylied Ruins, Imperial Forts and Large Rocks.  The total RAEVWD mod contains 681 _far.nifs.

Q2) I don't know what the skyblivion method for VWD generation is, but here is a quote from the RAEVWD readme:

 

All of the meshes have been checked and had the following done:

* Collision data removed. If actual collision grids were still present, the branches have been deleted entirely. It's impossible to collide with a VWD object.
* Animation controllers removed. It is impossible to animate a VWD object, so this data is bloat.
* Geometry morphers removed. If a mesh had these, they've been removed, as they are only useful in animation.
* All NiStringsExtraData blocks removed. These are nearly always associated with collision.
* All BSX Flags removed. These are nearly always used for collision and animation.
* All NiSpecularProperty blocks removed. Leaving these in place causes visual anomalies, most notably the "every VWD turned yellow" issue.
* All NiBinaryExtraData blocks (tangent/normal spaces) removed. This data is not required for VWD meshes and helps tremendously in reducing memory usage.
* All parallax flags turned off. The distances involved make this useless anyway.
* All meshes have been assigned lowres textures instead of hires ones.
* Nearly all NiAlphaProperty blocks removed. If the mesh required it for transparency, it was kept. If this is left on a mesh that does not require it, visual anomalies can result.
* All NiVertexColorProperty blocks removed. These lead to some cases of black VWD objects.
* Optimization using PyFFI after the above has been done.  
 

Regarding your comment on combining textures: many NIF files already share a single texture file or use a common texture resource.  For example, many armor models will share portions of the same shiny metalic plate texture or chainmail texture.  The biggest drawback in trying to combine more textures after the fact is that it will break the UV coordinates in the models.  Of course, recalculating UV maps programmatically is an option.  Coming from the Morrowind modding world, I still see the gold standard for automated Distant Land and Distant Object generation to be MGE-XE.  You can set a size threshold to be used in selecting which statics will have LOD meshes generated, and you can set the amount of detail as a percent of the original to set the quality for the generated meshes and textures.  Blender has some crappy decimation tools: there is one function that tries to remove vertices while preserving the original UV map (the results are models that may only be 10% smaller than the original), and there is another that can do a better decimation but breaks the UV map and does not recalculate it for you.  Compared to the ease of use of MGE-XE, Blender is worthless for automated LOD mesh generation.

Q3) not sure, but the real question is can the average user's graphics card handle larger resolutions?  Both in terms of maximum individual texture size and total VRAM for all textures.  Keep in mind that memory requirements grow exponentially with linear increases in resolution.

Q4) The LOD mesh will take advantage of the appropriate sized mipmap, but the issue is that the full resolution texture with all mipmaps is what gets transferred across the PCI-E/AGP pipeline and stored in VRAM.  The GPU hardware then calculates what pixel to paint based on your texture filtering algorithm (ex, trilinear will interpolate between two mipmap levels to create better quality textured polys).  Bandwidth and storage are probably the major performance bottlenecks for high resolution textures (bandwidth for transferring the textures and VRAM storage of the textures).  This, along with disk reading needed to load 100-1000s of megabytes of high resolution textures into memory also contributes to in-game stutter.  Is this better than 100-1000s of textures of that are only 1-10 megabytes in size?  Perhaps -- I think it would require testing and performance tuning to find the right balance.

By automated, I mean you click a button and it scans the ENTIRE "\Morrowind\Data Files" folder including BSA and loose .NIFs and generates new LOD meshes and textures for every single nif model that meets the criteria you select and with the LOD quality you specify.  There's no opening of any modelling programs, no loading of individual meshes and no fiddling with decimation tools.  You click once and it does all the work.

The reason you don't see many _far.nifs in MGE-XE is that it does not use them.  MGE-XE has its own engine and file format for distant lands and meshes.  Check you "\Morrowind\Data Files\distantland\statics" to see what it generates.

Morroblivion has some VWD models which I think were generated by qwertyasdfgh.  The core "Morrowind_ob - Meshes.bsa" contains 98 _far.nifs.  The Morroblivion VWD mod contains 201 _far.nifs.  I think the file sizes are smaller but I did not check the polycounts.

Regarding the TheBloatedFloat_far.nif, I think you would get better performance impact from reducing the polygon count first -- there are multiple polygons in areas that would likely render to only 1-2 pixels at distances where the _far.nif is loaded in place of the full NIF -- check the handles on the ship's wheel.