DynDOLOD 3.00 Alpha 180

[sheson]

1 hour ago, m300 said:

thank you, and the fact you still gave me directions is really appreciated!!!!

one last question if i may, i got those warning messages: 

Could not find model Landscape\Grass\DLC02VolcanicAshRocks01.nif
Could not find model landscape\Grass\EGrass05.nif
Could not find model landscape\Grass\EGrass36b.nif
Could not find model landscape\Grass\ESpFAngularSolomonSeal02.nif
Could not find model landscape\Grass\ESpFAngularSolomonSeal04.nif
Could not find model landscape\Grass\espfernbraken05st.nif
Could not find model landscape\Grass\ESpLadysMantle.nif
Could not find model landscape\Grass\espmaylily02.nif
Could not find model landscape\Grass\ESPMeadowsweet02.nif
Could not find model landscape\Grass\espscilla01blue.nif
Could not find model landscape\Grass\esutansy01.nif
Could not find model landscape\Grass\EWpShore03.nif
Could not find model landscape\Grass\fallforestgrass0bj03.nif
Could not find model landscape\Grass\UG_forestgroundcover02.nif

did you had them too and do i need to ignore them?

If a model does not exist in the load order, its bounds can not be calculated.

In case of the vanilla grass model DLC02VolcanicAshRocks01.nif defined by GRAS record 0401771E, the model does indeed not exist.
The record is not being used by anything (Referenced by tab in xEdit), so it is an orphaned record and the message can be ignored.

That might be also the case for whatever grass mod you are using.

17 minutes ago, m300 said:

i did what you instructed i recalculated bounds for verdant saved and deployed mods made sure that the newer file in use(in vortex)

but after running texgen i got the same result in TexGen_TES5VR_Grass_Billboards.txt

i guess i will try to force it 

TexGen_TES5VR_Grass_Billboards.txt 15.86 kB · 0 downloads

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts.

I suggest to verify the updated esp with xEdit, that the objects bounds are actually updated and not -1 or 0 anymore for the GRAS records in question.

[m300]

1 hour ago, sheson said:

If a model does not exist in the load order, its bounds can not be calculated.

In case of the vanilla grass model DLC02VolcanicAshRocks01.nif defined by GRAS record 0401771E, the model does indeed not exist.
The record is not being used by anything (Referenced by tab in xEdit), so it is an orphaned record and the message can be ignored.

That might be also the case for whatever grass mod you are using.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts.

I suggest to verify the updated esp with xEdit, that the objects bounds are actually updated and not -1 or 0 anymore for the GRAS records in question.

thank you so much i finally managed to have grass lod but its in a different color for example in whiterun grass is orange but in the lod its green do you maybe have a fix for that or maybe a guide for grass color fix?

[sheson]

25 minutes ago, m300 said:

thank you so much i finally managed to have grass lod but its in a different color for example in whiterun grass is orange but in the lod its green do you maybe have a fix for that or maybe a guide for grass color fix?

Assuming the grass LOD billboards match the full grasses properly, https://dyndolod.info/Help/Grass-LOD#Settings
In case the grass LOD brightness or color seems off (it might depend on weathers or ENB settings), try different Direct/Ambient settings for grass LOD billboards in TexGen. In addition or alternatively change the GrassBrightnessTop*/ComplexGrassBrightnessTop* and GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini - those settings help if the color tone is off. Especially the image based lighting effect from ENB has a big impact on the brightness and color tone of the grass LOD. Additional complex grass lighting and time of day settings will obviously not apply to object LOD, as they are separate meshes and shaders. Do not use them so full grass and grass LOD match better for all weathers/times.

[Chromatic]

9 hours ago, sheson said:

GLDebug=1 does more debugging and is not supposed to make a difference how things work, so no change is expected.

Download this test version https://mega.nz/file/pQIW3BjB#lUFjXiTiHkI-yu1yfow_e0X5E2VrHkD_lp5tER_GrEA and upload new bugreport.txt, log and debug log.

New logs as requested: https://ufile.io/7jlxnjar

[sheson]

13 hours ago, Chromatic said:

New logs as requested: https://ufile.io/7jlxnjar

Make sure to use a driver only installation and/or terminate crapware with task manager before testing. For example:
amdfendrsr.exe
atiesrxx.exe
atieclxx.exe
RadeonSoftware.exe
cncmd.exe

Use this test version https://mega.nz/file/MZA2VDoT#1KgtOQa-L74pnMVRCCF1uTsh4ixwTZ08Ezbbc4haBVg, upload new bugreport.txt, log and debug log.

[TioDrakul]

Skyrim LE user here. I've configured and installed DynDOLOD 3.00 Alpha 156 and successfully installed it, but it's causing me a serious problem: The bridge to Winterhold College has disappeared, and I've discovered that it has ended up far, far below where it should be in the game. The NIF affected is "winterholdextbridge01.nif" and it is displayed in the game, but in a completely wrong position on the altitude axis.

I read in a previous comment that Sheson was doing a test with this object and that it caused the same problem (the bridge disappears) but related to Skyrim SE, but whatever he did negatively affected Skyrim LE as well.

On 11/5/2023 at 7:22 AM, Morti said:

Weird stuff. After last time I generated DynDOLOD I found out that WInterhold bridge disappeared.

In SSEEDit I found out that DynDOLOD.esm changed its Z position from -9088 to -30000. You know why it could do that? Easily fixed, but still odd.

 

Same problem here, but using Skyrim LE. Could you describe how you corrected the wrong positioning?

Edited November 25, 2023 by TioDrakul

[sheson]

12 hours ago, TioDrakul said:

Skyrim LE user here. I've configured and installed DynDOLOD 3.00 Alpha 156 and successfully installed it, but it's causing me a serious problem: The bridge to Winterhold College has disappeared, and I've discovered that it has ended up far, far below where it should be in the game. The NIF affected is "winterholdextbridge01.nif" and it is displayed in the game, but in a completely wrong position on the altitude axis.

Same problem here, but using Skyrim LE. Could you describe how you corrected the wrong positioning?

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

Generating a LOD mod for Skyrim LE with DynDOLOD does not create a DynDOLOD.esm.
Do not install output generated for other game versions.
Make sure the output folder is empty before generating a new LOD patch from scratch.

[AriochRN]

Hi, SkyrimVR player and I’m having a visual issue after travelling to Solstheim: after I got there I could see black areas on the volcano and Skyrim mainland. I went through the process of disabling Dyndolod & rerunning xlodgen/texgen/Dyndolod and everything on the distant landscape looked fine when I got back into the game - until after I’d been inside a building. When I came outside again the black areas were back. Doing the uninstall/install process again brought back the good landscapes - until after I’d been inside a building again!

Any help would be greatly appreciated if I’m missing something obvious.

 

[sheson]

1 hour ago, AriochRN said:

Hi, SkyrimVR player and I’m having a visual issue after travelling to Solstheim: after I got there I could see black areas on the volcano and Skyrim mainland. I went through the process of disabling Dyndolod & rerunning xlodgen/texgen/Dyndolod and everything on the distant landscape looked fine when I got back into the game - until after I’d been inside a building. When I came outside again the black areas were back. Doing the uninstall/install process again brought back the good landscapes - until after I’d been inside a building again!

Any help would be greatly appreciated if I’m missing something obvious.

 

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

This is the terrain underside peeking through.

Try to increase LOD distance in DynDOLOD SkyUI MCM Settings.
Try to generate better quality terrain LOD for Solstheim with xLODGen.
Try to generate better quality terrain underside and/or use higher height setting for Solstheim.
You can change the z-height manually afterwards with xEdit by editing the reference. You get its form ID by clicking the mesh when console is open.

[AriochRN]

Thanks for the reply - after several hours of fiddling it doesn’t appear to be tied to LOD distance (I’ve tried increasing fblockmaximum up to 500,000 and the level 0/1 numbers up without visible difference), I’ve reran xlodgen with 4/8/16/32 levels all set at quality 0, generated underside at quality 0 & height 990 - nothing makes a difference. 

I’ll see if I can do the xEdit thing but a quick look at the mod page makes me think it might be beyond my ability

I don’t see anything similar in mainland Skyrim so I might just have to do my best to ignore it whilst in Solstheim.

[TioDrakul]

16 hours ago, sheson said:

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

Generating a LOD mod for Skyrim LE with DynDOLOD does not create a DynDOLOD.esm.
Do not install output generated for other game versions.
Make sure the output folder is empty before generating a new LOD patch from scratch.

 

No no, let's be clear here, I said the problem is similar but I didn't generate an "ESM", I correctly followed the instructions to generate an "ESP", which is what Skyrim LE uses and using the LE options of the DynDOLOD 3.0

The problem is as I described. The entire section of the bridge that is composed of the file "winterholdextbridge01.nif" has been moved far below the terrain, the game informs me that the last plugin to modify the related object was Dyndolod and using TSE5Edit I couldn't find out where this modification would be (may be applied via script?).

I also checked the nif file itself in case the problem was in it, but I don't have any other mod changing that nif. I suspect it's related to the problem the other user reported because he had the same result (the object being positioned far below the terrain) but while he uses Skyrim SE I use Skyrim LE. I propose that you have a look at the code you mentioned using as a test of these "large references" to see if it wasn't being activated in the LE version in addition to the SE version, given that what you had mentioned it would do is exactly the problem I'm experiencing.

Edited November 26, 2023 by TioDrakul

[sheson]

9 hours ago, AriochRN said:

Thanks for the reply - after several hours of fiddling it doesn’t appear to be tied to LOD distance (I’ve tried increasing fblockmaximum up to 500,000 and the level 0/1 numbers up without visible difference), I’ve reran xlodgen with 4/8/16/32 levels all set at quality 0, generated underside at quality 0 & height 990 - nothing makes a difference. 

I’ll see if I can do the xEdit thing but a quick look at the mod page makes me think it might be beyond my ability

I don’t see anything similar in mainland Skyrim so I might just have to do my best to ignore it whilst in Solstheim.

Editing the z position of the reference in xEdit is pretty straight forward.

Open DynDOLDO.esp in xEdit and enter DLC2SolstheimWorld_Underside_DynDOLOD_NOLOD into the Editor ID field top left and hit Enter to open up the record.
Then in the right window scroll to the bottom and unfold Data - Position/Rotation, double or right click edit the Position Z entry and set something like -1200.

[sheson]

13 hours ago, TioDrakul said:

No no, let's be clear here, I said the problem is similar but I didn't generate an "ESM", I correctly followed the instructions to generate an "ESP", which is what Skyrim LE uses and using the LE options of the DynDOLOD 3.0

The problem is as I described. The entire section of the bridge that is composed of the file "winterholdextbridge01.nif" has been moved far below the terrain, the game informs me that the last plugin to modify the related object was Dyndolod and using TSE5Edit I couldn't find out where this modification would be (may be applied via script?).

I also checked the nif file itself in case the problem was in it, but I don't have any other mod changing that nif. I suspect it's related to the problem the other user reported because he had the same result (the object being positioned far below the terrain) but while he uses Skyrim SE I use Skyrim LE. I propose that you have a look at the code you mentioned using as a test of these "large references" to see if it wasn't being activated in the LE version in addition to the SE version, given that what you had mentioned it would do is exactly the problem I'm experiencing.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

https://dyndolod.info/Official-DynDOLOD-Support-Forum
Report the actual problem or error message without making assumptions or asking leading questions. Read the explanations and tips below, especially about what information and logs to provide and how.

Posts are answered based on the actual information given which without the requested logs and screenshots is pretty much none. The requested information is required for qualified troubleshooting to quickly find out the actual cause in this particular case.

Skyrim LE should not use patch files for Skyrim SE.
If it did, the replacement copy to the DynDOLOD.esp is made before moving the original reference below ground.
Hundred other users and I do not have this problem with the current alpha version with Skyrim LE.

[AriochRN]

59 minutes ago, sheson said:

Editing the z position of the reference in xEdit is pretty straight forward.

Open DynDOLDO.esp in xEdit and enter DLC2SolstheimWorld_Underside_DynDOLOD_NOLOD into the Editor ID field top left and hit Enter.
In the bottom of right window unfold Data - Position/Rotation, double or right click edit the Position Z entry and set something like -1200.

Thank you very much for the detailed instructions; I’ve dropped the Z-position to -1200 but unfortunately the underside looks unchanged and is still poking through on Red Mountain & the mainland.

Is it anything to do with the bit in the guide about SkyrimVR terrain LOD meshes being lowered in the distance being baked into a shader? If I look at the volcano and look upwards I can see the problem disappear on the lower slopes in the bottom of my view (the view frustum thing?)

If I’ve read your guides correctly, the underside is used to give more accurate shadows and sun-rays. Skyrim VR doesn’t have volumetric sun-rays so that’s no great loss to me, so I’ve just deleted the underside.nif for Solstheim. I’ve run around the island for an hour and not noticed a massive difference in the shadows so I think this will be the Gordian Knot solution to my problem

Thanks again for your help.

Edited November 27, 2023 by AriochRN

[sheson]

4 hours ago, AriochRN said:

Thank you very much for the detailed instructions; I’ve dropped the Z-position to -1200 but unfortunately the underside looks unchanged and is still poking through on Red Mountain & the mainland.

Is it anything to do with the bit in the guide about SkyrimVR terrain LOD meshes being lowered in the distance being baked into a shader? If I look at the volcano and look upwards I can see the problem disappear on the lower slopes in the bottom of my view (the view frustum thing?)

If I’ve read your guides correctly, the underside is used to give more accurate shadows and sun-rays. Skyrim VR doesn’t have volumetric sun-rays so that’s no great loss to me, so I’ve just deleted the underside.nif for Solstheim. I’ve run around the island for an hour and not noticed a massive difference in the shadows so I think this will be the Gordian Knot solution to my problem

Thanks again for your help.

Then try lower values, like -1500 or -2000 for example.

Yes it is possible that the automatic lowering of terrain LOD could be the cause. It may also be just the usual z-fighting. Other worldspaces cover up terrain LOD with object LOD, not so those far away land masses in Solstheim.

If the underside is not required/desired then simply do not check the option.
If you just do not want to generate the underside for Solstheim add DLC2SolstheimWorld to the ignore list in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini
TerrainUndersideIgnoreWorlds=Blackreach, DLC01SoulCairn, DLC2ApocryphaWorld, ccBGSSSE067DeadlandsWorld, ccKRTSSE001QNWorld, DLC2SolstheimWorld