Jump to content

sheson

Mod Author
 View Profile  See their activity

  • Posts

    13,181

  • Joined

  • Last visited

  • Days Won

    431

 Content Type 

Everything posted by sheson

  1. sheson
    The log messages that are printed to the message window can be copied and pasted or maybe you can screenshot them as last resort in case the log file is not create while closing the program. Look out for warning message passing by. There seems to be a problem with a landscape texture. See if this debug version says which.
  2. sheson
    Check what this debug version does.
  3. sheson
    Maybe this debug version spits out more than the release version.
  4. sheson
    The problem is that there can not really be an unhandled exception, because of the tool (madexcept) is supposed to capture them all and write the bugreport txt. The bugreports you had didn't really made much sense so far. Since you also already had a crash while xEdit loads the plugins at startup, this problems happens long before there is any multi-threading code generating LOD. So it could be something that was added to xEdit 4.1.3g, which does have way more updates to its code then the 1 fix that was made to terrain LOD generation code in 81. E.g. the change between 77 and 78 was the update to 4.1.3g and something to external LODGen.exe. The entire problem is a random fluke that only you have so far and without the bugreport it will be hard to troubleshoot.
  5. sheson
    It seems you generated the first step incorrectly with dynamic LOD and saved and installed the DynDOLOD plugins.There should be no DynDOLOD plugins loaded when doing the second pass. Make sure to really follow the instructions.
  6. sheson
    Near grid is a concept of DynDOLOD. The large ref grid has whatever size is set for uLargeRefLODGridSize in the SkyrimPrefs.INI. The launcher defaults are from 5 to 11. The Near Grid and a Far Grid setting in DynDOLOD do not affect the uGridsToLoad or uLargeRefLODGridSize INI settings or systems. They exist to control dynamic LOD of DynDOLOD. Nothing else. Upgrade NearGrid Large Refs checkbox makes any large reference that was supposed to only show in the Near Grid show to the Far Grid distance. It does not matter if the large ref system is on or off. DynDOLOD3/docs/help/Advanced.html: Unchecked large references that would have dynamic LOD in the NearGrid are ignored. They will not have LOD beyond the large reference distance setting. Checked large references that would have dynamic LOD in the NearGrid are added to the FarGrid. They will have LOD beyond the large reference distance setting.
  7. sheson
    That version does not have terrain LOD yet. The beta test here is obviously not completed yet. Your last crash happened while loading plugins, long before any LOD generation.
  8. sheson
    Set Export=0 in the DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini
  9. sheson
    Download it from the #xedit-builds channel from the xEdit discord.
  10. sheson
    There is really no need for the unrelated LODGen logs, especially when xEdit already stops while loading plugins long before generation any LOD. See what the lastest xEdit_4.1.3g experimental posted by ElminsterAU to the #xedit-builds does.
  11. sheson
    The fact that no bugreport is created and the program is just closes (it does, yes? Hence the event viewer entries and no xLODGen log?) indicates not a "normal" exception that the program can handle, but it just seems to be terminated. Is odd. No other similar reports yet. We will have to see. Test it by starting directly without mod manager active and see what happens if it runs for vanilla only. Set command line arguments with a shortcut.
  12. sheson
    The terms near and far grid are sole concepts of DynDOLOD. DynDOLOD does not change any INI settings. Upgraded large references show further away to the far grid distance instead to the near distance, which means more stuff in the distance and more resource usage. If the large reference system is used, there is typically no need to extend their distance beyond the near grid as the near grid distance is deemed sufficient (because they are typically smaller objects). The uGrids is the active cells which always shows full models. The LargeRefGrid shows full models or large references outside the uGrids if it is larger. For normal large ref grid sizes, the visuals are a bit better because full models switch to LOD model a bit further out, at the cost of more performance requirements and sometimes really bad decals that are not fading which both gets worse with greater large ref distance. The large reference system is not visually active anymore, e.g. not used when its size is equal to the uGrids size. If the upgrade option is not checked, then near grid large refs will not be upgraded. In case the large ref system is off, it means these reference actually do not show any dynamic LOD outside the active cells. Hence the suggestion to check the box to upgrade them, so they show outside the uGrids to the far grid distance instead not at all. This is all became necessary because of side effects of the large ref system. What is considered good quality is personal preference and depends on load order. Typically it is nice to have ful models load a couple cells further out with the large ref system. It goes to hell once you notice the decals (can be undone by unsetting NoFade in the shader flags for the affect models) and especially if large reference bugs are triggered everywhere - which is mostly solvable by making plugins ESM and avoiding the other causes. I documented the bugs and main fix 2016, how there are still so many visually incompatible plugins triggering them I dunno.
  13. sheson
    The answer depends on what mod manager you are using and how you installed the TexGen output and is not related to the tools itself.
  14. sheson
    You keep posting the logs from Edit Scripts/LODGen.exe that generates terrain LOD meshes. The xLODGen log would be the SSELODGen.txt that shows all log messages printed to the message window. You sure that system/memory is stable, disk OK, no interference from antivir?
  15. sheson
    Mesh rules always apply whatever affect they have on the different LOD types. There are rules that can affect if a tree gets tree LOD or not for example. That is a typo obviously. It is supposed to say "Requires Generate object LOD to be checked." Sometimes there are posts or instructions that tell users to unchecked tree LOD generation and instead use pre-made tree LODs from a mod. Yes, second pass like the one for Open Cities.
  16. sheson
    If this happens to be reproducible, compare with this version, unless I have posted a new beta with a higher version than 81. The next beta 82 and newer will include whatever it is I did in the test version.
  17. sheson
    Great. Then all that is left to do is to make sure TexGen generates the appropriate LOD texture(s) as required by the mod, so users do not accidentally end up with the wrong mountainslablod. If that is all the same to you I can just add that with the next update of DynDOLOD. It seems to be made out of mountainslab01.dds and mountainslab02_n.dds in a 2x1 tile. Is that correct?
  18. sheson
    Mountainslablod.dds is a vanilla LOD textures that is a 3x3 stitched version of the vanilla textures\landscape\mountains\mountainslab02.dds. Mountainslab02.dds is a square and tillable texture used by vanilla and custom full and LOD models. Mountainslablod.dds is used by vanilla and custom LOD models. By default TexGen updates mountainslablod.dds with the currently installed mountainslab02.dds according to this rule, obviously. Whenever a mod makes a change to mountainslab02.dds that does not change the full models UV or shader, then automatically every full and LOD model and the generated LOD with TexGen/DynDOLOD will match without nobody needing to do anything. If a mod replaces a vanilla full or LOD texture that requires UV or shader updates of full or LOD models to look and work correctly, then it seems necessary to update every vanilla or custom full or LOD model. That seems like a lot of unnecessary work tracking all mods or having to deal with users dealing with visual problems. It seems advantageous to use new texture filenames for both the full and LOD texture to avoid such conflicts. You might want to look at new land mods in this particular case. Regardless of replacing a vanilla texture or using a new texture filename, an updated TexGen rule that gets automatically applied should be added to create the different version of "your" LOD texture that is required.
  19. sheson
    Terrain LOD generation does not use object LOD textures. Terrain LOD generation uses the texture sets and their landscape full textures as they are used on the landscape records. Typically DynDOLOD should have / can use the same LOD resources as xLODGen. Of course if so required by a mod, assets that ship with DynDOLOD Resources need to have additional replacements in addition to the vanilla LOD assets.
  20. sheson
    The HD LOD flag alone is not the only deciding factor if a shape of a LOD model is flagged HD or not. As explained earlier, this is done so HD and non HD shapes can be in the same LOD model. Other deciding factors are NIF and texture names, also because LOD is generated for base records that do not or can not have LOD models defined. One of those defaults is what caused you the troubles. The bit that is hilarious is that you did not report or ask any question because you assumed that DynDOLOD would need changes, while DynDOLOD famously has changes and updates all the time to better support mods and mod authors. Always report problems or issues so they can be discussed and resolved and so the tools or processes can be improved as required. If a mod makes changes so that it updates models which require new textures that are styled differently, then the new textures should have a new file names, so that there is no conflict with other mods that still require the original styled textures and for which the new texture style does not work. Unless you intend to make patches for these mods as well. If technically possible, TexGen should be used to generate the accompanying LOD texture either updating existing or adding new rules. This will future proof the mod for texture updates or replacement textures. The rules for TexGen/DynDOLOD can be installed with the mods assets into the data folder so they are used automatically. Users do not have to do anything other than installing mods and running the tools as always. DynDOLOD Resources needs to overwrite mods that include vanilla LOD resources, mods with updated LOD resources overwrite DynDOLOD Resources, TexGen output overwrites everything, then DynDOLOD output overwrites everything. Every time TexGen/DynDOLOD run they automatically load rules for mods without the user having to do anything. This is how TexGen/DynDOLOD work since over half a decade and that is why it is so easy to generate LOD for the load orders. Not sure what this refers to specifically.
  21. sheson
    Instead of the the LODGen log post the xLODGen logs.
  22. sheson
    Terrain is the ground you walk on. It can not really be clicked. Everything else is objects. Looking at the foggy images I probably though we looking at a rocky mountain model. Rectangular holes in the LOD that appear/disappear when moving form one cell to the next is the broken vanilla occlusion data or outdated occlusion data.
  23. sheson
    The problems you ran into are because of a couple very much intended things in xLODGen/TexGen/DynDOLOD and LODGen which can or could be easily controlled by config files and INI settings, also included in mods to automate things. >I didn't report this issue because I assume that DynDoLod would need bigger changes to solve this issue. And I solved it anyway. This is a bit hilarious, considering the feature updates and support given to other mods and mod authors in the last half decade. >And it is the duty of these authors to take care about the lod textures. Only for textures that TexGen can not yet generate, especially now that the alpha version can render object LOD textures and billboards from models. If custom LOD textures are required, create a rule for so it is generated with TexGen for the load order. Especially if they need to replace existing LOD textures. That is the sole purpose of TexGen. The current solution might have visual problems with 3rd party mods that include new full or LOD models that use overwritten textures that are made for different UV.
  24. sheson
    The last image does not show any mountain? It shows terrain LOD as far as I can tell. Check with xEdit Asset Browser (CTRL+F3) if a Tamriel.4.92.-4.bto exists. If none exists you will need to double check the position. You are probably one quad (e.g. 4 cells) off. That far out is typically only vanilla LOD files as this area was cut from the vanilla plugins. Make sure to update occlusion for this load order.
  25. sheson
    Not sure if this is just information or a discussion to find better solutions to make everything more compatible and easier by updating assets, settings, configs or the involved tools as deemed necessary?
×
×
  • Create New...

Important Information

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

  I accept