DynDOLOD Beta for Skyrim Special Edition, Skyrim VR and Enderal SE 2.98

[DarthVitrial]

Oh, neat. Thanks. If there’s a way to donate to you I’d be happy to fund the purchase of said mod (or just as a way to thank you for the wonder that is dyndolod). Out of curiosity, what was “odd†about the nif? Is there some unique way it’s made that tools like nif optimizer should be aware of?

 

also, sorry if this is a stupid question but is there a difference between  the sselodgen included with dyndolod and the one included in the latest sseedit build?

Edited June 11, 2018 by DarthVitrial

[sheson]

Oh, neat. Thanks. If there’s a way to donate to you I’d be happy to fund the purchase of said mod (or just as a way to thank you for the wonder that is dyndolod). Out of curiosity, what was “odd” about the nif? Is there some unique way it’s made that tools like nif optimizer should be aware of?

 

also, sorry if this is a stupid question but is there a difference between  the sselodgen included with dyndolod and the one included in the latest sseedit build?

No need to worry abut funding. Donate to STEP or GamerPoets just because :)

 

Homestead contains a nif that has a NiNode root node instead of the usual BSFadeNode for such objects. It happens that enabling such a nif with the IsFullLOD flag causes CTD.

Changing the root node to BSFadeNode fixes that. In this particular case, DynDOLOD uses the nif as full model in static object LOD instead, which circumvents the problem altogether and is also better for performance.

 

For future troubleshooting, DynDOLOD 2.37 will mention NiNode used as root node in the log when it uses such a nif for dynamic LOD.

 

I bet you mean LODGen.exe/LODGenx64.exe which is not to be confused with xLODGen/TES5LODGen/SSELODGen and its special version DynDOLOD. Yeah I know we probably should have used somewhat better naming conventions...

 

In any case, there is only one LODGen.exe/LODGenx64.exe. Whatever tool/archive is the most recent upload has typically the latest version of it. 2.1.7 is the current build.

Newer versions of LODGen.exe/LODGenx64.exe however maybe incompatible with older versions of xLODGen. Typically its best to use the version shipped with the main tool xLODGen/DynDOLOD.

Edited June 11, 2018 by sheson

[DarthVitrial]

Thanks for the detailed explanations! Is the NiNode thing an engine bug (ie something that could potentially be fixed by sse engine fixes) or working as intended and just being used incorrectly by homestead and/or the older dyndolod?

[sheson]

Thanks for the detailed explanations! Is the NiNode thing an engine bug (ie something that could potentially be fixed by sse engine fixes) or working as intended and just being used incorrectly by homestead and/or the older dyndolod?

I am not sure if the same issue exists in the old Skyrim which would indicate that this "normal" behavior. There were a like a couple cases with mods were enabling IsFullLOD NIFs caused CTD, but I just ignored those models and never really looked into the cause. It could have been the same or something else entirely. The models display fine in nifskope and work in the game if used normally.

 

The default root node for all vanilla world models (with collision/Havok) seems to be BSFadeNodes and the game does not really enable/disable that many references with the IsFullLOD flag anyways. So NiNode probably only happen with older (3DSMax?) export plugin or when manually doing NIFs in nifskope.

 

In any case, the root node of a NIF is easily converted with niskope with a right click, Block, Convert, so trying to fix this in the engine seems more trouble than it is worth.

[alt3rn1ty]

Just noticed new DynDOLOD and resources beta - Grabbed and will be testing

[alt3rn1ty]

@Sheson

 

Has something changed with regards to the Output Path?

 

I usually use a desktop icon which has the following in the Icon properties target

 

D:\DynDOLOD\DynDOLOD.exe -SSE -o:D:\1-DynDOLOD-Out\

 

But my first run of 2.37 via the same icon has output to its own directory instead in ..

 

D:\DynDOLOD\DynDOLOD_Output\ <-- All folders / files (meshes and textures etc) end up in here

 

So it has ignored the icon output path -o:D:\1-DynDOLOD-Out\

[sheson]

@Sheson

 

Has something changed with regards to the Output Path?

 

I usually use a desktop icon which has the following in the Icon properties target

 

D:\DynDOLOD\DynDOLOD.exe -SSE -o:D:\1-DynDOLOD-Out\

 

But my first run of 2.37 via the same icon has output to its own directory instead in ..

 

D:\DynDOLOD\DynDOLOD_Output\

 

So it has ignored the icon output path -o:D:\1-DynDOLOD-Out\

It seems so, but that was unintentional. I will check what happened.

 

Once you set a output path in the interface and generated LOD it will remember next time it loads.

 

 

Edit: DynDOLOD Standalone 2.37 beta 1 restores the old behavior by using -o until the preset is saved.

Edited June 11, 2018 by sheson

[DarthVitrial]

One minor thing I'm wondering about. It's not possible to open DyndoLod .esm in SSEEdit if you have Homestead, because DynDOLOD requires hstead.esm to be loaded first but SSEEdit always loads DyndoLOD before hstead.esm.  Do you have any recommendations?

[sheson]

One minor thing I'm wondering about. It's not possible to open DyndoLod .esm in SSEEdit if you have Homestead, because DynDOLOD requires hstead.esm to be loaded first but SSEEdit always loads DyndoLOD before hstead.esm.  Do you have any recommendations?

Until xEdit is updated, you can open such a load order by temporary "removing" CC plugins from Skyrim.ccc (text file in game folder) by adding an x in front of the filename. When done editing restore correct filename, so game knows again to load the CC plugins right after DLC.

Edited June 12, 2018 by sheson

[mtreis86]

Thanks for the update.

 

I am not seeing any bruma lods in the output, have they been removed?

Edited June 12, 2018 by mtreis86

[dcads]

Ditto with the Bruma.  In the world selection BSHeartland.esm is not listed.  I have tested this using 2.36 - BSHeartland is there and 2.37 where it is missing.

 

I tried copying across the BSHeartland file from 2.36's Exports folder, but guess I am also missing something else?

[sheson]

Thanks for the update.

 

I am not seeing any bruma lods in the output, have they been removed?

Ditto with the Bruma.  In the world selection BSHeartland.esm is not listed.  I have tested this using 2.36 - BSHeartland is there and 2.37 where it is missing.

 

I tried copying across the BSHeartland file from 2.36's Exports folder, but guess I am also missing something else?

See the update post https://forum.step-project.com/topic/12479-dynamic-distant-objects-lod-dyndolod-237/ and check what it says about Bruma

 

See the FAQ: Not seeing all worlds in the selection box

[dcads]

See the update post https://forum.step-project.com/topic/12479-dynamic-distant-objects-lod-dyndolod-237/ and check what it says about Bruma

 

See the FAQ: Not seeing all worlds in the selection box

Thanks Sheson.  Stupidly when I was trying to self help, I edited the TES 5 ignore file and not SSE. Duh!

[KorruptkSwades]

Hello I found ""LODGen.exe - catch an error in nif and print its name to log"" in the changelog. I enable the Debug setting in json worlds and my papyrus logging. I have been getting CTDs from what i think is a bad mesh and hoped this would help me find it. But when i look at the papyrus log i can't seem to find where DynDOLOD wrote the bad mesh ?

[sheson]

Hello I found ""LODGen.exe - catch an error in nif and print its name to log"" in the changelog. I enable the Debug setting in json worlds and my papyrus logging. I have been getting CTDs from what i think is a bad mesh and hoped this would help me find it. But when i look at the papyrus log i can't seem to find where DynDOLOD wrote the bad mesh ?

LODGen.exe is a command line program that geenrated object LOD meshes. It is spawned by DynDOLOD.exe. It writes its output to the ..DynDOLOD\Logs\ folder. The DynDOLOD log itself will print a message if a LODGen log had errors at generation time or if it completed without errors.

 

It is an additional error message that helps determining the cause of incomplete object LOD generation.

 

The debug option for the papyrus scripting exist much longer already and is part of the troubleshooting steps explained in the ..DynDOLOD\Docs\DynDOLOD-README.txt - which also explains in great detail what log messages in the papyrus log to look for.

Edited June 12, 2018 by sheson