sheson

LOD for a worldspace is always loaded. It is enabled/disabled for the areas where cells are attached. If you want to find out if a specific LOD type might have the highest impact on resource usage, then disable only it. Easiest via settings,

Testing lower game settings is typically a way to start. For testing LOD, For disabling specific LOD types only help. Reading the manual helps. Understanding that rendering grass or grass LOD outside the loaded cells really requires performance and resource no matter what. It doesn't come free.

Don''t overload the system with a too busy load order, large textures, large models, high settings etc.. That applies to everything, full or LOD models and textures, grass etc. The LOD mod is created based on the load order on your choices helps. It typically contains 3 LOD types that work independently of each other. All have their own creation options, models and textures and settings in game.

LOD does not typically cause stutter since LOD is always loaded. Unless maybe available memory is really low. It is typically the loading of the cell and its full models. Make sure that No Grass in Objects has OnlyLoadFromCache = True

You can always test defaults. But also have an eye on the installed billboards and any other mods supplying LOD textures, like HD LOD. If none of that helps. Do a test run with DynDOLOD 3 alpha. It is is more robust and has somewhat better error handling.

The error happens while generating the object LOD atlas. There might be a problem with a texture DynDOLOD is trying to read. Unfortunately none of the files give a hint which one it might be. What texture size did you set in TexGen?

Grass billboards and grass LOD can be generated with any grass mod in the load order. It is all explained in second post and its source ..\DynDOLOD\docs\help\GrassLOD.html and the rest of manual. A couple posts back, the user gigan2 uploaded his TexGen config file for Tamrielic. Either that or updating the objects bounds with CK to make sure all grass billboards are created.

DynDOLOD is a set of tools that generates a LOD mod based on the load order and options/settings made by the user. The visual results and the performance impact are what the user chooses it to be. The resource requirements can be less, same or more than the vanilla game while the visual result is always vastly superior. A single bad INI setting can require more resources than all LOD together. If you use grass LOD with a large LOD level 4 distance , it almost does not matter if medium or high preset was selected. Grass LOD has hundred of thousands of billboards.

Read the section "How LOD works in Skyrim" and "Mod Configuration Menu (SkyUI MCM)" in ..\DynDOLOD\docs\DynDOLOD_Manual.html The static LOD distance settings can be changed at any time, even directly in the game with the DynDOLOD SkyUI MCM Settings as already explained.

Yes, that looks like grass. pretty thin though. Check the 2nd post again, troubleshooting, first entry about the object bounds. There might be grass meshes that have no billboards generated because of 0 object bounds.

Are you reporting a problem with the DynDOLOD 3 alpha that doesn't happen with DynDOLOD 2.x or vanilla LOD for that matter? Otherwise just increase the LOD distances in the INI or the DynDOLOD SkyUI MCM Settings as explained in the manual.

The log seems to indicate it finds cgid files and grass placements. Check ..\Meshes\Terrain\Tamriel\Objects\Tamriel.4.-16.-20.bto in NifSkope if it contains something that looks like grass LOD .

That video pretty much useless regarding grass LOD. Grass LOD is part of object LOD meshes. The plugins, the DynDOLOD SkyUI MCM has nothing to do with it at all. The video shows short LOD distances. Increase the tree LOD distance in the DynDOLOD SkyUI MCM Settings. TexGen does not care about the grass cache files. The game INIs do not affect grass LOD generation. Grass Control INI does not affect grass LOD generation. No need to waste time doing unrelated things. I wrote a post with lots of things to check related to grass LOD generation. Last time everything looked to be in place for LODGen to be able to generate grass LOD in the object LOD meshes, but the object LOD meshes you checked in NifSkope didn't contain grass LOD. Since the load order changed, check again that LODGen_SSE_Export_Tamriel.txt contains GrassMap=..LODGen_SSE_Grass_Map_Tamriel.txt and that that file lists the desired grass billboards for the worldspace. Also check that GrassDensity is not 0 or another silly low number. Let it be something between 33 and 100. If that is in place and the BTO still do not show obvious grass, do the verbose LODGen run in expert mode. Then check/upload that log.

From the second post or ..\DynDOLOD\docs\help\GrassLOD.html In case the grass LOD brightness or color seems off (it might depend on weathers or ENB settings), change the GrassBrightnessTop and GrassBrightnessBottom settings in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini.

Is this behavior different between DynDOLDO 2.x and the DynDOLOD 3 alpha? Instead of saying "sometimes" say when or which model it happens. The usual FAQ answer about flickering apply. Large reference bugs etc. Generate LOD with the Glow Windows High check box checked. If there still is an on/off difference then you have a mod that makes changes to the full model windows. DynDOLOD Resources updates a few Riften houses for that reason.

Right click a value and select edit and enter a number <= +- 128. In case it is a overwrite record use numbers from master mod as a guideline. The right column has insane values that are way larger than 128. Set them to the the same values as the left column.

I will have too look into why that happens and fix that for the next version. The filename of the file is correct if only the ESL flag is added and nothing else changed.

That file won't be listed in the log messages. You can check the debug log ..\DynDOLOD\Logs\TexGen_SSE_Debug_log.txt for it. Should look like this: [00:08] <Debug: Loading DynDOLOD\DynDOLOD_SSE_TexGen_Billboards_tamrielicgrassesp.txt> [00:08] <Debug: Processing tg_pineforest_mixedplants,True TamrielicGrass.esp tg_pineforest_mixedplants [GRAS:06000800]> [00:08] <Debug: Processing tg_field_eriophorum01,True TamrielicGrass.esp tg_field_eriophorum01 [GRAS:06000801]> [00:08] <Debug: Processing tg_pineforest_bentgrass,True TamrielicGrass.esp tg_pineforest_bentgrass [GRAS:06000802]> [00:08] <Debug: Processing tg_pineforest_heather,True TamrielicGrass.esp tg_pineforest_heather [GRAS:06000803]> [00:08] <Debug: Processing tg_field_lupinus01,True TamrielicGrass.esp tg_field_lupinus01 [GRAS:06000804]> [00:08] <Debug: Processing tg_pineforest_drygrass,True TamrielicGrass.esp tg_pineforest_drygrass [GRAS:06000805]> You can also just verify if the Preview window lists the base record you specifically forced to true. Overall it is preferable for the plugin to have correct bounds.

DynDOLOD does not change how full grass renders. As explained in the second post, either grass LOD can start right beyond the uGridsToLoad with GrassLargeReference=0 or beyond the uLargeRefLODGridSize with GrassLargeReference=1. No other INI settings matter. This can only be changed by generating LOD again, obviously. No Grass In Objects should be set to either render the full grass to the end of uGridsToLoad with DynDOLODGrassMode=1 or the end of uLargeRefLODGridSize with DynDOLODGrassMode=2 accordingly.

To fix worldspace bounds error, open xEdit, open the DLC2SolstheimWorld worldspace record by entering the FormID 04000800 into the field top left of xEdit. Hit Enter key. Scroll right to the column of the mod SlavePackRiekling.esp. Scroll down to the rows for Objects Bounds. Right click a value and select edit and enter a number <= +- 128. In case it is a overwrite record use numbers from master mod as a guideline. Ask specific questions if one of the steps is unclear.

The xEdit screenshot shows the landscape record for the cell 0,0 obviously. If you search for -16,-2 for Tamriel with the Cell Browser it will find the cell for -16-,2 with the form id 000099F4 The last plugins to the right are the winning overwrites. Whatever they do typically counts. To test if "this" is a problem remove the last overwriting plugin that does "this". Whatever "this" is...

This cell is already "fixed" by the smash patch.esp, which unsets the flags. Otherwise copy a record as overwrite into a new plugin with right click in the left tree view and then unset the flags. However, Open Cities setting the flags is correct and the smash patch reverting it is wrong. There is no need for terrain in that particular cell, as walled cities typically have references placing normal 3D models acting as the ground.

To see large references, turn off LOD with tll in console. Whatever full models remain that area are the large references and IsFullLOD references (dynamic LOD from DynDOLOD for example). That's the area to check.

What happens is that object LOD for the large references in this cell won't be unloaded outside the uGridsToLoad and inside the uLargeRefLODGridSize. If there is actual texture flicker to be seen, depends if any of the large references actually have object LOD and if that is the case if the LOD and full model occupy the same 3D space for triangles to z-fight. Use the cow console command from the main menu, like: cow blackreach 3 3

The RNAM lists are one a the few types of data that is merged at run time and do not adhere to the rule of one. Hence xEdit does not order the lists.