Jump to content

Recommended Posts

Posted

Hello! 

I managed to generate a (mostly) working grass LOD setup for 1.6.640. The only issue is that the Tundra/Whiterun grass LOD has a different color when compared to the regular grass. The rest of the grass LODs appear normal. I tested with and without a weather mod (Obsidian) and no ENB is used. Grass is not complex, but I do use Grass Lighting for Community Shaders.

 

Relevant screenshots (Hosted in Discord):

Tundra
Falkreath

Relevant log files (hosted in Ufile.io, zipped), also included in this post for convenience.

Logs

Any advice is highly appreciated!

ErrorHelpRequest.7z

Posted (edited)
2 hours ago, sheson said:

No point in adding large references to the near grid since they cover the same distance.

The limitation that only large references can use the far grid came from the fact that scripts for large references do not receive a cell attach / detach events.  A third helper reference (in addition to near and far activators) for each cell with dynamic LOD for large references needed to be added using the on load/unload events to signal large ref grid changes. The limit means not having to add a fourth helper activator and even more script load, risking triggering large reference bugs etc.

The large references bugs workarounds do not have that limit anymore, though.

I'll try to summarize my understanding of how the whole thing works: by default large reference NearGrid dynamic LODs are ignored because large reference system already achieves the same result; non-large reference FarGrid dynamic LODs are relegated into NearGrid because making them work as intended would require heavy script work (I know nothing about scripts) which could result in more large reference bugs. The Upgrade NearGrid Large References to FarGrid option is there to ensure large reference NearGrid dynamic LODs can still show up when the large reference system is essentially disabled by uLargeRefLODGridSize=5, and upgrading them to FarGrid is more of a unintended but necessary side effect. The Downgrade FarGrid references to NearGrid option is hidden and always checked to avoid more large reference bugs, but since large reference bugs workarounds can in theory eliminate all large reference bugs, you can uncheck them safely when using DynDOLOD DLL NG. Is this description accurate?

Edited by heheloveer
Posted
1 hour ago, SeaSparrow said:

Hello! 

I managed to generate a (mostly) working grass LOD setup for 1.6.640. The only issue is that the Tundra/Whiterun grass LOD has a different color when compared to the regular grass. The rest of the grass LODs appear normal. I tested with and without a weather mod (Obsidian) and no ENB is used. Grass is not complex, but I do use Grass Lighting for Community Shaders.

 

Relevant screenshots (Hosted in Discord):

Tundra
Falkreath

Relevant log files (hosted in Ufile.io, zipped), also included in this post for convenience.

Logs

Any advice is highly appreciated!

ErrorHelpRequest.7z 48.83 kB · 0 downloads

It is not possible atm to have the same shader settings/properties in LOD as the full grass, so it is not possible to match it depending mostly on the relative sun position.

Posted
6 hours ago, sheson said:

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

Try the same INI setting as I suggested above.

Thank you so much !

It works for me  too !

Posted
32 minutes ago, heheloveer said:

I'll try to summarize my understanding of how the whole thing works: by default large reference NearGrid dynamic LODs are ignored because large reference system already achieves the same result; non-large reference FarGrid dynamic LODs are relegated into NearGrid because making them work as intended would require heavy script work (I know nothing about scripts) which could result in more large reference bugs. The Upgrade NearGrid Large References to FarGrid option is there to ensure large reference NearGrid dynamic LODs can still show up when the large reference system is essentially disabled by uLargeRefLODGridSize=5, and upgrading them to FarGrid is more of a unintended but necessary side effect. The Downgrade FarGrid references to NearGrid option is hidden and always checked to avoid more large reference bugs, but since large reference bugs workarounds can in theory eliminate all large reference bugs, you can uncheck them safely when using DynDOLOD DLL NG. Is this description accurate?

Instead of saying it would require heavy script, lets just say, it would have made things even more complicated and convoluted back in 2016.

If you disable large references setting it to 5, use the ignore option so everything works again as it does in Skyrim Legendary. But suppose the uLargeRefLOD is just 7, then those are now do not show as far as they did with NearGrid 11 in the old game, so this option can be used to easily select supposedly larger object to show further away for better visuals.

You got the gist of it. DynDOLOD NG now allows me to move more and more things from script into C++ code with every update to it.

  • Like 1
Posted
10 hours ago, Thorg said:

Thank you so much !

It works for me  too !

It would help if you uploaded the log and bugreport.txt as requested. The debug log is most likely overwritten by now, so don't worry about it.

Posted
12 hours ago, sheson said:

Instead of saying it would require heavy script, lets just say, it would have made things even more complicated and convoluted back in 2016.

If you disable large references setting it to 5, use the ignore option so everything works again as it does in Skyrim Legendary. But suppose the uLargeRefLOD is just 7, then those are now do not show as far as they did with NearGrid 11 in the old game, so this option can be used to easily select supposedly larger object to show further away for better visuals.

You got the gist of it. DynDOLOD NG now allows me to move more and more things from script into C++ code with every update to it.

Ah yes, there's that ini option. Using it does make sense if you're sure you are not going to enable the large reference system, could save a bunch of trouble. Still, if someone sets large reference size to 7, then by checking Upgrade NearGrid Large References to FarGrid the viewing distance of these objects would jump from 7 to 21 when the intended viewing distance is just 11. Well, as you said, considering large references are supposed to be large, maybe extending their viewing distance further can be noticeable.

Aside from enabling large reference bugs workarounds, is there any other benefit in using DynDOLOD DLL NG?

Posted
1 hour ago, heheloveer said:

Ah yes, there's that ini option. Using it does make sense if you're sure you are not going to enable the large reference system, could save a bunch of trouble. Still, if someone sets large reference size to 7, then by checking Upgrade NearGrid Large References to FarGrid the viewing distance of these objects would jump from 7 to 21 when the intended viewing distance is just 11. Well, as you said, considering large references are supposed to be large, maybe extending their viewing distance further can be noticeable.

Aside from enabling large reference bugs workarounds, is there any other benefit in using DynDOLOD DLL NG?

Scripted stuff is being moved into the DLL, so it will be more efficient.

Posted (edited)

If I get these kind of warnings at the end of the log/DynDOLOD process, but can still open the .nif files with nifskope without an error, is it ok to keep the run or should I start a new one to make sure everything is working correctly?

<Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-32.20.bto": Error reading NIF block 124 BSSubIndexTriShape: Out of memory>
[28:39] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-28.0.bto": Error reading NIF block 27 BSSubIndexTriShape: Out of memory>
[28:39] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-28.28.bto": Error reading NIF block 70 BSSubIndexTriShape: Out of memory>
[28:39] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-28.-12.bto": Error reading NIF block 21 BSSubIndexTriShape: Out of memory>
[28:39] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-24.-12.bto": Error reading NIF block 15 BSSubIndexTriShape: Out of memory>
[28:39] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-24.-4.bto": Error reading NIF block 33 BSSubIndexTriShape: Out of memory>
[28:41] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-24.0.bto": Error reading NIF block 9 BSSubIndexTriShape: Out of memory>
[28:41] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-20.-4.bto": Error reading NIF block 21 BSSubIndexTriShape: Out of memory>
[28:41] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.52.-32.bto": Out of memory>
[28:41] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-20.-12.bto": Error reading NIF block 39 BSSubIndexTriShape: Out of memory>
[28:42] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-16.-4.bto": Error reading NIF block 33 BSSubIndexTriShape: Out of memory>
[28:42] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-16.-12.bto": Error reading NIF block 21 BSSubIndexTriShape: Out of memory>
[28:44] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-12.-4.bto": Error reading NIF block 51 BSSubIndexTriShape: Out of memory>
[28:44] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-16.-16.bto": Error reading NIF block 9 BSSubIndexTriShape: Out of memory>
[28:44] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-12.-12.bto": Error reading NIF block 97 BSSubIndexTriShape: Out of memory>
[28:44] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.8.8.bto": Error reading NIF block 9 BSSubIndexTriShape: Out of memory>
[28:46] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.12.8.bto": Error reading NIF block 112 BSSubIndexTriShape: Out of memory>
[28:46] <Warning: Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-12.-16.bto": Error reading NIF block 94 BSSubIndexTriShape: Out of memory>

I got no other 'interesting' errors or warnings I am concerned about, also no bugeport.txt.

Here are the Logs: Download

Edited by PRieST
Posted
1 hour ago, PRieST said:

If I get these kind of warnings at the end of the log/DynDOLOD process, but can still open the .nif files with nifskope without an error, is it ok to keep the run or should I start a new one to make sure everything is working correctly?

I got no other 'interesting' errors or warnings I am concerned about, also no bugeport.txt.

Here are the Logs: Download

https://dyndolod.info/FAQ "High memory usage / Out of memory"
If DynDOLOD runs out of memory while generating occlusion, see Out of Memory while Generating Occlusion Data.

https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data

Posted
11 minutes ago, Sulazarg said:

After generation, there are extra textures in the Helgen starting location. Generated a total of 3 times with disabled mods. Nothing has changed. Any ideas?
https://imgur.com/a/DbrNlOk

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

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to take screenshots with information.

See answers for https://dyndolod.info/FAQ "Out of place or floating objects"

Posted
36 minutes ago, maruru said:

Does anyone know if the update from April 27th (Version 2.82.5) is usable as a drop-in update for 2.2.0 guide?

This is the DynDOLOD support forum. Questions about third party modding guides should be asked on their appropriate forum. Probably here https://stepmodifications.org/forum/forum/157-step-skyrim-se-guide/

The latest DynDOLOD DLL 2.x version works with the latest DynDOLOD 2.x/3.x Standalone.

https://dyndolod.info/Downloads
Always use the latest version available. 

Posted

Hi I have the latest 3 version (alpha-128) and tried running it this morning at 10.30 with seasons for Skyrim AE it has not moved in from "Processing Patches" since then, is that normal with this version? Did something get changed? In the past with seasons it all took just over 30 mins on my system but its been hours and not moved on I don't know if its stuck, bugged or what. Tried doing a google but nothing useful so asking here. Thanks

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.