DynDOLOD 3.00 Alpha 190

[sheson]

  On 3/23/2022 at 12:10 AM, DankTemplar said:

Newest version of Dyndolod 3 alpha has solved my "out of memory issues" so far. Whatever you did Sheshon, it worked! Thanks for the update!

Expand  

The promised logs and no concrete information about the what and when were provided, nothing was or could be done.

The https://dyndolod.info/Changelog explains what was fixed or changed.

[NephilimOokami]

I am having a bug that some parts of the terrain(in some locations) has no textures at all(can walk in the air)

Attached is one of the cells that this happen.

Edited March 23, 2022 by NephilimOokami

[sheson]

  On 3/23/2022 at 4:37 PM, NephilimOokami said:

I am having a bug that some parts of the terrain(in some locations) has no textures at all(can walk in the air)

Attached is one of the cells that this happen.

Expand  

https://dyndolod.info

"Dynamic Distant Objects LOD (DynDOLOD) is the advanced and easier version of xLODGen to generate a comprehensive LOD mod for the entire load order of the different Skyrim and Enderal game versions for drastically enhanced and better matching tree LOD and object LOD plus optional dynamic LOD, glow LOD, grass LOD, occlusion data and terrain underside in a few simple steps."

DynDOLOD does not generate or affects terrain LOD in any way.

Wherever the player walks, is active cells. They do not show any LOD. DynDOLOD does not affect terrain in loaded cells.

The DynDOLOD SkyUI MCM - You Are Here page shows the current player position and calculates the cell coordinates and LOD filenames based on that.
What is the purpose of posting that screenshot?

Why do you believe the problem has something to do with the DynDOLOD output?

[NephilimOokami]

  On 3/23/2022 at 4:48 PM, sheson said:

https://dyndolod.info

"Dynamic Distant Objects LOD (DynDOLOD) is the advanced and easier version of xLODGen to generate a comprehensive LOD mod for the entire load order of the different Skyrim and Enderal game versions for drastically enhanced and better matching tree LOD and object LOD plus optional dynamic LOD, glow LOD, grass LOD, occlusion data and terrain underside in a few simple steps."

DynDOLOD does not generate or affects terrain LOD in any way.

Wherever the player walks, is active cells. They do not show any LOD. DynDOLOD does not affect terrain in loaded cells.

The DynDOLOD SkyUI MCM - You Are Here page shows the current player position and calculates the cell coordinates and LOD filenames based on that.
What is the purpose of posting that screenshot?

Why do you believe the problem has something to do with the DynDOLOD output?

Expand  

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?

Edited March 23, 2022 by NephilimOokami

[sheson]

  On 3/23/2022 at 9:52 PM, 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?

Expand  

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]

  On 3/24/2022 at 6:06 AM, sheson said:

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

Expand  

Thanks for the guidance

[sheson]

  On 3/24/2022 at 8:50 AM, 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.

Expand  

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]

  On 3/26/2022 at 12:43 AM, 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.

Expand  

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]

  On 3/26/2022 at 9:30 AM, 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. 

Expand  

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]

  On 3/26/2022 at 6:04 PM, 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.

Expand  

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]

  On 3/26/2022 at 6:24 PM, 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.

Expand  

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