sheson
-
Posts
13,180 -
Joined
-
Last visited
-
Days Won
431
Everything posted by sheson
-
..\DynDOLOD\Logs\DynDOLOD_SSE_Debug_log.txt not containing a line with "Gathering grass data for object LOD" means Grass=1 is not set in the DynDOLOD INI. Set Grass=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Make sure there is no extraneous spaces or other characters. That also explains that there are no grass billboards. Does the ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt have the same/similar time stamp as the other files in the folder? BTOs are just NIF files and can be opened with NifSkope.
-
Check the troubleshooting section of the second post. Check in MO2 right data tab there are ..\Grass\Tamriel*.cgid files Make sure TexGen is generating billboards for grasses by checking its log ..\DynDOLOD\Logs\TexGen_SSE_log.txt Check the grass billboards in the TexGen output show something and are no fully transparent Check the DynDOLOD debug log ..\DynDOLOD\Logs\DynDOLOD_SSE_Debug_log.txt contains <Notice: [Tamriel] Gathering grass data for object LOD> Check the DynDOLOD log ..\DynDOLOD\Logs\DynDOLOD_SSE_log.txt that there we no errors in the LODGen log or check the LODGen log ..\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt directly that its last line is Code: 0 Check the object LOD atlas ..\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds contains some of the grass billboards generated by TexGen Check the export file ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt has GrassMap=..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt. Check that GrassDensity is not 0. If it is very low grass may be very thin to non existined. Check that ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt contains a few lines with grass billboard texture names and paths in it Open ..\DynDOLOD_Output\Meshes\Terrain\Tamriel\Objects\Tamriel.4.0.0.bto and check visually if there is grass LOD in there. The many tiny X will be obvious. If you can't find a BTO with patches of grass, set expert=1 and verbose=1 in the DynDOLOD.INI and start DynDOLOD in expert mode, select worldspace and click Execute LODGen. Once its done, you can check the LODGen log for lines like Found z grass placements for LOD level 4 coord [x, y] . Check the BTO for the mentioned coordinates.
-
See if this version of LODGenx64.exe fixes it for good https://mega.nz/file/ABZkQBrR#vkmRuZyY3cJS5IZJsJ3_yRUi42ndrGq4W0e20EWNaf4
-
Is that reproducible when executing LODGen in expert mode? If it happens to run through on second try, its fine for now
-
Start DynDOLOD in expert mode and execute LODGen for Tamriel. Bring the LODGen command prompt to the front to see if it prints more details to the console. If that does not give more detail , check the Windows event viewer for additional messages from the .NET Runtime
-
TexGen generates billboards for "trees" for the current load order. See ..\DynDOLOD\docs\help\TexGen.html which explains what the criteria for a "tree" is in order for a billboard to be automatically created. Of course it creates billboards with the correct path and filename convention that is expected by xLODGen/DynDOLOD tree LOD generation, which has not changed since its inception. If users follow the instructions and run TexGen before DynDOLOD and install its output overwriting everything we can be reasonable sure the billboards are the correct ones for the tree at that time using the old system. In addition, DynDOLOD checks the full model and textures have the same CRC32 as they did when TexGen generated the billboards and prints warning messages in case they don't match anymore because the load order changed after generating the TexGen output.
-
DyndoLOD Aftermath - What have I done?
sheson replied to GreyMtnFox's question in DynDOLOD & xLODGen Support
FAQ: Game: Tree LOD: LOD trees textures cut off mid-way A: The tree texture atlas like Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds does not belong to the generated tree LOD in Meshes\Terrain\Tamriel\Trees\*.* A: Verify that the tree texture atlas Textures\Terrain\Tamriel\Trees\TamrielTreeLod.dds and the tree LOD in Meshes\Terrain\Tamriel\Trees\*.* are the ones from the DynDOLOD output folder and from the same LOD generation process and none of the files are overwritten by other mods. Increase object LOD distances in the DynDOLDO SkyUI MCM settings (or in the launcher or with BethINI) so object LOD actually shows in the distance. Always make sure the generated output overwrite everything. -
ENB has a distance shadow effect you might want to check out.
-
By default CELL water use the water record defined on the worldspace record. Unless a CELL record defines its own. Those things can be edited with CK/xEdit.
-
TreeLODGenerateMipMaps=0 in the DynDOLOD INI
-
xEdit/xLODGen is a CK replacement and its default settings are supposed to match the vanilla LOD files. TexGen/DynDOLOD is the advanced version for drastically improved tree and object LOD for Skyrim. Its defaults are based on actual testing. The point is, whatever I recommended and explain about TexGen, object LOD textures and billboards has no connection to terrain LOD. It requires its own and different testing.
-
Read the text at the bottom of the options window. The vanilla BA2 (typically Fallout4 - Meshes.ba2) with the lodsettings file for commonwealth is not being loaded (because of missing default INI setting) or it has been modified. Look at the log messages of xEdit/xLODGen. It lists all BA2 files that are being loaded.
-
Make all water and the LOD water use the same/similar water or change how the engine/water works.
-
The settings, instructions and recommendations for TexGen, which generates object LOD textures and billboards, obviously have no correlation to terrain LOD whatsoever. What resolutions are useful for terrain LOD in what scenarios are completely different.
-
That is not how water LOD works in the terrain LOD meshes works. There is only a general Water Shader hat can be defined. The world space record then defines which water record is actually used for all water LOD of the worldspace. Higher settings/resolutions require more resources, obviously.
-
The load order seems to have issues if the FPS is under 60. Use a pure and defined vanilla setup to test things, with nothing else that limits or hinders performance. With vsync disabled, obviously. The graphs do not not show GPU % usage. Obviously it is silly to use full models for all tree LOD models, especially now that creating hybrids became as simple as just saving the full model twice into trunk and crown. Every triangle saved means smaller files size, less resource usage, less memory usage, less draw calls that can be used for something else. For the few 3D tree LOD models that reveal so much (twisted) trunk and branches that they actually need 3D trunks and for Grass LOD for example. And the 8k skin and mandatory body physics...
-
Upload entire log files not just parts of it. Use search to find posts that might already answer questions. For example this post: "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." Based on the posted log lines there is no issue using DynDOLOD. It seems to work as intended and reports problems in the load order. Missing meshes can cause CTD or red exclamation marks in the game. DynDOLOD reports them and then will ignore the base records and any references using them. So in case it is an object that could have had LOD, it won't. Normal textures should end in *_n.dds. This check helps to find typos or accidentally setting the diffuse as normal texture. It is highly beneficial and best practice for example for better compatibility with other mods/tools to adhere to Bethesda file naming conventions.
-
That the map uses terrain LOD level 32 has already been explained several times and the advice to simply not generate these files or delete them afterwards has also been already explained before. These instructions apply to a specific mod and are not specific to whatever tool that was used to generate terrain LOD. Textures are not being distorted by terrain LOD meshes. The xy spacing of vertices/UV coordinates are always the same regardless of mesh quality or texture resolution. What that means is that looking at a terrain LOD mesh straight from above in Nifskope in orthographic view shows the texture 1:1 like looking at the terrain LOD texture in an image viewer. That means terrain LOD meshes and terrain LOD textures always work with each other regardless their source and quality.
-
Correct if the message only appears while loading. Once loading is completed and the error check does not report it anymore, it is indeed fine.
-
The latest version 2.95 works perfectly fine with just Cutting Room Floor. Other plugins or patches or LOOT rules might be interfering. Make sure to use the latest versions all mods/plugins involved. From the first post: Because of the need to have an ESM for things to work properly, there is a chance that some records have to copy as "underwrite" into the ESM and as normal overwrite into the ESP at the same time. The DynDOLOD.esm should never have any unflagged ESP as a master and only get its records/data from masterfiles (including flagged ESP). Post a report with log in case the DynDOLOD.esm has an unflagged ESP as master. LOOT typically will let you know one way or another (reporting cyclic interaction or crash for example). Do not use such plugins for anything as they are broken. Also post the exact error message.
-
I suggest to read the included TexGen manual and help. The first options has been available for years and still generates a select list of object LOD textures. As has been discussed over and over again for years, that first option can not update rendered object LOD textures. Now with the addition of the second option, a select list of rendered object LOD can updated as well. "Stitched object LOD textures are direct derivativs of resized full textures." "Rendered object LOD textures are rendered from special models in the ..\DynDOLOD\Edit Scripts\DynDOLOD\Render\Objects\ folder." DynDOLOD will use whatever object LOD textures are currently installed in the load order. If they are not updated with TexGen, some will still be vanilla, some will be from DynDOLOD Resources for vanilla and some from mods. All options that are enabled by default are "necessary" so that default object LOD and tree LOD generation use the best possible textures for the current load order. Unless you have a 4k or 8k monitor you not need to set 1024 in TexGen for the stitched or rendered object LOD textures. Remember that DynDOLOD 3 ALPHA is work in progress. I still need to update the texts, since nobody really pays much attention to t he manuals. From the help: "This sets the typical base size of the generated object LOD textures. The default is 256." Currently the generated stitched/rendered object textures can be anything from 32 to 2k with the base of 256. The defaults are good for a screen resolution of 1440p and lower. The stitched and rendered object LOD textures will probably also get a max texture size dropdown like the billboards. The dropdowns in DynDOLOD say "Max tile size..." From the help: "Max tile size LOD sets the maximum resolution a single object LOD texture can occupy on the object LOD texture atlas." "Max tile size full sets the maximum resolution a single full texture can occupy on the object LOD texture atlas." If a texture is larger, it is shrunk to the max tile size when it is added to the texture atlas. Again, the default are supposed to be good for 1440p. In a future update I plan to add more explanations to the manual, including how to determine live in the game the best resolution for a LOD texture in addition to the more mathematical explanations for billboards.
-
The NiAlphaPropertety requires/works with the alpha channel of the texture. The Alpha setting on the shader defines how how opaque the entire texture is regardless of its alpha channel. It can have any value between 0 and 1, even in LOD. It is always set to 1 in the LOD meshes. You adjust the threshold in the LOD model asset. Since this can not be done in the generated LOD meshes, DynDOLOD adjusts the threshold in the LOD texture, so it works with the hardcoded LOD meshes threshold of 128. The impact is that the threshold of the full model is used to adjust the alpha channel of the input full texture when it is being added to the LOD texture atlas and becomes a LOD texture, so that whatever pixels in the full model are transparent/opaque are also transparent/opaque in the LOD despite the LOD having a hardcoded threshold of 128.
-
LOD is generated for the current load order with the LOD assets that are installed at the time. In particular, object LOD are a collection of supermeshes made from combining LOD models. The generated object LOD files (which are just large NIF models) are loaded and placed in the game. If the load order or the LOD assets change used for LOD generation change, LOD needs to be generated again for the new load order and/or assets to be show in generated LOD. The alpha setting on the shader defines the transparency of the surface regardless of any alpha information in the texture. As explained in the manual, in case a model used for LOD generation has a NiAlphaProperty, the threshold value of it is used to adjust the alpha of the input texture (and the mipmaps that are generated for it with alpha-to-coverage) to account for the fixed threshold of LOD while the texture is added to the LOD atlas texture. the threshold is quantized into 16 steps to prevent ending up with too many similarly adjusted textures. For the changed thresholds in the LOD models to have an effect on the generated LOD meshes and textures, the LOD meshes and textures need to be generated after changing the LOD models.
-
open cities & surplus tree for open cities
sheson replied to pattesfolles's question in DynDOLOD & xLODGen Support
The first pass should be generated without Open Cities and any plugin/mod for it. The plugin SurplusTreesforOpenCitiesSkyrim.esp triggers "automatic Open Cities mode" intended for the second pass already for the first pass, because it contains OpenCties in the file name. Not having that plugin means, not getting any LOD for the trees. Since it does not seem to do anything else, it might work to just rename the plugin to SurplusTreesforOCS.esp and still have it loaded in the first pass. That hopefully should give you LOD for the trees and correct LODs for the castle. -
If you mean the ground in the distance between the rocks, that is terrain LOD. Generate terrain LOD for the load order with xLODgen. Use a suitable noise.dds as explained in the first post of xLODGen. Make sure to disable "improved" snow etc.
