[WIP] Vurt's Tree Replacers for Morroblivion

CREDIT: A huge thank you to vurt for allowing the Morroblivion community to finally enjoy what I believe are the definitive mods for Morrowind trees and shrubs: the Vurt's Tree Replacer collection!

This project began back in 2016 as part of the MGSO for Morroblivion project, but ran into a number of hurdles that have finally been overcome with the help of the ModExporter and FarNifAutoGen utilities. You can read more about it in my developer journal here. To find out about vurt and his collection of indispensable mods for Morrowind, go here.

Links to alpha versions:

Required: VWD Replacer for v064 Morroblivion: FarNifAutoGen-MorroblivionBSA.7z (mediafire)
Required: "Morrowind_Compatibility_Layer.esp" from Mods-for-ModExporter (mediafire)
Vurt's Bitter Coast Tree Replacer II for Morroblivion - alpha 3 (mediafire)
Vurt's Grazelands Unique Trees - alpha 2 (mediafire)
Vurt's Ashland Overhaul Trees - alpha 2 (mediafire)
Vurt's Leafy West Gash II - alpha 1 (mediafire)
Vurt's Ascadian Isles Trees II - alpha 2 (mediafire)
Vurt's Solstheim Tree Replacer II - alpha 1 (mediafire)

Directions:
1. Download and install the VWD Replacer for v064 Morroblivion with your favorite mod manager.
2. Downoad and install Mods-for-ModExporter: you only need to activate the "Morrowind_Compatibility_Layer.esp". Load-order: This ESP should be placed before (above) all ESP files from the Vurt mods in step 3.
3. Download and install any combination of Vurt tree replacers above and install with favorite mod manager. Remember to activate all ESPs in each vurt mod. Load-order: These ESPs need to be placed after the "Morrowind_Compatibility_Layer.esp". Place any worldmap mods after (below) these ESPs.
4. Run TES4LODGen utility after steps 1, 2 and 3. You will need to run this again any time you modify or add additional Vurt mods.
5. Run Oblivion.

Incompatibilities:
Any other mods which add VWD / _FAR.NIF files to the Morroblivion worldspace will need to have the alpha-properties fix described in the developer journal here.

To Do:
Further testing needed to find incompatible Morroblivion mods. Graphical artifacts are still present on some trees and may need some hand-tweaking of NIF files. Performance tuning needed as well as higher performance / lower detail VWD files.

Potential Questions:

Question: What's the difference between the Ashland Trees here and the prior conversion done by Artparker?
- Answer:
- Artparker's mod is a good quality, hand-converted pluginless replacer which replaces the 7 vanilla Morrowind ashtree types. It does not contain VWD files.
- The conversion here was created with ModExporter with automated generation of VWD files as well as automated generation of Normal-maps using the GIMP Normal-maps plugin. It contains the 7 replacement trees like Artparker's mod, but also has 8 additional tree models and special textures for unique and rare trees which were custom placed by Vurt.
Question: What's the difference between the Bitter Coast Tree Replacers mod here and the BC Tree Replacer mod released in 2016?
- Answer:
- The mod released in 2016 used the old ESPConverter tool and had hand-made, undecimated VWD models.
- The conversion here was created with ModExporter. The VWD files were mathematically decimated using Blender-Python scripts. Normal-maps were generated with the GIMP Normal-maps plugin.
Question: What is "Morrowind_Compatibility_Layer.esp" or Mods-for-Modexporter?
- Answer:
- This is a file used by mods which are created using newer versions of the ModExporter. It allows for compatibility with Morrowind-specific items such as scripts, quests, global settings and other elements that don't exist in Morroblivion.
Question: My Morroblivion worldmap mod got replaced by the vanilla Morroblivion map! How do I fix it?
- Answer:
- Using a mod mananger, move your worldmap mod's ESP to after (below) all Vurt mod ESPs.

Photos:

Last edited by ponyrider0 on 7 Apr 2019 - 11:43.

(No subject)

I updated the requirements

I updated the requirements and instructions to include "Morrowind_Compatibility_Layer.esp" which can be found with Mods-for-Modexporter.

Also updated some of the mods to "alpha 2".

To do: working on the last few alpha 1 mods to update the NIF files with definitive alphaproperties fix.

I'm not sure I understand

I'm not sure I understand your point about alpha transparency in VWD objects. Alpha property is removed from _far nifs, because having it there can cause graphic artifacts, like colored blobs appearing around distant objects (IIRC, this is also somehow connected to HDR - I think it happens only with HDR enabled).

From the testing I made when making the Ghostfence replacer, transparency does work on distant objects, but only with certain settings in NiAlphaProperty of the nif file. What I don't understand is your proposition to include NiAlphaProperty in all VWD meshes - why is it needed, exactly?

Here are before and after

Here are before and after screenshots to help illustrate the issue:

1) Before inserting NiAlphaProperty into all _FAR.NIF files:
http://www.mediafire.com/file/00gce8x5fo90wc9/Before.jpg/file
[External image]

2) After inserting NiAlphaProperty into all _FAR.NIF files:
http://www.mediafire.com/file/s1l6bub7i3u1gcm/After.jpg/file
[External image]

The "before" screenshot has a blocky appearing leaf/branch texture which is resolved in the "after" screenshot when I install the FarNifAutoGen-MorroblivionBSA.7z mod. This mod contains replacement files which override every FAR.NIF file contained in the "Morrowind_ob - Meshes.bsa" file. The key difference between the replacements and the originals is that an NiAlphaProperty is inserted into the properties list of every geometry block (ex. NiTriShape and NiTriStrips).

My best guess as to what is happening is that the TES4 game engine's graphics pipeline for rendering distant objects only sets the alpha-blending mode of the graphics context once at the start of each rendered frame. It then sends only the vertex and texture data for each distant object to the graphics card without changing the alpha-blending mode. This is actually a good way to optimize rendering, but it only works when the graphics engine pre-sorts the geometry data so that all triangles that require the same alpha-blending mode are rendered at one time before the graphics engine changes alpha-blending mode and sends another set of geometry data. Perhaps the geometry data is getting sorted, but there is a bug which prevents the graphics context from changing to a different alpha-blending mode.

In any case, the above graphic artifact only appears when the player is in a specific location and orientation where the queue of distant objects which will be rendered to the screen have FAR.NIF files that are missing an NiAlphaProperty, AND only when those FAR.NIF files are positioned to be rendered first in the queue. This resulted in a very long bug hunting process where I ended up removing all FAR.NIF files from the Morroblivion worldspace and slowly added them in one by one to try to figure out where the problem occured. I wasn't completely certain as to the cause of the problem until I modified the FarNifAutoGen tool to insert NiAlphaProperties into each geometry block. It's possible that I only need it in some geometry blocks in only certain situations, but applying it to all blocks appears to be a working solution at this point.

There is one open issue remaining: how to handle distant objects which use a specific alpha-blending mode with specific alpha thresholds that are incompatible with other distant objects. For now, it seems that most of the distant objects that require alpha-blending that I've come across use settings that are more or less compatible. In the future, I will probably try locking all distant objects into one blending-mode and one hard-coded alpha-threshold. I will then analyze the alpha-channel data in the DDS textures and adjust the alpha values to fit as best as I can to match the hard-coded alpha-threshold.

Let me know if you have any questions - hopefully that makes sense.

Huh, that's the first time I

Huh, that's the first time I hear of a problem like that.

This sounds cool! Vurt's mods

This sounds cool! Vurt's mods have a few problems according to the modding community, including optimization concerns, collision bugs, and texture errors. Modders have offered various fixes to these problems within the past year or so. Are you aware of these issues, and would having these fixes be helpful to your conversion process?

Any texture bugfixes would be

Any texture bugfixes would be directly usable -- at least in most circumstances.

Optimization is possibly useful -- as long as it is something more significant than just running through PyFFI to delete redundant nodes and vertices, since I've already done those things.

Collision might be the least useful, except for a few circumstances, since I've already noticed those issues and have custom written coding to detect problems and automatically generate collision geometry as needed... However, if it is hand-made collision geometry that is tuned for performance, then that would be (potentially) better than what the modexporter currently does.

Thanks!

UPDATE:

I found these 3 and will review them for inclusion/integration. Of course, I'll have to ask permission from those authors first.

(Solstheim II Texture Fix) https://www.nexusmods.com/morrowind/mods/45941
(BC II Remastered and Optimized) https://www.nexusmods.com/morrowind/mods/45941
(BC II Collision and other fixes) https://www.nexusmods.com/morrowind/mods/43528?tab=files

Let me know if I'm missing any.

PS - I'll probably be regenerating all the VWDs with the latest version of the FarNifAutoGen, so VWD performance should improve in future releases just from that.

No problem. Those were the

No problem. Those were the ones I was thinking of. Vurt's Solstheim page has it's own fix apart from the texture fix. Based on his comments, I believe Rytelier's BC2 fix supercedes MD's fix.

There's also this mod, which isn't a fix but an alternative to Vurt's Grazeland trees, for those who don't like the baoboa trees. https://www.nexusmods.com/morrowind/mods/46402

@ponyrider0

Did you try to contact Tiawar or Alenet about this Far nif rendering issue?

Also, How much generate a NiAlphaProperty for evry FAR nif affects performance?

I've considered an OBSE patch

I've considered an OBSE patch solution, and probably Alenet's Oblivion Reloaded sourcecode would be a good starting point to figure out a what to hook or modify. I haven't contacted either of them, but I'm not sure if this would be something they would consider working on since, I assume, they've moved on to other projects.

My informal testing doesn't show any detectable FPS drop that I can attribute to inserting NiAlphaProperty. My suspicion is that Oblivion is only reading the NiAlphaProperty and setting the alphablend computation mode with the first _far.NIF that it loads. Then all other NiAlphaProperty blocks it encounters in _far.NIF files after that are ignored. Potentially, there could be an added latency when loading in new _far.NIF files.

I know for sure that Alenet

I know for sure that Alenet is working on decoding SpeedTree usage in Oblivion graphic pipeline to implement "real" shadows for trees, and according to latest images on Discord it's at a good point.

Also Tiawar is still working on EBF. However Tiawar did very few things related to rendering. ( fixed a resolution check, a fix for a data race in SpeedTree loading, and a camera information fix for shadows )

Awesome! For some reason, I

Awesome! For some reason, I thought that EBF had not been updated since 2017. Good to hear that Alenet is still working on Oblivion, I thought he was working only on Skyrim now.