Jump to content

sheson

Mod Author
  • Posts

    13,179
  • Joined

  • Last visited

  • Days Won

    431

Everything posted by sheson

  1. The generated files are exactly the same regardless of the selected output folder. If they do not work in-game, they are not correctly installed. The files you sent were esp and BSAs, so you mean that, right. One test to do would be to not pack them and then selectively remove the atlas textures and then chunks of BTO in order to see if only specific files cause a problem. That can only "fix"things if files are outdated or there are still foreign files lingering around. The obvious first test would be to not install any mods, change any settings and then generate LOD for vanilla and see what happens. All of the xLODGen settings are equally safe to use. The only difference would textures sizes in terms of VRAM usage. It does not matter how the player gets to a location, the same bto/dds files are loaded. It the problem should also happen when fast traveling into Goodneighbour from afar, or just going through the gate from the Commonwealth. What mod manager are you using?
  2. Not that we expected anything different from Bethesda, but the update to version 1.5.39.0.8 still did not fix the large reference bug or the broken tree LOD reflections and most likely none of the other well known and documented bugs that should have been fixed years ago already. Shame.
  3. What is not working when you set a dedicated output path? I suggest to always generate to an empty dedicated folder to avoid overwriting existing files in the data folder. Then create archive from there. Typically either the LOD meshes/textures work or they don't. If a problem is not 100% repeatable it most likely has an unrelated cause. Especially, it should not matter from where or how the got to a location, either be it by walking, exiting an interior or fast traveling from afar. It could be a resource problem for example - though that seems a unlikely with the 64 bit engine, maybe VRAM limits, not sure I have not spend much time with FO4 or modding it. The defaults are based on the vanilla game, though Bethesda can not decide between DXT1 or DXT5 either. They use either across the main worldspace and the DLC. Visually and performance there won't be much of a noticeable difference. The LOD files you uploaded work fine in my game entering/exiting lots of different buildings in Goodneighbour. However, there is something off with the BTO meshes you uploaded. The alpha threshold on transparent shapes is set to 0 instead of 110 and that indicates something is amiss. I have no idea how that happened and I never have that happened here. For example check Commonwealth.4.0.0.bto in nifskope. Find a BSSubIndexTriShape with obj-at as its name an unfold it to find the NiAlphaProperty to see its Threshold value. It should be the 110 from the options. Maybe try to generate (just Commonwealth) with beta 10 I just uploaded today and check again.
  4. Only LOD 4 "knows" about large references, so it is possible if the uLargeRefLODGridSize is greater than how far LOD 4 goes (e.g. where LOD 8 starts) things get wierd. I never actually tested that specifically. Probably because large references are already pretty much broken in LOD 4 anyways if using any mods that modify the worldspace.
  5. The roof and the stone tower it sits on and the porch are all one shape and in the same segment (cell) in the BTO. Their LOD can only load/unload together. What happens when you set the Large Object Distance slider to the left? (uLargeRefLODGridSize=5 in SkyrimPrefs.ini) The roof is loading when you get near?
  6. That is very easy to do in xEdit: Get the form id from console in game. Enter form id in xEdit top left FormID field, hit enter. In the right window find the row FormID, then the column in the DynDOLOD plugin, CTRL + left click that entry, it will underline. Now the left tree view highlights the overwrite in the DynDOLOD plugin, right click it, select remove.
  7. Remind me, access to that only happens after advancing some quest right? For a quick "fix" you can just remove the overwrite from the DynDOLOD plugin that unsets the flags. If this also happens with a save that never saw a DynDOLOD plugin, then something else is happening.
  8. The refs do not exist in the child worldspace Solitude. They only exist in the Tamriel parent world. Before dynamic LOD is generated, they are flagged Is Full LOD which means they are always visible in all connected worldspace regardless of distance. They get updated for dynamic LOD, which means that flag gets unset which the consequence that they can not be seen from the child world anymore. What I wondering is from where behind the wall you are high enough to be able to see the building(s)? They are examples to document and test the large reference engine bugs. They have no use for game play.
  9. Really odd, I can not replicate this and the log and export file do not show anything. Can you check meshes\terrain\Tamriel\Objects\Tamriel.4.4.0.bto and meshes\terrain\Tamriel\Objects\Tamriel.8.0.0.bto in nifskope if they show the roof and if it is the same shape as the rest of the building? Just clock on it to highlight the the triangles. Upload those files too if you like.
  10. Maybe another model needs _2 as well to fill all holes? I might have a look some time myself and make adjustment for things to show properly on the map as well. That is the thing, it is not LOD you need to adjust, just add references for the full models to the child world.
  11. Thanks, Can you upload a screenshot of the problem?
  12. Please upload DynDOLOD\Logs\DynDOLOD_SSE_log.txt and DynDOLOD\Edit Scripts\Export\LODGen_TES5_Tamriel.txt to a file service for me to check.
  13. If you rename a mesh file from _lod_1.nif to _lod_2.nif in the name, nothing else needs to be done. Next time LOD is generated that model will also be used for LOD level 16 and show up on the map. No additional rules required. You are confusing the loaded cells with the LOD area past the loaded cells. Type tll in console to toggle LOD off/on. What remains are the loaded cells. The child worlds / walled cities cells are planted over the parent world cities. Mods that edit the immediate parent world cells right outside the walls also need to add the same objects to the child world cells in order for the object to show - unless the object has the Full LOD (neverfade) checked and the child world has the Use SkyCell flag checked (which is the case for all walled cities). For some obvious vanilla objects around Whiterun / Solitude the DynDOLOD Resources has the Exterior plugins/patch files, but nothing for other mods. There is no function in DynDOLOD to automatically patch such object from parent to child world.
  14. It seems there might have been a bug in the most recent LODGen.exe version. Get xLODGen beta 9 or newer and see if it solves your problem.
  15. That message does not matter. You need to establish if the generated LOD *.bto are fine/valid or not, e.g. has the generated LOD a problem or the setup. I can only help with the former. If you upload a bto file I could check.
  16. Yes. This sounds like a problem with occlusion planes. So you found the culprit to be solitude reborn. That mod is ignored by DynDOLOD as it only modifies the inside of the city without doing the same modifications to the outside. The Solitude Reborn.esp should probably load after DynDOLOD.esp, though I am not sure that will fix this kind of problem. No "disabled neverfade and replace by dynamic lod" messages mean that a reference that is always loaded and visible has been demoted to a normal reference, that now is only visible and loaded when its cell is loaded or the player is within the Near or Far Grid distance. Generating dynamic LOD has a check box on the advanced options window.
  17. This is a game engine bug. Bethesda should be the one to fix game breaking engine bugs, especially considering that Skyrim SE is an active platform for micro transactions / paid mods. By all accounts the most prominent parts of the bug should be easy to fix: always properly unload LOD as there is no reason to not unload it regardless of what mods do to references or anything else. It is likely possible to create a fix as a SKSE plugin after investigating the program code. However, I am not looking into fixing game breaking bugs of an active game platform that is used for in-game micro transactions. A possible workaround would be to rigorously remove all the existing large reference data from all vanilla plugins, including Skryim.esm and only add back the data for large references that are not modified by plugins in the current load order. That would be a drastic measure and doesn't help the 4.5 million or so console users, though.
  18. Looks like the single source LOD texture (should be textures\lod\MountainTrimAlphaLOD.dds) or the LOD texture atlas is missing transparency / alpha channel.
  19. Docs\SkyrimSELargeRefGrid\SkyrimSE-LargeRefGrid.html explains what large references are. A select few full (large) full models are loading a few cells ahead past the loaded cells. Docs\DynDOLOD_Manual.html explains what object, tree and the optional dynamic LOD from DynDOLOD is and how DynDOLOD drastically improves LOD by shipping with over 4500 new/updated LOD models. More or less each large full model that is pushed by the large references either has a real LOD model in vanilla or added with DynDOLOD or a full or LOD model like the large references in case it is animated or requires features that static object and tree LOD does not support. So DynDOLOD compensates adequately. It is basically back to how Skyrim worked already. For some objects it is nice to have the full model show a bit further, to push the distance of the transition from LOD to full model a bit ahead. Especially considering that those full models receive/cast shadows for example. If the hardware and setup supports it, using large references with DynDOLOD is visually the best possible mix (and the better the visuals the more performance it requires)... if... well if only there weren't the bugs because Bethesda did not anticipate that there would be any mods changing references in the worldspaces.
  20. You can install all created files through including all DynDOLOD plugins with one archive. Installing the same files in several steps would make no difference. The higher the uLargeRefLODGridSize, the higher its performance demands, since more and more full model objects are shown further away.
  21. AFAIK nobody knows the cause or has a fix for that issue in Skyrim SE that also happens with vanilla LOD.
  22. If those visual artifacts are caused by missing cell data, it is possible that xLODGen already fixes it because of the defaults settings it uses for undefined cells. Otherwise add terrain to the missing cells with CK.
  23. That depends if you use a lot of mods that cause the large reference bugs to be noticeable a lot. The list of plugins modifying large references at the end of the DynDOLOD log can be used as a hint. If you notice a lot of texture flicker with uLargeRefLODGridSize > 5 then it would seem better to not use it. If it is clear that large references setting is turned off then the best option is to set IgnoreLargeReferences=1 in the DynDOLOD ini. Alternatively, visually, the best option is to check Upgrade NearGrid Large Refs. That way the generated LOD mod will also stay compatible in case the future large references are used in the future.
  24. From the manual: Lanterns of Skyrim - Optional: to sync switching of LOD on/off install and overwrite one script from DynDOLOD Patches. Make a backup of the original script first, only change scripts between saves when in an interior.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.