sheson Posted October 20, 2023 Author Posted October 20, 2023 On 10/20/2023 at 9:36 AM, 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 Expand 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 Posted October 20, 2023 Posted October 20, 2023 On 10/20/2023 at 9:53 AM, 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. Expand 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 Posted October 20, 2023 Author Posted October 20, 2023 On 10/20/2023 at 10:10 AM, 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. Expand 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 Posted October 20, 2023 Posted October 20, 2023 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 Posted October 20, 2023 Posted October 20, 2023 On 10/20/2023 at 10:24 AM, sheson said: Clamping the crown seem to work as is, right? Its UV is slightly over the limit where it should work out. Expand 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 Posted October 20, 2023 Author Posted October 20, 2023 On 10/20/2023 at 11:31 AM, 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 Expand Under Aggregation check SubdividedGeomtryBasedOnUVTiles and set the slider to 1.
adancau Posted October 20, 2023 Posted October 20, 2023 On 10/19/2023 at 5:45 PM, 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. Expand 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.zipFetching info...
sheson Posted October 20, 2023 Author Posted October 20, 2023 On 10/20/2023 at 2: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 Expand 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 Posted October 20, 2023 Posted October 20, 2023 On 10/20/2023 at 2:38 PM, 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. Expand 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 Posted October 20, 2023 Posted October 20, 2023 On 10/20/2023 at 5:41 PM, 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. Expand 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 Posted October 21, 2023 Posted October 21, 2023 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 Posted October 21, 2023 Author Posted October 21, 2023 On 10/21/2023 at 4:14 AM, 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 Expand 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 Posted October 21, 2023 Posted October 21, 2023 On 10/20/2023 at 9:09 PM, 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. Expand 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.
tamrieltwo Posted October 22, 2023 Posted October 22, 2023 I'm getting an issue: DynDOLOD is choosing the wrong passthru_lod file. It's choosing pinus04_599919f0passthru_lod_80pct.nif (an old file in the same folder that I renamed) instead of pinus04_599919f0passthru_lod.nif. Why's this? This is my 3D LODs folder: pinus04 in Tree Report: Quote TreePineForest04 "pinus 04" [TREE:0004FBB0] Meshes\landscape\trees\nature_of_the_wild_lands\pinus\pinus04.nif [CRC32:599919F0] using textures\true forest\pinus\new\atlas_pine.dds, textures\true forest\pinus\new\atlas_pine_n.dds, textures\true forest\pinus\new\atlas_pine_sk.dds, textures\true forest\pinus\new\cap.dds, textures\true forest\pinus\new\cap_n.dds, textures\true forest\pinus\new\trunk_3.dds, textures\true forest\pinus\new\trunk_3_n.dds, textures\true forest\pinus\new\bark_4.dds, textures\true forest\pinus\new\bark_4_n.dds New tree, Billboard found, 3D LOD model found Billboard_0: textures\terrain\lodgen\skyrim.esm\pinus04_0004fbb0.dds, textures\default_n.dds Billboard_1: textures\terrain\lodgen\skyrim.esm\pinus04_0004fbb0_1.dds, textures\terrain\lodgen\skyrim.esm\pinus04_0004fbb0_1_n.dds Billboard_2: textures\terrain\lodgen\skyrim.esm\pinus04_0004fbb0_2.dds, textures\terrain\lodgen\skyrim.esm\pinus04_0004fbb0_2_n.dds Level0: meshes\dyndolod\lod\trees\pinus04_599919f0passthru_lod_80pct.nif [CRC32:9B3E1EF8] using textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_1.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_1_n.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_2.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_2_n.dds, textures\true forest\pinus\new\atlas_pine.dds, textures\true forest\pinus\new\atlas_pine_n.dds, textures\true forest\pinus\new\atlas_pine_sk.dds Level1: meshes\dyndolod\lod\trees\pinus04_599919f0passthru_lod_80pct.nif [CRC32:9B3E1EF8] using textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_1.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_1_n.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_2.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_2_n.dds, textures\true forest\pinus\new\atlas_pine.dds, textures\true forest\pinus\new\atlas_pine_n.dds, textures\true forest\pinus\new\atlas_pine_sk.dds Level2: meshes\dyndolod\lod\trees\pinus04_599919f0passthru_lod_80pct.nif [CRC32:9B3E1EF8] using textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_1.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_1_n.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_2.dds, textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\pinus04_599919f0_trunk_2_n.dds, textures\true forest\pinus\new\atlas_pine.dds, textures\true forest\pinus\new\atlas_pine_n.dds, textures\true forest\pinus\new\atlas_pine_sk.dds Dynamic: Meshes\landscape\trees\nature_of_the_wild_lands\pinus\pinus04.nif [CRC32:599919F0] using textures\true forest\pinus\new\atlas_pine.dds, textures\true forest\pinus\new\atlas_pine_n.dds, textures\true forest\pinus\new\atlas_pine_sk.dds, textures\true forest\pinus\new\cap.dds, textures\true forest\pinus\new\cap_n.dds, textures\true forest\pinus\new\trunk_3.dds, textures\true forest\pinus\new\trunk_3_n.dds, textures\true forest\pinus\new\bark_4.dds, textures\true forest\pinus\new\bark_4_n.dds Mask: tree File: C:\Games\Modding\DynDOLOD 3\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_Medium.ini LOD4: Level0 LOD8: Billboard1 using internal LOD16: Billboard1 using internal Expand Full logs: https://file.io/fS0zu3pc2CvD pinus04_599919f0passthru_lod.nif: pinus04_599919f0passthru_lod.nif pinus04_599919f0passthru_lod_80pct.nif: pinus04_599919f0passthru_lod_80pct.nif
sheson Posted October 22, 2023 Author Posted October 22, 2023 On 10/22/2023 at 11:59 AM, tamrieltwo said: I'm getting an issue: DynDOLOD is choosing the wrong passthru_lod file. It's choosing pinus04_599919f0passthru_lod_80pct.nif (an old file in the same folder that I renamed) instead of pinus04_599919f0passthru_lod.nif. Why's this? This is my 3D LODs folder: pinus04 in Tree Report: Full logs: https://file.io/fS0zu3pc2CvD pinus04_599919f0passthru_lod.nif: pinus04_599919f0passthru_lod.nif pinus04_599919f0passthru_lod_80pct.nif: pinus04_599919f0passthru_lod_80pct.nif Expand This is because filenames with numbers that it tries to apply to lod levels take priority. If you want to ensure that a nif in the data\meshes folder is not used use MO2 hide feature.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now