sheson

Make the first one more like: fTreeLoadDistance affects the distance from the center cell how far traditional billboard tree LOD is rendered (as opposed to 'full' trees closer to the PC) Second one should not really say "object tree LOD". Object LOD is a NIF with a list of combined shapes that share the same shader/textures that have no relation anymore to what they actually depict. To the engine its just triangles to render. Hence the phrase trees done in object LOD, just as mountains or structures are done in object LOD.

You want to fix the "Could not be resolved" and "Mesh -> Found a REFR reference, expected: NAVM" errors.

From "How LOD works": "Skyrim separates the LOD into 3 different types, the landscape and (large) bodies of water in the *.btr files, the objects in the *.bto files and trees in the *.btt files." "The landscape *.btr and the object *.bto files are actually nif meshes. The tree *.btt files are an index of x, y, z positions and tree type index numbers. The tree type index numbers point to data in the *.lst file." "The *.lst file contains the positions and dimensions of tree billboards on the tree LOD atlas texture. The tree LOD system uses this data to build 2 rectangular planes for the 2D billboard tree LOD." From Terminology: "Static object LOD generated by LODGen.exe are objects that do not change and are not animated, like buildings or landscape features like mountains and rocks." "Tree LOD generated by xLODGen for Trees LOD (or CK) are so-called billboard trees that uses two simple 2-sided rectangular models using the gams engine to display traditional tree LOD." "Tree LOD in static Object LOD is LOD trees done as static object LOD. This can be 3D static trees, billboards or a mixture of both - hybrid LOD trees." From the ultra tree LOD manual: "This will turn off traditional tree LOD generation in DynDOLOD.exe and create an empty OUTPUT PATH\Meshes\Terrain\Tamriel\Trees\Tamriel.lst file. This file causes the game to disable all tree traditional billboard tree LOD. Alternatively set fTreeLoadDistance=0 in SkyrimPrefs.ini or the DynDOLOD MCM Settings page." Of course fTreeLoadDistance does not affect object LOD. The fBlock* settings affect object LOD.

Remove all patches for open cities as well when doing the first pass. E.g. notice board - open cities patch.esp

Multithreaded access to the terrain texture cache that wasn't made fully thread save.

Also upload the DynDOLOD_SSE_log.txt which should contain both generations. Also would be good to have a debug of the first generation. Remember it gets replaced because it so large.

The setting does what it says: It is loading distance for trees. See "How LOD works in Skyrim" in the DynDOLOD manual. The Settings page of the DynDOLOD Skyui MCM

Fix (Resave in CK or xEdit with the Clamp FormID expert option checked) or permanently remove the broken plugin with all the HITME errors. I will need to elevate that to a stop error. Check the load order for errors with xEdit. They should be fixed as much as possible. If the error still happens then, upload the new logs and bugreport,

Make sure to carefully read how to set up those two mods together, The last plugin to overwrite wins. The last plugins set a model, which defines a texture. Those are the things to check. If there are error messages in the logs about missing normal map textures it means they might be substituted by the default flat normal. But it is more likely to be a problem with the mods modifying the shaders and the texture used by it.

A used mesh list with or without count is not created anymore atm. The export file is the export file for LODGen. It has a line for every reference that has a static object LOD, obviously.

Use tfc to make screenshots of LOD close up. Make all screenshots in daylight. Is there any difference compared to LOD generated by DynDOLOD 2.x? Read the first the post what log files to upload/page when making posts. TexGen/DynDOLOD do not change the snow LOD shaders, which is what is is applied onto the object LOD live in the game . Check in xEdit which plugins modify the material object shaders with form id 00050372 and 006AE38. TexGen updates object LOD textures from the currently installed full textures in the load order. The normal map might affect the snow shader. DynDOLOD uses whatever object LOD textures are currently installed in the load order to add them to the texture atlas. If normal maps are missing or are low res when TexGen generates object LOD textures or DynDOLOD adds textures to the LOD atlass, I could imagine how that might make the snow LOD shaders look bland.

Read the first post what log files to include when making reports.

This has nothing to do with Occlusion. For Open Cities generate LOD as explained in the manual. It requires two passes.

Correct. Lower values will make it darker.

Start by reading the first and second post.

Not sure what the problem is. xLODGen/DynDOLOD generate object LOD for objects added by plugins in the load order. If you do not like certain objects in the game, remove them from the plugin or remove the mod. Then generate LOD for the new load order. Remove any other LOD files in case they are not being overwritten.

Great! Uploaded as terrain LOD beta 81.

The Improved Mountain LOD and Z Fight Patch does add mountains far up north in the cells, though. LOD only works and looks correctly for the load it was generated for. Pre-made LODs are always wrong and nobody should be using them. They are just a waste of time, especially for the users. As explained in the manual, TexGen/DynDOLOD output always needs to overwrite everything. If there are pre-made LOD files in the load order for coordinates for which there is no data in the current plugins, then no new files will be generated to overwrite them and the engine will load and show those files obviously. The author of that mod list does not understand how LOD works.

TexGen uses the bounds to determine if a grass model should have a billboard generated automatically as is explained in the manual. There is also an alternative option to force generation of grass/tree billboards explained in the manual. The grass cache is generated by No Grass in Objects and its generation or what settings might influence it has nothing to do with TexGen/DynDOLOD.

There were no updates to the terrain LOD generation code after 75. This is still a beta test. Bugreport generation was added so we can troubleshoot better and fix the current version. Not sure why you posted the bugreport in a PM. Anyhow, based on that, test with this version: https://mega.nz/file/xUhyjYzS#NJsm-U7ejFK2eqU8LHqwtPwI1scID_yBYh-AF-tKs-4

You should be asking question related to the No Grass In Objects plugin on its comment section. AFAIK bounds do not affect the generated grass positions, though.

If there is a LOD model that matches the full model or a LOD model is defined on the base record, then DynDOLOD generates LOD for the reference using that base record. As it does since half a decade. If something doesn't have LOD as expected, then make a post about it.

Object Bounds NAM9 - Max Y of 141. Way more than the vanilla 51 They seem to be intentional. You can easily find the references by drilling down the Blocks/Sub-Blocks with high y numbers. E.g. Block 0,4 and Block -1,3 and you find they are added to cell -6,102 -2,97 and 8,140

Not sure what else you expect here. By this time you would have already found it by doing a binary search enabling/disabling plugins.

You could check the objects bounds of the worldspace records for Tamriel and all worldspaces that use it for LOD/SkyCell if there is a plugin that changes NAM9 - Max Y. None of them come close to 99 with their vanilla values AFAIK.