sheson
-
Posts
13,181 -
Joined
-
Last visited
-
Days Won
431
Everything posted by sheson
-
LOD generation does not care about interior cells and their LOD settings. The interior cells simply use the parent world LOD files as defined on those records.
-
A *.BTO is a object LOD NIF that can be opened with NifSkope. They are in Meshes\Terrain\Commonwealth\Objects\*.BTO The first number 4/8/16/32 is the LOD Level 0/1/2/3. It is the row/column number of cells a file covers. E.g. 4 x 4 = 16 cells for the nearest LOD level. The other two numbers are the x, y coordinates of the lower left (SW) cell of the file.
-
Have you done this yet? "Check a generated BTO if it includes all the LOD or not, to double check if the issue is in the game or not." Known issues: LOD was generated into the data folder instead of a dedicated output folder. It is anyone guess what the mod manager did do the actual generated files and were they really ended up. Game is installed in a special Windows folder. Access, read/write might be blocked.
-
The distances for the LOD levels are defined the Prefs.INI [TerrainManager]. The content of LOD meshes does not change how they are loaded or their distances in which they are displayed. You may have a mod that changes LOD distances.
-
While that seems logical, it isn't showing vanilla LOD level 32. Object LOD level 32 has merely a dozen high rises and the Zeppelin.
-
As I mentioned already: "Make sure the INI settings for the LOD Distances are not messed up and there is merely a problem that only shows in the game" That last screenshot is not showing LOD level 32. The higher LOD levels are supposed to have less LOD objects.
-
If you want to verify if assets are actually available in the loader for xEdit/xLODGen, use the xEdit Asset Browser (CTRL+F3). I am explaining how these work so you can troubleshoot as you did. You do not need to post screenshots to proof that to me. Check a generated BTO if it includes all the LOD or not, to double check if the issue is in the game or not. No xLODGen log, yet. We could check it for example if the required BA2 are being loaded or if there are any additional errors or warnings. Fix the already identified problems of not using a dedicate output folder and the game being installed into a special windows folder. Since I already mentioned access, read/write, make sure that no antivir blocks that.
-
You uploaded the LODGen_log.txt, not the xLODGen_log.txt (FO4LODGen_log.txt). Set a dedicated output folder as explained in the first post. Do not install the game into special Windows folders like programs Filesx86. The listed plugins, especially NeuraLOD is a LOD mod that replaces LOD assets. For reference to have LOD, a reference needs to exist in the load plugins. The reference needs to use base record that defines LOD models. Those LOD models and their textures need to exist in the load order either loose files or BSA filled. The loose files and BSA files need be loaded by the tools. That includes being able to access folders, read and write files. Make sure the INI settings for the LOD Distances are not messed up and there is merely a problem that only shows in the game
-
If that data would have been important I would have said something. OK, since it is unable to generate a bugreport and still reports a range check error despite that check being disabled you will have to remove the listed plugins one by one to see which is causing the problem. Start with the most right, e.g. the last to overwrite the worldspace record. Do that with xLODGen beta 81
-
It doesn't matter that it doesn't have the data. You can just drag and drop the data from another plugin into the DynDOLOD.esp with xEdit.
-
Check what happens when using this debug version.
-
The records in the DynDOLOD plugins (and Occlusion.esp for that matter) are created by copying the record from the plugin before, e.g. typically the highest ESP at that time. So if something is "missing" it is because of the highest plugin for that record didn't have it.
-
Check with xEdit which plugins overwrite the 0001691D Windhelmword record and post the list. Obviously it starts with Skyrim.esm, Update.esm, Dawnguard,esm, HearthFires.esm and Dragonborn.esm
-
Are you a 100% sure there is no bugreport.txt in any of the folders? How do you start the tool? If it is via MO2, also set the "start in" text field to the same folder the executable is in. xEdit/xLODGen always default to Fallout 4. As explained in the first post for xLODGen terrain LOD beta, either rename it to the desired game mode or add it as a command line argument. Upload the log.
-
Download this debug version, see if the log shows more or if it creates a bugreport.txt when the error happens.
-
No bugreport.txt?
-
Looks like we are just supposed to make blind guesses. If something doesn't have LOD it is because its LOD models not being defined or assets are missing from the load order. If something happened during LOD generation there will be error or warning messages in the log. Obviously, test LOD generation without any LOD mods. Then install them correctly.
-
Use the latest xLODGen version. Post/Upload the log and bugreport.txt if it exists.
-
Why do you believe this has something to do with DynDOLOD? Sounds like something is loading or maybe No Grass In Objects is generating grass / cgid files while new cells attach. Check its INI settings. What is "inactive cell grass"? Grass LOD is generated into object LOD meshes. TexGen typically does not generate grass LOD billboards for underwater grass. By default everything below the water is removed from object LOD as well. LOD meshes are always loaded. LOD segments are disabled for cells that are attached.
-
Are you saying that CELLs which are defined in a plugin do not have water LOD generated for cell water that is above the terrain level? Maybe post a screenshot.
-
Exception in unit prepare line 60: Too many full modules
sheson replied to Kovacks's question in DynDOLOD & xLODGen Support
The game has a full plugin limit. It is 255 for Skyrim and 254 for Skyrim Special Edition because of slot 0xFE for light plugins. Obviously xEdit/xLODGen/DynDOLOD adhere to the same limits as the engine. As explained in the manual, for Skyrim Special Edition two plugins are generate by default, so there needs to be room for 0xFC and 0xFD -
DynDOLOD Rseources include the 256x256 vanilla version from DLC to overwrite the 128x128 vanilla version of the base game for glacierslablod.dds However, there are a few more vanilla pre-rendered glacier textures used by the models, that neither DynDOLOD Resources/TexGen. HD LODs is supposed to be loaded after DynDOLOD Resources, it should cover those other textures as well. If there are no (better) LOD models available one option is to create them. Another is to try to use the full model for the first LOD level via mesh rules. Since glaciers and iceberg use parallax shaders, that might not work out well, because LOD does not support all shader options. In that case, so as a last simple resort you could try copying the full models to LOD model filenames and then edit the shader settings in NifSkope to the default shader and see if you need custom textures or can somehow mimic things somewhat they look acceptable. The problem is that the full really ice look very different depending on lighting and with the default shader it is impossible to exactly replicate that for all conditions. The LOD file name to copy to is typically full model_lod_0.nif, so meshes\landscape\ice\iceberglarge.nif to meshes\lod\ice\iceberglarge_lod_0.nif LOD is generated for the current load order. If there are changes to objects placements or the LOD resources and you notice the LOD not matching anymore, generate LOD again for the new load order.
-
LOD models are lower quality version of full models. Hence LOD is lower quality than full models. DynDOLOD Resources does not change or replace the vanilla LOD models for icebergs and glaciers. It adds a few new LOD models that were missing. Typically icebergs and glaciers use pre-rendered LOD textures that TexGen can not yet generate automatically, xLODGen/DynDOLOD simply use the LOD models and LOD textures that are currently installed in the load orders. So typically vanilla, unless a mod replaces them. Changing the distances for the different LOD models, does not change the quality of the LOD models. If you know the reference from id of an iceberg you can look it up in ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt to see which LOD models were used and found for the different LOD levels. Since you are posting in the DynDOLOD 3 alpha thread, I have to ask: Is there any difference compared to how LOD is generated with DynDOLOD 2.96?
-
Post it anyways. Maybe it spawns more silly ideas on my end what to try next. There no requirement to rush anything.
-
What is this supposed to mean? It ran and all was fine? There is no change to terrain LOD generation code. If xEdit can not write its log file when closing, there should be an error message. Sounds like a UAC, antivirus issue.
