DynDOLOD 3.00 Alpha 182

[sheson]

8 hours ago, NephilimOokami said:

I did'nt believe it's a DynDOLOD related bug, but I've searched for the same "bug", and found that one person with the same problem has comented here. Sorry if this it's not the right place to find solutions to my problem now, btw, any clue on what may be causing this bug? Or any redirections at all?

Check with xEdit which plugins modify the LAND records in the affected CELLs.

[Phlunder]

Hey sheson, I'm trying to work on LOD meshes for some more Enderal objects. I just have a small question regarding the UV range of 0.0-1.0 so the textures can be added to the atlas. How can I see this UV range in NifSkope? Its probably not a good thing to show screenshots here, but does the 1.0 range refer to the original texture shown in the blue square in the middle, or the 8 tiled squares outside, I marked in red here? Would it suffice to bring the UVs into that range? I marked those ranges after the fact, of course, just to show what I mean.

The goal is to keep the full texture assigned, like you did for many LOD assets, so DynDOLOD can automatically create downscaled textures from the full ones, and add them to the atlas. It worked before for other assets I worked on, but I'm not sure how to interpret the UV range. Sorry in advance if its off topic.

Edited March 24, 2022 by Phlunder

[NephilimOokami]

4 hours ago, sheson said:

Check with xEdit which plugins modify the LAND records in the affected CELLs.

Thanks for the guidance

[sheson]

2 hours ago, Phlunder said:

Hey sheson, I'm trying to work on LOD meshes for some more Enderal objects. I just have a small question regarding the UV range of 0.0-1.0 so the textures can be added to the atlas. How can I see this UV range in NifSkope? Its probably not a good thing to show screenshots here, but does the 1.0 range refer to the original texture shown in the blue square in the middle, or the 8 tiled squares outside, I marked in red here? Would it suffice to bring the UVs into that range? I marked those ranges after the fact, of course, just to show what I mean.

The goal is to keep the full texture assigned, like you did for many LOD assets, so DynDOLOD can automatically create downscaled textures from the full ones, and add them to the atlas. It worked before for other assets I worked on, but I'm not sure how to interpret the UV range. Sorry in advance if its off topic.

0.0 to 1.0 is the blue square.

If you find you need to add (lots of) triangles to achieve that, reuse/create stitched object LOD textures with TexGen rules that tile the full texture to a 2x2 stitched object LOD texture for example, then the UV for shapes that reference full textures only needs to stay between 0.0 to 2.0 (to the right and bottom in NifSkope)

For example ..\Meshes\lod\dirtcliffs\dirtcliffs01_lod_0.nif from DynDOLOD Resources.
It defines the full textures textures\landscape\dirtcliffs\dirtcliffs01.dds and textures\landscape\fieldgrass02.dds and the UV stays between 0.0 and 2.0.
You will find TexGen rules for these textures in DynDOLOD_ENDERALSE_TexGen_noalpha_skyrimesm.txt for example that instruct how to create the 2x2 textures\lod\dirtcliffs01lod.dds or textures\lod\fieldgrass02lod.dds. https://dyndolod.info/Mod-Authors#How-to-add-LOD-textures-creation-rules-to-TexGen

[Arctic4161]

I agree with others here. Ram usage needs to be addressed. The program itself is awesome and we appreciate your work. On win 11 it basically uses all ram and kills off all other running programs. Used 100% virtual memory and 99.9% physical memory.

[sheson]

9 hours ago, Arctic4161 said:

I agree with others here. Ram usage needs to be addressed. The program itself is awesome and we appreciate your work. On win 11 it basically uses all ram and kills off all other running programs. Used 100% virtual memory and 99.9% physical memory.

Read the first post which log and debug log and bugreport.txt to upload when making posts.

Read the https://dyndolod.info/FAQ DynDOLOD/TexGen Questions High memory usage

The screenshot does not show any information about anything related to the LOD generation processes. Computers have memory so it can be used by programs. The OS controls how much memory programs can use. 

[Arctic4161]

8 hours ago, sheson said:

Read the first post which log and debug log and bugreport.txt to upload when making posts.

Read the https://dyndolod.info/FAQ DynDOLOD/TexGen Questions High memory usage

The screenshot does not show any information about anything related to the LOD generation processes. Computers have memory so it can be used by programs. The OS controls how much memory programs can use. 

It's not a bug it's how you multithread the CMD for the different seasons. I code myself, an easy fix would be to run each season sequentially instead of in parallel. Each process is vying for memory. Would also probably help to run 2 season in parallel then run the next 2. That's just my 2 cents. Would probably speed it up too as each process is stepping on each other for memory.

Edited March 26, 2022 by Arctic4161
Accidental post before finished writing

[sheson]

38 minutes ago, Arctic4161 said:

It's not a bug it's how you multithread the CMD for the different seasons. I code myself, an easy fix would be to run each season sequentially instead of in parallel. Each process is vying for memory. Would also probably help to run 2 season in parallel then run the next 2. That's just my 2 cents. Would probably speed it up too as each process is stepping on each other for memory.

As already suggested, read the https://dyndolod.info/FAQ DynDOLOD/TexGen Questions High memory usage, which for example says this:
If too many concurrent LODGen processes running at the same time consume all available memory, limit their number by changing the MaxLODGen setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI.

It is also explained on the help page for seasons https://dyndolod.info/Help/Seasons#Out-of-Memory-errors:
In case this creates out of memory errors and/or high CPU usage, the number of simultaneously running LODGen process can be limited by setting MaxLODGen=x in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini.

[Arctic4161]

31 minutes ago, sheson said:

As already suggested, read the https://dyndolod.info/FAQ DynDOLOD/TexGen Questions High memory usage, which for example says this:
If too many concurrent LODGen processes running at the same time consume all available memory, limit their number by changing the MaxLODGen setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI.

It is also explained on the help page for seasons https://dyndolod.info/Help/Seasons#Out-of-Memory-errors:
In case this creates out of memory errors and/or high CPU usage, the number of simultaneously running LODGen process can be limited by setting MaxLODGen=x in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini.

Ah okay, thank you! I was not aware that the thread count was open to be adjusted via the ini. That's smart 

[Mousetick]

Understanding DynDOLOD.esm initially disabled large reference autofix.

The following example illustrates an instance of a large reference initially disabled by an ESM and automatically fixed by DynDOLOD in its ESM:

• I'm curious about the object being replaced with the WorshipperActivator, which is a simple invisible X Marker using a vanilla model unlikely to be replaced by a mod. I'm assuming this is done for dependability, efficiency and performance reasons. Even though these references are buried deep underground and can't be seen by the player, they're still enabled and their full model is still loaded in the extended large reference grid. So using a simplistic object instead of the original one is more efficient and consumes much fewer resources. Please correct me if I'm wrong.
• What are the exact criteria DynDOLOD uses to determine if this automatic fix can be applied?

Here is an example that is not automatically fixed:

• This reference is created and initially disabled by the same ESM plugin. It's not disabling an existing reference added by another ESM. It's declared as a large reference in that same ESM. No other plugin overwrites that reference. It's completely standalone.
• It's kinda weird. Its 'Enable Parent' field is set to PlayerRef, which means the reference is initially disabled, but then not really? I'm not sure what it's supposed to mean. Why not simply let it be enabled? Anyway, this is flagged by DynDOLOD as an 'initially disabled large reference' because it can't be fixed automatically.

Thanks.

 

[ozBillo]

** removed ** 

 

Edited March 27, 2022 by ozBillo
I didn't search first

[sheson]

8 hours ago, Mousetick said:

Understanding DynDOLOD.esm initially disabled large reference autofix.

The following example illustrates an instance of a large reference initially disabled by an ESM and automatically fixed by DynDOLOD in its ESM:

• I'm curious about the object being replaced with the WorshipperActivator, which is a simple invisible X Marker using a vanilla model unlikely to be replaced by a mod. I'm assuming this is done for dependability, efficiency and performance reasons. Even though these references are buried deep underground and can't be seen by the player, they're still enabled and their full model is still loaded in the extended large reference grid. So using a simplistic object instead of the original one is more efficient and consumes much fewer resources. Please correct me if I'm wrong.
• What are the exact criteria DynDOLOD uses to determine if this automatic fix can be applied?

Here is an example that is not automatically fixed:

• This reference is created and initially disabled by the same ESM plugin. It's not disabling an existing reference added by another ESM. It's declared as a large reference in that same ESM. No other plugin overwrites that reference. It's completely standalone.
• It's kinda weird. Its 'Enable Parent' field is set to PlayerRef, which means the reference is initially disabled, but then not really? I'm not sure what it's supposed to mean. Why not simply let it be enabled? Anyway, this is flagged by DynDOLOD as an 'initially disabled large reference' because it can't be fixed automatically.

Thanks.

 

The model is replaced so the full model does not have to be loaded and rendered.

The criteria is: is large reference, last overwrite record in ESM, is initially disabled, opposite enable parent player, z = -30000

No idea why that record is initially disabled or has the player as enable parent. It seems pointless, since it will be always enabled.

[blue321]

For some reason, some tree lods starts flickering. This happen around Whiterun. I dont see it happen anywhere else. Is there a solution to this? My dyndolod settings is set to high, i changed it to medium before but there is still some flickering. Back when I use Dyndolod 2.98, this doesnt happen. Only after I use Dyndolod 3, the tree lods started to flicker

[Aren]

Hello. I just upgraded to version 3.0 from 2.98 in an attempt to use this mod (as suggested in comments, version 2.x resulted in some missing billboard textures). After following the steps on the documentation, the mod seems to be working and my problem of missing texture is gone. However, I now have an issue with some other LODs as well, mostly trees. As you can see on the screens, some LODs quickly and completly disappear for about half a second when approaching, before reappearing as normal. This is annoying and gives an impression of constant flickering when moving. It's very noticeable in open spaces like Whiterun, and does not only affect the trees but some objects/rocks as well. Notice that it only affects close billboards, while the same ones in distant landscape stay in place.
 

Screens of the problem :

https://imgur.com/a/XBkN5oM
 

Thanks a lot for any help.

[sheson]

1 hour ago, Aren said:

Hello. I just upgraded to version 3.0 from 2.98 in an attempt to use this mod (as suggested in comments, version 2.x resulted in some missing billboard textures). After following the steps on the documentation, the mod seems to be working and my problem of missing texture is gone. However, I now have an issue with some other LODs as well, mostly trees. As you can see on the screens, some LODs quickly and completly disappear for about half a second when approaching, before reappearing as normal. This is annoying and gives an impression of constant flickering when moving. It's very noticeable in open spaces like Whiterun, and does not only affect the trees but some objects/rocks as well. Notice that it only affects close billboards, while the same ones in distant landscape stay in place.
 

Screens of the problem :

https://imgur.com/a/XBkN5oM
 

Thanks a lot for any help.

Read the first post which log and debug log to upload when making posts.

Test with a new game. If that fixes it, make sure to follow the instructions https://dyndolod.info/Updating and especially follow the clean save instructions https://dyndolod.info/Help/Clean-Save.

If it still happens with a new game, make sure that the DynDOLOD papyrus scripts are the latest version.
Either from the latest DynDOLOD Resources SE Alpha for PapyrusUtil or the latest DynDOLOD DLL scripts for DynDOLOD DLL.