DynDOLOD 3.00 Alpha 180

[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.

[sheson]

6 hours ago, The_Franks said:

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. 

Got the log OK now. Thanks.

Object LOD has 3 LOD levels in the game world and 3 distance settings https://dyndolod.info/Help/Object-LOD#Settings
The fBlockMaximumDistance is the one of interest. Beyond that the game just shows terrain LOD. Increase it to show object LOD further away.

As mentioned earlier, the current settings can be checked in the DynDOLOD SkyUI MCM - Settings page  https://dyndolod.info/Help/Mod-Configuration-Menu#Settings
Mods like VR FPS Stabilizer can change them on the fly.

[MisterMorden]

Hi again, Sheson...just a head's up that for some reason I get no windmill rotors when using DLL NG & scripts 20-23 + large ref bug workaround and starting a new game.  Version 19 is the last one that worked properly for me.  I will update with logs this evening, however everything in the generation seems to work fine the problem only occurs when switching to newer DLL NG versions.

[sheson]

17 minutes ago, MisterMorden said:

Hi again, Sheson...just a head's up that for some reason I get no windmill rotors when using DLL NG & scripts 20-23 + large ref bug workaround and starting a new game.  Version 19 is the last one that worked properly for me.  I will update with logs this evening, however everything in the generation seems to work fine the problem only occurs when switching to newer DLL NG versions.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots with more informative console of the full models that are missing with the output enabled.

Read https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing which papyrus log and DynDOLOD.log (after enabling debug) to also upload.

Just a heads up that I have no missing windmill fans using DynDOLOD DLL NG any version...

Report any main menu altering mods and how you start a new game.

[ni1by2]

Hi Sheson

Using DynDOLOD 3.0 Alpha-169 x64 - Skyrim Special Edition (SSE), with DynDOLOD DLL NG Alpha-23 and DynDOLOD Resources SE3.00 Alpha-49.

Trying to generate LODs for a fairly large mod list with new worldspaces (Wyrmstooth, MannyGT, Arnima etc), and Seasons, and Grass Lods with the new NGIO NG. On 1.6.640.

Lod gen took the longest it ever has - 16 hours+! - and right at the end, I got an error message, viz. LODGen4Win.exe failed to generate object LOD for Tamriel Sum.

I am not sure why this happened, all the other worldspaces and seasons worked fine, and for the Tamriel worldspace all other seasons generated LOD just fine. Hoping you can find the cause.

Link to the Logs - https://drive.google.com/drive/folders/1dfRGkkfrW25YraDvNharhFIT0Bq146cF?usp=sharing

Do i need to restart the whole process, or is there a way I can just generate the LODs for Tamriel SUM and add it to the already generated LODs?

Edited May 3 by ni1by2