Phlunder

This helped a lot, thanks! I was able to use Sniff to batch apply the correct vertex color alpha values to the meshes. Just a small addition to that info: Not all L mountain LOD meshes use exactly 0.4 vertex color alpha. From the ones I covered for now, I found that mountainpeak01_lod_0l.nif uses 0.41 and mountainpeak02_lod_0l.nif uses 0.42. Probably not much of a difference from 0.4 regarding how heavy the snow cover is, but just FYI.

Yes, mrkbuildingslod01 is rendered by TexGen and matches perfectly, but the stairs used in Markarth have a different set of textures than the Nordic ruin assets. To be exact, they use: textures\architecture\markarth\MrkStairsChunky01.dds While the nordic ruin exterior pieces use: textures\dungeons\RidgedStoneStairs01.dds This might not be as apparent with vanilla textures because they are more similar. Here is an example using retextures: Thanks for explanation regarding the mountain LOD meshes, that clears it up!

Just seeing this now, and I gotta say this comparison seems kinda strange... there are enough proper comparisons on the mod page that show you what the mod actually does, even with completely vanilla texture setup. Not trying to convince anybody here, I don't really care if people use it or not.

No issues to report, all working fine here with Alpha-93! Just two questions regarding LOD resources. This is likely also the case with vanilla LOD meshes. All the nordic ruin stair pieces (example: Meshes\lod\nordicexterior\norextwallbgstairssingle01_lod_0.nif) use a part of Markarths LOD textures (textures\lod\mrkbuildingslod01.dds), which causes a mismatch using most retextures. Everything else is already auto generated and matching fine! For now, I just pointed them to another texture to fix it, but maybe it would be possible to auto-generate them too? The full models use \Textures\dungeons\ridgedstonestairs01.dds. Second question, I've been working on redoing the LOD0 mountain meshes, and ran into the "H" and "L" variants for LOD0, an example would be mountaincliff01_lod_0h.nif and mountaincliff01_lod_0l.nif. What exactly is the difference between these 2? They seem to be identical in NifSkope.

Hey sheson, I'm trying to work on LOD meshes for some more Enderal objects. I just have a small question regarding the UV range of 0.0-1.0 so the textures can be added to the atlas. How can I see this UV range in NifSkope? Its probably not a good thing to show screenshots here, but does the 1.0 range refer to the original texture shown in the blue square in the middle, or the 8 tiled squares outside, I marked in red here? Would it suffice to bring the UVs into that range? I marked those ranges after the fact, of course, just to show what I mean. The goal is to keep the full texture assigned, like you did for many LOD assets, so DynDOLOD can automatically create downscaled textures from the full ones, and add them to the atlas. It worked before for other assets I worked on, but I'm not sure how to interpret the UV range. Sorry in advance if its off topic.

Just wanted to report that with the latest update (Alpha-77) all the Enderal trees/trunks as statics with added Has Tree LOD flag (and required bounds/volume) are now picked up by TexGen properly. Thanks a lot! Just for reference, one of these was _00E_TropicalTree_Trunk01 [STAT:000880FA] for example.

The Form ID isn't mentioned in the debug log at all (its also linked in my original post I quoted). I checked the object bounds and they exceed the minimum threshold. Edit. Sorry, after checking again I see that at least 3 of the variants have no object bounds set. All the others (and the one in question) do however, and are exceeding the threshold as mentioned.

I can confirm that the Has Tree LOD flag works in other cases, like the static DLC1TreeWinterAspenSnow01 [STAT:0200CE13]. Though with the Enderal tree mentioned in my previous post, _00E_TropicalTree_Trunk01 [STAT:000880FA], adding the flag does nothing. Are there any other requirements than the flag and volume for it to be detected, or do I have to solve this with a dedicated LOD mesh? That's fine too of course, just trying to understand the requirements.

Thank you, I could swear I already tried that, but I'll give it another go! Edit: Hm, no that didn't work. I tried to give the tropical tree trunks that are very commonly used in the Powder Desert billboards, one of them would be _00E_TropicalTree_Trunk01 [STAT:000880FA] for example, or the ref ID 99544. I added the Has Tree LOD flag to all of them (in the Test.esp), but they weren't picked up by TexGen. Here's the TexGen log: https://drive.google.com/file/d/1xTA-q8l-qnqOT8wLhL-cqsqnJ0gQQA6P/view?usp=sharing

How do I handle trees that are statics, when I want TexGen to pick them up for billboard creation?

Ahh, that makes sense. Adding the mesh rule fixed it indeed. Thanks for looking into it!

Here is the Level 4 BTO file for that area: https://drive.google.com/file/d/16CILX3YKEJiqzqEPEwVeYkGyBO9BwGek/view?usp=sharing Indeed, these tree LOD meshes look different even in NifSkope:

Sorry, atlas was a bad idea without further info. I also tried several times of day, and yes the trees in the foreground are loaded and of the same type of course, to show the difference. Here are the base IDs, I hope I got them all: 88025 8671B 86726 8671F 86724 8813F 88102 Some better comparisons. I picked a time of day were the issue is most visible. Seems like backlight influence, though Billboard4 is used? The 3rd shot shows such a tropical tree next to a vanilla tree billboard:

I've seen these errors, unfortunately Enderal has a few of those. I will look into covering those missing normals. I checked the normal map atlas for the tree LOD, and the only thing that stands out is that the trunks of some of the trees have flat normals, the crown is always covered. And two tree types not shown in the screenshots have flat normals too. Here's the output atlas, if it helps: https://drive.google.com/file/d/1EaqpfUik1h8DTPHO3tuy1ap7nF9YG78i/view?usp=sharing I thought its maybe something with those trees brightness too, but then again, there are other trees in the game (and in vanilla Skyrim) that are brighter, like snow pines, and they don't have this issue. They are also seen in the screenshot. Near the glaciers.

Hey sheson, thanks for updating so fast to include the new resources for Enderal! They work great! If you remember, quite a while ago I posted some pics of visual artifacts when using ultra trees in Enderal. You were right back then, it was the fault of some of the custom tree models in Enderal. I was finally able to fix these meshes, so they don't show visual artifacts when fading in from object LOD. The results are great, and I'm happy to finally be able to use ultra trees (Billboard4) in Enderal: The only thing that still gives me headaches are the tropical trees. There is now great blending for all tree types, but for some reason these are unnaturally glowing. I can't figure out why. I included a shot where you can see other tree LODs that look fine from the same view point. ENB is not used in the shots, and I also tried other weathers (fw 81a) but its always the same result: An example reference would be 11F62D. Logs are here: https://drive.google.com/file/d/1iavFfJ24R-tDT1hqwuxLolyApltIvdPi/view?usp=sharing

No issues to report, Alpha 73 working great here! I have a small suggestion regarding the LOD resources for Enderal. The Powder Desert has a variation of Blackreach pillars which are missing LOD. DynDOLOD's Resources already cover the Blackreach variant, the only difference of the Enderal variant is that the top part has a sand texture assigned. Maybe it would be possible to reuse the Blackreach pillar resources here? The statics in question are: _00E_SandDesertPillar01 [STAT:000431DA] _00E_SandDesertPillar02 [STAT:000431DB] _00E_SandDesertPillar03 [STAT:000431DC] _00E_SandDesertPillar04 [STAT:000431DD] _00E_SandDesertPillar05 [STAT:000431DE] _00E_SandDesertPillar06 [STAT:000431DF] An example reference would be 6216C.

Reducing fBlockLevel0Distance to 44000 fixes it in 99% of cases in FO4. Since using that value, I personally didn't run into that issue at all anymore. Its another value in SSE but using DynDOLOD and sheson's suggested settings I never seen it there either.

I didn't see an increase. Not sure if I'm looking in the wrong place though. I brought the UVs into the 1x1 range with NifSkope. Covered all Riekling architecture now. They all use shared textures from the atlas, and it all works on the fly when generating with DynDOLOD, very nice! They are probably still a bit too detailed, but I guess its fine:

Thanks for all the helpful insight. I am not sure how to check triangle count after generating LOD. Are you referring to the model in the BTO mesh? Regarding UVs, for these models it was relatively easy to get them in the 1x1 range, as they were in 2x2 range by default. It was just daunting to do that for models like the glaciers. The models are indeed very small so I'll see what works best there, maybe isn't necessary to have them in all LOD stages. For now I just created a single LOD model for each object. I know that this wouldn't work with ones that have many references. The models also aren't as optimized as the ones in the DynDOLOD Resources or vanilla game, I am aware of that. I always try to reduce them to roughly 1/5th their full model poly count/vertices but at a certain point it breaks the shape and UVs. And yes I inherited the NiTriShape names and structure of the model. I realize that on a big scale with many references (Tamriel worldspace mostly) these models wouldn't be ideal. But Solstheim is too small for any impact probably.

Just a short report on DynDOLOD 3.00 Alpha 60 working as intendend! I started cover some of the Riekling architecture. Created decimated meshes, and tweaked the UVs inside the range of 0.0-1.0 as you suggested. I kept the full texture assigned in the model. DynDOLOD automatically created downscaled textures from the full ones and added them to the atlas. I didn't assign any LOD to the static record, DynDOLOD picked it up automatically from the standard naming scheme I used (I guess?) "full model name"_lod.nif. I also tried Simplygon, but its Blender plugin seems to be broken right now... but the native tools helped as well. If this doesn't belong here, feel free to tell me so!

I used Billboard1 with HD Tree LOD in object LOD for quite a long time now, and while it does react better to light than regular billboards, Billboard4 is really perfect now. I'll try not to miss your suggestions the next time, the whole site has always been a great resource for me!

That makes sense. It just took me a while to figure out it was even an option. Its a drastic improvement, and its performance friendly too. Great alternative to 3D tree LOD indeed, as stated on the info page.

While reading through your new info page, I stumbled upon your suggestion to try Billboard4 for HD Tree LOD in object LOD. I have to say, I am blown away. I never saw such good blending and reaction to lighting from billboards. No need to change anything about lighting settings in TexGen either. Perfect blending with every setting on default - with or without ENB - no matter which weather mod. This is great, I just wanted to leave a big thank you - again! I just have one question: Why isn't this setting used by default?

Your suggestion worked out perfectly. The fact that this texture is slightly darker helps, because of the slight visual difference that is still there due to LOD not supporting parallax. The effect does make the mesh darker - kind of - so that's a perfect match. I will just assign this texture for all of them. Yes, its funny that people just notice the flickering/Z-fighting on transitions now... I reduced the scale to 0.99 and it fixes it, but of course the mesh "grows" a tiny bit on transition from LOD to full model. I guess this is due to glaciers being such large objects to begin with. I'll see what value works best. Screen using glacierslabnoalpha.dds/glacierslabnoalpha.dds_n:

It seems it didn't work out, they didn't use the full textures as assigned in the mesh, and the UVs seem to be broken. I didn't see anything before atlas creation regarding glacierslab textures in the log. Log: https://ufile.io/f/8af5s Mesh in question is base ID 0401b927, ref ID 0401459b: Another small question. People are complaining about a slight Z-fighting on LOD transition. I know this is because I didn't change the size/scale of the LOD meshes when creating them, compared to full model. Could I use the scale option of the NiTriShape in NifSkope to just scale them to say 0.95 or 0.9 to fix that?