DynDOLOD 3.00 Alpha 182

[sheson]

10 hours ago, mattski123 said:

Hey, what settings do I need to see this landscape section and load the grass?

 

Also, how do I find this cell in xEdit?https://i.imgur.com/TywtZEV.png

This thread is for the DynDOLOD 3 alpha test. DynDOLOD does not change grass in loaded cells. DynDOLOD does nothing with landscape. Use xEdit cell browser with CTRL+SHIFT+F.

[sheson]

On 11/3/2021 at 12:18 AM, TechAngel85 said:

The refs are "initially disabled", parent is set to "Player" with "enable opposite of parent" flag set, and then they are set to -30000 for Z value. They are mainly splashes (MSTT) that you're not going to see as large refs (I don't recall them having any LOD). I'm 99% positive DynDOLOD v2 doesn't call out these references but v3 is, which is why I'm confused as to what changed. I've never seen any issues with it in-game. Also with the amount of users installing RWT, I'm sure someone would have reported the issue by now too, if there was one. These edits have been with RWT since last year sometime. The only thing being reported now for some users are the messages from DynDOLOD v3.

Large reference bugs cause the LOD for all large references in the same cell to stay loaded. It does not matter if the large reference causing the bug itself has LOD.

DynDOLOD 3.x reports many more problems and issues than DynDOLOD 2.x. The end of process summary about issues is not finished yet.

DynDOLOD 2.x/3.x fixes the UDR in ESM flagged plugins by removing the Initially Disabled flag and removing the enable parent to the player.

On 11/3/2021 at 1:35 AM, Epslion_09cc said:

Thanks mate, but that makes no sense.

I installed resource file for 6 times at least. And I just checked my resource file folder, It looks like that:

https://imgur.com/a/RNUFKHz

And here is the Script folder looks like:

https://imgur.com/a/yHeP9Zt

I will try only with DynDOLOD to generate files later, and re-install all files of course.

 

I already even tried, vanilla game +skse +USSEP +DynDOLOD. Still same problem, Unable to bind script..

Yes I am 100% sure I re-install resource files and re-generated files.

Here is the DynDOLOD log:

https://ufile.io/cxubudq6

The first two screenshots do not show if the DynDOLOD Resources are actually enabled and if the scripts are actually available in the ..\Data\Scripts\ folder and accessible by the game when it runs. Whatever problems causing the game not loading scripts from other mods and DynDOLOD Resources is outside of DynDOLOD control. Assuming the files are at the correct location and have the correct file names and the game is started from MO2, it could be permission problems, anti-vir etc.

[Tahano]

Just started using DynDOLOD fairly recently and it is amazing. Fixed all kind of issues with LOD's.

I'll try to be brief and I know this is going to sound really petty, but I gotta ask anyway.

I play Skyrim SE on my 42" TV. As a result I have to scale display to 200% to be able to see the desktop. When running TexGenx64, at the first GUI where you choose format type  and tile size, at a 200% scale, the last row with the buttons does not show. I have to change back to 100% scale to be able to see them, then go back to 200% scale. Kind of a pain, which no part of is any fault of yours.

I was wondering if, since the GUI is considered an Object with specific attributes, if someone could turn off the frame lock so the GUI  size could be adjusted.

Like I said, I know it's petty and probably only applies to my situation and "maybe" a few others.

If you wanna tell me tough cookie, I'll perfectly understand, but I just had to ask anyway.

Thanks again for all yall's great work and effort. Great Mod.

[TechAngel85]

6 hours ago, sheson said:

Large reference bugs cause the LOD for all large references in the same cell to stay loaded. It does not matter if the large reference causing the bug itself has LOD.

DynDOLOD 3.x reports many more problems and issues than DynDOLOD 2.x. The end of process summary about issues is not finished yet.

DynDOLOD 2.x/3.x fixes the UDR in ESM flagged plugins by removing the Initially Disabled flag and removing the enable parent to the player.

Upon closer testing, literally TFCing over there, I can see at least some of these splashes are, indeed, an issue. They are loaded for the first LOD level only in vanilla (and moving), but not when RWT is active. When I run DynDOLOD, the result is that the DynDOLOD plugin removes the "initially disabled" and "parent" records, but keeps the -30000 from the RWT changes. DynDOLOD does not touch RWT's custom placed references that replace these vanilla ones. In-game after DynDOLOD is ran, the result is the same for RWT assets. They do not show on LOD and pop-in when the cell is loaded. This means the RWT placed references aren't being see from afar (first LOD level).

Does these mean I need to remove the "initially disabled" and "parent" records from these references? Will that prevent the reported issues?

Second, question is the script for new RNAM was never ran for RWT (wasn't aware of it). I take it this needs to be done, and if so, is the script included with xEdit up to date (currently using v4.0.3)? Will this enable the RWT references to show on the first LOD level like vanilla? Being a moveable static, I'm not sure if those are handled differently.

[sheson]

On 11/3/2021 at 3:24 PM, Tahano said:

Just started using DynDOLOD fairly recently and it is amazing. Fixed all kind of issues with LOD's.

I'll try to be brief and I know this is going to sound really petty, but I gotta ask anyway.

I play Skyrim SE on my 42" TV. As a result I have to scale display to 200% to be able to see the desktop. When running TexGenx64, at the first GUI where you choose format type  and tile size, at a 200% scale, the last row with the buttons does not show. I have to change back to 100% scale to be able to see them, then go back to 200% scale. Kind of a pain, which no part of is any fault of yours.

I was wondering if, since the GUI is considered an Object with specific attributes, if someone could turn off the frame lock so the GUI  size could be adjusted.

Like I said, I know it's petty and probably only applies to my situation and "maybe" a few others.

If you wanna tell me tough cookie, I'll perfectly understand, but I just had to ask anyway.

Thanks again for all yall's great work and effort. Great Mod.

Sounds like an issue with the OS not scaling things correctly. Is this Windows 10?

If I can replicate I might be able to add a pixel or two to prevent that.

On 11/3/2021 at 3:29 PM, TechAngel85 said:

Upon closer testing, literally TFCing over there, I can see at least some of these splashes are, indeed, an issue. They are loaded for the first LOD level only in vanilla (and moving), but not when RWT is active. When I run DynDOLOD, the result is that the DynDOLOD plugin removes the "initially disabled" and "parent" records, but keeps the -30000 from the RWT changes. DynDOLOD does not touch RWT's custom placed references that replace these vanilla ones. In-game after DynDOLOD is ran, the result is the same for RWT assets. They do not show on LOD and pop-in when the cell is loaded. This means the RWT placed references aren't being see from afar (first LOD level).

Does these mean I need to remove the "initially disabled" and "parent" records from these references? Will that prevent the reported issues?

Second, question is the script for new RNAM was never ran for RWT (wasn't aware of it). I take it this needs to be done, and if so, is the script included with xEdit up to date (currently using v4.0.3)? Will this enable the RWT references to show on the first LOD level like vanilla? Being a moveable static, I'm not sure if those are handled differently.

If you do not want Initial Disabled large references to trigger visible large reference bugs, then maybe change those records in the plugin.
However, DynDOLOD fixes those anyways. In the release version it will only report records that it couldn't fix, like DynDOLOD 2.x does.

If you have an ESM flagged plugin and want its references to be large reference, then you can use the script. Make sure to use this version:
https://github.com/TES5Edit/TES5Edit/blob/sheson-create-large-ref-script-updates/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

Or better, add rules for DynDOLOD so the full model (or a special dynamic LOD model) gets dynamic LOD in the NearGrid.

Large references do not show in an object LOD Level. They are full models that are loaded already in the LOD area beyond the uGridsToLoad.
Similar to IsFullLOD/Persistent references.

[TechAngel85]

19 minutes ago, sheson said:

If yo do not want Initial Disabled large reference to trigger visible large reference bugs, then maybe change those records in the plugin.
However, DynDOLOD fixes those anyways. In the release version it will only report records that it couldn't fix, like DynDOLOD 2.x does.

Okay. I will change those since they seem to not be needed and just keep the -30000. This replicates the DynDOLOD results, regardless if the final version will print the messages or not. I would rather have it done right than DynDOLOD needing to fix it. 

19 minutes ago, sheson said:

If you have a ESM flagged plugin and want its references to be large reference, then you can use the script. Make sure to use this version:
https://github.com/TES5Edit/TES5Edit/blob/sheson-create-large-ref-script-updates/Build/Edit Scripts/Skyrim SE - Generate Large References.pas

Okay, that doesn't sound like what I want. The ESM is only used to move the vanilla references out of the way and contains no new references. The ESP is what places the new references in the same locations as the old. Should the new references also be in the ESM?

This option (call it option #1) would seem to be the only way to replicate vanilla without requiring DynDOLOD, correct?

19 minutes ago, sheson said:

Or better, add rules for DynDOLOD so the full model (or a special dynamic LOD model) gets dynamic LOD in the NearGrid.

Call this option #2; the preferable option?

I do like this better as it keeps the ESM to only vanilla records. This option would require DynDOLOD, though. The unfortunate reality is that there are still users that don't use DynDOLOD because they think it too complicated and then for those that do there are still users it would scare to add rules.  I have to consider that RWT has nearly 400K downloads at its peak and adding any requirements to the mod isn't a light decision. Any requirement added as to be weighted whether it's the right things to do. In this case, I would love to bring all those users onboard with DynDOLOD, but the reality is that decision could also alienate 100s of thousands of users. It would fall somewhere in the middle of alienation and onboarding, but how far the scale would tip one way or the other is totally unknown.

I think the best solution for everyone would be option #1, if it indeed replicates vanilla behavior (have to test). Else I will go with option #2 and make it "optional" for those users adventurous enough to learn new things; others will simply have to deal with the pop-in. I don't think there has been any reports, yet, because the issues are kind of hard to view from normal gameplay. I was TFCing and TCLing around to view them. Users would normally be within the loaded range of the cells before seeing most of the references so the issues are never noticed.

[sheson]

42 minutes ago, TechAngel85 said:

Okay. I will change those since they seem to not be needed and just keep the -30000. This replicates the DynDOLOD results, regardless if the final version will print the messages or not. I would rather have it done right than DynDOLOD needing to fix it. 

Okay, that doesn't sound like what I want. The ESM is only used to move the vanilla references out of the way and contains no new references. The ESP is what places the new references in the same locations as the old. Should the new references also be in the ESM?

This option (call it option #1) would seem to be the only way to replicate vanilla without requiring DynDOLOD, correct?

Call this option #2; the preferable option?

I do like this better as it keeps the ESM to only vanilla records. This option would require DynDOLOD, though. The unfortunate reality is that there are still users that don't use DynDOLOD because they think it too complicated and then for those that do there are still users it would scare to add rules.  I have to consider that RWT has nearly 400K downloads at its peak and adding any requirements to the mod isn't a light decision. Any requirement added as to be weighted whether it's the right things to do. In this case, I would love to bring all those users onboard with DynDOLOD, but the reality is that decision could also alienate 100s of thousands of users. It would fall somewhere in the middle of alienation and onboarding, but how far the scale would tip one way or the other is totally unknown.

I think the best solution for everyone would be option #1, if it indeed replicates vanilla behavior (have to test). Else I will go with option #2 and make it "optional" for those users adventurous enough to learn new things; others will simply have to deal with the pop-in. I don't think there has been any reports, yet, because the issues are kind of hard to view from normal gameplay. I was TFCing and TCLing around to view them. Users would normally be within the loaded range of the cells before seeing most of the references so the issues are never noticed.

If you just need to move something, just move it via the ESM. If the reference is using different base record / NIF then adding a new reference might be better to avoid trigger large references bugs because the "volume" or the base record type is different.

If you want the newly added references to be large references, then they need to be in the ESM and the large reference data needs to be genrated.

If you believe you owe users who do not mod properly anything, that is up to you.

[TechAngel85]

22 minutes ago, sheson said:

If you just need to move something, just move it via the ESM. If the reference is using different base record / NIF then adding a new reference might be better to avoid trigger large references bugs because the "volume" or the base record type is different.

If you want the newly added references to be large references, then they need to be in the ESM and the large reference data needs to be generated.

Yes, in the case of RWT, it's both a new base record and new NIF. I just finished testing this and it worked beautifully. The new references are added via ESM and new data generated. It replicated vanilla perfectly by showing up in the first level. They may still benefit from a DynDOLOD rule, though, by pushing them to load out to the next level. I'll have to test to see if it's worth it, since these aren't very large.

Thanks for your help on understanding this better!

22 minutes ago, sheson said:

If you believe you owe users who do not mod properly anything, that is up to you.

Love this. 

[z929669]

2 hours ago, TechAngel85 said:

Okay, that doesn't sound like what I want. The ESM is only used to move the vanilla references out of the way and contains no new references. The ESP is what places the new references in the same locations as the old. Should the new references also be in the ESM?

IIRC, you DO want to flag the water spray and such as large refs so that they get dynamic LOD (they move even in the higher LOD levels, which is more realistic but may cost a bit in performance). I also think we would want to tick "Upgrade large refs to near grid" option.

@sheson will correct me if I'm mistaken.

[TechAngel85]

33 minutes ago, z929669 said:

IIRC, you DO want to flag the water spray and such as large refs so that they get dynamic LOD (they move even in the higher LOD levels, which is more realistic but may cost a bit in performance). I also think we would want to tick "Upgrade large refs to near grid" option.

@sheson will correct me if I'm mistaken.

For a rule, perhaps. But updating the ESM with the new references and running the script worked perfectly. It will be fixed in the next release of RWT, as such. I haven't gotten around to a rule yet. The sprays from RWT are particles. Not sure how particle effects fit into this mix. I know they don't show in vanilla for the first level of LOD, nor do they using the ESM/script. Only the static part of them show.

[Sandcom]

Hey, so for some context I've been trying to resolve this issue I've been having since early January when I switched to SE modding, that is involved with my DynDOLOD 3 LODGen, and I've been too stubborn to ask for help here because I didn't want to bother any of you guys, and I've resolved 99% of my problems but I have a final one I just can't resolve, or i'm just too stupid to figure out and feel overwhelmed and frustrated from information overload.

I've been try to generate my Grass LOD, and I use Verdant for my grass mod inside MO2, it wasn't being recognized but I fixed that learning from an old 2020 thread stating I need to Recalc Bounds for the grass so that way TexGen recognizes it, bingo bango, did that, its recognized and working fine, processed in TexGen, but the problem came up when I went to try and Generate the LODGen DynDOLOD_Output, it does every other correctly all the way up to,
[tamriel] updating height map from terrain LOD meshes
[tamriel] updating height map from object LOD meshes

Once it gets there I end up freezing, over the last couple months i've followed alot of old threads where it states its a Hardware issue, so i've done the recommended of turning off my Overclocking, then I set Max Thread Limit in DynDOLOD_SSE.ini for both OcclusionMaxThreadsTerrainLOD=6 OcclusionMaxThreadsObjectLOD=6 since I have 16 Logical Processors (and make sure nothing else is running.). 

Important contextual information is that DynDOLOD LODGen would run fully prior to me Recalc Bounds for Verdant Grass to make it recognizes the grass mod, and from my understanding Verdant Grass works for many others just fine with DynDOLOD 3 so I don't think thats the case, and I think it might be a problem on my end, and I made sure to Recalc Bounds for everything inside the Verdant Grass listing for Object Menu in Creation Kit SSE version. 

Here's the only available Log generated from when it Freezes, and a picture I took of the screen when it freezes, its always the exact same last message shown before it does for me on screen. Sorry if poor quality, phone and all that since I couldn't screenshot.

Thank you so much for even just reading, you guys are absolutely great, and I apologize if this is something super obvious and I was just too stupid to realize from how overloaded my brain feels, and how frustrated I feel, I do not like the idea of wasting your guys time.

LODGen_SSE_Tamriel_log.txt

[sheson]

13 hours ago, z929669 said:

IIRC, you DO want to flag the water spray and such as large refs so that they get dynamic LOD (they move even in the higher LOD levels, which is more realistic but may cost a bit in performance). I also think we would want to tick "Upgrade large refs to near grid" option.

@sheson will correct me if I'm mistaken.

Only thins that have dynamic LOD objects or rules will they have dynamic LOD. If they large references and are assigned to FarGrid or are assigned to NearGrid and the Upgrade NearGrid large references to FarGrid is checked.

12 hours ago, TechAngel85 said:

For a rule, perhaps. But updating the ESM with the new references and running the script worked perfectly. It will be fixed in the next release of RWT, as such. I haven't gotten around to a rule yet. The sprays from RWT are particles. Not sure how particle effects fit into this mix. I know they don't show in vanilla for the first level of LOD, nor do they using the ESM/script. Only the static part of them show.

Full models are always full models. Large references are full models in the LOD area just like IsFullLOD/Persistent references that are disabled and unloaded  at the uLargeRefLODGridSize, which has no levels.  Dynamic LOD models included in DynDOLOD often have particles removed for optimization.

[sheson]

8 hours ago, Sandcom said:

Hey, so for some context I've been trying to resolve this issue I've been having since early January when I switched to SE modding, that is involved with my DynDOLOD 3 LODGen, and I've been too stubborn to ask for help here because I didn't want to bother any of you guys, and I've resolved 99% of my problems but I have a final one I just can't resolve, or i'm just too stupid to figure out and feel overwhelmed and frustrated from information overload.

I've been try to generate my Grass LOD, and I use Verdant for my grass mod inside MO2, it wasn't being recognized but I fixed that learning from an old 2020 thread stating I need to Recalc Bounds for the grass so that way TexGen recognizes it, bingo bango, did that, its recognized and working fine, processed in TexGen, but the problem came up when I went to try and Generate the LODGen DynDOLOD_Output, it does every other correctly all the way up to,
[tamriel] updating height map from terrain LOD meshes
[tamriel] updating height map from object LOD meshes

Once it gets there I end up freezing, over the last couple months i've followed alot of old threads where it states its a Hardware issue, so i've done the recommended of turning off my Overclocking, then I set Max Thread Limit in DynDOLOD_SSE.ini for both OcclusionMaxThreadsTerrainLOD=6 OcclusionMaxThreadsObjectLOD=6 since I have 16 Logical Processors (and make sure nothing else is running.). 

Important contextual information is that DynDOLOD LODGen would run fully prior to me Recalc Bounds for Verdant Grass to make it recognizes the grass mod, and from my understanding Verdant Grass works for many others just fine with DynDOLOD 3 so I don't think thats the case, and I think it might be a problem on my end, and I made sure to Recalc Bounds for everything inside the Verdant Grass listing for Object Menu in Creation Kit SSE version. 

Here's the only available Log generated from when it Freezes, and a picture I took of the screen when it freezes, its always the exact same last message shown before it does for me on screen. Sorry if poor quality, phone and all that since I couldn't screenshot.

Thank you so much for even just reading, you guys are absolutely great, and I apologize if this is something super obvious and I was just too stupid to realize from how overloaded my brain feels, and how frustrated I feel, I do not like the idea of wasting your guys time.

LODGen_SSE_Tamriel_log.txt 39.45 kB · 0 downloads

No idea what thread from 2020 you refer to, but the object bounds and to recalc them is explained in this thread and in the included documentation. For that grass mod, too IIRC.

Limit the max threads to reduce memory consumption as explained in these post or the INI. Start with 1:

https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/124/?tab=comments#comment-250521
https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/15/?tab=comments#comment-244301

https://www.take-a-screenshot.org/windows.html

[Sandcom]

1 hour ago, sheson said:

No idea what thread from 2020 you refer to, but the object bounds and to recalc them is explained in this thread and in the included documentation. For that grass mod, too IIRC.

Limit the max threads to reduce memory consumption as explained in these post or the INI. Start with 1:

https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/124/?tab=comments#comment-250521
https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/15/?tab=comments#comment-244301

https://www.take-a-screenshot.org/windows.html

Thank you so much for all your work Sheson, not just your help with me, i'll take a look over it and continue from there. Just having a lead gives me so much relief.

The old thread was just you explaining that overclocking can cause functional errors with LODGen as it causes the generator to misread, but its possible it was for /normal/ DynDOLOD or LE DynDOLOD, not sure but regardless it seemed smart to turn it off anyways just incase.

Edited November 4, 2021 by Sandcom

[Sandcom]

10 hours ago, sheson said:

No idea what thread from 2020 you refer to, but the object bounds and to recalc them is explained in this thread and in the included documentation. For that grass mod, too IIRC.

Limit the max threads to reduce memory consumption as explained in these post or the INI. Start with 1:

https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/124/?tab=comments#comment-250521
https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/15/?tab=comments#comment-244301

https://www.take-a-screenshot.org/windows.html

IT WORKED! WOOOO! Setting it to 1 fixed everything, thanks a bunch!