DynDOLOD 3.00 Alpha 173

[sheson]

24 minutes ago, drift123 said:

So to be clear, the grass "pre-cache" is referring to the file generation using the MO2 plugin that launches Skyrim and crashes then relaunches Skyrim and outputs the CGID files?

Whereas the grass "cache" is the grass LOD output the Dyndolod creates? Or are the pre-cache and cache synonymous? As I understand it both the LOD grass and full grass are cached for better performance compared to the vanilla loading technique.

I have Superdense grass set to false and Dyndolod mode to 1 in the grass control .ini for No Grass In Objects mod. I'm only rendering full grass in the 5x5 loaded cell but it was still a heavy performance hit. I'm aware that I can lower the grass density in Dyndolod and lower the billboard quality in TexGen. Is there any performance reason to regenerate the CGID pre-cache files if SuperDenseGrass was false and the load order is the same?

cache = precache = the files in the ..\data\grass\ folder generated by NGIO.

https://dyndolod.info/Help/Grass-LOD
Grass LOD uses grass LOD billboards in object LOD, similar to ultra tree LOD. [..] Grass LOD is generated for LOD level 4 only.
Grass LOD generation requires a warmed (current) grass precache for the current load order. It uses the *.CGID files found in the ..\Data\Grass\ folder.

If you do not change any settings that affect the data in the cache, like changing the filenames of full grass models, the number of full grasses per landscape texture or the density full grass, then there is no need to generate the grass cache again, as it will be more or less the same.

[Jonado]

On 6/3/2024 at 9:23 AM, sheson said:

It is correct. The screenshotted reference xx00C938 using Meshes\jk's blue palace\sbluepalacegate.nif also has Meshes\jk's blue palace\sbluepalacegate.nif in the BTO because of that mesh mask rule. The full model gate can be seen in the BTO. That reference is not involved in the issue you are seeing. As I suspected, I found the different reference to be xx5A004B in BluePalaceTerrace.esp. That is the one that is being replaced to a completely different model because of sos_seasons_vigilant_win.ini defines that swap.

You can look up these references (BA00C938 and 325A004B) in the export file LODGen_SSE_Export_Tamriel_WIN.txt to see which reference uses which LOD model in the BTO in the end.

There was a typo in SoS_Seasons_Vigilant_WIN.ini, but I didn't notice because SoS_Seasonspatch_WIN.ini is taking priority on my build. I would have expected that at least one of the 10,000 people who have downloaded the mod would have noticed it and reported the bug, but apparently not. I have updated the mod now with a fix.

On 6/3/2024 at 9:23 AM, sheson said:

I got confused with Base Object Swapper. Seasons INIs can have any file name and DynDOLOD does load them alphabetically (can be checked in the debug log). So "zzzConfig wins over aaaConfig". The problem is that SOS treats the filenames case sensitive while xEdit - like Windows - by default does not. For example, a is loaded after B by SOS. I will address that in the next alpha (including making sure the underscore sorts the same way - its after uppercase but before lowercase usually)

Thanks for the clarification. I was a bit scared when you said you were using load order for determining priority rules, since that could have caused a lot of mismatches for other types of objects (like trees). But isn't Base Object Swapper also sorting alphabetically? It isn't documented, but I assumed that was the case, which is also what I have experienced during my testing. And are you sure about the case sensitivity? It sounds weird to me that a would load after B.

Edited June 4 by Jonado

[drift123]

1 hour ago, sheson said:

If you do not change any settings that affect the data in the cache, like changing the filenames of full grass models, the number of full grasses per landscape texture or the density full grass, then there is no need to generate the grass cache again, as it will be more or less the same.

Does that include these settings?

NGIO:
Ensure-max-grass-types-setting = 15
Overwrite-min-grass-size = -1

Veydosebrom:
iMaxGrassTypesPerTexure=15
iMinGrassSize=20

I have good performance with full grass at the default Veydosebrom ini settings above (in the loaded 5x5 cell), so I used these settings to generate the CGID cache files. I'm going to try non-HD grass billboards and a lower density setting in Dyndolod, but not sure if these specific ini settings for the grass cache are relevant to grass LOD performance.

[sheson]

7 hours ago, Jonado said:

There was a typo in SoS_Seasons_Vigilant_WIN.ini, but I didn't notice because SoS_Seasonspatch_WIN.ini is taking priority on my build. I would have expected that at least one of the 10,000 people who have downloaded the mod would have noticed it and reported the bug, but apparently not. I have updated the mod now with a fix.

Thanks for the clarification. I was a bit scared when you said you were using load order for determining priority rules, since that could have caused a lot of mismatches for other types of objects (like trees). But isn't Base Object Swapper also sorting alphabetically? It isn't documented, but I assumed that was the case, which is also what I have experienced during my testing. And are you sure about the case sensitivity? It sounds weird to me that a would load after B.

Yes you are correct, both BOS and DynDOLOD also sort the BOS INIs alphabetical. Same issue with the case sensitivity though - that I double checked with the logs. So that will be fixed as well. 

[sheson]

6 hours ago, drift123 said:

Does that include these settings?

NGIO:
Ensure-max-grass-types-setting = 15
Overwrite-min-grass-size = -1

Veydosebrom:
iMaxGrassTypesPerTexure=15
iMinGrassSize=20

I have good performance with full grass at the default Veydosebrom ini settings above (in the loaded 5x5 cell), so I used these settings to generate the CGID cache files. I'm going to try non-HD grass billboards and a lower density setting in Dyndolod, but not sure if these specific ini settings for the grass cache are relevant to grass LOD performance.

Ensure-max-grass-types-setting changes number of full grasses per landscape texture. Overwrite-min-grass-size changes density of full grass.

As explained by NGIO, the above settings overwrite iMaxGrassTypesPerTexure and iMinGrassSize in the Skyrim/mod INI.

Changing these settings changes full grass amount and density, so the positions. So the cache and the LOD should be updated to reflect those changes.

[MitchBandito]

Hi,

I'm here because I'm a little bit desperate... The new update of No grass in object for AE is amazing, I have beautiful grass LODs but now I have a new problem...

I will try to explain it. You can see grass LOD in the distance but the loaded grass near the player is fading before disappearing completely when walking away. Please watch the video for more details.

May someone help me please, it makes me have nightmares.

 

[sheson]

17 minutes ago, MitchBandito said:

Hi,

I'm here because I'm a little bit desperate... The new update of No grass in object for AE is amazing, I have beautiful grass LODs but now I have a new problem...

I will try to explain it. You can see grass LOD in the distance but the loaded grass near the player is fading before disappearing completely when walking away. Please watch the video for more details.

May someone help me please, it makes me have nightmares.

DynDOLOD does not do anything to full grass. Set the appropriated settings in NGIO GrassControl.config.txt to control full grass and its max render distance.

https://dyndolod.info/Help/Grass-LOD
With No Grass In Objects full grass can be rendered past the active cells, so Grass LOD can either start right beyond the active exterior cells (uGridsToLoad), which has better for performance - or beyond the large reference distance (uLargeRefLODGridSize). The DynDOLODGrassMode/DynDOLOD-Grass-Mode 1 or 2 setting controls the distance of full grass respectively.
Set the same desired Mode in the advanced mode of DynDOLOD under the Grass LOD checkbox and for DynDOLODGrassMode/DynDOLOD-Grass-Mode in the settings file. While the DynDOLODGrassMode/DynDOLOD-Grass-Mode setting can be changed at any time, the Mode used to generate grass LOD is baked into the object LOD meshes.

If you have problems with full grass and NGIO, you need to ask on the NGIO forum or comments.

[KRZ]

13 hours ago, sheson said:

If you are absolutely sure that the load order did not change after generating the output with alpha 170 let me know for follow up questions/troubleshooting..

Otherwise, generate a LOD patch from scratch with the latest alpha for the current load order, to verify that the crash still happens.
If it does, upload new DynDOLOD log and debug log and new crash log and keep the output around for follow up questions/troubleshooting.

Welp, you were right that my LO had changed - I've been wondering about that cause the RAM address was different in those crash logs. Below I've attached all logs from a new A170 run with identical LO this time (also identical to A169). Sadly the crashes persisted. I've also tested whether crashes would occur in Markarth, Windhelm or Solitude as well and they didn't (or I just haven't found the spot).

DynDOLOD_SSE_Debug: https://mega.nz/file/IGtykIzI#j9kKzjggkK3vStV3a9oIAQIjyyzQurM66J_OjvCuM0M
 

Logs.zip

Edited June 5 by KRZ

[sheson]

55 minutes ago, KRZ said:

Welp, you were right that my LO had changed - I've been wondering about that cause the RAM address was different in those crash logs. Below I've attached all logs from a new A170 run with identical LO this time (also identical to A169). Sadly the crashes persisted. I've also tested whether crashes would occur in Markarth, Windhelm or Solitude as well and they didn't (or I just haven't found the spot).

DynDOLOD_SSE_Debug: https://mega.nz/file/IGtykIzI#j9kKzjggkK3vStV3a9oIAQIjyyzQurM66J_OjvCuM0M

Logs.zip 1.18 MB · 0 downloads

The mentioned records are parent > child copies. There should not be really anything different between the references/base records in Alpha 169 and 170.

Lets just look at one crash log: crash-2024-06-05-08-57-45.log
Base record WRHouseStables01 with form ID 0x000627AA
used by reference 0x130BAEC0 in DynDOLOD.esm

Since you have both outputs, do the following:

Lookup the reference in xEdit by its EditorID in DynDOLOD.esm in both outputs. Enter skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO into the Editor ID field top left of xEdit and hit Enter key and wait for it to find it. Obviously it should find the reference 0x130BAEC0 for the output put from 170. The form ID will different in the DynDOLOD.esm for the output of 169.

Compare the references if there is anything different.
Both should use the same base record 0x000627AA in Skyrim.esm, which seems not to be overwritten by any plugin and define Architecture\WhiteRun\WRBuildings\WRHouseStables01.nif. It (and any textures it uses) should also be identical for both load orders. Let me know in case this is not the vanilla NIF and if it comes from a mod and which.

If so far you haven't found a difference compare, check the Cell 0x00071E94 the reference resides in and compare the overwrites in the DynDOLOD.esm and Occlussion.esp for both output if there is anything different.

Let me know if you can spot anything different or obvious errors or if everything looks the same.

[MitchBandito]

1 hour ago, sheson said:

DynDOLOD does not do anything to full grass. Set the appropriated settings in NGIO GrassControl.config.txt to control full grass and its max render distance.

https://dyndolod.info/Help/Grass-LOD
With No Grass In Objects full grass can be rendered past the active cells, so Grass LOD can either start right beyond the active exterior cells (uGridsToLoad), which has better for performance - or beyond the large reference distance (uLargeRefLODGridSize). The DynDOLODGrassMode/DynDOLOD-Grass-Mode 1 or 2 setting controls the distance of full grass respectively.
Set the same desired Mode in the advanced mode of DynDOLOD under the Grass LOD checkbox and for DynDOLODGrassMode/DynDOLOD-Grass-Mode in the settings file. While the DynDOLODGrassMode/DynDOLOD-Grass-Mode setting can be changed at any time, the Mode used to generate grass LOD is baked into the object LOD meshes.

If you have problems with full grass and NGIO, you need to ask on the NGIO forum or comments.

Thank you so much for your answer 🙏

[KRZ]

3 hours ago, sheson said:

The mentioned records are parent > child copies. There should not be really anything different between the references/base records in Alpha 169 and 170.

Lets just look at one crash log: crash-2024-06-05-08-57-45.log
Base record WRHouseStables01 with form ID 0x000627AA
used by reference 0x130BAEC0 in DynDOLOD.esm

Since you have both outputs, do the following:

Lookup the reference in xEdit by its EditorID in DynDOLOD.esm in both outputs. Enter skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO into the Editor ID field top left of xEdit and hit Enter key and wait for it to find it. Obviously it should find the reference 0x130BAEC0 for the output put from 170. The form ID will different in the DynDOLOD.esm for the output of 169.

Compare the references if there is anything different.
Both should use the same base record 0x000627AA in Skyrim.esm, which seems not to be overwritten by any plugin and define Architecture\WhiteRun\WRBuildings\WRHouseStables01.nif. It (and any textures it uses) should also be identical for both load orders. Let me know in case this is not the vanilla NIF and if it comes from a mod and which.

If so far you haven't found a difference compare, check the Cell 0x00071E94 the reference resides in and compare the overwrites in the DynDOLOD.esm and Occlussion.esp for both output if there is anything different.

Let me know if you can spot anything different or obvious errors or if everything looks the same.

Sorry for taking so long, xEdit reported a patch causing errors, so I replaced it and ran Alpha 170 again to see whether that's been the culprit - it was not. I've included a comparison shot of both entries below (Alpha 169 on the left, Alpha 170 on the right). I can't really spot a difference, however it appears that in Alpha 170's output skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO doesn't actually get referenced by anything opposed to Alpha 169's output, which has exactly one reference.

The WRHouseStables01.nif is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/120159

Edited June 5 by KRZ

[sheson]

1 hour ago, KRZ said:

Sorry for taking so long, xEdit reported a patch causing errors, so I replaced it and ran Alpha 170 again to see whether that's been the culprit - it was not. I've included a comparison shot of both entries below (Alpha 169 on the left, Alpha 170 on the right). I can't really spot a difference, however it appears that in Alpha 170's output skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO doesn't actually get referenced by anything opposed to Alpha 169's output, which has exactly one reference.

The WRHouseStables01.nif is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/120159

Error check the DynDOLOD and Occlusion plugins in xEdit.

To be sure, test without the mod / hide the model so that the vanilla model is used. I do not expect that to make a difference.

Report if anything overwrite the original reference 00099F21.

[KRZ]

43 minutes ago, sheson said:

Error check the DynDOLOD and Occlusion plugins in xEdit.

To be sure, test without the mod / hide the model so that the vanilla model is used. I do not expect that to make a difference.

Report if anything overwrite the original reference 00099F21.

I'm getting a couple of errors with both Alpha 169 and Alpha 170, but it's hard to tell whether that isn't caused by me replacing that one patch and adding 3 more patches which had been chosen by the FOMOD. Should I create a new Output for Alpha 169 as well to maintain consistency or does it not matter? I had to replace the patch or xEdit would have thrown a fit and I couldn't check for errors etc.

I've attached the findings anyways, but if I have to do another round let me know.

 

Launching without the mod/model did nothing.

Nothing touches the original reference 00099F21.

Error check.txt

[sheson]

14 hours ago, KRZ said:

I'm getting a couple of errors with both Alpha 169 and Alpha 170, but it's hard to tell whether that isn't caused by me replacing that one patch and adding 3 more patches which had been chosen by the FOMOD. Should I create a new Output for Alpha 169 as well to maintain consistency or does it not matter? I had to replace the patch or xEdit would have thrown a fit and I couldn't check for errors etc.

I've attached the findings anyways, but if I have to do another round let me know.

 

Launching without the mod/model did nothing.

Nothing touches the original reference 00099F21.

Error check.txt 638.44 kB · 1 download

The Unknown 2 are expected.

The unresolved Form ID are a problem. This should not happen right after patch generation. So if you generate again with 170, check it right after. For troubleshooting I do not need a new 169 for now.

[KRZ]

14 hours ago, sheson said:

The Unknown 2 are expected.

The unresolved Form ID are a problem. This should not happen right after patch generation. So if you generate again with 170, check it right after. For troubleshooting I do not need a new 169 for now.

Once again everything's brand new, including TerrainLOD this time, but the crashes persist.

DynDOLOD_SSE_Debug: https://mega.nz/file/FDlAwDTa#pI9vxOzqgJoBPAB8x5lMWILKdnqLzjxsXwmVdZ6QzQU

 

Fwiw, I've noticed there are a ton of 0D and FE005 FormIDs in xEdit's error report, which are

evgSirenroot.esm https://www.nexusmods.com/skyrimspecialedition/mods/70917 and

Landscape and Water Fixes.esp https://www.nexusmods.com/skyrimspecialedition/mods/26138 in my LO.
I wonder whether that's related somehow.

 

Peculiar, I've done another Alpha 170 output without Sirenroot and Landscape and Water Fixes, but while all the 0D errors are gone, the FE005 have changed. Everything related to this is in Logs 2 & DynDOLOD_SSE_Debug 2.

DynDOLOD_SSE_Debug 2: https://mega.nz/file/9XsBEADa#mMWBomfMs2suBL9rzJLxHOQwFrVpbDRO3ifMmHFhaBs

 

Logs.zip

Logs 2.zip