Jump to content

DynDOLOD 3.00 Alpha 169


sheson

Recommended Posts

3 hours ago, sheson said:

Add RenderSingle=1 under [TexGen] in E:\Game Modding\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini and check if it makes a difference.

By the divines it works!!! Thank you so much! You should become the tenth divine after Tiber Septim.

Link to comment
Share on other sites

In https://dyndolod.info/Help/Dynamic-LOD, you mentioned:

Quote

In the Skyrim version, the NearGrid and FarGrid start right beyond the uGridsToLoad. In Skyrim Special Edition / Skyrim VR the FarGrid starts beyond the uLargeRefLODGridSize, while the NearGrid still starts beyond the uGridsToLoad.

I'm not very sure if I understand this correctly. Does this mean, assuming NearGridsToLoad=11, FarGridsToLoad=21, UGridsToLoad=5 and uLargeRefLODGridSize=11 (for SE only), that in Oldrim the behavior is [NearGrid dynamic LODs in 5-11 area, FarGrid dynamic LODs in 5-21 area], while in SE it's [NearGrid dynamic LODs in 5-11 area, FarGrid dynamic LODs in 11-21 area]? How does the large reference system interfere with dynamic LOD grids anyway?

Link to comment
Share on other sites

35 minutes ago, heheloveer said:

In https://dyndolod.info/Help/Dynamic-LOD, you mentioned:

I'm not very sure if I understand this correctly. Does this mean, assuming NearGridsToLoad=11, FarGridsToLoad=21, UGridsToLoad=5 and uLargeRefLODGridSize=11 (for SE only), that in Oldrim the behavior is [NearGrid dynamic LODs in 5-11 area, FarGrid dynamic LODs in 5-21 area], while in SE it's [NearGrid dynamic LODs in 5-11 area, FarGrid dynamic LODs in 11-21 area]? How does the large reference system interfere with dynamic LOD grids anyway?

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.

  • Thanks 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 !

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
×
×
  • Create New...

Important Information

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