DynDOLOD 3.00 Alpha 169

[sheson]

8 minutes ago, orbnauticus said:

I encountered the same problem as @bloodmage and did a little more investigating.

Setting RealTimeLog=1 also fixed the process for me. I've attached my logs folder for both the crashed and successful runs.

Although the stalled process was using a lot of memory, I'm not convinced this is memory related. My total system memory usage never rose above 70%. This system has integrated graphics and 32GB of system memory.

Markarth Crash Report.zip

You only selected the MarkarthWorld in both runs, correct?
You also did not post TexGen logs, you ran it before right, all billboards textures were generated by it?

What using the other 10GB or so, is that dedicated to video memory?

If you do not have a dedicated graphics card, this might have to do with the issue. Read through the list of https://dyndolod.info/FAQ#High-memory-usage-Out-of-memory anyways, even just to really rule these possibilities out. Do both of these at the same time to see if they makes a difference:

add the -memory command line argument
In the C:\Games\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini, add a line TextureCache=10 under [DynDOLOD]

[mooit]

Hi,

I'm running SSE 1.6.640.0 using DynDOLOD 3 Alpha 169

In the DynDOLOD Summary of Messages - File Not Found Textures I have this line;

Warning: File not found textures\. Used by Meshes\landscape\trees\treepineforest03_burnt2.nif blubbos_trees_in_whiterun.esp treepineforest03_burnt2 "treepineforest03_burnt2" [TREE:3A005909]

It's this line I don't understand which isn't pointing to anything?

Warning: File not found textures\.

I uploaded treepineforest03_burnt2.nif;

https://www.mediafire.com/file/dobpmy7hts9wzpm/treepineforest03_burnt2.nif/file

Would the nif have something wrong with it, as to why DynDOLOD says \. the nif needs fixing?

If any DynDOLOD logs are needed, please let me know.

THANKS

Edited April 30 by mooit

[sheson]

3 hours ago, mooit said:

Hi,

I'm running SSE 1.6.640.0 using DynDOLOD 3 Alpha 169

In the DynDOLOD Summary of Messages - File Not Found Textures I have this line;

Warning: File not found textures\. Used by Meshes\landscape\trees\treepineforest03_burnt2.nif blubbos_trees_in_whiterun.esp treepineforest03_burnt2 "treepineforest03_burnt2" [TREE:3A005909]

It's this line I don't understand which isn't pointing to anything?

Warning: File not found textures\.

I uploaded treepineforest03_burnt2.nif;

https://www.mediafire.com/file/dobpmy7hts9wzpm/treepineforest03_burnt2.nif/file

Would the nif have something wrong with it, as to why DynDOLOD says \. the nif needs fixing?

If any DynDOLOD logs are needed, please let me know.

THANKS

Warning: File not found textures\.

The missing texture is "textures\" as the period denotes the end of the sentence.

https://dyndolod.info/Messages/File-Not-Found-Textures
The texture can not be found.
This can happen if not all required textures where included in the download archive of a mod or there are typos in the *.NIF files.

Open the NIF in NifSkope to check and to fix it.

The NIF defines "textures\" instead of the glow/detail map for SmallPineBranches and should typically be the same as the diffuse texture for tree branches or empty.

The NIF defines "textures\" instead of a normal map texture for SmallPineMainTrunk and should point textures\landscape\trees\treepineforestbarkcomp3_n.dds

If the intention is to not define a texture, the slot should be empty.

[Phlunder]

Another question regarding the TexGen billboard renderer. In some of the prior updates, the appearance of normal maps changed slightly. Since then, some of the billboards generated for Enderal specific trees are showing dark spots on the crowns. When checking the normal map of those trees in question, these spots are very bright, almost white. I am aware that the Enderal assets are kind of all over the place in quality/execution, so maybe that's just an issue with the meshes themselves.

Some screenshots of the issue, logs are here. 

  

[sheson]

1 hour ago, Phlunder said:

Another question regarding the TexGen billboard renderer. In some of the prior updates, the appearance of normal maps changed slightly. Since then, some of the billboards generated for Enderal specific trees are showing dark spots on the crowns. When checking the normal map of those trees in question, these spots are very bright, almost white. I am aware that the Enderal assets are kind of all over the place in quality/execution, so maybe that's just an issue with the meshes themselves.

Some screenshots of the issue, logs are here. 

  

The files in ..\DynDOLOD\Edit Scripts\Shaders last changed in 2022

From left to right. TexGen Alpha-109 from January 2023, TexGen Alpha-166 from January 2024, current TexGen

There is no change how the normal map vectors are calculated as far as I can tell.

The generated normal map texture is the result of the normal vector, bi/tangents vectors and the normal map texture.
In simple terms, the normal map textures being generated is the result of how the model reacts to light from the front + left/right and top/bottom - without the vector ever going "negative" into the opposite direction.

Using NifSkope shining direct light from behind to illustrate:

If I had to guess, what changed is the full models or its textures in the recent Enderal update. I assume that is why I have a different model, since I didn't have time to apply the update yet.

Dark aeras mean the combined vectors face away from the light source. In addition, this tree uses doublesided flag. The back faces are always darker since they face the opposite direction of the normal vector of the triangle.

The question is, does the full model look drastically different at about the same distance compared to Billboard4 using these textures. If so I suggest to test applying a bit of "smoothness".

[Phlunder]

12 minutes ago, sheson said:

The files in ..\DynDOLOD\Edit Scripts\Shaders last changed in 2022

From left to right. TexGen Alpha-109 from January 2023, TexGen Alpha-166 from January 2024, current TexGen

The generated normal map texture is the result of the normal vector, bi/tangents vectors and the normal map texture.
In simple terms, the normal map textures being generated is the result of how the model reacts to light from the front + left/right and top/bottom - without the vector ever going "negative" into the opposite direction.

Using NifSkope shining direct light from behind to illustrate:

If I had to guess, what changed is the full models or its textures in the recent Enderal update. I assume that is why I have a different model.

Dark aeras mean the combined vectors face away from the light source. In addition, this tree uses doublesided flag. The back faces are the "dark side".

The question is, does the full model look drastically different at about the same distance compared to Billboard4 using these textures. If so I suggest to test applying a bit of "smoothness".

Thanks for looking into it! My result is actually the same as yours, I just uploaded the wrong tree billboard normal map. I assumed its just how the model is built, that the parts facing away from the viewpoint are darker. The full model doesn't have that kind of shadowing from the same angle right when the cell is loaded. I guess it just comes from the size and shape of those models, they are much less uniform compared to vanilla tree meshes.

[sheson]

17 minutes ago, Phlunder said:

Thanks for looking into it! My result is actually the same as yours, I just uploaded the wrong tree billboard normal map. I assumed its just how the model is built, that the parts facing away from the viewpoint are darker. The full model doesn't have that kind of shadowing from the same angle right when the cell is loaded. I guess it just comes from the size and shape of those models, they are much less uniform compared to vanilla tree meshes.

If smoothness doesn't help or just because, you could make sure the triangles face skywards and not towards the ground, or disable the double sided flag, copy/paste the mesh and flip its faces so each branch has a surface facing both directions. If that works merge the two faces, so avoid doubling the drawcalls.

[The_Franks]

I fixed the college of Winterhold with a meshmask rule, and now I can't unsee the missing Azura statue.

Debug @ Googledrive link. Log hereDynDOLOD_TES5VR_log.txt.

I tried both ideas for meshmask rules from here Replaced Full Model - Example Azura Statue | DynDOLOD, and neither one seemed to work for me. I am not replacing Azura with a mod, and there is no light or anything. It might be a higher quality mesh, but it is the right nif name and has the lod in lod\clutter\ that it should have (and they match), and I verified in xEdit that nothing effects 0033dcb or 0033dca after dyndolod. Only BDS2.1 messes with 003dca, and only UESP modifies 0033dcb. In either case, dyndolod is last.

This is also an issue with the mountain tops near Azura, so maybe it is a large reference issue. I am definitely closer than 100 cells away.

Example: "architecture\winterhold\winterholdextcenter01.nif None None None None NeverFadeLOD Unchanged" works and I can see that mesh from anywhere it is not blocked from view, like from Shor'sWatchtower for example. The same meshmask rule for Azura changes nothing.

This is different from None None None None NeverFadeFull Unchanged and the Full Full Full None FarLOD Unchanged in the linked dyndolod explainer, but I tried those already with the same results.

  
Azura pops in at the top of the mountain behind Winstad manor from the west and at the flat rock by Cragslane Cavern located here.

  

And yes, I am amazed that dyndolod is so good that I can see the rock on the map. This is the view from the rock

  

and if I take one step backward

  

the tops of the mountains and the statue disappear, but the college remains. I am stumped.

[The_Franks]

Never mind. I set a mesh rule that works for me.

VWD None None None None NeverFadeFull Original. I can it from everywhere, and I don't care so much about the mountain peaks.

 

Aedra and Daedra together at last

   

The view from Shor's Watchtower.

[Soulmancer]

is re-generating dyndlod mid-save akin to compressing form IDs of plugin in a sense?  The form IDs generated in the re-run would not remain the same as they were in the prior build? ... Does using/updating the existing plugins as opposed to deleting them mitigate any change to the form IDs?

I know what the manual says about updating, but it advises you to disable the plugins in an existing save, which seems like a worse idea.

 

 

[sheson]

2 hours ago, Soulmancer said:

is re-generating dyndlod mid-save akin to compressing form IDs of plugin in a sense?  The form IDs generated in the re-run would not remain the same as they were in the prior build? ... Does using/updating the existing plugins as opposed to deleting them mitigate any change to the form IDs?

I know what the manual says about updating, but it advises you to disable the plugins in an existing save, which seems like a worse idea.

If there is an actual issue behind these questions, then report it.

Form IDs are not the same when generating from scratch. That is why the clean save instructions exists since epoch. Following this procedure is not a problem with plugins generated by DynDOLOD. The remaining orphaned scripts are reused by the new LOD patch generated from scratch without a problem.

Updating only adds new records, it does not remove records and does not change the form IDs of existing records.

[sheson]

11 hours ago, The_Franks said:

I fixed the college of Winterhold with a meshmask rule, and now I can't unsee the missing Azura statue.

Debug @ Googledrive link. Log hereDynDOLOD_TES5VR_log.txt.

I tried both ideas for meshmask rules from here Replaced Full Model - Example Azura Statue | DynDOLOD, and neither one seemed to work for me. I am not replacing Azura with a mod, and there is no light or anything. It might be a higher quality mesh, but it is the right nif name and has the lod in lod\clutter\ that it should have (and they match), and I verified in xEdit that nothing effects 0033dcb or 0033dca after dyndolod. Only BDS2.1 messes with 003dca, and only UESP modifies 0033dcb. In either case, dyndolod is last.

This is also an issue with the mountain tops near Azura, so maybe it is a large reference issue. I am definitely closer than 100 cells away.

Example: "architecture\winterhold\winterholdextcenter01.nif None None None None NeverFadeLOD Unchanged" works and I can see that mesh from anywhere it is not blocked from view, like from Shor'sWatchtower for example. The same meshmask rule for Azura changes nothing.

This is different from None None None None NeverFadeFull Unchanged and the Full Full Full None FarLOD Unchanged in the linked dyndolod explainer, but I tried those already with the same results.

  
Azura pops in at the top of the mountain behind Winstad manor from the west and at the flat rock by Cragslane Cavern located here.

  

And yes, I am amazed that dyndolod is so good that I can see the rock on the map. This is the view from the rock

  

and if I take one step backward

  

the tops of the mountains and the statue disappear, but the college remains. I am stumped.

The google link for the debug log wants me to login.

I know from the other post you now have a solution that works for you, however we never actually followed through investigating the actual reason for the statue, college or mountains to not show at a certain distance or from a certain location. For example, I asked to double check the object LOD distances in the DynDOLOD SkyUI - MCM and to test without Occlusion.esp in the load order etc.

For future reference, it is better to first find out the actual reason for something, so it can be fixed properly instead of making workarounds like setting full models to show in the LOD area. That should not be needed under normal circumstance and costs more performance. These references typically do not show on the map. It is also possible that the issue is caused by a problem or bug somewhere that ought to be fixed properly for everybody.

In case there is an issue in the future, just report it verbatim and follow through with requested information and the suggested troubleshooting steps. You do need to find a workaround for something that should not require a workaround to begin with. The statue, college and mountains should just show as is.

[The_Franks]

17 hours ago, sheson said:

The google link for the debug log wants me to login.

I know from the other post you now have a solution that works for you, however we never actually followed through investigating the actual reason for the statue, college or mountains to not show at a certain distance or from a certain location. For example, I asked to double check the object LOD distances in the DynDOLOD SkyUI - MCM and to test without Occlusion.esp in the load order etc.

For future reference, it is better to first find out the actual reason for something, so it can be fixed properly instead of making workarounds like setting full models to show in the LOD area. That should not be needed under normal circumstance and costs more performance. These references typically do not show on the map. It is also possible that the issue is caused by a problem or bug somewhere that ought to be fixed properly for everybody.

In case there is an issue in the future, just report it verbatim and follow through with requested information and the suggested troubleshooting steps. You do need to find a workaround for something that should not require a workaround to begin with. The statue, college and mountains should just show as is.

I'll do that stuff for you and get back to you. Here, try this link to the debug log.  https://drive.google.com/file/d/1TT_w94HwSwRKzdjsTfRdUKZFKtVmdxnc/view?usp=sharing.  

Edit: lod settings L0-35000, L1-70000, tree-102500. 

Edit2: running a regular high settings build without the occlusion.esp doesn't change anything about the visibility of the college, the statue, nor the mountain peaks. 

Edited May 2 by The_Franks

[Crimson121]

Im new to modding so sorry ahead of time, im getting this error running the TextGen file:

 

Old DynDOLOD files detected. Unpack the DynDOLOD Standalone archive into a new 'DynDOLOD' folder.

 

my DynDOLOD is already in a correct folder, I looked up this issue but Im stumped.

[z929669]

2 hours ago, Crimson121 said:

Im new to modding so sorry ahead of time, im getting this error running the TextGen file:

 

Old DynDOLOD files detected. Unpack the DynDOLOD Standalone archive into a new 'DynDOLOD' folder.

 

my DynDOLOD is already in a correct folder, I looked up this issue but Im stumped.

Searching this forum using the term, "old files" (with quotes), yields your answer:

 

Delete your current \DynDOLOD folder, and replace it with the \DynDOLOD folder from the downloaded archive. Retry.