sheson
-
Posts
13,181 -
Joined
-
Last visited
-
Days Won
431
Everything posted by sheson
-
The large references bugs and the warning messages have been discussed plenty of time before and are not new to DynDOLOD 3 alpha. The large reference bugs have been documented and explained years ago already in ..\DynDOLOD\Docs\SkyrimSELargeRefGrid\SkyrimSE-LargeRefGrid.html Since ever DynDOLOD prints the list of overwritten large references that trigger these bugs. The main "fix" is still the same: Only ESM flagged plugins should overwrite large references.
-
xLODGen beta 82 will now not stop with out of range message anymore, but just print a notice if it encounters a cell in a plugin that is outside the usable area for occlusion calculations: <Note: Cell [CELL:FE0018A3] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 338,9) added by JK Skyrim Feat Trees In Cities 5in1 Patch v4_2.esp out of range> The plugin JK Skyrim Feat Trees In Cities 5in1 Patch v4_2.esp adds a cell at coordinates 338,9. It's an unintended wild edit that the mod author might want to remove at some point, but it is not really hurting anything either AFAIK. With the new version occlusion generation should just run as usual with the plugin enabled. There is DynDOLOD/docs/help/Underside.html. Also read the the remarks in the INI above each settings.
-
xLODGen beta 82 now expects and uses a different options file name for terrain LOD generation to avoid conflicts of options and having to generate LOD in two separate sessions.
-
Temporarily removing plugins is a troubleshooting step to test if said plugin is the culprit of a problem. Now that you reported it, I can hopefully test myself what the problem is and if it is something in the plugin that needs fixing or if it is a bug in the program. You should make a proper error report about the other plugin in the DynDOLOD 3 alpha test thread with the logs and bugreport as explained in the first post. It is very unlikely that the location and reason for that access violation is the same. DynDOLOD 3 does not replace DVLaSS. It only replaces the underside that is included in the mod. Make sure to read message carefully and to use the "Help for this message" link for further explanations as suggested by the first post of the DynDOLOD 3 alpha test.
-
I would assume it hat to do with the large reference grid, right?
-
Test generating object LOD with the checkbox "No vertex colors" checked.
-
The first screenshot has way too many structures to be one of the 4 LOD level 32 files, no? The one you posted has the most structures of the 4 files. The screenshot shows way more things. Are there any other people having similar issues with their load order? If you believe there is something going on with the LOD meshes, then I suggest to actually start troubleshooting that. For example, identify which LOD level 4 BTO is supposed to show there immediately beyond the loaded cells. Then add more LOD level 4 BTO for the surrounding area maybe. Then add LOD Level 8 meshes. Or maybe vice versa, start with adding only LOD Level 32 BTO and then go down. Maybe you identify a single file. Maybe compare BTO closer than just visually. Like the additional settings and values in the NIF blocks that are not vertex data/shader/texture.
-
There is nothing in the generated LOD mod that runs every few seconds, obviously. You may want to read the performance section in the manual.
-
As already explained, delete every file that TexGen generates. It always generates the same folders and files for the same load order.
-
Understand that none of these questions have anything to do with TexGen or DynDOLOD. I am not really able to provide generic modding support. You probably want to undeploy first. Then specifically only delete the textures that are generated by TexGen from the data folder. Then deploy the installed mods again. However, refer to the documentation of the used "mod manager". For future reference I suggest to follow a modding guide and learn how to use an easier and better mod manager like MO2.
-
There shouldn't be any other manually installed mods. If there are other mods installed in the data folder you might want to fix that as well. In case there are other mods with textures in the data folder, generate TexGen by ignoring the warning into the output folder to see what folders and files it creates specifically. Once all files TexGen generates have been removed form the physical data folder, also clear the output folder. Then run TexGen (this time there should be no warning) and install the output as a mod with the mod manager.
-
If you are using a mod manager there should never be anything installed into the physical data folder. TexGen always generates the exact same folder and files into ..\Textures\ so you can probably just remove that and all subfolders. If unsure compare, compare folders/files names with the output that was installed as a mod. Typically a user knows if TexGen needs to be updated, because old object LOD textures do not match different/new full textures anymore. If unsure, then simply run TexGen to before running DynDOLOD. Carefully read "Updating" in the manual, especially the part about creating a "clean save". There should be no old TexGen in the load order when running TexGen. There should be no old DynDOLOD in the load order when generating from scratch.
-
Installing and uninstalling of mods is handled by the mod manager you are using. Refer to its documentation. If textures should be updated depends on if the load order changes affected any of the source textures that TexGen uses to create the object LOD textures. Read DynDOLOD/Docs/DynDOLOD_TexGen.html
-
Generate a new LOD mod from scratch. Read "Updating" in the DynDOLOD_Manual.html
-
The OpenGL rendering is running out of video memory. Typically it is using the first graphics card found in the system. Looks like it is using an integrated graphics card. If there is no real graphics card available, maybe try to allow for more video memory through driver or hardware settings if possible. Make sure to close all other process that might use video or system memory at the same time. Otherwise try setting MaxMultiSamples=4 or lower in ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI or lower the texture size for rendered object LOD textures. A firewall controls network traffic. None of the tools use a network connection.
-
Enderal SE includes object and tree LOD generated with DynDOLOD 3 alpha. However, it does not include dynamic LOD or LOD occlusion data of a typical DynDOLOD generation. You will have to select ignore for now, as you can not really uninstall the TexGen textures included in Enderal SE.
-
That sounds like that once the game was started, plugins/mods are active again. You still seem to assume the generated LOD making the game doing things differently, despite by now you hopefully have compared many different BTOs that they actually contain what they are supposed to contain. Especially LOD level 4 which is the nearest LOD level. That LOD we can see is not object LOD level 32, obviously. This just looks like a cell does not have full models defined and its LOD is disabled. That is probably because you have a mod that disables LOD for that cell in order to show full models instead. You have to add reference for all buildings of the entire cell obviously. Generate LOD into a dedicated output folder. Pack it and install as a mod. The game should not be installed into special Windows folders so avoid permission/access problems because of UAC, antivir etc.
-
As I said, generate object LOD in one session and the terrain LOD in another. No clue, especially if it is the same water record. It's probably because of the LOD shader being different to the full water shader. You probably have find to a trick, like placing water meshes directly with the IsFullLOD flag that cover each cell, or one large mesh that covers the entire area, or maybe just add reference that only have faces downwards just right below the water level.
-
Have you compared LOD level 4/8/16 BTOs contain what they should? Following proper modding practice. Use a modding guide. Use MO2, do not install the game into Program Filesx86 and do not have any loose files in the physical data folder. Generate LOD into a dedicated output folder, pack it and install it as a mod. Test it with the vanilla game, no additional mods, not even the LOD stuff. If then there still is a problem and the generated BTOs seem fine, start by posting the xLODGen log.
-
The game uses LOD level 32. It is the furthest away LOD level. It will be used about starting about 250000 units away from the current center cell. The nearest LOD level is 4. It starts right beyond the loaded cells.
-
There is really only two possibilities. There are plugins in the load order that change references/base record etc. so that the generated LOD is different (can be checked by comparing BTOs) or something else changes that has nothing to do with xLODGen and the generated LOD meshes and textures. Since nobody else ever reported this issues so far, we can assume the LOD generation itself works as it should.
-
Is it possible that the options file with the setting to ignore water so that underwater faces are not removed from object LOD is also used for terrain LOD generation and there ignore water means to not generate water LOD. So generate object in one session with the options file and then in a new session generate terrain LOD without the options file. They look OK. LOD generation does not care about INI settings. As explained earlier, it simply generates the BTOs for the different LOD levels with the LOD models defined on the base records.
-
The distances of the different LOD levels are defined in the *Prefs.INI under [TerrainManager]. Typically the launcher sets them so that LOD level 4 is the first starts beyond the loaded cells, then 8, then 16 and then 32. If generated BTOs contain what they should for each LOD level, then there is really nothing else to do or check in regards to xLODGen or the LOD generation process. Check the CELL record for the coordinates that have no water LOD in xEdit. The xLODGen log shows the values SW and Stride values which were read from the lodsettings file.
-
So the CELL record for the cell that does not have water LOD has the Has Water flag set? The water height is default, -2147483648.000000 (which also means default) or 0.0? The cell is inside the SW and the SW + stride coordinates of the lodsettings file? Have you checked the *.BTR for that area that it is exists?
-
You should follow the instruction given by NeuraLOD (or probably any other well made modding guide) which packs generated LOD into BA2.
