DynDOLOD 3.00 Alpha 198

[sheson]

1 hour ago, bloodmage said:

ok good news, it's in there this time.

Logs.rar

This archive does not seem to contain a DynDOLOD_SSE_realtime_log.txt or a new DynDOLOD log and debug log.

[Guest]

DynDOLOD_SSE_Debug_log.txtDynDOLOD_SSE_log.txt

I thought these are what you needed.

the realtime  never worked for me. here is the ini

TexGen_SSE.INIDynDOLOD_SSE.ini

[sheson]

45 minutes ago, bloodmage said:

DynDOLOD_SSE_Debug_log.txt 185.11 kB · 0 downloads DynDOLOD_SSE_log.txt 82.25 kB · 0 downloads

I thought these are what you needed.

the realtime  never worked for me. here is the ini

TexGen_SSE.INI 3.31 kB · 0 downloads DynDOLOD_SSE.ini 22.53 kB · 0 downloads

The DynDOLOD log and debug are the same as from this post https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-169/?do=findComment&comment=278595 which show that LOD billboards were not found and then no LOD generation was started.

Check the dates and content of the log files are the ones from the last generation.

The DynDOLOD_SSE.ini shows that ; RealTimeLog=1 is commented out. Remove the semicolon and any spaces in order to have the setting take effect.

[Guest]

amazing! real time log made it work.

Thank you so much. So the program ran very different. A bit longer, but much smoother with no freezing or big time gaps. Was this all just a VRAM or resource issue?

Thank you for your patience sheson. The only bad thing about dydolod...you can't go back to not using it. 

you and Enai and powerof3 (and many others) are some of the best out there man. I wish I understood half as much. Modding is as fun as playing.

it was the last tool I added to my arsenal and is essential now.

I would love to know what you find from the correct logs this time

Logs.rar

[sheson]

12 hours ago, bloodmage said:

amazing! real time log made it work.

Thank you so much. So the program ran very different. A bit longer, but much smoother with no freezing or big time gaps. Was this all just a VRAM or resource issue?

Thank you for your patience sheson. The only bad thing about dydolod...you can't go back to not using it.

you and Enai and powerof3 (and many others) are some of the best out there man. I wish I understood half as much. Modding is as fun as playing.

it was the last tool I added to my arsenal and is essential now.

I would love to know what you find from the correct logs this time

Logs.rar

If it runs through now, then it is hard to pinpoint a specific reason.

As I suggested in an earlier post, check memory usage of DynDOLOD in Windows task manager and check if it has sub processes like LODGenx64.exe or Texconvx64.exe that might be using lots of memory. The task manager can show both main and video memory usage.

When you have to generate again in the future, see the answers for https://dyndolod.info/FAQ#High-memory-usage-Out-of-memory first to test different settings and without enabling the real time log, in particular:
If DynDOLOD runs out of memory while generating atlas textures, add a line TextureCache=10 to ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI. If there are still problems, set MaxTextureSize=8192 in the same INI file.
If too many concurrent LODGen processes running at the same time consume all available memory, limit their total number by changing the MaxLODGen setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI.

So next time, try setting TextureCache=10 and MaxLODGen=2 to see if it makes a difference.

[orbnauticus]

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

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

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