Phlunder

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.

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.