Phlunder

Just a heads up, Alpha-101 is called Alpha-57 on the Skyrim LE Nexus page. Correct version in the archive of course.

There's nothing to fix there, other than (roughly) blending the landscape texture with the used grass mod. Whiterun is one of the very few places where the difference will be obvious. The blending of grass in the first LOD stage actually looks perfect in your screen.

As I already said, there is no need to use full models. Just use LOD0 mountain meshes in all stages, they are reduced full models and use full textures so they will always match with your mountain retexture. This can be done with DynDOLOD rules:

You could use LOD0 meshes in all LOD stages, as they use full model textures. Otherwise LOD8/16 will be mismatched as they use custom created LOD textures not generated by TexGen. Also keep in mind that the MM DynDOLOD 3 pack redirects the normal map for LOD0 meshes to a custom texture so that will likely not fit to your retexture either.

That's caused by your direct/ambient lighting changes. The defaults are fine here, and work with every tree shape I've come across. As recommended by z929669 in an earlier post, don't do such drastic changes if you wanna tweak billboard lighting, maybe -10/+10 at most.

Sorry, just pure laziness regarding putting that on the existing mod page. Majestic Mountains has vanilla LOD0 meshes with UV and shader tweaks, maybe vertex colors too, didn't check. But not sure what is meant with premium. Edit: Apparently sheson has made new LOD meshes for MM on the SE page, sorry. These are indeed superior if you use MM. The vanilla LOD0 mountain meshes are of varying degrees of quality, sometimes they were just way to crude in shape for my tastes. Also, I always thought they looked too flat, some of that was because they lost the vertex colors of the full model, which gave them some fake AO and highlights, all around making them look more interesting.

I have to agree that a TreeMSAlphaThreshold of 144 really works well, so thanks to z929669 for the suggestion. But its mostly visible in lower mip map steps. At the distance you view those trees (LOD8-16) you only see much higher mip map steps, which alpha threshold/coverage will lead to a different outcome in terms of visuals appearance. I also think the lighting changes you did were too much, maybe tone it down a bit or revert to defaults of TexGen.

Sorry, I am still not sure what you are referring to. The "bump" is an improvement to the visuals in LOD16? As already mentioned, this is the furthest LOD step for object LOD (which is what ultra trees use) so the difference what you use there will be very minor. Call me crazy there, but the backlighting issue for Billboard1 was even apparent to me in LOD16, so I chose to just use Billboard4 there too. 128 is a good starting point.

I disagree, even LOD16 being Billboard1 is noticeable as they are brighter than anything else. I don't see the point of saving performance there, as Billboard4 is practically zero impact. In the end, the results and preferences are what you find works best for your setup. There is no "one right way".

A distance drop? What are you referring to?

Ah, now I get what you mean with red boxes, okay. There are no Level3 LODs for trees, so it will fall back to regular billboards in object LOD. Not sure what you mean with better distance? LOD16 is the furthest LOD step for object LOD, so the furthest you will be able to see them. If you don't want a visual difference between LOD8 and LOD16, use Billboard4 for both. Again, usually Billboard4 doesn't require you to make any brightness changes, they blend pretty perfectly with any lighting situation, so make sure to revert the tweaks you made.

If you use Billboard4 (use it for LOD8 and 16) you usually don't have to mess with brightness settings, so revert them to default. The brightness difference compared to full models mainly comes from backlighting, as regular billboards (Billboard1) are not double-sided. Not sure what you mean with red boxes? Provide a screenshot and logs if possible. I personally use Billboard4 in all LOD stages, its very performance friendly and looks great, and everything can be generated by TexGen on the fly, so the resources all look consistent.

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: