DynDOLOD 3.00 Alpha 180

[ni1by2]

8 minutes ago, sheson said:

Speechless at 424GB. That probably means more than 100GB for the default season. That is probably the result of full models used for LOD and/or insane settings for lots of full grass. How is the game performing after doing something like this?

LODGen generates object LOD meshes. Executing LODGen will overwrite the existing ones of the selected worldspace and seasons in generates. That is actually what you want.

well.. crap. Like I said, I used the STEP settings from here (Grass) and here (DynDOLOD). I don't know enough to muck about with those settings. I haven't actually tried to play with them. Could the size not be a function of 25 worldspaces with the majority having seasons?

Yeah, I worked out too late that I needed to run Execute LODGen, so tried to restart, but well, see above post - I am not being allowed to select the original output folder for the new run. Any ideas?

Edited May 3 by ni1by2

[sheson]

17 minutes ago, ni1by2 said:

well.. crap. Like I said, I used the STEP settings from here (Grass) and here (DynDOLOD). I don't know enough to muck about with those settings. I haven't actually tried to play with them. Could the size not be a function of 25 worldspaces with the majority having seasons?

Yeah, I worked out too late that I needed to run Execute LODGen, so tried to restart, but well, see above post - I am not being allowed to select the original output folder for the new run. Any ideas?

The settings of modding guide like STEP typically apply to their specific list of used mods.

If you check the folder size of the different worldspaces, I would expect it to show that the largest chunk by far is usually the Tamriel worldspace.
You can check how long object LOD generation time with LODGen took by checking the logfiles - if it was successful. You uploaded LODGen_SSE_Tamriel_SPR_log.txt, which took 01:47:22. I would expect LODGen_SSE_Tamriel_log.txt took the longest. I would be somewhat curious if that is the case here.

What does not being allowed mean? What is the problem or error message?

You can simply copy or move the generated LOD meshes after geenration, where you need them to be, e.g. the MO2 mod folder where you already installed the output form the generation where the two LODGen processes failed. Just overwrite the existing *.BTO files.

[ni1by2]

18 minutes ago, sheson said:

The settings of modding guide like STEP typically apply to their specific list of used mods.

If you check the folder size of the different worldspaces, I would expect it to show that the largest chunk by far is usually the Tamriel worldspace.
You can check how long object LOD generation time with LODGen took by checking the logfiles - if it was successful. You uploaded LODGen_SSE_Tamriel_SPR_log.txt, which took 01:47:22. I would expect LODGen_SSE_Tamriel_log.txt took the longest. I would be somewhat curious if that is the case here.

What does not being allowed mean? What is the problem or error message?

You can simply copy or move the generated LOD meshes after geenration, where you need them to be, e.g. the MO2 mod folder.

Thanks, I think we crossed messages, I will copy over the files to the original output folder.

18 minutes ago, sheson said:

What does not being allowed mean? What is the problem or error message?

It just says:

<Error: Path not allowed E:\Purush\tools\DynDOLOD\DynDOLOD_Output\>
Resetting not allowed path to E:\Purush\tools\DynDOLOD\DynDOLOD_Output\

The CLI window that opens also shows that the files are being written to the new folder which I want to change back from

18 minutes ago, sheson said:

. I would expect LODGen_SSE_Tamriel_log.txt took the longest. I would be somewhat curious if that is the case here.

I have uploaded that file to the google drive folder. It uhh... I think it says it took ~12 hours?

 

 

Once I finish Tamriel SUM I will compress and install and see how the game plays and report back

Edited May 3 by ni1by2

[sheson]

44 minutes ago, ni1by2 said:

Thanks, I think we crossed messages, I will copy over the files to the original output folder.

It just says:

<Error: Path not allowed E:\Purush\tools\DynDOLOD\DynDOLOD_Output\>
Resetting not allowed path to E:\Purush\tools\DynDOLOD\DynDOLOD_Output\

The CLI window that opens also shows that the files are being written to the new folder which I want to change back from

I have uploaded that file to the google drive folder. It uhh... I think it says it took ~12 hours?

Once I finish Tamriel SUM I will compress and install and see how the game plays and report back

But it still seems to use that path and it is the same the first session was generated to?

Are there any other files in that folder other than the DyDOLOD.esm, DynDOLOD.esp, Occlusion.esp and the meshes, skse and texture folders?

[The_Franks]

12 hours ago, sheson said:

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.

That must be it then.  I checked my prefs ini and fBlockMaximumDistance is set to 102500, and not maxdistance. I am going to check that out and I bet that's the answer. Confirmed. That was it. Statue and college now appear from everywhere, including the world map. You're a legend. That only leaves one last thing, and it is not a big deal, but it is a big hole.

  

There is this occlusion hole in a Morrowind mountain that the player character cannot even get near. It will disappear for a moment while on the road out of Winterhold, but the reappear 10 steps south again, and I have confirmed that loading the game without the occlusion.esp will make the hole go away, so I think it must be occlusion related. It is only visible from Winterhold and the surrounding waters. Like I said, it's not like I can go there, so it not a big deal, but it is the last thing.  This has been a persitent thing, so the logs I already sent may have some idea why it is there. Thanks again.

[sheson]

On 5/3/2024 at 7:34 PM, The_Franks said:

That must be it then.  I checked my prefs ini and fBlockMaximumDistance is set to 102500, and not maxdistance. I am going to check that out and I bet that's the answer. Confirmed. That was it. Statue and college now appear from everywhere, including the world map. You're a legend. That only leaves one last thing, and it is not a big deal, but it is a big hole.

 

There is this occlusion hole in a Morrowind mountain that the player character cannot even get near. It will disappear for a moment while on the road out of Winterhold, but the reappear 10 steps south again, and I have confirmed that loading the game without the occlusion.esp will make the hole go away, so I think it must be occlusion related. It is only visible from Winterhold and the surrounding waters. Like I said, it's not like I can go there, so it not a big deal, but it is the last thing.  This has been a persitent thing, so the logs I already sent may have some idea why it is there. Thanks again.

"maxdistance" is not a valid value for fBlockMaximumDistance. It requires a floating point number to be set. In case of invalid settings it will most likely revert to some internal default number. See https://stepmodifications.org/wiki/Guide:SkyrimPrefs_INI/TerrainManager#fBlockMaximumDistance

Did you generate terrain LOD with xLODGen? Was one of the restored terrain plugins like SSE-Terrain-Tamriel-Extend.esm installed?

https://dyndolod.info/Help/xLODGen#Requirements

[ni1by2]

1 hour ago, sheson said:

But it still seems to use that path and it is the same the first session was generated to?

Are there any other files in that folder other than the DyDOLOD.esm, DynDOLOD.esp, Occlusion.esp and the meshes, skse and texture folders?

So in the image, the Output folder is listed as MO2\tools\Dyndolod\Dyndolod_output. That's the folder where the output from my first run went. I changed that to another folder outside MO2, called testoutput. After working out how Execute Lodgen works, I tried to change the output folder back from testoutput to the first one, and that's when I got the error message.

No, there isn't anything other than the folders and the esm and esps.

The testoutput folder now has Meshes, Seasons, SKSE, and tesxtures folders, as well as Dyndolod.esm, Dyndolod.esp and Occlusion.esp, all generated from running Execute Lodgen for just Tamriel SUM. Do i copy this all back into MO2\tools\Dyndolod\Dyndolod_Output, where the rest of the worldspaces are? Both folders and files? Or folders only?

Edited May 3 by ni1by2

[sheson]

2 minutes ago, ni1by2 said:

So in the image, the Output folder is listed as MO2\tools\Dyndolod\Dyndolod_output. That's the folder where the output from my first run went. I changed that to another folder outside MO2, called testoutput. After working out how Execute Lodgen works, I tried ti change the folder back from testoutput to the first one, and that's when I got the error message.

The testoutput folder now has Meshes, Seasons, SKSE, and tesxtures folders, as well as Dyndolod.esm, Dyndolod.esp and Occlusion.esp, all generated from running Execute Lodgen for just Tamriel SUM. Do i copy this all back into MO2\tools\Dyndolod\Dyndolod_Output, where the rest of the worldspaces are? Both folders and files? Or folders only?

Instead of screenshotting text, copy and paste the text if possible, upload the entire log and debug log etc.

The problem here is that MO2 is installed into E:\Purush\ and that despite the installation instructions being clear about not installing DynDOLOD into mod manager folder, it is being installed in to a subfolder of MO2. That is why you see the message about the output folder being not allowed, but the tool not having a choice to use its default output folder in its own subfolder. 

In any case, if you click the "Execute xLODGen" button, then the only thing that is being generated is BTO object LOD meshes to the meshes\terrain\.. folder. As I wrote, once that completes, close DynDOLOD via the Cancel button or the X top right.

Doing so will not generate any plugins, SKSE folder or textures. If you got any of those, you did something else in addition to clicking "Execute LODGen".

I suggest to delete testoutput. Then start DynDOLOD in expert mode, make sure the the new output folder is empty. Select desired worldspaces and seasons, click the  Execute LODGen button., wait for all spawned LODGen processes/command prompt windows to finish and then click the Cancel button or the X top right to close DynDOLOD. Then you should only have the meshes folder in the new output folder. Merge it with the existing output, overwrite all already existing BTO files with the new ones. Install result as a mod.

[The_Franks]

On 5/3/2024 at 8:10 PM, sheson said:

"maxdistance" is not a valid value for fBlockMaximumDistance. It requires a floating point number to be set. In case of invalid settings it will most likely revert to some internal default number. See https://stepmodifications.org/wiki/Guide:SkyrimPrefs_INI/TerrainManager#fBlockMaximumDistance

Did you generate terrain LOD with xLODGen? Was one of the restored terrain plugins like SSE-Terrain-Tamriel-Extend.esm installed?

https://dyndolod.info/Help/xLODGen#Requirements

Yes, I did generate terrain lod with xlodgen with that exact mod installed. My map is giantic now, which is cool. I can always run it again, because I did run it since then to bump up the lod4 texture quality, but had that mod turned off in the list to save time. I assume I will need to regenerate the occlusion data after that. Should I just do that with xlodgen at the same time?

Edit: That was it. I reactivated SSE_Terrain-Tamriel-Extended.esm, reran xlod gen for tamriel, deleted the esm, reran dyndolod for occlusion only and the hole is gone. Thank you. 

[Farsveinn]

Logs.7z DynDOLOD - Fix.7z

 

Hi. This is probably going to be funny, but the problem is back. I updated DynDOLOD to the latest version and put your fixed meshes. But this waterfall is flickering again (static only! 1 screenshot). I don't want to distract you anymore, which parameter in the nif is responsible for this so I can experiment. With fly cam everything is great, but that's probably how it should be.

Edited May 5 by Farsveinn

[sheson]

49 minutes ago, Farsveinn said:

Logs.7z 311.92 kB · 0 downloads DynDOLOD - Fix.7z

 

Hi. This is probably going to be funny, but the problem is back. I updated DynDOLOD to the latest version and put your fixed meshes. But this waterfall is flickering again (static only! 1 screenshot). I don't want to distract you anymore, which parameter in the nif is responsible for this so I can experiment. With fly cam everything is great, but that's probably how it should be.

You need to rename 

..\Meshes\DynDOLOD\lod\effects\fxwaterfallbodytall02_dyndolod_lod.nif to fxwaterfallbodytall02_1af8a0c0_dyndolod_lod.nif
..\Meshes\lod\waterfalls\fxwaterfallbodytall02passthru_lod.nif to fxwaterfallbodytall02_1af8a0c0passthru_lod.nif
and make sure they overwrite the ones in DynDOLOD Resources SE.

Then "Execute LODGen" in expert mode for Tamriel to update the static object LOD meshes.

[Phlunder]

What are the requirements for LOD meshes to be recognized for glow/own emit? I've gone through the DynDOLOD info page about glow LOD, but its not what I am referring to in this case. I am trying to make resources for the larger Blackreach crystals. This worked fine for the Blackreach mushrooms, they are automatically added to the DynDOLOD_Blackreach_Glow atlas and also get the shader properties for glow. Somehow the crystals are ignored, even though they have exactly the same shader settings as the mushrooms. But maybe I missed something. If you have the time, its about blackreachcrystall01-05, wip resources are here.

[Farsveinn]

Now it's having the opposite effect. Flickering at a great distance is gone, but it appeared at the waterfalls highlighted in the console. 

[sheson]

22 minutes ago, Farsveinn said:

Now it's having the opposite effect. Flickering at a great distance is gone, but it appeared at the waterfalls highlighted in the console. 

The delete ..\Meshes\DynDOLOD\lod\effects\fxwaterfallbodytall02_dyndolod_lod.nif and its renamed copy fxwaterfallbodytall02_1af8a0c0_dyndolod_lod.nif so it uses the one from DynDOLOD Resources again. No need to run DynDOLOD.

[sheson]

49 minutes ago, Phlunder said:

What are the requirements for LOD meshes to be recognized for glow/own emit? I've gone through the DynDOLOD info page about glow LOD, but its not what I am referring to in this case. I am trying to make resources for the larger Blackreach crystals. This worked fine for the Blackreach mushrooms, they are automatically added to the DynDOLOD_Blackreach_Glow atlas and also get the shader properties for glow. Somehow the crystals are ignored, even though they have exactly the same shader settings as the mushrooms. But maybe I missed something. If you have the time, its about blackreachcrystall01-05, wip resources are here.

The crystals set a parallax shader and not a glow shader. Parallax shaders are not supported by LOD and thus converted to the default shader.

You can try to rename files to *passthru_lod.nif so all their shaders are (mostly) kept as is but the outcome may not work or look satisfactory.
Otherwise change the shader type to glow shader I suppose.

If only a specific shape/shader in a NIF needs that while the other can be set to proper LOD settings, add PassThru to the shape name.

I suggest to use LOD levels in the filename. Just the highest level they should appear in, which in case of small crystals should be Level 4 = *_lod_0.nif and in case of the tall mushrooms Level 8 = *_lod_1.nif and Map/Level 16 = _lod_2.nif.

The big epic mushroom could use a version without CoreGlow:17 for the higher LOD Levels. I would probably even remove Core:Glow:16 for LOD Level 16 since it is unlikely to be seen from below and also remove the branches without heads in a 3D editor. This is in case it is used by a mod in bigger worldspaces.

Just *_lod.nif means the model is applied to all 3 LOD levels and is almost as bad as mods duplicating the same NIF 3 times as _0, _1, _2.

Maybe you planed that all along, just making sure.