sheson

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which logs and debugs to upload. Here are some links that are probably relevant: https://dyndolod.info/Generation-Instructions#Prerequisites https://dyndolod.info/Mods/Open-Cities-Skyrim https://dyndolod.info/Messages/Unresolved-Form-ID Setting up a load order without errors is required for a stable and working game and is also a requirement for patchers like DynDOLOD to be able to do their work. AFAIK the Skyrim VR game files did not have any updates in years, so the Skyrim VR - USSEP 4.2.2 and SSE 1.5.97 Compatibility Patch should still work with the current Skyrim VR game files and with the unofficial patch 4.2.5b. Probably best to follow a modding guide that explains how to properly setup Skyrim VR.

I moved the post to the DynDOLOD 3 Alpha thread. Read the first post which log and debug log to upload when making posts. Pay attention to the log message https://dyndolod.info/Messages and summary https://dyndolod.info/Help/Summary-Of-Messages. Read the the answer for "ILS or CTD" at https://dyndolod.info/FAQ Read the ..DynDOLOD\Docs\DynDOLOD-README.txt included in the standalone archive. First check the crash log from .Net Framework or Crash Logger. Upload the crash log if help is needed. You list a couple of mods that you believe are relevant to the LOD patch generation. It is guaranteed to be incomplete. Use modwat.ch or loadorderlibrary.com instead.

I moved your posts to the DynDOLOD 3 Alpha thread. For future reference, read the first post where to post, which entire log and debug log to upload when making posts and to search this thread for similar problems. https://stepmodifications.org/forum/search/?q=texgen opengl memory&quick=1&type=forums_topic&item=16796 TexGen does not really use .Net, so it seems likely that the reboot cleared up the resources being used by several processes. Resources like video memory are controlled by the OS/drivers - which is what is telling TexGen it can not have any more memory.

Terrain LOD is generated for areas for which at least one CELL record exists. LAND record is not required, it will use the default terrain/water height from the worldspace record.

Generate terrain LOD with xLODGen. Generate object and tree/3D tree LOD and occlusion with DynDOLOD 3 Alpha. Cathedral - Water Overhaul and Bug Fixes has no relevance to LOD/Occlusion generation.

They should only do that in in the LOD area, not in the active cell area when getting close, which is what the screenshot seems to be from.

How do you load into the new game and how long do you wait before fast traveling? Are there any plugins overwriting the reference form ID 000CA6EA for the Winterhold Tower? Check for DynDOLOD related error messages in the papyrus log. Open ..skse\plugins\StorageUtilData\DynDOLOD_Tamriel_Objects.json from the DynDOLOD output in a text editor and search for a line containing winterholdexttower01. Paste that line.

https://dyndolod.info/Help/Ultra-Tree-LOD#Generating https://dyndolod.info/Help/Mesh-Mask-Reference-Rules Using 3D tree LOD in the higher LOD levels most likely has a noticeable performance requirement. Consider generating HD billboards with TexGen and to set Billboard4 in the mesh mask rules.

Pay attention to the skipping chunk messages because terrain LOD Level 32 textures already exist in the output folder. From Terrain-LOD-Readme.txt: If terrain LOD textures already exist in the output folder, their generation will be skipped. This can be used to continue generating terrain LOD textures for large worldspaces in case there was a problem like not enough space left on a drive. Simply restart with the same options. Otherwise move or selectively delete old terrain LOD textures before generating new ones. Take note of the skipping messages. If the diffuse or normal texture for a higher LOD level already exists, then all lower LOD levels that are covered by the higher LOD level are skipped as well. So in order to re-generate a LOD level 4 texture, it is not enough to just delete the LOD level 4 files for the diffuse and normal texture, the higher LOD level diffuse and normal textures files need to be deleted as well.

Read the first post which log and debug log to upload when making posts. You most likely have not followed the instructions for generating LOD for Open Cities correctly. This overwrite is typically only done for the vanilla record only when Open Cities rules are not loaded. This either means the plugin was generated without Open Cities in the load order, or the rules where not updated when doing the second pass with Open Cities loaded. https://dyndolod.info/Mods/Open-Cities-Skyrim ... Click one of the presets buttons Low, Medium or High to update the rules. ...

You uploaded the LODGen_log.txt, the command line program that generates LOD meshes. Upload the xLODGen_log (SSELODGen_LOG.txt). Do not generate into game data or mod manager folders. Always set a dedicated output folder, then install output as mod as explained in the instructions. To prevent issues with UAC, antivir etc. do not install the game into special Windows folders like Programs Files x86. Do not install programs like xLODGen into special Windows folders like Users/Documents/Desktop. Black terrain means the textures for the BTR are missing or can not be loaded. LOD is generated from the SW origin set in the *.LOD file up to the discovered cells. If you want to increase how LOD goes, add more cells to the worldspace to cover those area. Create an appropriate *.LOD file for custom worldspaces with https://www.nexusmods.com/skyrim/mods/10896. I suggest to use a multiple of 32 for the SW coordinates, e.g -64,-64 for example.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload when making posts. Check that the generated grass LOD billboards look correct, use better GrassBrightnessTop* or GrassBrightnessBottom* settings as explained at https://dyndolod.info/Help/Grass-LOD. If all 3 values for top or bottom are the same, then the colortone of the grass LOD billboard is not changed. If ENB is used, disable to test its affect. As explained at https://dyndolod.info/Help/Grass-LOD, grass LOD starts either beyond the active cells (uGridsToLoad) or beyond the large reference grid (uLargeRefLODGridSize) depending on the Mode that was in the DynDOLOD advanced options. Set the DynDOLODGrassMode in the NGIO INI accordingly so that full grass renders to where grass LOD starts. Make sure grass cache files have been generated for those cells.

You did not mention if deactivating/activating from the DynDOLOD SkyUI MCM main page as suggsetd by the FAQ answer did anything. What are the steps to reproduce this problem?

Read the log messages/summary and their explanations. https://dyndolod.info/Messages There are plugins that need cleaning. There are lots of overwritten large references reported, which are one cause of z-fighting. Why do you believe this has anything to do with DynDOLOD then? Best not to speculate about reasons and instead read the FAQ answers. Test if it goes away by disabling LOD with tll. If that is the case it is probably large reference bugs or stuck object LOD because of uLockedObjectLOD INI setting. Test with a new game as suggested by the FAQ answers. You did not mention if deactivating/activating from the DynDOLOD SkyUI MCM main page as suggsetd by the FAQ answer did anything. The previous posts about scripting issues might be related.

Read the first post which log and debug log to upload when making posts. Read https://dyndolod.info/FAQ General Game Questions / Out of place or floating objects

This is the DynDOLOD 3 Alpha thread. You seem to be using using DynDOLOD 2.x. You seem to be starting it without the -sse command line argument. Read the DynDOLOD 2.x installation instructions included in the DynDOLOD 2.x download archive. Start with DynDOLOD_QuickStart.html For questions use https://stepmodifications.org/forum/topic/13894-dyndolod-beta-for-skyrim-special-edition-skyrim-vr-and-enderal-se-298/

https://dyndolod.info/Updating#Removed-Mods-or-Plugins

Maybe you have a mod/script causing problems. Check the papyrus log. If cleaning saves causes problems, then do not clean saves. Especially if everything works as expected in the game. Check the scripts folder of DynDOLOD Resources to see the papyrus scripts filenames which belong to DynDOLOD. They all start with SHESON_DynDOLOD_*

Comparing the messages shows it is not the same problem. You are using Skyrim Special Edition, while pohtatoe uses Skyrim Legendary Edition. Do not install DynDOLOD into any mod manager folders. Check the load order for errors with xEdit error check and especially correct unresolved form id errors. Consider using DynDOLOD 3 Alpha for better problem detection/handling.

Test with DynDOLOD 3 Alpha. Check its log/summary for wild edits/deleted references. If that doesn't reveal anything upload the log and debug log as explained at https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-95/ Generating simple object LOD (no ultra tree LOD, no grass LOD etc.) for Tamriel just for testing should not take that long.

LOD shaders do not support parallax. The engine does not support swapping of textures based on view angle AFAIK. LOD does not support a billboard mode where they always face the camera.

Those are the instructions from https://dyndolod.info/Help/Clean-Save. If the are no unattached instance after doing that, then the clean save procedure was performed correctly. There only should be orphaned scripts, which will not be orphaned anymore once the clean save is loaded with the DynDOLOD plugins again. This all reads like there is a mod/script causing problems.

It is so the beams (of the two level highways) show from both side. If there is a normal game situation where the z-fighting on top can be seen, then let me know the coordinates, form ids, LOD model involved etc.

It is not really clear what you are trying to do but it sounds like if you are doing a small worldspace that does not require its own LOD, however it can be a child world of the Tamriel worldspace, like one of the walled cities. You might want to set the Parent WNAM record to Tamriel and the all the flags to use its LOD. In that case whatever cells are not loaded will be using the Tamriel LOD files directly.

I suggest to never "mess around" with anything and actually go about things methodically... 3D tree LOD models using the full model crowns and textures are as detailed as the (static parts) of full tress. If tree LOD in the distance seems inconsistent it might be because not all trees have 3D tree LOD models and fallback to billboards. For the vanilla 3D tree LOD models included in DynDOLOD Resources you should not really see much of a difference for the same distance when compared to their full models. LOD tends to have better mipmap transparency.