sheson

The TexGenx64.exe is from Alpha-2. Make sure to use the latest Alpha. That error was fixed in Alpha-4.

Please use an upload service or pastebin to post log files. I moved your post to the appropriate DynDOLOD 3.0 Alpha thread. Please read the first post what logs to provide in case of problems, e.g. we require the debug log and the bugreport if it exists.

You posted logs from TexGen? Is there anything going on while creating textures? The bugreport is actually the debug log from DynDOLOD second pass with Open Cities. Is that when DynDOLODx64.exe is using a lot of memory? If it is the first pass, you need to upload that debug log, as it gets completely replaced every time. In my "Lexylike" load order - without Open Ctities - generating all LOD for all worldspaces DynDOLOD it peaks at 10 or 11GB, typically while generating the texture atlas for a large worldspace like Tamriel or Solstheim. See what happens if you add the -memory command line argument. For me it then peaks at 7 or 8GB. Check the log what DynDOLOD is doing when it reaches such a high peak.

Post the required logs as explained in first post.

This is a statement without any information. If there is help required or a question, provide information (version used, logs, modwatch etc.) and ask a question.

This should be fixed again in next Alpha. Yes, that shader setting can be set with NifSkope. Test that it works (visually with the leafs and also for LOD generation) with one or to trees first.

xLODGen exports textures uncompressed for the external Texconv tool to compress them. Despite the texture having an issue, it does load in irfranview. It is very unlikely for texconv not to print an error if it has a problem reading or writing a texture - which typically should be reported in the log. In that case, it seems more likely that the texture was corrupted afterwards. For example when outputting into game or mod manager folders, or if antivir checks the file afterwards. Double check the log. 565 will not work in Windows 7. Generate the same file without compression (specific chunk in xLODGen), then no Texconv will be invoked. Then manually convert the texture with texconv to the desired format, see what happens.

If the error message about the unresolved form id shows, click the "Help for this message" link to open ..\DynDOLOD\docs\help\Unresolved.html for help.

Vanilla settings, vanilla grass, with vanilla 3D tree LOD with DynDOLOD high from the screenshots is 3GB. Post debug log please, so I can double check why the build in ITM remover did not remove them.

This is not an error, is fully intended and should not be changed.

1. First, test without weather mods. Test without ENB, see if either has an influence. Maybe also want to test with vanilla grass models/textures to learn which things have affects. This is basically the tree LOD brightness problem in reverse, as the grass in the loaded cells doesn't have the complete lighting like normal models and object LOD has. Some time in the future we might be able to have a custom LOD shader or a better grass shader that make things match better without tricks: "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." "To test different GrassBrightnessTop or GrassBrightnessBottom settings, change GrassLargeReference in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_[WORLDSPACE].txt, start DynDOLOD in expert mode, select the desired worldpace and click the Execute LODGen button. Then merge the new output with the existing output, overwriting all older files." "To speed things up, limit generation to LOD Level 4 by using the Specific Chunk dropdowns." You could try to increase/lower direct/ambient light in TexGen to generate brighter billboards. Read "Rebuild Atlas" in ..\DynDOLOD\docs\help\Expert.html how just to update the object atlas texture with the new billboards. You could also test if setting min billboards size to 64 or 128 has an effect. 2. For the same distance, 4 triangles per grass placement is always better than any of the full model grass. In addition, all the different grass billboards are combined into large super meshes for each LOD quad.

This should be fixed in Alpha-10.

Should be fixed in Alpha-9 Can't update Nexus atm, so Mega only The error message is already self explanatory. Click the "Help for this message" in the message window if available for further explanations.

Some of the warnings are just xEdit plugin loader warnings or that show while the reference cache is being build. The reference cache is build on demand if certain other checks require it. So you may see warning about unused data in Skyrim.esm or not. Some of the other warnings are xEdit error check warnings that should be fixed. A deleted reference means the plugins should to be cleaned. e.g. UDR. Those things should be checked before running DynDOLOD. E.g. when I say finalize the load order first etc. If a NIF root block is a NiNode that is bad. It should be a BSFadeNode. The NIF is ignored for dynamic LOD, because enabling NIF with NiNode causes CTD. A overwritten large reference still triggers large reference bugs. An initially disabled large reference can trigger large reference bugs (also if in ESM) File not found errors are... file not found errors. In case of normalmap_n.dds the default normal is used. There are - a lot - of typos and wierd stuff in lots of mods. It does not yet cover instances where textures in NIF are not used at all because of texture set replacements. A billboard having different CRC32 for a mesh or texture means that the billboard was generated with a different mesh/texture for that tree base record and TexGen should be run again. (These were sometimes wrong before Alpha-4) All in all all. Errors typically need to be fixed. They prevent LOD generation for the mentioned stuff or in general. Warnings typically should be fixed if possible, because of good practice or because they prevent the desired outcome.

Nothing. I also did something update around the code in Alpha-8 which fixes a potential race condition that caused it. If it works great. If there still is something that only happens occasionally it will pop-up soon enough again. You sure those records/plugins (LAL, Open Cities etc.) where the highest at the time the DynDOLOD plugins were generated?

If you narrowed it down to a single file you can alays upload it for me to check what is wrong with it and what might have caused it. To interpret crash logs programming experience and knowledge about the game data and assets is required. The relevant object and stacks and other will either hint strongly at NIFs bs mentioned NIF blocks, names etc if not outright naming the NIF or texture somewhere earlier when it was loaded. Just upload it as well.

Instead of posting screenshots of text, post the text to paste bin or upload logs to a file service. The FAIL loading means, that the file dds file was not loaded by Texconv and thus not converted to the DXT1 compression format. If the file existed it would simply be still fully uncompressed R8G8B8. If the file is missing and there was no error about saving it, then something like 3rd party antivir, crapware deleted it in the meantime. Typically uncomprrsed R8G8B8 textures or missing textures do not cause CTD. Unless you somehow tricked xLODGen to not use the texture resolution set in its options, it cannot possibly generate non power of 2 textures. Why do you believe the meshes or textures are causing CTD? CTD caused by invalid meshes or texture are typically so reproducible that it can be narrowed down to single files with a binary search, or better yet by simply looking at the crash log.

How do you know that the CTD is caused by meshes or textures generated by xLODGen? Problems with meshes or textures are typically 100% repeatable. If the game works with the meshes and texture, then the generated meshes and textures are fine. xLODGen does not create faulty meshes or textures occasionally. If it did, this thread would be full of reports. Do proper troubleshooting. Find the cause of the crash in the log from .NetFramework. Problems with meshes/texture are typically very obvious in the log.

Can you repeat this error or does it work if trying a second time?

No need. I found it, should be fixed in Alpha-7

Use the x64 version. See first post which logs to upload/paste if problem persists

It is fully intentional to report errors that need to be fixed. Overwritten large references were already reported in a long list at the end in the older version. I have't added a similar final reporting of problems yet.

Alpha-5 now just warns about the duplicate cell - it will be ignored. The dupes should probably be removed, but for Beyond Bruma I checked the cell in game there was nothing wierd to see. No idea ho the engine handles that. Alpha-5 should now be loading the grass cgid without that error should be fixed in Alpha-5

You can see in the first image that the leafs use a texture directly. This is probably because the UV of the leafs is not within 0.0 and 1.0 limits - which are required for atlas textures. LODGen tries to re-UV, but depending on different circumstances either can not successfully re-UV or decides not to. re-UV will increase triangle count. The texture is not changed in any way by DynDOLOD. You would need to update it yourself to have better mipmaps. You can try to CLAMP the UV in the shader of the tree LOD model. If the UV is just a bit beyond the 0.0 / 1.0 limits, the difference can not be noticed in the the distance.

Can you double check in the BTO mesh if those leafs actually use the atlas texture and not the full texture? Let me know if you need more details how to do that.