Phlunder

No update that caused the issue to appear to my knowledge. I'm always using the latest Nvidia driver, which is currently 546.33. But thank you for making me look into other causes. INI settings for mip maps are default, but I found that the issue is caused by using the default ingame AA (I believe its MSAA), when I switch to FXAA the issue is gone. I also don't have this issue in my modded setup that uses ENB and its built-in AA methods. Edit: Changing the Texture Clamp Mode to WRAP_S_WRAP_T didn't fix it. I guess its just something with the games built-in MSAA that causes issues. Not sure if its worth rolling back drivers for it, I am fine with using FXAA if I want to jump into my vanilla setup.

I couldn't find any inconsistencies in the atlas layout/placement either, that's what I checked first. Here's an example reference: Here is the BTO file of that cell cluster. Tamriel.4.4.-12.bto I am not entirely sure how to check the UV sets. I found many, some say 0.25 on the Y axis, others not.

I'll do so once I'm at home.

It is hard to make close up screenshots of it, because those lines are mainly visible in far away mip maps. All trees are affected. Here are the full logs and alpha atlas: Logs + Alpha Atlas LODGen_TES5_ObjectAtlasMap_Tamriel.txt

Hey sheson! Since some of the latest updates, tree LOD (ultra using Billboard4 in all stages) is showing a small cross at the top. Like UVs were very slightly out of range for the billboard, or there was some other offset in the atlas. I only ran into it testing with my vanilla profile. Everything was generated fresh with Alpha 165. Logs

That fixed it! I also removed the passthru before generating.

Yes that's clear to me, I was just wondering why it does that even though the emit settings are different. Here are all the meshes used, the only thing I changed for the correct emit settings to be applied was hiding everything else but the epic mushroom LOD mesh, and I added "passthru" to its filename: Blackreach LOD Meshes As soon as I use them together, it applies the emit settings of the other mushroom LOD meshes to the epic mushroom.

Thanks for testing! I edited my post above with a link to the BTO Mesh. It seems to work as a singular LOD mesh, but in the Blackreach worldspace, it combines it with all the other smaller glowing mushrooms, and also uses their different emit settings. Is it because they use the same texture? Edit: Just wanted to confirm my theory. When I remove the LOD resources for all the other glowing mushrooms, the correct emit settings are used on the epic mushroom LOD mesh: Already tried the passthru for filename/shapes as well without any luck.

Sorry, the epic mushroom in question has the base ID DB9CE, ref ID DB9CF: The LOD mesh has exactly the same emit settings as the full model, it mostly still is the full model, so far I just removed some small parts inconsequential or unsupported by LOD. I wanted to check how the glow matches before reducing the mesh further/merging the shapes etc. WIP LOD Mesh I'll try adding passthrough to the relevant shapes/filename. Dynamic LOD would be an option as well for this specific case, and maybe the Blackreach sun too, thanks. Edit: I checked the BTO and the epic mushroom indeed uses the same emit settings/color as all the other mushrooms, and not his own: BTO Mesh

Hey sheson! I have a question regarding the glow/emit effect in object LOD. I made some resources for Blackreach assets that were lacking LOD so far, to reduce the jarring pop-in of large glowing objects in that small worldspace. As its not possible to directly use the layered effect shaders that are used for the full model, I attempted to manually adjust the glow so it matches the full model good enough. This worked for all of the regular mushrooms and tendrils hanging from the ceiling. But for the big/epic mushroom in the middle, it seems to ignore the different color of glow/emit effect. I attached some screens and relevant logs if it helps. Maybe I am just misunderstanding how exactly the emit effect is even supported in LOD, it just seemed to have worked for all the other assets: Logs General overview how LOD meshes with glow/emit are displayed in LOD (still needs some adjusting to match): The difference of the epic mushroom, that seems to not use the glow/emit color as set in the LOD mesh:

That fixed it, thanks!

Editor ID is: skyrimesm_01B1F1_WhiterunMainGateRef_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD

I have no mods adding a new gate reference there. I also did a reverse search for the references of the 2 base records listed. The only thing is USLEEP editing the position of the child world gate reference. Here is a screen, I disabled the interior gate so its better visible:

Great work on the latest update, does a lot for consistency in child worldspaces! I tried both child > parent and parent > child options. So far, the only thing I ran into was that the exterior Whiterun gate is added to the child worldspace, but you only see it clipping through when you exit and the gate opens. Working flawless otherwise. If needed, logs are here. And sorry if I missed it, but how does the reference copying work in case of the Markarth worldspace?

I noticed that a while ago too, and it bothered me that most of the structure on Valtheim Towers is missing, at least in the very first LOD stage (these beams are too small for any further distances) so I made a very minimalistic LOD mesh for that one beam type. I uploaded it here.

Just a short question regarding the DynDOLOD Resources 3 Alpha-32 for LE. The passthru LODs for vanilla trees don't use the generated trunk billboards, and don't create crown textures from the full ones. They still use the prepared atlas in Textures\DynDOLOD\lod\dyndolodtreelod.dds. The SE resources have the correct passthru meshes. No logs, just wanted to ask if its intended that the LE resources didn't get the latest passthru meshes.

Sorry for the late response. Only now I get why you think my screenshots are using TFC... which would be a strange and useless comparison indeed. In SE, these meshes are FarGrid large references. So you basically start seeing those meshes in ~LOD8 stage, which is incredibly far away. Obviously, that system doesn't exist in LE, so you see those meshes right from the first LOD stage.

I always try to keep an eye out for conflicts with the DynDOLOD Resources when I work on things, and I noticed that in Alpha-29 you included most mountain LOD0 meshes now. The only change I could see is that the Vertex_Alpha flag was removed. Should I carry this change forward, as I am working on improved LOD0 mountain meshes?

Have you checked out the Beyond Skyrim - Bruma section on the DynDOLOD page? https://dyndolod.info/Mods/Beyond-Skyrim-Bruma

Yes, using this version fixed all issues regarding these trees. Also this one below I overlooked: Left: Alpha-102 - Right: Test version Thanks again!

I have another question about the additional Enderal billboards. I realized that the only ones that made sense for billboard use are trunk01_000880fa, trunk03_00088146 and trunk05_00088148. TexGen now generates normal maps fine after I updated tangents and faced vertex normals. It all looks fine, apart from the first side view of trunk05_00088148. The preview looks ok, but the actual texture output has a transparent square in the trunk: Here are the TexGen logs.

That indeed fixed it! I just updated tangent space for all of them, not sure if something else is necessary, but looks fine now! Thanks a lot.

Oh my, I seemed to never have updated my paths in MO2 for DynDOLOD/TexGen for my Enderal setup. Sorry for that. Works fine with x64 version!

It is always a different texture, ridgedstonewall and now cavebasewall05. I also set the RenderThreads to 1 in the TexGen_ENDERAL.ini but I get the same error. I'll see if a reboot fixes it, but I never seen that problem before on my system/setup either.

I ran into an issue with Alpha-101 using TexGen for Enderal LE. The process seems to run out of memory with a vanilla texture. Another issue I had with earlier versions as well is that for a few tree types (as statics) that I flagged with Has Tree LOD and given proper bounds, TexGen doesn't generate normals (just flat ones). One example for that would be 000880FA;_00E_TropicalTree_Trunk01. Here are the logs.