sheson

Good you solved it , but since you asked :) That requirement exists since Skyrim SE / LZ4 support was added to LODGen.exe 2 and half years ago and then DynDOLOD 2.22. The LODGen.exe/LODGenx64.exe in 2.60 is the same as in 2.59.

The manual and videos instruct to run TexGen before DynDOLOD to first update some of the LOD textures used by DynDOLOD. All linked video show running TexGen and installing its output before DynDLOD. ...consider updating LOD textures with TexGen.exe for the load order first... [...] Start DynDOLOD.exe.... Then for Open Cities, generating LOD with DynDOLOD.exe becomes a two step process.

Read the included Manual Custom Settings For Specific Mods - Open Cities Skyrim Going by your list the LOD generation would be complete after the two runs and installing everything as a mod in MO in step 3. No idea what you are trying to do in 4 and later. You probably should do that beforehand. If you want to generate LOD again later because of updates or changes, start from scratch again. Consider watching the video from GamerPoets once or read the instructions in the manual.

Fixed. thanks for letting me know.

Please test with DynDOLOD 2.60 and let me know if I managed to work around the problem by removing the -m 0 from the command, fingers crossed.

The log is saved to file when closing the program. Otherwise copy and paste the entire message window. This might happen because something is preventing read/write access. From the DynDOLOD Standalone archive copy the content of the 'DynDOLOD' folder, which contains the files DynDOLOD.exe, TexGen.exe, DynDOLOD_QuickStart.html and the sub folders 'Docs' and 'Edit Scripts' with all their content into a new 'DynDOLOD' folder outside of special OS folders like 'Programs Files' or 'Program Files (x86)', the SteamApps or game folders and Mod Organizers virtual file structure. Do not mix with old versions or xEdit installation.

Once the script engine is overloaded and starts dumping stacks, it will take everything currently being active with it. To troubleshoot that properly its best to find what a reproducible way to cause it. If it is just tight memory situation, it might help to slightly(!) raise iMaxAllocatedMemoryBytes. Note that there is no DynDOLOD involvement in the dumped stacks for 17 minutes once the dumping started. DynDOLOD typically only runs scripts when cells are entered/left. Based on the log it seems not right that the same stack/function with the same form shows up so many times [alias PlayerRef on quest 0001SmoothCameraFollow (7D003DD7)].SmoothCameraFollow.OnCrosshairRefChange() - (requested call) It might be called and never return properly before the next call building up a long list on the same form. If you compare this to other dumps several minutes later, like [ (C0052956)].SHESON_DynDOLOD_LODObject.OnCellDetach() - (requested call),you can see they come typically from different forms. In this particular case, OnCellDetach should only happen 5 times (uGrids) when the player leaves a row of cells behind, but the script engine is overloaded with other things, so these calls build up over time as well.

I was going to say check the entire log to find the cause. Broken plugins need to be fixed or removed entirely. Removing a plugin temporarily is a troubleshooting step, not a solution. If the plugin is broken, it is also broken in the game.

See the included manual "Updating" chapter. There is no need to generate LOD just because a new mod was added. New objects may be missing LOD, but that is only a visual problem. The link does not go to a mod. But in order for objects to have performance friendly LOD that works well with the rest of the load order and the already existing LOD, it is typically necessary to generate it.

You uploaded the TexGen log instead of the DynDOLOD log. Not a big problem, because the bugreport has the error message. FAQ: DynDOLOD.exe: Exception in unit xxx line xxx: Can not copy xxxx from xxxx.esp into xxx.esp A: Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. A: There might be plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. Get recent Wrye Bash from https://github.com/Wrye-Code-Collection/wrye-bash/releases Searching for the error find this related threads:https://forum.step-project.com/topic/13939-exception-in-unit-userscript-line-331-can-not-copy-refr110259dchttps://forum.step-project.com/topic/13936-exception-in-unit-userscript-line-234-assertion-failurehttps://forum.step-project.com/topic/14005-dyndolod-exception-in-unit-prepare-line-579-errorhttps://forum.step-project.com/topic/13956-assertion-failure

Correct, the SphereNormals replaces the normals, so it doesn't matter what they are in the LOD model. Such 3D tree LOD can work fine. It all depends on the number of trees and their total triangles. The most important optimization of LOD is that it creates large combined supermeshes of things and such 3D tree LOD does not really change that.

FAQ: LODGen.exe: Runs a long time / The LOD files generated are several GB in size A: The selected configuration options require a lot of work. Do not manually close LODGen.exe. Wait for all processes to complete before closing DynDOLOD. A: If there are more objects with LOD, it takes longer and creates larger files. If there are more triangles in the models used for LOD, it takes longer and creates larger files. If there are more triangles in the terrain meshes, it takes longer. A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. Read c:\Skyrim\DynDOLOD\Docs\trees.ultra\DynDOLOD-Trees.htmlDo not use full model fallback. Use tree mods that have optimized 3D LOD models, let the remaining trees use billboards.

First keep this in mind: LODGen.exe will limit the shader flags and settings to the ones found in the vanilla LOD for best compatibility. So certain things you are setting in the LOD source model will just be ignored once it is added to the BTOs. You can instruct LODGen to keep (some) non vanilla settings by either added passthru to the LOD model file name (impractical without DynDOLOD, because you would need to update lots of base records), adding a passthru file mask to the options file, so all LOD models matching that mask keep their shader settings (impractical in some cases because it applies to all shaders in a NIF) or by adding "passthru" to the BSTriShape name (e.g. "TreeChargen01_LOD_0:1" -> "TreeChargen01_LOD_0:1 Passthru"). While testing if different settings have an affect in the game, do that in a BTO directly. Once you have the desired settings update the LOD model with them. If you find some settings still don't get through despite a "passthru" command let me know so I can update LODGen.exe. Now the most important thing that affects how a triangle is lit is the normal vector, which is defined together with the vertices and UV. It basically points into the direction from which a light source illuminates the triangle the most. With a double sided triangle the back side gets as much light as is defined by Backlight Power (for vanilla LOD models the shader settings in the NIF are often overwritten by the settings in the referenced BGSM files). For models without "passthru" check the Use backlight power checkbox so this settings is kept. By default the normal vector points perpendicular from the triangle surface. That does not work very well for the planes. If you check DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_flat_2x2_lod.nif you will notice its normal vectors point upwards instead, basically to where the sun is at noon. That works somewhat better as long as the trees stand upright because usually the normals are rotated with the model. You can instruct LODGen to not rotate normals by adding "FixedNormals" to the BSTriShape name (e.g. "TreeChargen01_LOD_0:1 Passthru FixedNormals"). However such normal vectors pointing always straight upwards makes all sides of all the planes being lit exactly the same, which makes for very flat tree LOD (like the vanilla tree LOD in Skyrim). To counter this, you can instruct LODGen to ignore the normal vectors and instead calculate them to be somewhat spherical by adding "SphereNormals" to the BSTriShape name (e.g. "TreeChargen01_LOD_0:1 Passthru SphereNormals"). It is briefly explained in DynDOLOD/Docs/trees.ultra/DynDOLOD-Trees.html with an image example. This should help a bit with lighting and the normal map textures. I suppose this somehow should also affect specular and ENB. Though, I never really did much testing with non vanilla specular textures/settings in FO4. It is something that is not supported (well) in Skyrim, so it is not something I looked into at all that much. Also I am not sure how ENB plays into all this.

Good to hear, even though we didn't learn the cause in the end.

It is the different mesh rules in some odd combination with a mod. The next version should fix it.

We had that before. A mod is confusing DynDOLOD - not sure which one it was. You could just copy the texture to that wrong path. Next version should fix that.

If you upload one of those models and its accompanying LOD meshes/textures I could have look. I can not promise anything but may something sticks out that helps.

There is a pop-up message when the count is over a certain number, so you can't miss it.

The text in the message windows can be marked and copied to the clipboard. Once the program is closed all the messages are saved to FO4LODGen_log.txt. The message is "No options file found: C:\Skyrim\xLODGen\Edit Scripts\FO4LODGen_[Plugin_Worldspace]_Options.txt". That is expected and the default. The Options file can be used to set custom options for LODGen.exe. You mean the shadowy thing on the trees in the video? That looks a bit like (ENB) low quality Ambient Occlusion to me. Those look like 2D billboard trees? FO4 does not have billboard tree LOD but of course that can be done in object LOD. This requires good understanding about the normals and how to create the normal map and the specular textures. I am not even sure how to make a specular billboard texture right now. The Object LOD atlas has 3 separate compression settings for each of the 3 texture types Diffuse, Normal and Specular. All vanilla textures always use BC5 for normal _s and specular _s textures. That 2 channel compression is pretty much perfect for these textures. If the input textures use BC5, there is usually no point using a different compression for the output atlas textures. In any case I have no idea if or which of the textures are even related to what you might be seeing.

My question about Engine Fixes was about the persistent reference cap, since it would notify you. The x5 Access Violation is such a generic error message, it seems it could mean anything.

Interesting. If that is the case, remove the remaining records in batches as well. You have SSE Engine Fixes installed?

And if you remove the worldspace 3C from the plugin the problem is gone?

To avoid problems I suggest to follow the installation instructions in the manual: From the DynDOLOD Standalone archive copy the content of the 'DynDOLOD' folder, which contains the files TexGen.exe/TexGenx64.exe, TexGen.exe/TexGenx64.exe, DynDOLOD_QuickStart.html and the sub folders 'Docs' and 'Edit Scripts' with all their content into a new 'DynDOLOD' folder outside of special OS folders like 'Programs Files' or 'Program Files (x86)', the SteamApps or game folders and Mod Organizers virtual file structure. Do not mix with old versions or xEdit installation.

Good. That narrows it down quite a bit. You can now do a binary search type of thing where you make a backup of the plugin and use xEdit to remove batches of records from the ESM. If the problem is gone, go back to the backup and remove other records. That way you will eventually end up only with the record causing the problem. Logically the issue should only be with records with the worldspace Tamriel. So start by removing all other worldspaces. You do this in xEdit by right clicking on the worldspace name and selecting remove. If it still has the issue after removing them, remove the Tamriel persistent cell 00000D74. If the problem goes away go back to the update and remove all "Blocks" which are childs of 0000003C Tamriel. If the problem seems to be in one of the "Blocks", remove them one by one or in 50% batches. The continue with the subblocks etc. Once you are down to a cell, remove the content of the CELL first. It is possible that the problem is with something on the worldspace record 3C itself. So you might want to do a quicktest with removing all childs first. In any case you should be able to narrow it down to a single record and it will go pretty quickly if you remove half the records each time. Let me know if anything is unclear or needs more explanation.

I can not begin to imagine all the errors and issues caused by executing programs from the documents folder. Why would you do that to yourself? So if there are file access/writing issue that would be the first to check. Be that as it may. xEdit and consequently DynDOLOD, which is a modified xEdit, read the Bethesda entry in the Windows Registry for the game path. That path is obviously set to c:\program files (x86)\steam\steamapps\common\Skyrim\Data\ If the starting the launcher is not updating the Windows Registry it might be because the OS, UAC or anti virus are preventing the launcher from accessing the Windows Registry. It might have to with the fact that the Documents folder is supposed to hold data and not programs.