sheson
-
Posts
13,181 -
Joined
-
Last visited
-
Days Won
431
Everything posted by sheson
-
As explained at https://dyndolod.info/Help/Snow-Ash-LOD-Shader, the snow shader does not affect LOD generation and DynDOLOD does not change the shaders. TexGen generates updated object LOD textures for those LOD models from the full textures. If the normal map full texture is flat, the bricks will appear be less bumpy to the shader.
-
Why do you believe it is not the vanilla LOD model? You can try to delete any loose LOD model with the same path and filename as the LOD model in Skyrim Meshes BSA,. LOD models do not contain snow shaders. Whatever snow cover you see is applied onto the already generated object LOD.
-
Either textures\landscape\mountains\mountainslab02.dds is being replaced by a mod or full the mountains use a different texture. textures\lod\mtnpeak02lod.dds is a vanilla object LOD texture that ships with Skyrim - Textures5.bsa. As explained, it is not being updated by TexGen at the moment and needs to be manually created. If those mountain use a texture set replacement, the LOD models that use the rendered object LOD texture need custom models with their own unique LOD texture filename so they do not interfere with the "normal" mountains. Can not look myself without a form ID or cell coordinates.
-
No load order was provided. Looks like there is a custom mountain texture installed and its rendered object LOD textures for the further away mountains LOD are not updated to match the full texture. https://dyndolod.info/Help/TexGen#Rendered-Object-LOD-Textures However, far away mountains, icebergs and glaciers are not yet covered. If a mod makes changes to these relevant full textures, it should also include updated pre-rendered object LOD textures. If this is the vanilla game provide form ID or location information. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
-
Read https://dyndolod.info/Help/Snow-Ash-LOD-Shader. You can set a rule with the NoMato flag set for the reference or the mesh to not set the material shader. See https://dyndolod.info/Help/Mesh-Mask-Reference-Rules
-
As explained, it is best to not install (or remove) 3rd party billboards and instead use TexGen to generate all desired billboards. TexGen does not care about billboards in the load order. TexGen Configuration explains how TexGen determines which billboards to create automatically and how to force enable/disable specific billboard creation. DynDOLOD will use all billboards found in the load order.
-
SSE - Flickering Mountains (Z Fighting)
sheson replied to HiTMAN31X's question in DynDOLOD & xLODGen Support
Use modwatch instead of posting screenshots of the load order. You did not say which DynDOLOD version you are using. LOD generation does not change how the engine works. It does not change z-fighting. However, generating higher resolution terrain LOD meshes and more object LOD (when using a mod that adds additional mountains objects) can cover up z-fighting better. Increase (or decrease) object and/or terrain LOD distances in the DynDOLOD SkyUI MCM Settings to change how object LOD and terrain LOD intersect. -
That is what the message reports. The plugin defines assets that do not exist. If the assets would exist or if the plugin wouldn't contain records that define missing assets there would be no messages.
-
Read the first post of the DynDOLOD 3.00 Alpha thread where to make post when participating in the DynDOLOD 3 Alpha test. I moved the post to the thread. Do not post screenshots of text. Copy and paste the text instead. Read the first post which logfiles to include when making posts. Read the Summary that opens in the the default browser and what it explains about the file not found messages or read the explanations directly at https://dyndolod.info/Messages/File-Not-Found-Meshes You seem to be surprised that files that can not be found do not exist. If a file would exist it would be found. Not sure what the question is?
-
The (truncated) debug log does not shed any more light on things, so do the different tests and suggestions already given in earlier posts.
-
The normal and easiest way is to to run the games launcher once so it updates the Windows registry to the new path.
-
Read the first post or my signature which both explain to use an file service to upload logfiles. Check with task manager that there no hidden Texconv zombie process from earlier unsuccessful runs. Maybe reboot. Delete old unsuccessful output and temp folder. Make sure to not use anything else while running TexGen, especially not anything that makes heavy use of the graphics card. Test if Texgen runs through if you only select stitched object LOD (the billboards and rendered object LOD went through fine in the last run). You can merge the output of the different texture types. Test if it runs through if you set DXT5 for diffuse alpha/normal specular and DXT1 for diffuse/normal. Then test A8R8G8B8 and R8G8B8. These uncompressed formats will not require the use of Texconv. Convert textures with Texocnv or another tool afterwards.
-
Read the first post which log files and bugreport.txt if it exists to upload when making posts. Nobody knows what "tons of different errors at various stages" means or what their cause is. Maybe this error message is the result of other problems. The error message from Texconv is kind of self explanatory. Seems it can not acquire enough main memory or VRAM to convert a texture. If more than one graphics card exists make sure the first one is the better one. An obvious first troubleshooting step would be to check the textures\dungeons\mines\minerockwall03.dds is not corrupt and can be read with an image viewer without problem. While you are at it, checks its resolution. Then maybe try to convert it with texconv on the command prompt directly to see if that works or not. Another reason might OS, antivir etc interfering with read/write access. DynDOLOD 3.x has no external scripts anymore. DynDOLOD_Worlds.pas was for DynDOLOD and not TexGen anyways.
-
This came up before: https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-56/?do=findComment&comment=250166 Increase LOD distances in the DynDOLOD SkyUI MCM.
-
You do not provide any information, no logs. You are posting on xLODGen thread. No idea what DynDOLOD version you are using or what the exact error message is. You are just making assumptions about things to explain the problem instead of reporting the problem. So I can just explain how checking if a file exists actually works. You probably need to add exceptions to Windows Defender like everybody else as explained and discussed dozens of times before. For any tool to be able to "access" VFS of MO2, the tool needs to be started from MO2.
-
Programs like xEdit, xLODGen, DynDOLOD etc. use standard OS function to access files. It is the OS that tells a program if a file exists or not. Either because the files does not exist or the OS prevents access, typically because of UAC, antivir etc.
-
Read the first post which log files and bugreport.txt to upload when making posts. DynDOLOD does not "crash". It reports an error. From the snippet you uploaded, it seems the external tool Texconv.exe has a problem or is being prevented to run properly by the OS, antivir. It might also possible there is a problem with the mentioned texture textures\landscape\trees\gkbsmoothdarkbark20.dds or accessing the graphics card, but then typically the error code would be different.
-
This is the xLODGen thread!? If TexGen or any tool has problem finding files it because the files do not exist or the OS, antivir etc. prevent access. We all use MO opening files without problems.
-
The default diffuse and normal map already exist in the vanilla BSA and are used automatically. The point of the error message is to actually install the correct textures so the default ones are not used.
-
Based on bugreport.txt, use the x64 version.
-
I am not clear what the connection to DynDOLOD is supposed to be? Have you check the DynDOLOD log for Root node messages as explained the readme? In case you still need to find the corresponding NIF: The shape names are inside a NIF, so in order to find the NIF you need to search all NIF in the load order for those texts. There are tools that can search text in binary files. In case it is a NIF that is enabled by dynamic LOD, you might get lucky by enabling the debug mode message to the papyrus log as explained in the readme.
-
Any exception happening in the application is handled by it and should produce a bugreport.txt. That is why it makes it so hard to analyze or troubleshoot. Any normal race condition should not be able to break out of it. it you have the means to reduce the max number of cores/threads for testing, try that anyways.
-
Recreated and uploaded the Standalone archive again. Download Alpha-56 again unpack into new, empty folder.
-
I can not really check a problem that happens on your PC, OS or installation. Without any information there is only one thing I can tell you: do not rename or modify any of the files. There might be a problem with the archive. Let me me upload a new one.
