Phlunder

Thank you for the detailed explanation. I force Level0 mountain meshes in all LOD stages with a custom rule already, because I personally can't stand the vanilla Level1 and Level2 mountain meshes. Its not a performance concern, just wanted to err on the side of caution regarding optimization. Regarding automatic detection of LOD meshes, looking forward to future improvements. Its already impressive how much stuff is simply auto detected.

Sorry, already another mesh mask/rule question. I made Level 8 meshes for mountains, that still have the full texture assigned and differentiate between heavy and light snow coverage with the vertex alpha values. How can I make DynDOLOD recognize them with rules? Or is that only possible with a plugin? For example, instead of mountaincliff01_lod_1.nif I now have mountaincliff01_lod_1h.nif and mountaincliff01_lod_1l.nif and so on.

Yea I already have a text file to paste some of my mesh masks from. Found another way to filter out 2 meshes of a path that already has a rule applied, by creating a rule right above that acts like a filter.

Would it be possible for the Mesh Mask / Reference FormID field to allow multiple entries? Maybe its already a thing but I didn't find a way.

Apologies for getting back to you so late about this. Just wanted to report that changing the shape name in NifSkope to SovngardeStatue01Desert fixed it indeed!

Thanks for the resources Alpha-44 update! Just wanted to inform that sstuccowallint01.dds is missing. I copied it from the previous resources Alpha-43 and everything generated just fine otherwise.

Yea its like they faded it out for higher mip map steps to eventually make it completely flat. If you happen to update the resources for LE because of the lakesnow01_lod.nif, maybe you could also include the fixed impextbridge01_lod.nif? It still missing the Z translation in the resources for LE. Edit: Sorry just realized the resources weren't updated yet since I reported it. Referring to this:

Looks perfect now, thanks for looking into this! I assume this affected all rendered textures, also billboards for example?

Hm that is strange, apart from unofficial patches/engine fixes my game is 100% vanilla. I'll investigate further if its something on my side. Edit 1: textures\landscape\Snow01_n.dds is provided by vanilla BSAs. Edit 2: Wait, in the preview, it looks perfectly normal. Just when its rendered and saved, the normal map looks that intense: Edit 3: Here are the TexGen logs: https://drive.google.com/file/d/1orujy8PfMtcqrZ4OtPfvoGC-_Q2G64jr/view?usp=sharing I have the feeling all rendered textures are bumpier than they should be. They look fine in the preview, but not after they are generated and saved.

Yes that fixed it! DLC1IceSnow.dds was correctly generated as well. Only thing that is noticeable is some tiling, which turns out is due to the rendered normal map. It may be correct like this though, just not visible as much in the full model, as seen here: Thanks for looking into it!

Sure, here you go:

Hey sheson. Ran into another issue recently. With the latest DynDOLOD Resources 3 Alpha-43 and DynDOLOD 3 Alpha-196, the snowdrifts on the ice lake in Forgotten Vale are just squares. Couldn't figure out what the issue is when looking at the LOD mesh in question and the record of the full model. Base ID of the mesh in queston: 02004BE2 Logs: https://drive.google.com/file/d/1n5dLqYCRYnyNnWr3wAuZI7gIaDbDbZ82/view?usp=sharing

Thanks for checking the mesh, I will apply the suggested tweaks to it. In this case, the shape name really matched. Sometimes its a generic name from Blender instead. Ah yes, I also noticed that standard for the vanilla LOD resources, regarding the _LOD in the shape name, appreciate the explanation.

Thanks, I had no idea about that entry in the shader settings! Here's the object report: https://drive.google.com/file/d/1o3y9Wm0bnC9EG7LHm_x3346YTMPablv8/view?usp=sharing

First problem, yes it fixed the seams, but the UV is very messed up otherwise. Can't see it in Blender or NifSkope: Second problem is exactly the same:

Like this?

Hey sheson! Currently working on some additions for Enderal's LOD, and ran into 2 issues I wasn't able to figure out. First thing is a 3D tree LOD mesh for a particular crooked dead tree, that doesn't work well with billboards. Even if the model is solid, and its UVs are within the 0.0-1.0 range, it has a tears in it. Screenshot attached. The other is a variant of the Sovngarde statue (01) that is used in the Powder Desert. I made a unique LOD mesh for it, unique textures, UVs again within correct range, but DynDOLOD seems to create some other texture for it, that is not the one I assigned in the mesh. Screenshots of that also attached. Also the logs and the work in progress mod. The meshes in question are deadtree01_lod.nif as well as sovngardestatue01desert_lod.nif. Logs Enderal LOD Meshes

Oh I wasn't aware of that mod. I blended it now visually without separate glow meshes, but thanks anyway! I also noticed that the Dwemer roads used in Blackreach are missing LOD, but I might just reuse the road LOD meshes from the DynDOLOD resources for that, changing the assigned textures to Blackreach road textures. Or maybe sheson could include them in the resources? They seem to be carbon copies of the regular road meshes, just with blackreach road texture assigned.

Sorry, it was right in front of me and I just overlooked the main shader type was still MultiLayer Parallax. So if I change that to Glow Shader it should work, thanks! For now, I was just testing how I can match the glow to the rather special setup they used for the full models. I think it would suffice to limit most of the resources to lower LOD levels as you suggested. Should make no difference for the very limited Blackreach worldspace but some mods also add these to Tamriel and other larger worldspaces. Thanks for your input, much appreciated!

What are the requirements for LOD meshes to be recognized for glow/own emit? I've gone through the DynDOLOD info page about glow LOD, but its not what I am referring to in this case. I am trying to make resources for the larger Blackreach crystals. This worked fine for the Blackreach mushrooms, they are automatically added to the DynDOLOD_Blackreach_Glow atlas and also get the shader properties for glow. Somehow the crystals are ignored, even though they have exactly the same shader settings as the mushrooms. But maybe I missed something. If you have the time, its about blackreachcrystall01-05, wip resources are here.

Thanks for looking into it! My result is actually the same as yours, I just uploaded the wrong tree billboard normal map. I assumed its just how the model is built, that the parts facing away from the viewpoint are darker. The full model doesn't have that kind of shadowing from the same angle right when the cell is loaded. I guess it just comes from the size and shape of those models, they are much less uniform compared to vanilla tree meshes.

Another question regarding the TexGen billboard renderer. In some of the prior updates, the appearance of normal maps changed slightly. Since then, some of the billboards generated for Enderal specific trees are showing dark spots on the crowns. When checking the normal map of those trees in question, these spots are very bright, almost white. I am aware that the Enderal assets are kind of all over the place in quality/execution, so maybe that's just an issue with the meshes themselves. Some screenshots of the issue, logs are here.

Hey sheson! No logs today, I just wanted to report something with the latest DynDOLOD Resources 3.00 Alpha-43. The packaged impextbridge01_lod.nif is missing the Z-translation of the vanilla LOD resource, causing the LOD mesh to be offset on that axis and in relation to the full model.

Its less visible than before, but the issue itself persists. Edit: Its definitely better, and only visible in higher mip map steps.

Testing it now, but this executable won't be used if I'm running the 64-bit version of DynDOLOD? Even if I use the 32-bit version of DynDOLOD, it lists the LODGen.exe as external tools.