How to Adjust the LODs for the Simply Dirt Roads Mod ?

[Clemus]

Hello everyone !

I am the author of the mod Simply Dirt Roads.

It’s a fairly simple mod that modifies the vanilla road meshes by removing the paved sections, leaving only the Landscape textures visible (a sort of alternative to Northern Roads).

A user noticed that after generating LODs with DynDOLOD, the roads still display the vanilla road textures.
I have tried reading several topics and posts on this forum, but I can’t find anything conclusive... Especially since I am French and might not understand all the nuances of your language...

Currently, I don't know if I need to create "_LOD.nif" models for each mesh and region, or if I just need to create a Mesh Mask Reference Rules. I haven't changed any data regarding the LODs of roads and bridges in the Creation Kit, but maybe I just need to modify something in my ESP ? Or maybe I just need to change the Road01 textures, etc., to dirt02, fallforestdirt01, reachdirt01, and snowlandscape01 ?

Sorry for all these questions. I’m attaching a screenshot taken by the user which clearly illustrates the issue.

If anyone kind enough could help me out, it would be really great !
Thank you !

 

Clemus.

[DoubleYou]

Did you change the shape and/or the texture path?

[Clemus]

I've removed the cobblestone path on Nifscope. So all that's left is the "Landscape" part. On esp, I had to touch up the texture sets and texture paths on the meshes, but nothing more. I've just tried Texgen and it still generates the vanilla road textures.

[DoubleYou]

Yeah, with your method, you would need to also modify the relevant LOD models, or make a TexGen rule.

[sheson]

1 hour ago, Clemus said:

Hello everyone !

I am the author of the mod Simply Dirt Roads.

It’s a fairly simple mod that modifies the vanilla road meshes by removing the paved sections, leaving only the Landscape textures visible (a sort of alternative to Northern Roads).

A user noticed that after generating LODs with DynDOLOD, the roads still display the vanilla road textures.
I have tried reading several topics and posts on this forum, but I can’t find anything conclusive... Especially since I am French and might not understand all the nuances of your language...

Currently, I don't know if I need to create "_LOD.nif" models for each mesh and region, or if I just need to create a Mesh Mask Reference Rules. I haven't changed any data regarding the LODs of roads and bridges in the Creation Kit, but maybe I just need to modify something in my ESP ? Or maybe I just need to change the Road01 textures, etc., to dirt02, fallforestdirt01, reachdirt01, and snowlandscape01 ?

Sorry for all these questions. I’m attaching a screenshot taken by the user which clearly illustrates the issue.

If anyone kind enough could help me out, it would be really great !
Thank you !

 

Clemus.

Since you modified the full meshes, the LOD models for roads do not match anymore. The LOD models included in DynDOLOD Resources only have the stone parts. So simply not generating any LOD for roads seems yo be the best solution in this case.

Add a rule files that disables LOD for roads. https://dyndolod.info/Help/Mesh-Mask-Reference-Rules and https://dyndolod.info/Mod-Authors#How-to-add-a-rule-file-for-a-plugin

Create a new file ..\Data\DynDOLOD\DynDOLOD_SSE_simpledirtesp.ini
Edit it in notepad and add
[Skyrim LODGen]
LODGen1=\roads\,None,None,None,None,None,Unchanged,1
LODGen2=roadchunk,None,None,None,None,None,Unchanged,1

Ship the file with your mod or let me know if you want me to include it in the next alpha version.

Let me know in case something does not work as expected or needs further clarification. In that case include DynDOLOD log and debug log as explained https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs and useful screenshots of full and LOD model as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

[Clemus]

Thank you very much for your reply ! 

I hadn't understood that an .ini file was required in addition to the Mesh Mask Reference Rules. 
However, I have one last question. My mod also includes a bridge modification. Would the safest way to have corresponding lods be to create them for each region and add them to my esp via the statics object edit in a Meshes/Lod/SimpleDirt/Bridges folder ? ( I don't think this would take very long to do, I'd just like to make sure I'm not doing anything wrong ). 

 

I've made another road mod called Real Dirt Roads, which includes road textures. As for the snow-covered roads, I proceeded in the same way as Simply, removing the cobblestones completely and creating a new folder with the new meshes (as it also includes modifications to be compatible with Footprints and the sound of footsteps). I guess I couldn't do it the same way. ( And I wouldn't want to bother you once again with a similar problem before your next alpha release.

 

Thanks again for your answers, I'll try to find a solution for Simply first. I'll get back to you to tell you what worked. And I have no problem adding it to your next alpha release. Maybe it'll be easier for users of this kind of mod.

[Clemus]

It worked ! Thanks so much ! So I created the ini for the high, medium and low values. I'll be able to publish this. I'll take a closer look at the bridges.

[sheson]

43 minutes ago, Clemus said:

Thank you very much for your reply ! 

I hadn't understood that an .ini file was required in addition to the Mesh Mask Reference Rules. 
However, I have one last question. My mod also includes a bridge modification. Would the safest way to have corresponding lods be to create them for each region and add them to my esp via the statics object edit in a Meshes/Lod/SimpleDirt/Bridges folder ? ( I don't think this would take very long to do, I'd just like to make sure I'm not doing anything wrong ). 

Since you modified the full models of bridges and also have filename collisions - the same filename used in different folders - I suggest to use the CRC32 of the full model as part for all the LOD filenames. See https://dyndolod.info/Mod-Authors#How-to-add-your-own-object-LOD-models

For example, copy ..\Meshes\lod\bridge\bridgenarrow01_lod_1.nif to bridgenarrow01_C88D9EE2_lod_1.nif, then remove the "BridgeNarrow01:7" shape from it.
For example, copy ..\Meshes\lod\bridge\bridgenarrow01_lod_1.nif to bridgenarrow01_28960E8B_lod_1.nif, then remove the "BridgeNarrow01:7" shape from it and replace the textures textures\landscape\Dirt02.dds and Dirt02_N.dds "for" BridgeNarrow01: with textures\landscape\snow01landscape.dds and snow01_n.dds

You will probably want to edit the 3D in Blender or 3DMax to close the holes to the side walls that will happen because of that. I would keep the new LOD files in the same folder ..\Meshes\lod\bridge\

16 minutes ago, Clemus said:

It worked ! Thanks so much ! So I created the ini for the high, medium and low values. I'll be able to publish this. I'll take a closer look at the bridges.

You do not need to create low, medium, high INI files if they all contain the same rules as the normal INI. They are only needed if you want different rules for a preset.

[sheson]

43 minutes ago, Clemus said:

I've made another road mod called Real Dirt Roads, which includes road textures. As for the snow-covered roads, I proceeded in the same way as Simply, removing the cobblestones completely and creating a new folder with the new meshes (as it also includes modifications to be compatible with Footprints and the sound of footsteps). I guess I couldn't do it the same way. ( And I wouldn't want to bother you once again with a similar problem before your next alpha release.

Thanks again for your answers, I'll try to find a solution for Simply first. I'll get back to you to tell you what worked. And I have no problem adding it to your next alpha release. Maybe it'll be easier for users of this kind of mod.

Yeah this is somewhat "bad" since there are filename collisions with different full models havening the same filename.

However, the LOD models included in DynDOLOD Resources might still work for the roads in ..\meshes\landscape\roads\roadstraight02.nif and you can add a rule as before to disable LOD for the full models in \SRsnowyroads like so:

[Skyrim LODGen]
LODGen1=\srsnowyroads,None,None,None,None,None,Unchanged,1

The bridges you do as above.

If anything does not have the desired results let me know.

[Clemus]

Wow, I understand much better the problems and the solutions I can bring to all this.
Yes, I suppose it was a bad idea not to change the names of the meshes for the snowy roads... I didn't think it would have caused so many problems...
I think I'll be able to solve this problem soon with your help.

Many Thanks Sheson. Thank you for taking the time to reply and help me. 
I'll get back to you if I run into any more problems. and if that works too. 

Have a nice day !

[Clemus]

Hi again,

I'm currently preparing a new update for Simply Dirt Roads, and this time I’d like to properly fix the issue with the bridges LODs, which previously didn't work correctly due to shared filenames across variants (e.g., snowy, fallforest versions of bridgenarrow01.nif).

From what I understand, I need to include the CRC32 of the full model in the LOD mesh filename, like so:
bridgenarrow01_[CRC32]_lod_1.nif

However, I have two main questions:

1. How exactly can I calculate the correct CRC32 that DynDOLOD expects?
   I’m aware of crctool.exe, but I want to be sure that the CRC32 it gives matches the one DynDOLOD would use internally. Is it based on the file's binary contents, or on specific parts of the NIF (e.g. node names, structure)?

2. Do I need to add anything to my plugin (.esp) to make DynDOLOD use the correct LOD mesh?
   Since STAT records support MNAM entries, is it better to define the LOD model there directly (with the CRC32-named file)?
   Or is it sufficient to rely on DynDOLOD’s automatic scanning and let it match LOD files via filename and CRC32 without touching the plugin?

I think I’ve grasped most of the system, but I want to be 100% sure before finalizing this update. Thanks in advance !

I was also wondering if I should create a rule for Texgen so that it generates the landscape texture instead of the roads ?

Clemus

Links to my wip update

https://drive.google.com/file/d/1tHemDDLtk8VYR_bai4iPwdnRL9Xf9N_8/view?usp=drive_link

 

Edited May 2 by Clemus

[sheson]

1 hour ago, Clemus said:

Hi again,

I'm currently preparing a new update for Simply Dirt Roads, and this time I’d like to properly fix the issue with the bridges LODs, which previously didn't work correctly due to shared filenames across variants (e.g., snowy, fallforest versions of bridgenarrow01.nif).

From what I understand, I need to include the CRC32 of the full model in the LOD mesh filename, like so:
bridgenarrow01_[CRC32]_lod_1.nif

However, I have two main questions:

1. How exactly can I calculate the correct CRC32 that DynDOLOD expects?
   I’m aware of crctool.exe, but I want to be sure that the CRC32 it gives matches the one DynDOLOD would use internally. Is it based on the file's binary contents, or on specific parts of the NIF (e.g. node names, structure)?

2. Do I need to add anything to my plugin (.esp) to make DynDOLOD use the correct LOD mesh?
   Since STAT records support MNAM entries, is it better to define the LOD model there directly (with the CRC32-named file)?
   Or is it sufficient to rely on DynDOLOD’s automatic scanning and let it match LOD files via filename and CRC32 without touching the plugin?

I think I’ve grasped most of the system, but I want to be 100% sure before finalizing this update. Thanks in advance !

I was also wondering if I should create a rule for Texgen so that it generates the landscape texture instead of the roads ?

Clemus

Links to my wip update

https://drive.google.com/file/d/1tHemDDLtk8VYR_bai4iPwdnRL9Xf9N_8/view?usp=drive_link
 

Also consider using unique filenames for your full models. In that case you do not need the CRC32.

https://dyndolod.info/Mod-Authors
In case of filename collisions or in case of popular full models being replaced by many different mods - waterfalls or trees for example - the CRC32 of the full model should be added to LOD model filename in the form house_[CRC32]_lod_[0|1|2|3].nif. With the CRC32 in the LOD model filename there is no more ambiguity and users do not have worry about overwrite order of LOD assets. Also see the CRC32 explanations for 3D Tree LOD Model and ultra tree LOD. The file ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_Object_Report.txt helps with checking which LOD assets were found and also what the expected CRC32 is.

Every CRC32 implementation is supposed to generate the same value for the same input. You can double check the CRC32 value DynDOLOD looks for and which LOD model has been actually used by checking for it in ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

For example:
BridgeNarrow01 [STAT:000CAD7D] Meshes\landscape\bridges\bridgenarrow01.nif [CRC32:BAFCFBAC] using ...

It is not only sufficient but actually preferred to rely on the automatic matching. By default the LOD data on a STAT base record is only used if the automatic matching couldn't find anything.

You would have to elaborate on your TexGen question as I am not sure what you are asking.
Only if the texture is not yet covered consider creating a new rule for TexGen to generate 2x2 or 4x4 stitched object LOD textures for example, so that the LOD model which still defines the full texture can use UV between 0.0 and 2.0 or 0.0 and 4.0 respectively instead of having to stay between the more restrictive 0.0 and 1.0.

[Clemus]

3 hours ago, sheson said:

Also consider using unique filenames for your full models. In that case you do not need the CRC32.

 

Hi Sheson,

Following up on our previous exchange — I just want to confirm if I now fully understand what would be considered the best approach.

If I want to provide LOD models for variants of the same mesh (for example, different bridge models using different textures or mesh edits depending on the region like FallForest, Snow, etc.), is it correct that the recommended solution is to:

• Give each full model a unique filename (e.g., bridgenarrow01_fall.nif, bridgenarrow01_snow.nif, etc.)

• Then name the corresponding LODs without using CRC32, just following the pattern:
  bridgenarrow01_fall_lod_1.nif, bridgenarrow01_snow_lod_1.nif, etc.

That way, the automatic matching works without ambiguity and there’s no need to use the CRC32 in the LOD file name — right?

Thanks again for your time and explanations.

[sheson]

2 hours ago, Clemus said:

Hi Sheson,

Following up on our previous exchange — I just want to confirm if I now fully understand what would be considered the best approach.

If I want to provide LOD models for variants of the same mesh (for example, different bridge models using different textures or mesh edits depending on the region like FallForest, Snow, etc.), is it correct that the recommended solution is to:

• Give each full model a unique filename (e.g., bridgenarrow01_fall.nif, bridgenarrow01_snow.nif, etc.)

• Then name the corresponding LODs without using CRC32, just following the pattern:
  bridgenarrow01_fall_lod_1.nif, bridgenarrow01_snow_lod_1.nif, etc.

That way, the automatic matching works without ambiguity and there’s no need to use the CRC32 in the LOD file name — right?

Thanks again for your time and explanations.

If you want to be extra sure, you could also add like your/mod initials to the filename. In particular when you use something common like 'fall' or 'snow'.
Try to do a cross check with other mods  - the game typically does not use a _ separator but of course check with it, too.

In that case no CRC32 is needed, since filename collisions are very unlikely.

[Clemus]

Many thanks !! 
I think I have all the answers I need to move forward now.