DynDOLOD 3.00 Alpha 180

[mooit]

I forgot to mention, ever since I reported this problem, if anyone remembers how long that was, I looked for the original posts, they were moved/removed.

For this long, I've been running over, probably 20-30 times xLODGen beta 94 and DynDOLOD Alpha95 playing around with different mods and tweaking and never once did I run into any problems as I've been playing and testing, until now again with Alpha98 giving me a problem.

Please believe me when I say, I know my setup is fine, otherwise how could I run DynDOLOD Alpha95 20-30 times without problems, but every time I just try a new version, this problem happens.

THANKS

Edited September 23, 2022 by mooit

[sheson]

53 minutes ago, mooit said:

Hi,

I'm back to this same issue, Alpha 95 no problems, I switched over now to Alpha98 and the same issues, no grass/trees in the distance.

My Setup is 100% correct/fine, there is absolutely nothing wrong with it, I've been using this same setup for around 6-8 months without any problems till now.

I'm certainly not a pro like Shenson, but I've been modding in SSE for 2 years, so please, let's not start bickering back and forth how it's my setup, because it's not, and I'd like to figure it out so I can use the latest Alpha, rather then getting blamed I'm screwing up.

As I said before, if I'm screwing up, then nothing is going to work, and Alpha95 works just fine, you can't have one work, and the other one not work, I don't see it happening like this.

These are the only changes I made in the DynDOLOD_SSE.ini;

GrassGID=gid
 
	; grass LOD brightness multipliers - applied to grass LOD billboards created from "normal" grass without normal map textures
GrassBrightnessTopR=1.0
GrassBrightnessTopG=1.0
GrassBrightnessTopB=1.0
; make bottom darker to fake shadowing
GrassBrightnessBottomR=1.0
GrassBrightnessBottomG=1.0
GrassBrightnessBottomB=1.0
	; complex grass LOD brightness multipliers - applied to grass LOD billboards created from "complex" grass with normal map textures
ComplexGrassBrightnessTopR=0.500
ComplexGrassBrightnessTopR=0.500
ComplexGrassBrightnessTopR=0.500
; make bottom darker to fake shadowing
ComplexGrassBrightnessTopR=0.500
ComplexGrassBrightnessTopR=0.500
ComplexGrassBrightnessTopR=0.500

I also have ENB Complex Grass installed for Folkvangr  and Origins of Forest and I had them installed when I created my grass cache.

These are the xLODGen, TexGen, DynDOLOD settings I'm using off of the Guide here.

XLODGen LOD32 — Freeimage.host - Previous settings, there was no mipmap and it had Default Size diffuse and normal?

TexGen 2.1.0 QHD — Freeimage.host - Previous TexGen, I didn't use Complex Grass - Complex Grass was also not installed when creating the grass cache.

https://freeimage.host/i/sq5y5N - I used instead for tree LOD4/Level0 LOD8/Level0 LOD16/Level1

 

THANKS

Read the first post which log and debug log to upload when making posts.

You did not post an in-game screenshot, so it is unclear if tree/grass LOD is not part of the object LOD meshes or if the entire object LOD is missing.

Test with a new game.
Test new game without the terrain LOD meshes from xLODGen enabled. They should be irrelevant. (Unrelated:  there is no need to check mipmaps for normals, the game only makes use of mipmaps for LOD level 4 diffuse terrain textures), 2k for the map textures seems high, default size can be really low to conserve video memory)
Test new game without the DynDOLOD, Occlusion plugins active, just the meshes/textures output.

44 minutes ago, mooit said:

I forgot to mention, ever since I reported this problem, if anyone remembers how long that was, I looked for the original posts, they were moved/removed.

For this long, I've been running over, probably 20-30 times xLODGen beta 94 and DynDOLOD Alpha95 playing around with different mods and tweaking and never once did I run into any problems as I've been playing and testing, until now again with Alpha98 giving me a problem.

Please believe me when I say, I know my setup is fine, otherwise how could I run DynDOLOD Alpha95 20-30 times without problems, but every time I just try a new version, this problem happens.

THANKS

AFAIK no posts are removed, there seems to be a problem with search, though. Older posts seem not to be indexed right now.

I suggested to test without the plugins already, never heard back about the result. I also reported that the LOD files  you uploaded work perfectly fine here.

[mooit]

Ok, I'll go back and play again, with what you mentioned trying.

In the meantime I deleted DynDOLOD Resources SE Alpha-28 and installed Alpha-27 and then recreated the grass cache over. Then I ran xLODGen Beta94, and DynDoLOD Alpha95, and here are two screenshots, showing this has worked.

Actually, I've been using Alpha95 since it came out and I've done a lot of running it since then, pretty much on average 20 - 30 hrs a week hacking away LOL, and as I mentioned, never a problem till now.

THANKS

Alpha95 at Whiterun;

1. Alpha95 — Freeimage.host

2. Alpha95 — Freeimage.host

 

Edited September 23, 2022 by mooit

[sheson]

1 hour ago, mooit said:

Ok, I'll go back and play again, with what you mentioned trying.

In the meantime I deleted DynDOLOD Resources SE Alpha-28 and installed Alpha-27 and then recreated the grass cache over. Then I ran xLODGen Beta94, and DynDoLOD Alpha95, and here are two screenshots, showing this has worked.

Actually, I've been using Alpha95 since it came out and I've done a lot of running it since then, pretty much on average 20 - 30 hrs a week hacking away LOL, and as I mentioned, never a problem till now.

THANKS

Alpha95 at Whiterun;

1. Alpha95 — Freeimage.host

2. Alpha95 — Freeimage.host

I did not ask for screenshots, information from or to troubleshoot older versions. Read the first post.

[sheson]

16 hours ago, Blackread said:

Hello sheson,

I am once again looking for assistance with LOD overlapping loaded large reference models. This time I'm having problems with Obscure's College of Winterhold. The issue seems to affect all or almost all of the references OCW places in the cell 28, 27. Naturally they aren't large references by default, but have been made such in my game (with the usual script). Some examples are:
xx4e43d1
xx4e43d3
xx4e43ce
xx4e43cb
xx4e43c4

Looking at things in xEdit I noticed that DynDOLOD.esm replaces the base objects in the equivalent vanilla references with ones that have had the Has Distand LOD flag removed. I was wondering if this is relevant and whether I should do a similar thing to the OCW references that replace the vanilla ones?

Anyway, here are the usual logs: https://mega.nz/file/YT8xjbxD#EYzt1jNYLf2Na8Mu0JakqCRR8z9MBthBe739G1HJa14

Additionally, the first 3 or 4 times I started TexGen after updating to Alpha 98 I got a Duplicates Not Allowed error. I haven't been able to replicate this since, but I thought I'd share the logs for that too: https://mega.nz/file/cGdUDIib#WmOyEAiQg4AQaJERJHVG-qR1qIr-0iGNK7ELkl7c2GE

This mod overwrites large references in its default state. So it triggers the bugs.

To counter this, the plugin initially disables every large reference (via an enable parent marker) that has visual flicker (but for example not the large mountainrocks, since their full model and LOD model do not share same 3D space as obviously, you can use the spire 00106C9E to test if the full model and its LOD are both loaded) and adds the bridge as new non large references. It comes with its own object LOD BTO file which has the LOD for bridge added as normal references as well. So by itself the mod appears visually fine and continues to look fine when LOD is generated with DynDOLOD.

Flagging the plugin ESM does not help or change that. The bugs caused by the via enable parent initially disabled large refs are visually still not obvious.

Once you make the new references large refs, the bugs will become obvious again.

If you have the time you could test this:
With the plugin flagged as ESM but not large refs generated yet, bring up the marker xx4E43C3 and check its referenced by tab. Remove the enable parent from all listed large references. Set their deleted flag. Clean the plugin afterwards to make proper UDRs out of them. Then generate LOD with DynDOLOD and test if bugs are still triggered by checking the spire 00106C9E.
If bugs do not happen anymore, generate large refs and LOD and see if things still work as they should.

If bugs still happen, send me the edited plugin for further reviews. It is always possible there is more than one cause.

Ignore the entrance 00106e5f of the bridge in the next cell over for now and remember that cell has vanilla bugs or add these two lines back to ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_skyrimesm_tamriel.patch which add a new non large ref and then "deletes" the large ref.
copy2esp=skyrim.esm;00106e5f
delete=skyrim.esm;00106e5f

It is OK if you decide not to do that test and just see if the large ref workarounds do their job sufficiently without problems.

[Blackread]

3 hours ago, sheson said:

This mod overwrites large references in its default state. So it triggers the bugs.

To counter this, the plugin initially disables every large reference (via an enable parent marker) that has visual flicker (but for example not the large mountainrocks, since their full model and LOD model do not share same 3D space as obviously, you can use the spire 00106C9E to test if the full model and its LOD are both loaded) and adds the bridge as new non large references. It comes with its own object LOD BTO file which has the LOD for bridge added as normal references as well. So by itself the mod appears visually fine and continues to look fine when LOD is generated with DynDOLOD.

Flagging the plugin ESM does not help or change that. The bugs caused by the via enable parent initially disabled large refs are visually still not obvious.

Once you make the new references large refs, the bugs will become obvious again.

If you have the time you could test this:
With the plugin flagged as ESM but not large refs generated yet, bring up the marker xx4E43C3 and check its referenced by tab. Remove the enable parent from all listed large references. Set their deleted flag. Clean the plugin afterwards to make proper UDRs out of them. Then generate LOD with DynDOLOD and test if bugs are still triggered by checking the spire 00106C9E.
If bugs do not happen anymore, generate large refs and LOD and see if things still work as they should.

If bugs still happen, send me the edited plugin for further reviews. It is always possible there is more than one cause.

Ignore the entrance 00106e5f of the bridge in the next cell over for now and remember that cell has vanilla bugs or add these two lines back to ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_skyrimesm_tamriel.patch which add a new non large ref and then "deletes" the large ref.
copy2esp=skyrim.esm;00106e5f
delete=skyrim.esm;00106e5f

It is OK if you decide not to do that test and just see if the large ref workarounds do their job sufficiently without problems.

Ah thanks for the explanation, I wasn't aware that references disabled via enable parent also trigger the bugs. I can test this too.

In the meantime, seeing as this will probably be the way moving forward, I generated full LODs with the workarounds enabled and checked the cells reported having bugs in the logs - which was painful, I doubt I'll do this ever again. I found very few references that had both the full and LOD model appear at the same time. Here's the full rundown:

Spoiler

RedBag's Rorikstead - Large Refs.esm xxxxx800 in cell -20, 1 of Tamriel, no overwrites

Skyrim.esm aa6bc in cell -38, 2 of Tamriel, no overwrites

Skyrim.esm bbc23 in cell -38, 2 of Tamriel, no overwrites

Skyrim.esm 39055 in cell -38, 2 of Tamriel, no overwrites

Here are the logs for the generation: https://mega.nz/file/oK0EXKZA#-j__STXxB7dBA8srl5Z7XqSgfQE-gMe932k_kSWJILg I also included the custom RedBag's Rorikstead plugin and my modified version of the main plugin it was designed to be used with. If this interests you and there's anything you need let me know.

Of course my load order isn't super massive and it is already prepared for large references using the old methods, so I'm probably not the ideal test subject.

Edited September 23, 2022 by Blackread
Formatting

[Blackread]

2 hours ago, Blackread said:

Ah thanks for the explanation, I wasn't aware that references disabled via enable parent also trigger the bugs. I can test this too.

In the meantime, seeing as this will probably be the way moving forward, I generated full LODs with the workarounds enabled and checked the cells reported having bugs in the logs - which was painful, I doubt I'll do this ever again. I found very few references that had both the full and LOD model appear at the same time. Here's the full rundown:

  Reveal hidden contents

RedBag's Rorikstead - Large Refs.esm xxxxx800 in cell -20, 1 of Tamriel, no overwrites

Skyrim.esm aa6bc in cell -38, 2 of Tamriel, no overwrites

Skyrim.esm bbc23 in cell -38, 2 of Tamriel, no overwrites

Skyrim.esm 39055 in cell -38, 2 of Tamriel, no overwrites

Here are the logs for the generation: https://mega.nz/file/oK0EXKZA#-j__STXxB7dBA8srl5Z7XqSgfQE-gMe932k_kSWJILg I also included the custom RedBag's Rorikstead plugin and my modified version of the main plugin it was designed to be used with. If this interests you and there's anything you need let me know.

Of course my load order isn't super massive and it is already prepared for large references using the old methods, so I'm probably not the ideal test subject.

I did a bit of further testing and found out, that disabling and enabling one of the affected objects in cell -38, 2 will unload the LOD for all of them. The same did not happen for the rock cliff near rorikstead. I had Papyrus logging enabled during this. I did not notice anything LOD related in the log, but then again I don't really know what I should be looking for. Here's the log: https://mega.nz/file/hK0ABS4R#Cbd0-QnDBGndefdG_p6iBfP0bhm_6bYvoIt8Lda4Urk

Edited September 23, 2022 by Blackread

[sheson]

47 minutes ago, Blackread said:

I did a bit of further testing and found out, that disabling and enabling one of the affected objects in cell -38, 2 will unload the LOD for all of them. The same did not happen for the rock cliff near rorikstead. I had Papyrus logging enabled during this. I did not notice anything LOD related in the log, but then again I don't really know what I should be looking for. Here's the log: https://mega.nz/file/hK0ABS4R#Cbd0-QnDBGndefdG_p6iBfP0bhm_6bYvoIt8Lda4Urk

I am interested in the papyrus log if there is ever some kind of error/warning messages from the SHESON_DynDOLOD_* scripts. If there are no such messages like in this case it is enough to report that.
Typically when the game starts/loads there should only be a couple normal status messages about loading data files etc. but nothing more beyond that.

[Smokey]

On 9/22/2022 at 5:48 AM, sheson said:

Read the first post which entire log from the LOD generation session, which entire debug log and bugreport.txt to upload when making posts.

Do screenshots in broad day light.

Read the answers for "High memory usage / Out of memory" at https://dyndolod.info/FAQ and/or https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data

Do not use DynDOLOD output unless the process "completed successfully" as explained at https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD

Read the already linked explanations of the DynDOLOD documentation which explain how to use the tools, how everything works and how to troubleshoot certain things. For example, the screenshot shows the base form ID of the tree, which you can look up in the TexGen log to if a billboard has been generated and the already mentioned DynDOLOD_SSE_Tree_Report.txt to see which log assets were found and used. Ask specific questions if further help is needed in addition to the linked explanations.

I read and did everything from the out of memory usage link and for some reason my dyndolod takes so many hours to complete now when generating tamriel lod. I literally couldn't post here until it was done and i still get the access violation error and out of memory messages in log. I lowered the OcclusionMaxThreadsObjectLOD to 1 as stated on the site, I have no clue if its a corrupted plugin as I have never had that problem before when using dyndolod and when i ran the script to check if there was something wrong with the plugins in xedit i got so many messages from every mod which i didnt really know what to fix or if anything need fixing since i didnt have any problems when playing before, also i saw somewhere that i shouldn't just clean mods if i dont know what im doing as some mods are not supposed to be cleaned since they contain records that would break the mod if cleaned. All i can do now is just show you my logs because im honestly really tired at this point and im thinking of just getting rid of the tree mod all together since it has caused me to much issues that are not worth the time and i dont feel like waiting another 6 hours for dyndolod to process tamriel lod again which is still ridiculous, never had it run that slow before.

Sorry for bothering this is the last straw for me, if you can still help im up for it but if theres nothing else to suggest i will just be removing the tree mod from my load order and call it a day.

DyndolodSSE.log- https://drive.google.com/file/d/1zL8wrFDBmlR41_3PIb6MPsq-9YRfG6Ic/view?usp=sharing

DyndolodDebug.log-https://drive.google.com/file/d/1aTQlGph3W2FecNI8AlMZYI4SE281xtrV/view?usp=sharing

Edited September 23, 2022 by Smokey

[sheson]

1 hour ago, Smokey said:

I read and did everything from the out of memory usage link and for some reason my dyndolod takes so many hours to complete now when generating tamriel lod. I literally couldn't post here until it was done and i still get the access violation error and out of memory messages in log. I lowered the OcclusionMaxThreadsObjectLOD to 1 as stated on the site, I have no clue if its a corrupted plugin as I have never had that problem before when using dyndolod and when i ran the script to check if there was something wrong with the plugins in xedit i got so many messages from every mod which i didnt really know what to fix or if anything need fixing since i didnt have any problems when playing before, also i saw somewhere that i shouldn't just clean mods if i dont know what im doing as some mods are not supposed to be cleaned since they contain records that would break the mod if cleaned. All i can do now is just show you my logs because im honestly really tired at this point and im thinking of just getting rid of the tree mod all together since it has caused me to much issues that are not worth the time and i dont feel like waiting another 6 hours for dyndolod to process tamriel lod again which is still ridiculous, never had it run that slow before.

Sorry for bothering this is the last straw for me, if you can still help im up for it but if theres nothing else to suggest i will just be removing the tree mod from my load order and call it a day.

DyndolodSSE.log- https://drive.google.com/file/d/1zL8wrFDBmlR41_3PIb6MPsq-9YRfG6Ic/view?usp=sharing

DyndolodDebug.log-https://drive.google.com/file/d/1aTQlGph3W2FecNI8AlMZYI4SE281xtrV/view?usp=sharing

The debug log shows OcclusionMaxThreads=2. Set OcclusionMaxThreads=1

However, it should be apparent that something is very wrong when LODGen takes several hours to generate LOD for worldspace.

You probably have too hi-res tree 3D LOD models and/or there is just too much grass. I am not entirely sure what the main tree mod is, but make sure to use one that has optimized 3D tree LOD models or just use Billboards instead.
In addition, you instructed to generate 3D tree LOD for all 3 object LOD Levels. Use Billboards for the higher LOD levels instead.

Regarding grass see https://dyndolod.info/Help/Grass-LOD. Do not use SuperDenseGrass when generating the grass cache and also make sure to "LODGen takes a long time or uses a lot of memory"

If the object LOD meshes are getting too huge because of the settings and LOD models, then you need to cut down on that.

Also see https://dyndolod.info/FAQ "Long running time or output several GB in file size".

If you are worried about problematic plugins/records, pay attention to the log message about deleted reference, HITMEs etc. https://dyndolod.info/Messages
Clean every plugin that LOOT tells you to clean, clean every plugin that has deleted references. Quick autoclean is safe when following the instruction. Follow proper modding guide if necessary. Ignoring errors and hoping for the best is never the right option.

[member282]

Hello, I tried to find if anyone else had this error, but there was only one post I could only see from google and it looks like it  was removed or moved. 

When trying to run Dyndolod from Vortex tools I get this error:

Error: DynDOLOD Resources SE core files newer than DynDOLOD Standalone.

Use DynDOLOD Standalone 3.00 or newer. 

I am using both the 3.0 versions. Specifically Alpha-98 and Alpha-28 as it says on the Nexus pages. 
Here is the DynDOLOD_SSE_log.txt, the only other that is in the log folder are TexGen_SSE_log.txt (which TexGen ran successfully and I was able to add it to Vortex), and a blank file of becauseofreasons.txt.
My game is 1.5.97 since I decided to roll it back from the newer game update, though I'm not sure that information is helpful, I'm fairly new to modding in general. 
Initially I did accidentally install the 1.6.40 version of DLL SE - SKSE64 Plugin, but I removed it right afterwards and got the correct 1.5.97 version. 

Thank you in advance

[Blackread]

7 hours ago, sheson said:

This mod overwrites large references in its default state. So it triggers the bugs.

To counter this, the plugin initially disables every large reference (via an enable parent marker) that has visual flicker (but for example not the large mountainrocks, since their full model and LOD model do not share same 3D space as obviously, you can use the spire 00106C9E to test if the full model and its LOD are both loaded) and adds the bridge as new non large references. It comes with its own object LOD BTO file which has the LOD for bridge added as normal references as well. So by itself the mod appears visually fine and continues to look fine when LOD is generated with DynDOLOD.

Flagging the plugin ESM does not help or change that. The bugs caused by the via enable parent initially disabled large refs are visually still not obvious.

Once you make the new references large refs, the bugs will become obvious again.

If you have the time you could test this:
With the plugin flagged as ESM but not large refs generated yet, bring up the marker xx4E43C3 and check its referenced by tab. Remove the enable parent from all listed large references. Set their deleted flag. Clean the plugin afterwards to make proper UDRs out of them. Then generate LOD with DynDOLOD and test if bugs are still triggered by checking the spire 00106C9E.
If bugs do not happen anymore, generate large refs and LOD and see if things still work as they should.

If bugs still happen, send me the edited plugin for further reviews. It is always possible there is more than one cause.

Ignore the entrance 00106e5f of the bridge in the next cell over for now and remember that cell has vanilla bugs or add these two lines back to ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_skyrimesm_tamriel.patch which add a new non large ref and then "deletes" the large ref.
copy2esp=skyrim.esm;00106e5f
delete=skyrim.esm;00106e5f

It is OK if you decide not to do that test and just see if the large ref workarounds do their job sufficiently without problems.

Just finished doing the tests. After converting the records to proper UDRs and generating the LOD there were no bugs, disabling the spire reference showed no LOD underneath. However, after generating large refs and LOD the bugs returned. I checked all the added large references in that cell but couldn't find any obvious causes of this. Here's the plugin if you want to look into it further. I'm personally satisfied with using the workarounds though as they seem to be working well, so if you have other things demanding your time there's no need to spend it on this, at least not on my account.

[sheson]

1 hour ago, member282 said:

Hello, I tried to find if anyone else had this error, but there was only one post I could only see from google and it looks like it  was removed or moved. 

When trying to run Dyndolod from Vortex tools I get this error:

Error: DynDOLOD Resources SE core files newer than DynDOLOD Standalone.

Use DynDOLOD Standalone 3.00 or newer. 

I am using both the 3.0 versions. Specifically Alpha-98 and Alpha-28 as it says on the Nexus pages. 
Here is the DynDOLOD_SSE_log.txt, the only other that is in the log folder are TexGen_SSE_log.txt (which TexGen ran successfully and I was able to add it to Vortex), and a blank file of becauseofreasons.txt.
My game is 1.5.97 since I decided to roll it back from the newer game update, though I'm not sure that information is helpful, I'm fairly new to modding in general. 
Initially I did accidentally install the 1.6.40 version of DLL SE - SKSE64 Plugin, but I removed it right afterwards and got the correct 1.5.97 version. 

Thank you in advance

Read the log uploaded. It tells you the DynDOLOD version is 2.97 (from the 2.98 download archive most likely)

You can not use the DynDOLOD Resources SE 3 Alpha with DynDOLOD 2.x.

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

Make sure to start the DynDOLODx64.exe from the DynDOLOD 3 Alpha installation folder.

40 minutes ago, Blackread said:

Just finished doing the tests. After converting the records to proper UDRs and generating the LOD there were no bugs, disabling the spire reference showed no LOD underneath. However, after generating large refs and LOD the bugs returned. I checked all the added large references in that cell but couldn't find any obvious causes of this. Here's the plugin if you want to look into it further. I'm personally satisfied with using the workarounds though as they seem to be working well, so if you have other things demanding your time there's no need to spend it on this, at least not on my account.

Thanks for the plugin. Still need to make sure that DynDOLOD does not itself create bugs. The fewer there are the better, also with the workarounds.

[Smokey]

4 hours ago, sheson said:

The debug log shows OcclusionMaxThreads=2. Set OcclusionMaxThreads=1

However, it should be apparent that something is very wrong when LODGen takes several hours to generate LOD for worldspace.

You probably have too hi-res tree 3D LOD models and/or there is just too much grass. I am not entirely sure what the main tree mod is, but make sure to use one that has optimized 3D tree LOD models or just use Billboards instead.
In addition, you instructed to generate 3D tree LOD for all 3 object LOD Levels. Use Billboards for the higher LOD levels instead.

Regarding grass see https://dyndolod.info/Help/Grass-LOD. Do not use SuperDenseGrass when generating the grass cache and also make sure to "LODGen takes a long time or uses a lot of memory"

If the object LOD meshes are getting too huge because of the settings and LOD models, then you need to cut down on that.

Also see https://dyndolod.info/FAQ "Long running time or output several GB in file size".

If you are worried about problematic plugins/records, pay attention to the log message about deleted reference, HITMEs etc. https://dyndolod.info/Messages
Clean every plugin that LOOT tells you to clean, clean every plugin that has deleted references. Quick autoclean is safe when following the instruction. Follow proper modding guide if necessary. Ignoring errors and hoping for the best is never the right option.

So I have some good news and bad news...

Good news: 

-dyndolod doesn't take hours anymore its more like 5-10 minutes again since i turned a lot of stuff down and used billboards instead

-I think i found out why those whiterun stable trees dont render from far away:

explanation- The tree mod causing the issue is this mod https://www.nexusmods.com/skyrimspecialedition/mods/16230?tab=description "whiterun trees overhaul", turns out when i checked the download file it literally only includes a esp file and not any textures,billboard or lod files. I checked its requirements and found out that "Skyrim 3D trees and plants" was a optional file to work alongside it, but I already have a another skyrim tree model replacer mod - "Veydogolt Trees" and it includes its own billboard and lod files for generation which actually works ingame for other trees outside whiterun but for some reason it doesn't work for the "whiterun trees overhaul". "Skyrim 3D trees and plants" also has its own files needed for lod and texgen so i can assume this is why those trees are not showing up at all, which makes sense now. Veydogolt Trees has its own whiterun tree addition mod - https://www.nexusmods.com/skyrimspecialedition/mods/63251 which i will be trying next to see if anything changes with the render distance.

Bad news:

-Tree still doesn't render from far(i will be changing tree mods for the reason stated above so this issue in not that problematic anymore)

-Whiterun walls seem to be flickering in and out of 2 textures or something see video for reference: https://imgur.com/a/xvJkyhW

I'll be back to report my testing to see if the other whiterun tree mod has the same issue. Thanks for the help so far i really appreciate it.

 

 

 

[mooit]

14 hours ago, sheson said:

I did not ask for screenshots, information from or to troubleshoot older versions. Read the first post.

I was only trying to show Alpha95 is fine with my setup.

Now with Alpha98, for xLODGen Beta95, I removed the mipmap on xLODGen, made the Default size Diffuse/Normal 256, and format BC7 max which is what they were listed before, and I didn't use Grass Complex mods installed, so no HD Grass, these are the only two differences I made this time.

Now DynDOLOD crashes on me, and the log says this;

Error processing grass data C:\Steam\steamapps\common\Skyrim Special Edition\Data\Grass\Tamrielx0045y-027.gid Unable to read beyond the end of the stream. 

hmm

P.S. I went back and this time installed the Complex Grass, but I didn't generate the grass cache with it installed, and I kept the mipmap unchecked in xLODGen, and for the Default size Diffuse/Normal put both on none, but it still crashed on me, the same error.

So now, the only thing I've not done differently here is not generated the grass cache with the ENB Complex Grass installed. It seems like the only way to make Alpha98 work is the ENB Complex Grass has to be installed when generating the grass cache.

Edited September 23, 2022 by mooit