About MM DynDoLod Ressources and why they behave like they do

[T4GTR34UM3R]

Majestic Mountains has a multilayer texture applied to the whole mesh without tiling to achieve variety. This forces me to apply one texture on the HDLod mesh without tiling.
The irony is the fact that it was never planned to use the mountainslab02.dds for the lod. I've created a mountainslabHQ.dds for
this purpose.
But DynDoLod refused to flag the mountains as HQLod when I used another texture. Even when I set this texture as HQLod
texture in the plugin files.

I had to use the mountainslab02.dds as a workaround.
The mountainslab02.dds and the lod normal is a 8 x 4 tiled texture that blends with a single tiled one. This means that the mountainslab02.dds has a lod only function in MM.
It wasn't the most elegant solution. But it works pretty good.

The next problem were all the rock and trim meshes that are using multiple lod textures.
These meshes are using the mountainslab02.dds and additional lod textures. The fact that these meshes have mixed textures prevents DynDoLod form flagging these meshes with HdLod.
This caused problems due to the mesh merging. DynDoLod merges the lod meshes by texture. And it merged the unflagged cliff and trim meshes with the lod mountains and it didn't set the HdLod flag for the mountain meshes after the merging.

About 30 percent of my mountain lod was merged with rockcliff meshes etc. And the mountain lod got the wrong normal map applied.

I dealt with the problem by redirecting the texture path to the correct mountainslablod.dds and did a reunwrap.
I didn't report this issue because I assume that DynDoLod would need bigger changes to solve this issue. And I solved it anyway.

Concerning texture path:

MM changes almost every mesh that uses the mountainslab textures in Skyrim. This means the near models and the lod models.
There is simply no reason for keeping the DynDoLod textures.
Because DynDoLod doesn't have the control about the near meshes. The near meshes are always controlled by the texture or model author.
And it is the duty of these authors to take care about the lod textures. Though many authors seem to forget this.

This is the reason why I've chosen and keep the vanilla path. And it is the technically correct path.

And getting the MMDynDoLod to work is pretty easy in that way.

Install DynDoLod, install DynDoLod Ressources, install DynDoLod Ressources for MM, overwrite the original DynDoLod Ressources, run DynDoLod, install the generated lod, be happy...

I hope that I could finally clarify how the MM lod works, what obstacles I had to overcome and why I made certain descisions.

Cheers,

T4

[T4GTR34UM3R]

I wrote this to ensure that everyone understands why I made certain descisions.

MM can't be treated like the vanilla mountains. But I have the feeling that too many people are doing that.

The only things that are in common with vanilla are the mesh names and the shapes.
And the lod is vastly different too.

It ain't a problem to have no HdLod flag on certain mountains with the vanilla meshes. You won't notice any difference.
But it was a problem with the MM lod.

And the example that I addressed the problem by my self should show that I need the control about the lod process. (I had a small hope that this would fix the Large Ref Bug too. But it didn't! )
This is the reason why I keep the vanilla paths.

I need the control to provide a working lod. And I took the responsebility too.

The lod works with any issues. And I don't see any need for improving compatibility right now.

[sheson]

Not sure if this is just information or a discussion to find better solutions to make everything more compatible and easier by updating assets, settings, configs or the involved tools as deemed necessary?

[z929669]

7 hours ago, T4GTR34UM3R said:

/snip...

Install DynDoLod, install DynDoLod Ressources, install DynDoLod Ressources for MM, overwrite the original DynDoLod Ressources, run DynDoLod, install the generated lod, be happy...

I hope that I could finally clarify how the MM lod works, what obstacles I had to overcome and why I made certain descisions.

This is exactly how we instruct our users to install MM.

I personally follow sheson's suggestion to improve mountain LOD for reduced view distances (e.g., < 20000/50000/100000) even when I am not using reduced view distances, which is to set a new mountains rule to use Level0 at both LOD 4 and LOD 8 and Level 1 at LOD 16 (instead of the catch-all rule of Lovel0/Level1/Level2).

Are you making this post in response to this topic or similar elsewhere? See user's solution in last post. We don't instruct to do this.

[T4GTR34UM3R]

5 hours ago, z929669 said:

Are you making this post in response to this topic or similar elsewhere? See user's solution in last post. We don't instruct to do this.

The noisy snow was caused by the HdLod flag issue that I fixed in my last lod update.
Everything works like intended now.

It was caused by the fact that both DynDoLod and MM doesn't completely behave like vanilla.
And that triggered some issues.

Edited May 12, 2021 by T4GTR34UM3R

[sheson]

The problems you ran into are because of a couple very much intended things in xLODGen/TexGen/DynDOLOD and LODGen which can or could be easily controlled by config files and INI settings, also included in mods to automate things.

>I didn't report this issue because I assume that DynDoLod would need bigger changes to solve this issue. And I solved it anyway.
This is a bit hilarious, considering the feature updates and support given to other mods and mod authors in the last half decade.

>And it is the duty of these authors to take care about the lod textures. 
Only for textures that TexGen can not yet generate, especially now that the alpha version can render object LOD textures and billboards from models.

If custom LOD textures are required, create a rule for so it is generated with TexGen for the load order. Especially if they need to replace existing LOD textures. That is the sole purpose of TexGen.

The current solution might have visual problems with 3rd party mods that include new full or LOD models that use overwritten textures that are made for different UV.

[T4GTR34UM3R]

1 hour ago, sheson said:

The problems you ran into are because of a couple very much intended things in xLODGen/TexGen/DynDOLOD and LODGen.

It is intended to prevent HdLod flag from the mountain lod?

 

 

1 hour ago, sheson said:

This is a bit hilarious, considering the feature updates and support given to other mods and mod authors in the last half decade.

I fixed an issue that shows up only with my mod and this is hilarious? Because I felt responsible for that.
OK!
I will ignore any upcoming issues.

 

1 hour ago, sheson said:

at TexGen can not yet generate, especially now that the alpha version can render object LOD textures and billboards from models.

If custom LOD textures are required, create a rule for so it is generated with TexGen for the load order. Especially if they need to replace existing LOD textures. That is the sole purpose of TexGen.

OK!
Northern Ice would require a custom rule, Underground, Majestic Landscapes, Glorious Glaciers and any texture mod on the Nexus.
Because you don't have the control about the near textures.
You can provide a working lod mesh/ texture pack. But you can't guarantee that it fits to the near object.

I hope that you get my point. If mod authors do it right then most texture packs would need a lod texture to get a good transition.
This would end in rule mess. Because every texture mod would need it's own rule.

And the only reason why it didn't happen yet is the fact that most mod authors simply don't care.

I suggest the load order solution.
And NMM proofs the advantages.

I install DynDoLod + Ressources, overwrite it with my files and run DynDoLod. I install the generated lod and it's done.

Without working with a lot of rules or ini settings.
This is the most user and author friendly way.

Because people regret to read instructions. My readme has ways less informations than yours. But people still don't read it.
The ask the same questions over and over again.
And these questions are answered.

I guarantee that they won't load tons of rules to create the lod.

But you can give me examples how this would break other mods if you want.

Edited May 12, 2021 by T4GTR34UM3R

[z929669]

@T4GTR34UM3R & @sheson

While we have you both in here, and it's pretty quiet, I'd like your input as to how to treat the two LOD-specific files provided by MM: One file provided for use with DynDLOLOD and another for use with xLODGen.

The xLODGen file provides only textures and is completely overwritten by the DynDOLOD file, which has many more assets and overwrites many of the DynDOLOD Resources 3.00 files.

The seemingly redundant xLODGen textures are very obviously different than those same assets provided by the DynDOLOD file.

Since there aren't any instructions that I can find on the MM Nexus page (sorry if I have missed them all this time), I have to think that T4's intent was that xLODGen be run with that mod active to gen terrain LOD and THEN activate the DynDOLOD file before running DynDLOLOD for object LOD.

This is contrary to most of what I have learned generating LOD (no other mods or instructions I know of use the different versions of the same textures for these different pieces of overall LODGen).

hopefully, you can both see that the textures are different just by looking at the thumbs in explorer:

Note that the textures are on the same path. Intuitively, it seems like both texture versions could be used at different times, depending on what of the two mods is active, because a given mesh could use either version of any of these textures. Also intuitively, it doesn't seem like terrain LOD will generate anything that conflicts with object LOD, so this confuses me.

[TechAngel85]

MM's Doc say this:

Quote

The Lod Ressources
- (optional) You need this packs for creating a fitting mountain lod.
There are two ways to generate lod in Skyrim.
Either you use SSELodGen/xLodGen or DynDoLod. DynDoLod is the recommended method because you can create an almost seamless mountain lod with it.
I've uploaded a lod texture pack for each tool.

Basically, you can use either or to accomplish the same thing, however, DynDOLOD is recommended.

[z929669]

Yes, but I'm trying to get a bit more info as to why some of the textures are so different. Currently, I am running terrain LOD with the xLODGen file overriding the DynDOLOD file textures (it provides only a handfull). Then I will gen object lod as normal after deactivating the xLODGen file.

This may be completely redundant, but I want to hear it from the horses.

[sheson]

11 hours ago, T4GTR34UM3R said:

It is intended to prevent HdLod flag from the mountain lod?

The HD LOD flag alone is not the only deciding factor if a shape of a LOD model is flagged HD or not. As explained earlier, this is done so HD and non HD shapes can be in the same LOD model. Other deciding factors are NIF and texture names, also because LOD is generated for base records that do not or can not have LOD models defined. One of those defaults is what caused you the troubles.

11 hours ago, T4GTR34UM3R said:

I fixed an issue that shows up only with my mod and this is hilarious? Because I felt responsible for that.
OK!
I will ignore any upcoming issues.

The bit that is hilarious is that you did not report or ask any question because you assumed that DynDOLOD would need changes, while DynDOLOD famously has changes and updates all the time to better support mods and mod authors. Always report problems or issues so they can be discussed and resolved and so the tools or processes can be improved as required.

11 hours ago, T4GTR34UM3R said:

Because you don't have the control about the near textures.
You can provide a working lod mesh/ texture pack. But you can't guarantee that it fits to the near object.

I hope that you get my point. If mod authors do it right then most texture packs would need a lod texture to get a good transition.
This would end in rule mess. Because every texture mod would need it's own rule.

If a mod makes changes so that it updates models which require new textures that are styled differently, then the new textures should have a new file names, so that there is no conflict with other mods that still require the original styled textures and for which the new texture style does not work. Unless you intend to make patches for these mods as well.
If technically possible, TexGen should be used to generate the accompanying LOD texture either updating existing or adding new rules. This will future proof the mod for texture updates or replacement textures. The rules for TexGen/DynDOLOD can be installed with the mods assets into the data folder so they are used automatically. Users do not have to do anything other than installing mods and running the tools as always.

11 hours ago, T4GTR34UM3R said:

I install DynDoLod + Ressources, overwrite it with my files and run DynDoLod. I install the generated lod and it's done.

DynDOLOD Resources needs to overwrite mods that include vanilla LOD resources, mods with updated LOD resources overwrite DynDOLOD Resources, TexGen output overwrites everything, then DynDOLOD output overwrites everything.

11 hours ago, T4GTR34UM3R said:

Without working with a lot of rules or ini settings.
This is the most user and author friendly way.

I guarantee that they won't load tons of rules to create the lod.

Every time TexGen/DynDOLOD run they automatically load rules for mods without the user having to do anything. This is how TexGen/DynDOLOD work since over half a decade and that is why it is so easy to generate LOD for the load orders.

11 hours ago, T4GTR34UM3R said:

But you can give me examples how this would break other mods if you want.

Not sure what this refers to specifically.

[sheson]

5 hours ago, z929669 said:

@T4GTR34UM3R & @sheson

While we have you both in here, and it's pretty quiet, I'd like your input as to how to treat the two LOD-specific files provided by MM: One file provided for use with DynDLOLOD and another for use with xLODGen.

The xLODGen file provides only textures and is completely overwritten by the DynDOLOD file, which has many more assets and overwrites many of the DynDOLOD Resources 3.00 files.

The seemingly redundant xLODGen textures are very obviously different than those same assets provided by the DynDOLOD file.

Since there aren't any instructions that I can find on the MM Nexus page (sorry if I have missed them all this time), I have to think that T4's intent was that xLODGen be run with that mod active to gen terrain LOD and THEN activate the DynDOLOD file before running DynDLOLOD for object LOD.

This is contrary to most of what I have learned generating LOD (no other mods or instructions I know of use the different versions of the same textures for these different pieces of overall LODGen).

hopefully, you can both see that the textures are different just by looking at the thumbs in explorer:

Note that the textures are on the same path. Intuitively, it seems like both texture versions could be used at different times, depending on what of the two mods is active, because a given mesh could use either version of any of these textures. Also intuitively, it doesn't seem like terrain LOD will generate anything that conflicts with object LOD, so this confuses me.

Terrain LOD generation does not use object LOD textures. Terrain LOD generation uses the texture sets and their landscape full textures as they are used on the landscape records.

Typically DynDOLOD should have / can use the same LOD resources as xLODGen. Of course if so required by a mod, assets that ship with DynDOLOD Resources need to have additional replacements in addition to the vanilla LOD assets.

[T4GTR34UM3R]

6 hours ago, z929669 said:

@T4GTR34UM3R & @sheson

While we have you both in here, and it's pretty quiet, I'd like your input as to how to treat the two LOD-specific files provided by MM: One file provided for use with DynDLOLOD and another for use with xLODGen.

The xLODGen file provides only textures and is completely overwritten by the DynDOLOD file, which has many more assets and overwrites many of the DynDOLOD Resources 3.00 files.

The seemingly redundant xLODGen textures are very obviously different than those same assets provided by the DynDOLOD file.

Since there aren't any instructions that I can find on the MM Nexus page (sorry if I have missed them all this time), I have to think that T4's intent was that xLODGen be run with that mod active to gen terrain LOD and THEN activate the DynDOLOD file before running DynDLOLOD for object LOD.

This is contrary to most of what I have learned generating LOD (no other mods or instructions I know of use the different versions of the same textures for these different pieces of overall LODGen).

The instructions of the mod page changed a lot over time.
And I've taken out a lot of instructions. Because I played with the idea to create very basic, vanilla like bto files for people who don't use DynDoLod.
Because MM needs DynDoLod to have a really good lod. And I added a sticky that you should always use the DynDoLod pack if you are using DynDoLod.

Because a lot of people refuse to use DynDoLod. And that is a problem.
But there were several other problems that I needed to solve before I could even think about a bto release.
And I'm currently thinking about a removal of the xLodGen files.

And yes!
I use xLodGen only for terrain creation.
There is no reason for touching the object lod with xLodGen when I'm using DynDoLod.

 

[T4GTR34UM3R]

3 hours ago, sheson said:

If a mod makes changes so that it updates models which require new textures that are styled differently, then the new textures should have a new file names, so that there is no conflict with other mods that still require the original styled textures and for which the new texture style does not work.

This would break compatibility.
Because a mod that uses the mountainslablod.dds for the lod would use my mountainslab textures for the full object.

And your lod texture doesn't fit to mine.

This is the reason why I asked for an example.

Overwriting your texture by a rule creates the same result than overwriting them directly. But it leaves out two additional steps.
And I prefer the direct ways. Because it is cleaner.

Edited May 13, 2021 by T4GTR34UM3R

[sheson]

53 minutes ago, T4GTR34UM3R said:

This would break compatibility.
Because a mod that uses the mountainslablod.dds for the lod would use my mountainslab textures for the full object.

And your lod texture doesn't fit to mine.

This is the reason why I asked for an example.

Mountainslablod.dds is a vanilla LOD textures that is a 3x3 stitched version of the vanilla textures\landscape\mountains\mountainslab02.dds.
Mountainslab02.dds is a square and tillable texture used by vanilla and custom full and LOD models. Mountainslablod.dds is used by vanilla and custom LOD models.
By default TexGen updates mountainslablod.dds with the currently installed mountainslab02.dds according to this rule, obviously.
Whenever a mod makes a change to mountainslab02.dds that does not change the full models UV or shader, then automatically every full and LOD model and the generated LOD with TexGen/DynDOLOD will match without nobody needing to do anything.

If a mod replaces a vanilla full or LOD texture that requires UV or shader updates of full or LOD models to look and work correctly, then it seems necessary to update every vanilla or custom full or LOD model. That seems like a lot of unnecessary work tracking all mods or having to deal with users dealing with visual problems. It seems advantageous to use new texture filenames for both the full and LOD texture to avoid such conflicts. You might want to look at new land mods in this particular case.

Regardless of replacing a vanilla texture or using a new texture filename, an updated TexGen rule that gets automatically applied should be added to create the different version of "your" LOD texture that is required.

[T4GTR34UM3R]

12 minutes ago, sheson said:

If a mod replaces a vanilla full or LOD texture that requires UV or shader updates of full or LOD models to look and work correctly, then it becomes necessary to update every vanilla or custom full or LOD model to avoid conflicts.

This is what I did.
My lod package contains about 1500 meshes.

And that is a huge part of the meshes in the lod folder.

14 minutes ago, sheson said:

Mountainslablod.dds is a vanilla LOD textures that is a 3x3 stitched version of the vanilla textures\landscape\mountains\mountainslab02.dds.
Mountainslab02.dds is a square and tillable texture used by vanilla and custom full and LOD models.

MM has a completely different texture layout.
Therefore it was necessary for me to update all full models and a lot of lod models in all worldspaces.

This means that mods need to activly decide to support MM.
MM's approach is to move into a different direction. Like all of my mods.

MM is intended to break through old patterns and to open up new fields.

 

I quote myself:

16 hours ago, T4GTR34UM3R said:

MM can't be treated like the vanilla mountains. But I have the feeling that too many people are doing that.

That's the problem.

And I still put a lot of work to stay as compatible as possible. It is a miracle that I achieved the amount of compatibility.

Same to Northern Ice. I added static snow instead of projected one to fix the dark snow lighting. And the UV's are completely different too.
But this mod doesn't have such a big impact to the worldspace.
While MM changes almost everything. Though it isn't visible that easily.