DynDOLOD 3.00 Alpha 182

[sheson]

2 hours ago, objir said:

Hi, When DynDOLOD generates refs for [0009A365] and [0009A366] (2 "WHshorttower" in WindHelm), it copies the position and rotation edits by JK's Skyrim. As a result, the generated refs are out of place. 

 

 

Any chance for somthing like a custom rule for the refs?

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

Using the position data from the winning plugin is the correct, documented and expected procedure.

In cases where mods make "bad" changes to child worldspaces to objects that have no representation in the parent worldspace already, the solution is to ignore the objects for the child > parent copying. In fact, included rules already instruct to ignore JK Skyrim.esp changes to the the child worldspace.

Next alpha version will make sure that it is also ignored in case the record is overwritten.

[tamrieltwo]

On 10/15/2023 at 9:43 AM, sheson said:

Find the best translation, so it looks good when hopefully most of the trunk is hidden behind the crown.
Or edit the full model to have a straight trunk.
Or keep the 3D of the trunk and optimize/decimate it and make its UV stay inside 0.0 and 1.0 (if beneficial create a TexGen rule to generate a stitched 2x2 version so UV can stay between 0.0 and 2.0)

I'm trying the 3rd option: decimated 3D trunks.

However I'm struggling to get Texture Clamp Mode of CLAMP_S_CLAMP_T to work. Ingame, the trunk becomes partially invisible if I use CLAMP_S_CLAMP_T . Here's how it looks in Nifskope:

The UV map looks like this:

3D LOD with decimated 3D trunks: pinus04_599919f0passthru_lod.nif

Trunk texture, bark_4.dds: https://file.io/j6TSLL8b7irl

Thank you

[sheson]

4 minutes ago, tamrieltwo said:

I'm trying the 3rd option: decimated 3D trunks.

However I'm struggling to get Texture Clamp Mode of CLAMP_S_CLAMP_T to work. Ingame, the trunk becomes partially invisible if I use CLAMP_S_CLAMP_T . Here's how it looks in Nifskope:

The UV map looks like this:

3D LOD with decimated 3D trunks: pinus04_599919f0passthru_lod.nif

Trunk texture, bark_4.dds: https://file.io/j6TSLL8b7irl

Thank you

You do not want the force the UV between into 0.0 and 1.0 with the shader clamp setting. You should edit the actual UV instead.
The clamp can work OK if the UV is slightly over the limits but this is > 4.0. 

Not sure what you did to decimate the mesh, but it looks weird. Look into Simplygon, it is free for personal use and can take care of the UV to be between 0.0 and 1.0, or 0.0 and 2.0 for stitched textures generated by TexGen for example in addition to creating LOD meshes. (It can also create rendered LOD textures, but that prevents automatic updating with TexGen)

I have a hard time seeing anything in the 3rd screenshot. The branches seem to be in the way.
https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
To get closer to LOD, toggle to the free fly camera with tfc in console.

[tamrieltwo]

12 minutes ago, sheson said:

You do not want the force the UV between into 0.0 and 1.0 with the shader clamp setting. You should edit the actual UV instead.
The clamp can work OK if the UV is slightly over the limits but this is > 4.0. 

Not sure what you did to decimate the mesh, but it looks weird. Look into Simplygon, it is free for personal use and can take care of the UV to be between 0.0 and 1.0, or 0.0 and 2.0 for stitched textures generated by TexGen for example in addition to creating LOD meshes. (It can also create rendered LOD textures, but that prevents automatic updating with TexGen)

I have a hard time seeing anything in the 3rd screenshot. The branches seem to be in the way.
https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
To get closer to LOD, toggle to the free fly camera with tfc in console.

I will check out Simplygon, ty.

So, I got it to work just leaving shader clamp as WRAP_S_WRAP_T. Can I ask what the downside of WRAP_S_WRAP_T is? As far as I can tell, it looks like it's working.

Regarding the decimated mesh: I use Blender, the automated decimate modifier, to reduce polys by 75%. The decimated looks similar to the full 3D model trunk from LOD4 distance.

[sheson]

15 minutes ago, tamrieltwo said:

I will check out Simplygon, ty.

So, I got it to work just leaving shader clamp as WRAP_S_WRAP_T. Can I ask what the downside of WRAP_S_WRAP_T is? As far as I can tell, it looks like it's working.

Regarding the decimated mesh: I use Blender, the automated decimate modifier, to reduce polys by 75%. The decimated looks similar to the full 3D model trunk from LOD4 distance.

The most important optimization of LOD happens if it combines several different shapes into a single shape with one atlas texture to reduce drawcalls. That can only work if the UV is within the bounds of its specific LOD texture on the atlas texture.
LODGen will attempt to update the UV accordingly in case it is outside. It might have worked or the LOD is just using the full texture as is instead of the atlas texture.
If you have there are many of the same trees in the covered area, they will still be merged of course, just not with any other LOD, so in single case the performance impact is not noticeable but it will be a problem if each BTO ends up with several dozen shapes.

Decimating a mesh can have better results when ignoring normals, vertex colors, material boundaries etc. and first repeating holes, welding vertices.

Clamping the crown seem to work as is, right? Its UV is slightly over the limit where it should work out.

[Mousetick]

DynDOLOD 3a155 / DLL NG + Scripts 3a12

The dynamic LOD of certain references is not disabled when full models are loaded.

Dynamic LOD | Full Model

The above shots are just 2 instances. Upon closer inspection, all dynamic LOD of the same mod, or perhaps of all references with the same Enable Parent, not sure, is affected. The mod is Environs - Whiterun Watchtower Doesn't Stay Broken.

I haven't done an extensive check but other dynamic LOD works fine, such as Hearthfire houses.

Logs and other relevant files: https://drive.google.com/file/d/1ssrM9OwD-gSECDe9VrwLA5Szcdawq535/view

Thank you.

[tamrieltwo]

26 minutes ago, sheson said:

Clamping the crown seem to work as is, right? Its UV is slightly over the limit where it should work out.

Yeah, CLAMP_S_CLAMP_T on the crown works perfectly, it only fails with the trunk.

I'm using Simplygon now. I'm trying to constrain the trunk UV between [0,1] so that I can use CLAMP_S_CLAMP_T. Do you know what option I should try?

Basic options:

 

Advanced options:

I tried the ReductionPipeline. It decimated the mesh (50% less polys on trunk), but the UV mapping still appears to be the same as before (i.e. not in [0, 1]).

Btw, this is the original full model before decimation of the tree Im working on from NOTW: pinus04.nif

[sheson]

58 minutes ago, tamrieltwo said:

Yeah, CLAMP_S_CLAMP_T on the crown works perfectly, it only fails with the trunk.

I'm using Simplygon now. I'm trying to constrain the trunk UV between [0,1] so that I can use CLAMP_S_CLAMP_T. Do you know what option I should try?

Basic options:

 

Advanced options:

I tried the ReductionPipeline. It decimated the mesh (50% less polys on trunk), but the UV mapping still appears to be the same as before (i.e. not in [0, 1]).

Btw, this is the original full model before decimation of the tree Im working on from NOTW: pinus04.nif

Under Aggregation check SubdividedGeomtryBasedOnUVTiles and set the slider to 1.

[adancau]

20 hours ago, sheson said:

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen debug and bugreport.txt if it exists to upload.

See https://dyndolod.info/Messages/Exceptions#OpenGL which should open when clicking the link "Click on this link for additional explanations and help for this message" of the message prompt.

Having the same OpenGL framebugger objects unsupported issue with the latest Nvidia WHQL Game ready driver (545.84, released Oct 17). Attaching the requested files.

 

Logs.zip

[sheson]

On 10/20/2023 at 4:19 PM, adancau said:

Having the same OpenGL framebugger objects unsupported issue with the latest Nvidia WHQL Game ready driver (545.84, released Oct 17). Attaching the requested files.

Logs.zip 689.93 kB · 0 downloads

Do not install newer alpha version over older versions. Read 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\.

https://dyndolod.info/Updating

If the problem persists after properly unpacking the DynDOLOD Standalone into a new and empty folder, edit D:\Mod Repository\Skyrim SE & VR\tools\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini with notepad and add GLDebug=1 to the INI and then run again and upload that log and debug log and bugreport.txt if it exists.

If problem persists, add RenderSingle=1 under [TexGen] to see if it makes a difference.

If not, also add RenderTexturesSingleThread=1 to the INI and test if that makes a difference.

[adancau]

3 hours ago, sheson said:

If the problem persists after properly unpacking the DynDOLOD Standalone into a new and empty folder, edit D:\Mod Repository\Skyrim SE & VR\tools\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini with notepad and add RenderSingle=1 under [TexGen] to see if it makes a difference.

I did a clean install, but it didn't help. I added the RenderSingle=1 afterwards, and that allowed it to complete, but it took 20 times as long. For the kicks, I removed RenderSingle=1 afterwards and re-ran, and got the framebuffer objects unsupported again.

For whatever it's worth - last time I ran this version of TexGen was before the Nvidia driver update - and I had no issues. In fact I have not had any issues with TexGen/Dyndolod in a very very long time.

[z929669]

3 hours ago, adancau said:

I did a clean install, but it didn't help. I added the RenderSingle=1 afterwards, and that allowed it to complete, but it took 20 times as long. For the kicks, I removed RenderSingle=1 afterwards and re-ran, and got the framebuffer objects unsupported again.

For whatever it's worth - last time I ran this version of TexGen was before the Nvidia driver update - and I had no issues. In fact I have not had any issues with TexGen/Dyndolod in a very very long time.

As explained in several posts previously, the long gen times can be caused by driver-related software (some might say 'bloat'). Disabling all such software via Task manager such that only the NVIDIA/AMD drivers are at work rather than the post-processing --and other 'fancy' algorithms employed by some driver-related software-- are not interfering can vastly improve generation time. Example: I disable all of my AMD sortware, including Adrenaline, when generating any LOD.

[NeedsMoreBirds]

I've been fiddling about with my mod list again, trying out different grass and foliage mods and also decided to give ENB water a go. I'm having trouble generating for Solstheim again, though: https://paste.ee/p/tgBuK

[sheson]

3 hours ago, NeedsMoreBirds said:

I've been fiddling about with my mod list again, trying out different grass and foliage mods and also decided to give ENB water a go. I'm having trouble generating for Solstheim again, though: https://paste.ee/p/tgBuK

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

Is the error 100% repeatable if you just Execute LODGen again in expert mode for just Solstheim?
https://dyndolod.info/Help/Expert-Mode#Execute-LODGen

Do you mean this mod https://www.nexusmods.com/skyrimspecialedition/mods/37061?
Does the error not happen if you remove the mod again?

[adancau]

13 hours ago, z929669 said:

As explained in several posts previously, the long gen times can be caused by driver-related software (some might say 'bloat'). Disabling all such software via Task manager such that only the NVIDIA/AMD drivers are at work rather than the post-processing --and other 'fancy' algorithms employed by some driver-related software-- are not interfering can vastly improve generation time. Example: I disable all of my AMD sortware, including Adrenaline, when generating any LOD.

I have nothing else apart from the drivers themselves. Normally generation takes about 5 minutes, but setting RenderSingle=1 in order to bypass the opengl error made it take more than an hour. I assume this is because it runs a single thread rather than doing multithreading as normal.