DynDOLOD 3.00 Alpha 173

[Admiral30]

4 hours ago, sheson said:

Do not post screenshots of text. Post the text/log instead.

Why is using 100% CPU a problem?

Let the OS handle virtual memory with default settings.

Set OcclusionMaxThreadsObjectLOD=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini as explained at https://dyndolod.info/Help/Occlusion-Data

Start DynDOLOD with  -memory command line argument.

If none of this helps, generate only Occlusion in a separate session.

I already did set occlusion threads and it changed nothing. Adding -memory command doesn't fix it either.

I will try generating it in two steps, I have no idea how but I will figure it out.

As I said before it worked fine before (alpha 70 or 71), so something is clearly wrong with alpha 73.

[sheson]

1 hour ago, Admiral30 said:

I already did set occlusion threads and it changed nothing. Adding -memory command doesn't fix it either.

I will try generating it in two steps, I have no idea how but I will figure it out.

As I said before it worked fine before (alpha 70 or 71), so something is clearly wrong with alpha 73.

You are not the only user using DynDOLOD or generating Occlusion. There usually would be several reports within hours of the release.
Nothing changed in occlusion generation code since Alpha-71 fixed slow reading of BTO.

Most likely something changed in the load order or settings requiring more memory beforehand (e.g. larger BTO files because of 3D tree or grass LOD) or maybe the system has less memory to give.

[Admiral30]

14 minutes ago, sheson said:

You are not the only user using DynDOLOD or generating Occlusion. There would be several reports within hours of the release.
Nothing changed in occlusion generation code since Alpha-71 fixed slow reading of BTO.

Most likely something changed in the load order or settings requiring more memory beforehand (e.g. larger BTO files because of 3D tree or grass LOD) or maybe the system has less memory to give.

I have generated LOD with occlusion disabled, moved it to MO2 but didn't enable it, then used DynDOLOD again with only occlusion enabled (according to manual), and it works fine.

No idea why it happens, it isn't even reaching more than 70% of RAM usage, and I had WAY heavier load order before and it worked fine on earlier versions.

But in the end it works again, just one more step instead. Thanks for help, hopefully it will be accidentally fixed in alpha 74+.

[sheson]

11 minutes ago, Admiral30 said:

I have generated LOD with occlusion disabled, moved it to MO2 but didn't enable it, then used DynDOLOD again with only occlusion enabled (according to manual), and it works fine.

No idea why it happens, it isn't even reaching more than 70% of RAM usage, and I had WAY heavier load order before and it worked fine on earlier versions.

But in the end it works again, just one more step instead. Thanks for help, hopefully it will be accidentally fixed in alpha 74+.

If you do not enable the generated LOD for separate occlusion generation, it reads the object LOD that is available in the load order. Most likely vanilla object LOD which typically will have less details e.g. smaller files size.

Typically the generated LOD should be enabled, so its changes are taken into account for occlusion generation.

[Admiral30]

9 minutes ago, sheson said:

If you do not enable the generated LOD for separate occlusion generation, it reads the object LOD that is available in the load order. Most likely vanilla object LOD which typically will have less details e.g. smaller files size.

Typically the generated LOD should be enabled, so its changes are taken into account for occlusion generation.

I see. I have disabled it because DynDOLOD showed warning that output will be overriden (which technically I don't want, I just need separate occlusion.esp).

[sheson]

15 minutes ago, Admiral30 said:

I see. I have disabled it because DynDOLOD showed warning that output will be overriden (which technically I don't want, I just need separate occlusion.esp).

There won't be any changes to the existing DynDOLOD plugins if they are loaded and if you just select Occlusion and Plugin while  unchecking all other options - object, tree, dynamic, underside .

It should only save the new Occlusion.esp and no DynDOLOD plugins in that case. Despite the message about updating existing plugins.

Though if they are updated, it should work just all the same.

[SparklingSliver]

2 hours ago, sheson said:

Clean dirty plugins with deleted references, like Kynes Hunt - Quest for Chanterelle.esp, mini gardens.esp, stonhenge + hilltops.esp, NoBrokenWhiterunTower.esp, True Forest of riverwood.esp etc. https://dyndolod.info/Messages/Deleted-Reference

Fix or remove broken plugins with HITME errors like loftattic.esp  https://dyndolod.info/Messages/Internal-File-FormID-Is-A-HITME

Fix Unresolved FormID errors in loftattic.esp  https://dyndolod.info/Messages/Unresolved-Form-ID

Fix/remove duplicate worldspace problem with Undriel_FallingGildergreenPetals.esp. Might be a botched conversion to light plugin.

Use latest version of Flying Crows SSE 1.2 that does not contain meshes\crow\flyingcrow_lod.nif but contains mesh rule INI for DynDOLOD.

If the problem still happens afterwards, upload new bugreport, log and debug log.

I did everything you said and now it works! Thank you so much!!

[Admiral30]

1 hour ago, sheson said:

There won't be any changes to the existing DynDOLOD plugins if they are loaded and if you just select Occlusion and Plugin while  unchecking all other options - object, tree, dynamic, underside .

It should only save the new Occlusion.esp and no DynDOLOD plugins in that case. Despite the message about updating existing plugins.

Though if they are updated, it should work just all the same.

Keeping dyndolod output enabled again triggers out of memory errors. Unfortunately I'm forced to rollback to previous version for the time being.

[sheson]

11 minutes ago, Admiral30 said:

Keeping dyndolod output enabled again triggers out of memory errors. Unfortunately I'm forced to rollback to previous version for the time being.

Compare total size of the BTOs for the worldspace.

[Admiral30]

10 minutes ago, sheson said:

Compare total size of the BTOs for the worldspace.

I require explanation.

[sheson]

13 minutes ago, Admiral30 said:

I require explanation.

Compare the size of the folder ..\Meshes\Terrain\Tamriel\Objects\ which contains the object LOD *.bto files between old and new output.

[Admiral30]

19 minutes ago, sheson said:

Compare the size of the folder ..\Meshes\Terrain\Tamriel\Objects\ which contains the object LOD *.bto files between old and new output.

I have only one output atm and it's 3.46 GB.

I also have a backup of older output (the one with glitched waterfalls) and it's also 3.46 GB.

There is also possibility that arguments are incorrectly set

Edited February 19, 2022 by Admiral30

[sheson]

17 minutes ago, Admiral30 said:

I have only one output atm and it's 3.46 GB.

I also have a backup of older output (the one with glitched waterfalls) and it's also 3.46 GB.

There is also possibility that arguments are incorrectly set

Did you notice less CPU / peak memory usage while "Updating height map from object LOD meshes" after setting OcclusionMaxThreadsObjectLOD=1?

[Admiral30]

8 minutes ago, sheson said:

Did you notice less CPU / peak memory usage while "Updating height map from object LOD meshes" after setting OcclusionMaxThreadsObjectLOD=1?

CPU is almost constantly 100%, memory 30-70%. I have 16GB, I was thinking about getting another 16, but not because of DynDOLOD.

Edited February 19, 2022 by Admiral30

[sheson]

12 minutes ago, Admiral30 said:

CPU is almost constantly 100%, memory 30-70%. I have 16GB, I was thinking about getting another 16, but not because of DynDOLOD.

Check the peak working set with task manager.

We would expect CPU usage  of DynDOLOD.exe to not be 100% with only one thread reading object LOD.

Check if there is any actual difference to the default OcclusionMaxThreadsObjectLOD=4