DynDOLOD 3.00 Alpha 182

[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

[mooit]

xLODGen Beta 95 now kept crashing on me too, and there were no messages in the log, so I reverted back to Beta 94, and I installed the ENB Complex Grass and generated the grass cache then tested this all over, now I was able to get DynDOLOD to complete and not crash too.

I tested without the terrain LOD meshes from xLODGen enabled, and I tested without the DynDOLOD Occlusion plugins active.

Still the same problem, no grass/trees/objects in the distance.

Here's screen shots at Whiterun with Alpha98.

1. Alpha98 — Freeimage.host

2. Alpha98 — Freeimage.host

 

LOGS

DynDOLOD_SSE_Debug_log (mediafire.com)

DynDOLOD_SSE_log (mediafire.com)

LODGen_SSE_Tamriel_log (mediafire.com)

TexGen_SSE_Debug_log (mediafire.com)

TexGen_SSE_log (mediafire.com)

Edited September 24, 2022 by mooit

[sheson]

11 hours ago, Smokey said:

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.

Do not install any third party billboards. https://dyndolod.info/Help/Tree-Grass-LOD-Billboards#3rd-Party-LOD-Billboards
Use TexGen to generate all billboards. https://dyndolod.info/Help/TexGen#Tree-Grass-LOD-Billboards
Make sure all desired billboards are generated. https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards

For 3D tree LOD models, make sure they are actually somewhat optimized and just not copies of the full model.

See answers for "Object LOD model and full model show at the same time causing texture flicker" at https://dyndolod.info/FAQ