DynDOLOD 3.00 Alpha 169

[heheloveer]

28 minutes ago, sheson said:

How is DynDOLOD supposed to include settings/assets for all possible combinations of grass, weather or whatever mods, INI settings, ENB, ENB settings?

Default settings are for the vanilla game, simple as that.

How is DynDOLOD not supporting all kinds of modded content? You said you change the setting to get the desired effect? 

> they deserve a more... well, officially supported way to solve this

For things to get easier or be simplified, they first need to be reported or asked for. Maybe also monetary support helps adding convenience features.

The documentation already explains that weather, ENB etc. affect brightness and what settings to use to counter that. Like the tools, the documentation is in ALPHA, so not all aspects might be covered, yet.

Yes, so I'm doing what I can by reporting this potential problem and a potential solution that I have. Also you reminded me that I could support you monetarily. I will consider this when it's not 1 AM where I am lol.

I understand default settings are for the vanilla game, users have to make adjustments to make it suit their game better; what I'm trying to say is that editing meshes isn't the same as changing a setting, either in the UI or in the ini files. If, I mean if we can establish that billboard without Back_Lighting flag is in some scenarios preferred, I would suggest including one such mesh in the files, make it billboard 3 or something so that users could switch to it just by editing the ini file, not the mesh itself. Anyway this discussion has all been rhetorics and I don't have anything else useful to say right now. I'll be back with the information I promised.

Edited March 1, 2023 by heheloveer

[sheson]

4 minutes ago, heheloveer said:

Yes, so I'm doing what I can by reporting this potential problem and a potential solution that I have. Also you reminded me that I could support you monetarily. I would consider this when it's not 1 AM where I am lol.

I understand default settings are for the vanilla game, users have to make adjustments to make it suit their game better; what I'm trying to say is that editing meshes isn't the same as changing a setting, either in the UI or in the ini files. If, I mean if we can establish that billboard without Back_Lighting flag is in some scenarios preferred, I would suggest including one such mesh in the files, make it billboard 3 or something so that users could switch to it just by editing the ini file, not the mesh itself. Anyway this discussion has all been rhetorics and I don't have anything else useful to say right now. I'll be back with the information I promised.

Now that this has been reported/asked for, this will be looked into.

[mytreds]

Using TexGen for the first time, it stops around 7 minutes. I've watched this happen 3 times, it's working and then suddenly stops. I verify in the Task Manager that its cpu use is 0% after a certain point each time. I've added TexGen to my exceptions for my windows security. I am wondering how I can solve this problem before I give up.

TexGen_SSE_log.txt

[z929669]

12 hours ago, heheloveer said:

Grass mod is QW's Grass Patch (main version) with complex grass textures from https://www.nexusmods.com/skyrimspecialedition/mods/67304. ENB preset is Rudy Cathedral Zangdar's version. I meticulously followed the installation guides provided by their authors and have installed all their prerequisites.

I mean, DynDOLOD should support all kinds of modded content, right? Maybe it's just because I messed up somewhere but the grass mods I use are popular. If what I saw in my game can be replicated, it would mean lots of other people might be experiencing the same problem, and they deserve a more... well, officially supported way to solve this. Editing the ini files? Sure. But I don't think users should resort to editing the mesh themselves, or at least, there should be some mention in the official documents that editing the meshes are in some cases necessary. I will provide the logs, screenshots and any other relevant information I can think of sometime later and you could decide what to do with them.

I know that ENB-CG settings themselves can exacerbate issues. Some presets have the CG settings optimized, and some do not. Some of the CG settings only apply to 'basic' (non-CG grass) and others only impact CG grass. LOD grass obviously cannot be impacted by this, so we've found that keeping the settings moderate is best for LOD compatibility. Also, if certain grasses are not using a CG-compatible atlas, they will be overly bright in full grass. As I understand, you are saying that it's the LOD grass than can be very bright at certain ToD with respect to loaded grass.

I can corroborate that this is indeed true with Step SSE as well, and it sounds like the Back_Lighting flag may be part of the issue. We use Cathedral Landscapes Complex Grass for ENB and our own custom ENB preset (Heavy version), which is drastically simpler than many presets. ENB for SSE 0.488.

If I find the time, I can test with these two mods over vanilla and see if I can't mitigate with the flag setting. I'm swamped with work, RL, and multiple projects right now, so no promises. For now, this is the effect with all settings optimized for CG-LOD compatibility:

While the sun is overhead or even still peeking over the mountain and lighting up both foreground and background, things look as expected:

... but as it dips behind the mountain, one expects the shadow to creep from the mountain to the player, which indeed it does, but it doesn't impact LOD grass much at all, only the loaded grass:

The LOD grass will stay lit up until most of the ambient sunlight is gone. This is also true of other LOD objects, but it's not as pronounced/obvious (e.g., distant mountains, trees, and objects are a bit brighter than those in the loaded foreground but its pretty acceptable, IMO ... I think the loaded area is pretty obvious from the second screen).

EDIT: the so-called 'optimized' settings for our CG-LOD config are partly TexGen Direct/Ambient as indicated here, DynDOLOD grass T/B brightness all at 0.500, and ENB-CG settings moderate (with EFFECTs UseOriginalBloom=true UseOriginalPostProcessing=true). We are using Cathedral Weathers in those shots with Ambiance.

This must partly be a game limitation, but I'm intrigued if the grass LOD flag can mitigate without messing things up in full daylight or when the sun is behind the PC.

[sheson]

7 hours ago, mytreds said:

Using TexGen for the first time, it stops around 7 minutes. I've watched this happen 3 times, it's working and then suddenly stops. I verify in the Task Manager that its cpu use is 0% after a certain point each time. I've added TexGen to my exceptions for my windows security. I am wondering how I can solve this problem before I give up.

TexGen_SSE_log.txt 327.64 kB · 2 downloads

Moved to the DynDOLOD 3 Alpha thread. Also upload the debug log that should save together with the log when closing the program via X.

Otherwise add RealTimeLog=1 under [TexGen] to ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI run again and upload that log.

Check the task manager for Texconvx64.exe processes TexGen might be waiting for.

[adhocspamdie]

Apologies if this has been asked before, but I wasn't able to find an answer directly from dyndolod.info or a quick search here.

Normally the recommendation is to run xLodgen, then Texgen and finally Dyndolod. If I am only updating the textures by installing texture mods, is it sufficient to just rerun Texgen, or do I have to run the others too?

[heheloveer]

20 hours ago, sheson said:

Now that this has been reported/asked for, this will be looked into.

 

9 hours ago, z929669 said:

I know that ENB-CG settings themselves can exacerbate issues. Some presets have the CG settings optimized, and some do not. Some of the CG settings only apply to 'basic' (non-CG grass) and others only impact CG grass. LOD grass obviously cannot be impacted by this, so we've found that keeping the settings moderate is best for LOD compatibility. Also, if certain grasses are not using a CG-compatible atlas, they will be overly bright in full grass. As I understand, you are saying that it's the LOD grass than can be very bright at certain ToD with respect to loaded grass.

I can corroborate that this is indeed true with Step SSE as well, and it sounds like the Back_Lighting flag may be part of the issue. We use Cathedral Landscapes Complex Grass for ENB and our own custom ENB preset (Heavy version), which is drastically simpler than many presets. ENB for SSE 0.488.

If I find the time, I can test with these two mods over vanilla and see if I can't mitigate with the flag setting. I'm swamped with work, RL, and multiple projects right now, so no promises. For now, this is the effect with all settings optimized for CG-LOD compatibility:

While the sun is overhead or even still peeking over the mountain and lighting up both foreground and background, things look as expected:

... but as it dips behind the mountain, one expects the shadow to creep from the mountain to the player, which indeed it does, but it doesn't impact LOD grass much at all, only the loaded grass:

The LOD grass will stay lit up until most of the ambient sunlight is gone. This is also true of other LOD objects, but it's not as pronounced/obvious (e.g., distant mountains, trees, and objects are a bit brighter than those in the loaded foreground but its pretty acceptable, IMO ... I think the loaded area is pretty obvious from the second screen).

EDIT: the so-called 'optimized' settings for our CG-LOD config are partly TexGen Direct/Ambient as indicated here, DynDOLOD grass T/B brightness all at 0.500, and ENB-CG settings moderate (with EFFECTs UseOriginalBloom=true UseOriginalPostProcessing=true). We are using Cathedral Weathers in those shots with Ambiance.

This must partly be a game limitation, but I'm intrigued if the grass LOD flag can mitigate without messing things up in full daylight or when the sun is behind the PC.

I just spent a lot of time testing and the results are very very interesting. Not many screenshots though since I tested way too many things to record down one by one, and you'll have to trust my words for it. In any case, a key culprit for the phenomenon I encountered (LOD grass lighting up at dawn/dusk when facing the sun while full grass doesn't) was EVLAS. I also believe EVLAS is also responsible for the phenomenon shown in z929669's screenshots.

The summary to my findings is, EVLAS makes grass lods react to dawn/dusk lighting much more aggressively, as in, they can become very, very bright. With my ENB preset it isn't much of a problem when facing the direction opposite to the sun, since the full grass is also lit up, but when you're facing the sun, the effect becomes quite jarring, especially when EVLAS makes terrain and full grass turn darker. The screenshots were all taken with grass lods generated with the default billboard (with Back_Lighting flag). Without EVLAS, grass lods with or without Back_Lighting work more or less fine to me, but with EVLAS it seems Back_Lighting has to be removed so that grass lods won't become an eyesore when facing the sun, at least in my case.

The other interesting problem is the one illustrated in z929669's screenshots. We weren't really describing the same phenomenon, since in his screenshots the camera was facing the sun but the full grass was also quite bright, at least when the sun hadn't been obstructed by the mountains. He noticed that when the sun was obstructed but not yet sunk below the horizon, the full grass became dark but the grass lods remained bright, and I think this is also a behavior brought about by EVLAS. Step Guide does include EVLAS so I'm assuming he was using it. Anyway, without EVLAS, both the full grass and the grass lods would, as he described, "stay lit up until most of the ambient sunlight is gone". With EVLAS, sunlight can be obstructed by terrain and objects, and the full grass would not light up when the mountains are casting shadows on them. But grass lods behave the same as before: they begin to gradually light up when it's sunrise time, regardless of whether there's actually sunlight present. With Skyrim as mountainous as it is, this could create some quite confusing visuals when the sun is over the horizon but not over the mountains. Removing Back_Lighting flag doesn't really help in this case, since the grass lods would still light up when they think "it's time", albeit only on one side, instead of on all sides. z929669 thought it's likely an engine limitation and I'm inclined to agree. In any case this is for sure far beyond me to find some sort of fix.

Another thing I noticed is that, as I mentioned, in z929669's screenshots the full grass were bright when the camera was facing the sun, but in my game it would only light up when the camera is facing the opposite direction. I'm not very sure what makes the our games behave this differently. I found increasing SubSurfaceScatteringAmount parameter in ENB complex grass settings could make the grass somewhat brighter in backlighting conditions, but in the ENB preset he used this value isn't very high. This is worth considering however. If I understand it correctly, in some setups the full grass are darker when the camera's facing the sun, while in others they are brighter. This would mean some people have to resolve this "overly bright grass lods when facing the sun" issue while others don't, since the full grass are also bright anyway.

Anyway here's the logs and the ENB setting I used. I ran DynDOLOD two times with the same setting and TexGen textures. Only the billboard meshes were changed. https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

[sheson]

1 hour ago, adhocspamdie said:

Apologies if this has been asked before, but I wasn't able to find an answer directly from dyndolod.info or a quick search here.

Normally the recommendation is to run xLodgen, then Texgen and finally Dyndolod. If I am only updating the textures by installing texture mods, is it sufficient to just rerun Texgen, or do I have to run the others too?

https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins
In case a new mod only updates textures or tree full models (and standard tree LOD is used) relevant to to LOD, remove old TexGen output, then use TexGen to generate new output and install it as usual. Start DynDOLOD in expert mode, select all or only the affected worldspaces and click the Rebuild Atlas button to update the atlas textures. Then install the DynDOLOD output, overwriting the existing DynDOLOD output. See expert mode for more.

If landscape textures are updated, and terrain LOD does not match full terrain anymore, then it should be obvious that terrain LOD textures need to be updated.

[sheson]

9 hours ago, z929669 said:

I know that ENB-CG settings themselves can exacerbate issues. Some presets have the CG settings optimized, and some do not. Some of the CG settings only apply to 'basic' (non-CG grass) and others only impact CG grass. LOD grass obviously cannot be impacted by this, so we've found that keeping the settings moderate is best for LOD compatibility. Also, if certain grasses are not using a CG-compatible atlas, they will be overly bright in full grass. As I understand, you are saying that it's the LOD grass than can be very bright at certain ToD with respect to loaded grass.

I can corroborate that this is indeed true with Step SSE as well, and it sounds like the Back_Lighting flag may be part of the issue. We use Cathedral Landscapes Complex Grass for ENB and our own custom ENB preset (Heavy version), which is drastically simpler than many presets. ENB for SSE 0.488.

If I find the time, I can test with these two mods over vanilla and see if I can't mitigate with the flag setting. I'm swamped with work, RL, and multiple projects right now, so no promises. For now, this is the effect with all settings optimized for CG-LOD compatibility:

While the sun is overhead or even still peeking over the mountain and lighting up both foreground and background, things look as expected:

... but as it dips behind the mountain, one expects the shadow to creep from the mountain to the player, which indeed it does, but it doesn't impact LOD grass much at all, only the loaded grass:

The LOD grass will stay lit up until most of the ambient sunlight is gone. This is also true of other LOD objects, but it's not as pronounced/obvious (e.g., distant mountains, trees, and objects are a bit brighter than those in the loaded foreground but its pretty acceptable, IMO ... I think the loaded area is pretty obvious from the second screen).

EDIT: the so-called 'optimized' settings for our CG-LOD config are partly TexGen Direct/Ambient as indicated here, DynDOLOD grass T/B brightness all at 0.500, and ENB-CG settings moderate (with EFFECTs UseOriginalBloom=true UseOriginalPostProcessing=true). We are using Cathedral Weathers in those shots with Ambiance.

This must partly be a game limitation, but I'm intrigued if the grass LOD flag can mitigate without messing things up in full daylight or when the sun is behind the PC.

Something must have changed since September. The backlighting also wrongly affects the Vanilla Complex Grass for ENB with the default ENB complex grass setting s (mulitpliers at 1.0 or amounts at 0.0). So next Alpha version will probably use a NIF without backlighting for complex grass by default. Since it is also possible to control the amount/percentage of backlighting with a gray scale texture, e.g. black = off, white = on, an INI setting that creates a x% gray scale texture might be added as well in case someone wants to use backlighting and control it.

By default LOD does not cast or receive shadows, so with a mod like EVLaS that makes the game cast long shadows from full models it becomes very obvious what is LOD and what isn't. It seems the ENB distant shadow effect does not make full shadows cast on LOD either. It probably just makes LOD cast shadows on LOD.

[heheloveer]

2 hours ago, sheson said:

Something must have changed since September. The backlighting also wrongly affects the Vanilla Complex Grass for ENB with the default ENB complex grass setting s (mulitpliers at 1.0 or amounts at 0.0). So next Alpha version will probably use a NIF without backlighting for complex grass by default. Since it is also possible to control the amount/percentage of backlighting with a gray scale texture, e.g. black = off, white = on, an INI setting that creates a x% gray scale texture might be added as well in case someone wants to use backlighting and control it.

By default LOD does not cast or receive shadows, so with a mod like EVLaS that makes the game cast long shadows from full models it becomes very obvious what is LOD and what isn't. It seems the ENB distant shadow effect does not make full shadows cast on LOD either. It probably just makes LOD cast shadows on LOD.

Glad to see you already have some potential changes in mind. I think I should mention two other smaller problems I've encountered before you make an update:

1) When I was testing grass lods I noticed sometimes when I fast travel to Whiterun watchtower or load a save there, the grass lods would appear in some cells that should be inhabited by full grass. More specifically, I use grass lod mode 2 so the grass lods should only exist outside the uLargeRefLODGridSize area, but for some reason they can also appear inside it. This doesn't happen for all the cells in the area, only some of them, and I'm pretty sure the actually loaded cells weren't affected. In the affected cells grass lods coexist with the full grass that should be there. If not for the obvious color mismatches that we've been discussing I probably wouldn't have noticed them. Using LOD Unloading Bug Fix fixes this temporarily.

2) The Whiterun Exterior Patch in DynDOLOD Resources may conflict with mods that replaces the two bridges near Whiterun, like Lux Via and Northern Roads. After running DynDOLOD, lod meshes that match these mods' models would appear outside the city, but since the Whiterun Exterior Patch places full model vanilla bridges in the same places, there would be an overlap of bridges. This could be easily solved by removing some lines in the patch file or removing the added bridges in the DynDOLOD plugin though. Do you think you should include some kind of patch to this or that the patches should be provided by the mods' authors?

In case logs are needed, just use the ones I included with my previous post: https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

[z929669]

4 hours ago, heheloveer said:

 

I just spent a lot of time testing and the results are very very interesting. Not many screenshots though since I tested way too many things to record down one by one, and you'll have to trust my words for it. In any case, a key culprit for the phenomenon I encountered (LOD grass lighting up at dawn/dusk when facing the sun while full grass doesn't) was EVLAS. I also believe EVLAS is also responsible for the phenomenon shown in z929669's screenshots.

The summary to my findings is, EVLAS makes grass lods react to dawn/dusk lighting much more aggressively, as in, they can become very, very bright. With my ENB preset it isn't much of a problem when facing the direction opposite to the sun, since the full grass is also lit up, but when you're facing the sun, the effect becomes quite jarring, especially when EVLAS makes terrain and full grass turn darker. The screenshots were all taken with grass lods generated with the default billboard (with Back_Lighting flag). Without EVLAS, grass lods with or without Back_Lighting work more or less fine to me, but with EVLAS it seems Back_Lighting has to be removed so that grass lods won't become an eyesore when facing the sun, at least in my case.

The other interesting problem is the one illustrated in z929669's screenshots. We weren't really describing the same phenomenon, since in his screenshots the camera was facing the sun but the full grass was also quite bright, at least when the sun hadn't been obstructed by the mountains. He noticed that when the sun was obstructed but not yet sunk below the horizon, the full grass became dark but the grass lods remained bright, and I think this is also a behavior brought about by EVLAS. Step Guide does include EVLAS so I'm assuming he was using it. Anyway, without EVLAS, both the full grass and the grass lods would, as he described, "stay lit up until most of the ambient sunlight is gone". With EVLAS, sunlight can be obstructed by terrain and objects, and the full grass would not light up when the mountains are casting shadows on them. But grass lods behave the same as before: they begin to gradually light up when it's sunrise time, regardless of whether there's actually sunlight present. With Skyrim as mountainous as it is, this could create some quite confusing visuals when the sun is over the horizon but not over the mountains. Removing Back_Lighting flag doesn't really help in this case, since the grass lods would still light up when they think "it's time", albeit only on one side, instead of on all sides. z929669 thought it's likely an engine limitation and I'm inclined to agree. In any case this is for sure far beyond me to find some sort of fix.

Another thing I noticed is that, as I mentioned, in z929669's screenshots the full grass were bright when the camera was facing the sun, but in my game it would only light up when the camera is facing the opposite direction. I'm not very sure what makes the our games behave this differently. I found increasing SubSurfaceScatteringAmount parameter in ENB complex grass settings could make the grass somewhat brighter in backlighting conditions, but in the ENB preset he used this value isn't very high. This is worth considering however. If I understand it correctly, in some setups the full grass are darker when the camera's facing the sun, while in others they are brighter. This would mean some people have to resolve this "overly bright grass lods when facing the sun" issue while others don't, since the full grass are also bright anyway.

Anyway here's the logs and the ENB setting I used. I ran DynDOLOD two times with the same setting and TexGen textures. Only the billboard meshes were changed. https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

I don't thing EVLaS is really the culprit but rather reveals the problem (as sheson inferred in the last statement of his previous post). EVLaS gives us shadows from distant (non-LOD version) objects, and the reason the foreground is so dark in my last screen in previous post is due to EVLas allowing that big distant mountain to occlude 'sunlight' point source. This is how we want it, but the problem is that LOD is agnostic of EVLaS shadow effects and only responds to the light source (ambient/direct) without 'seeing' shadows cast via EVLaS mechanism (this is me guessing not a statement of facts).

The mountain shadow did creep along the ground as the sun dipped, but it was only apparent on the loaded grass. I took the shot after the shadow reached me to illustrate the LOD/loaded difference. So the sun did light up the CG loaded grass as in the first image, but it became darker when occluded by the mountain shadow (thanks to EVLaS) and not as bright as if the sun were behind me.

The effect of light on CG should be that when the sun is behind the PC, it lights up the side of the grass facing the PC, and when the sun is opposite the PC, the grass facing the PC is more shaded (depending on SubSurfaceScattering settings). The strength and behavior of this effect depends on the quality of the normal/specular of the CG grass and grey value of the flag area in the normal (this is why the CG grass I created for Cathedral Landscapes has different lighting than the one created by the Compendium CG mod). This effect only pertains to loaded grass though and not LOD grass, which lights up like other non CG objects. LOD also does not get shadows, so LOD grass will never react to light/shadow like loaded CG grass, but I think with the proposed changes to the next Alpha, we may see better approximation, given the game limitations.

[sheson]

1 hour ago, heheloveer said:

Glad to see you already have some potential changes in mind. I think I should mention two other smaller problems I've encountered before you make an update:

1) When I was testing grass lods I noticed sometimes when I fast travel to Whiterun watchtower or load a save there, the grass lods would appear in some cells that should be inhabited by full grass. More specifically, I use grass lod mode 2 so the grass lods should only exist outside the uLargeRefLODGridSize area, but for some reason they can also appear inside it. This doesn't happen for all the cells in the area, only some of them, and I'm pretty sure the actually loaded cells weren't affected. In the affected cells grass lods coexist with the full grass that should be there. If not for the obvious color mismatches that we've been discussing I probably wouldn't have noticed them. Using LOD Unloading Bug Fix fixes this temporarily.

2) The Whiterun Exterior Patch in DynDOLOD Resources may conflict with mods that replaces the two bridges near Whiterun, like Lux Via and Northern Roads. After running DynDOLOD, lod meshes that match these mods' models would appear outside the city, but since the Whiterun Exterior Patch places full model vanilla bridges in the same places, there would be an overlap of bridges. This could be easily solved by removing some lines in the patch file or removing the added bridges in the DynDOLOD plugin though. Do you think you should include some kind of patch to this or that the patches should be provided by the mods' authors?

In case logs are needed, just use the ones I included with my previous post: https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

1) Unrelated to complex grass.
https://dyndolod.info/FAQ "Object LOD model and full model show at the same time causing texture flicker"
Known as large reference engine bug in Skyrim Special Edition and Skyrim VR that happens just outside the active exterior cells in the uLargeRefLODGridSize area. Pay attention to log message and read their explanations.
Move the slider Large Object Distance on the View Distance tab of the Advanced options of the game launcher to the very left. Alternatively set [General] uLargeRefLODGridSize=5 in SkyrimPrefs.ini. If this does not affect the issue see the answers for Out of place or floating objects below.
Maybe the experimental workarounds do not fix the bugs in those cells. Sometimes it can take several seconds before it is cleared. https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing

https://dyndolod.info/FAQ "Object LOD shows in active exterior cells"
Known as stuck object LOD after fast travel engine bug that can happen after fast travel especially to in Whiterun. Consider using the dynamic LOD option of DynDOLOD which should fix that bug. If dynamic LOD is not used, use the LOD Unloading Bug Fix.
Can be caused by [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini (or SkyrimCustom.INI or a mod INI), especially if there are no object LOD level 32 meshes (which is the vanilla/default). See Trees on the Map for further explanations.

You sure the LOD Level 32 that according to the log were generated are activated when these issues happened?

2) https://dyndolod.info/Help/DynDOLOD-Resources
Whiterun Exterior contains patch files which adds some missing buildings outside the town walls. These buildings are missing from the vanilla game for performance reasons. Includes patches for Cutting Room Floor and Provincial Courier Service. Do not install if there are mods that add/change objects in the WhiterunWorld city worldspace outside the vanilla walls to the south and east.

I suppose I should change the instructions to not install the patches if there are any kind of conflicts in any worldspace. For the foreseeable future that is probably not going to change.

[heheloveer]

6 minutes ago, sheson said:

1) Unrelated to complex grass.
https://dyndolod.info/FAQ "Object LOD model and full model show at the same time causing texture flicker"
Known as large reference engine bug in Skyrim Special Edition and Skyrim VR that happens just outside the active exterior cells in the uLargeRefLODGridSize area. Pay attention to log message and read their explanations.
Maybe the experimental workarounds do not fix the bugs in those cells. Sometimes it can take several seconds before it is cleared. https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing

https://dyndolod.info/FAQ "Object LOD shows in active exterior cells"
Known as stuck object LOD after fast travel engine bug that can happen after fast travel especially to in Whiterun. Consider using the dynamic LOD option of DynDOLOD which should fix that bug. If dynamic LOD is not used, use the LOD Unloading Bug Fix.
Can be caused by [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini (or SkyrimCustom.INI or a mod INI), especially if there are no object LOD level 32 meshes (which is the vanilla/default). See Trees on the Map for further explanations.

You sure the LOD Level 32 that according to the log were generated are activated when these issues happened?

2) https://dyndolod.info/Help/DynDOLOD-Resources
Whiterun Exterior contains patch files which adds some missing buildings outside the town walls. These buildings are missing from the vanilla game for performance reasons. Includes patches for Cutting Room Floor and Provincial Courier Service. Do not install if there are mods that add/change objects in the WhiterunWorld city worldspace outside the vanilla walls to the south and east.

I suppose I should change the instructions to not install the patches if there are any kind of conflicts in any worldspace. For the foreseeable future that is probably not going to change.

1) Of course this isn’t related to complex grass, just something I noticed when testing grass lods. Anyway I use A Clear Map of Skyrim and Other Worlds. I’m pretty sure there is an ini file in that mod that enables the LOD32 map settings. In my knowledge the related bug is most commonly caused by installing that mod (thus enabling LOD32 map settings) while not generating needed LOD meshes with DynDOLOD 3? It can cause quite a mess, with LOD models appearing in loaded cells, but I don’t think these abnormal grass lods I saw appeared in loaded cells. Aside from them I only noticed some occasional faraway flickering likely caused by some large reference bugs. Nothing suspicious in loaded cells. I’ll get around with further testing sometime later.

2) Sure, I know it would likely be too much of a hassle for you to account for all these mods. In any case this can be easily fixed by users.

[heheloveer]

1 hour ago, z929669 said:

I don't thing EVLaS is really the culprit but rather reveals the problem (as sheson inferred in the last statement of his previous post). EVLaS gives us shadows from distant (non-LOD version) objects, and the reason the foreground is so dark in my last screen in previous post is due to EVLas allowing that big distant mountain to occlude 'sunlight' point source. This is how we want it, but the problem is that LOD is agnostic of EVLaS shadow effects and only responds to the light source (ambient/direct) without 'seeing' shadows cast via EVLaS mechanism (this is me guessing not a statement of facts).

The mountain shadow did creep along the ground as the sun dipped, but it was only apparent on the loaded grass. I took the shot after the shadow reached me to illustrate the LOD/loaded difference. So the sun did light up the CG loaded grass as in the first image, but it became darker when occluded by the mountain shadow (thanks to EVLaS) and not as bright as if the sun were behind me.

The effect of light on CG should be that when the sun is behind the PC, it lights up the side of the grass facing the PC, and when the sun is opposite the PC, the grass facing the PC is more shaded (depending on SubSurfaceScattering settings). The strength and behavior of this effect depends on the quality of the normal/specular of the CG grass and grey value of the flag area in the normal (this is why the CG grass I created for Cathedral Landscapes has different lighting than the one created by the Compendium CG mod). This effect only pertains to loaded grass though and not LOD grass, which lights up like other non CG objects. LOD also does not get shadows, so LOD grass will never react to light/shadow like loaded CG grass, but I think with the proposed changes to the next Alpha, we may see better approximation, given the game limitations.

Culprit was just a figure of speech, I’ll take weirdly bright LOD grass for like half an hour during sunrise and sunset over non-EVLAS lighting any day. Also it makes sense that normal maps made with different values would affect how the complex grass reacts to sunlight. Guess there might be some need for controllable backlighting strength after all…

[Mousetick]

The Mysterious Disappearance of Solitude Trees Finally Solved! (Not really)

Fellow community member @MisterMorden and I have been investigating a visual issue that has been plaguing bothering distracting us for a while. It's about trees that are visible in the distance on the mountain cliffs behind the north-side walls of Solitude, and then disappear as the player gets close.

What we have managed to determine when DynDOLOD is not used:

• There are trees added by USSEP in the cells behind the Solitude walls inside the Solitude worldspace. There are no trees there in vanilla.
• They are neverfades (Persistent Is Full LOD references) so their full models are normally loaded and visible from anywhere in the Solitude worldspace.

When adding DynDOLOD into the mix:

• DynDOLOD.esm UDR-disables those trees from USSEP. So the full models are never loaded/visible.
• This is apparently driven by USSEP-specific rules in DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini.
• There are (object) LODs for trees that are visible from a distance, and unload when the player gets close.

Screenshots to illustrate:

USSEP Only Far View > USSEP Only Far View Disabled >USSEP Only Near View

USSEP + DynDOLOD Far View > USSEP + DynDOLOD Far View No LODs > USSEP + DynDOLOD Near View

Misc. additional remarks:

• The tree LODs present when using DynDOLOD are apparently for trees that are in the Tamriel worldspace, they're not at all related to the trees placed by USSEP in the Solitude worldspace.
• Both Mr Morden and I are using Ultra Tree LODs.
• The Solitude Exterior option of DynDOLOD Resources makes no difference, with or without.
• Mr Morden is using an unknown version of DynDOLOD 3 Alpha, with LR Bugs Workarounds, while I used Alpha 118 without LR Bugs Workarounds for the tests and screenshots above.
• I've seen this issue for as long as I can remember since I started using DynDOLOD, going back to Alpha 60 or thereabouts.

Questions:

• Can you confirm our findings and would you agree this is an issue, or at least an unexpected visual behavior.
• Is this the way it's supposed to be, or have we messed up somewhere?
• What would be a solution? What if we duplicated all the tree references from Skyrim.esm in Tamriel worldspace to their corresponding cells in Solitude worldspace, as normal, temporary references?

Thanks. Full logs here if you need them: https://drive.google.com/file/d/1fSSsY4qewQzm7ygNqgYUYGHO4eGYhC7t/view.