Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Did you mean to post this on the xLODGen forum for sheson? Your question seems unexpected in this forum context. This is our new recommendation for LOD4 based on my post over there: Maybe you are addressing MisterModern's previous post, so perhaps I should shut up myself
  2. z929669
    Please disable DynDOLOD output mod to test this. If the problem is resolved, then you should post with logs in DynDOLOD support forum.
  3. z929669
    Is that LOD in your screens? I assumed not unless you used tfc in console or verified with tll. Looks like Solstheim, and I assume you are not running Step SSE strict. I'd say it's your complexparticlelights ENB settings and possibly litesprite
  4. z929669
    Try killing any unnecessary GPU software processes using Windows Task Manager. I do this as a general practice when grass caching and using xLODGen or DynDOLOD. This vastly speeds up gen time on my system (AMD GPU. NVIDIA's will be different): I use them at all times otherwise, but for LODGen and grass cache gen, only drivers are required. These other processes don't know how to behave with LODGen processes.
  5. z929669
    Did you update to the latest Embers XD and/or latest Particle Patch ... and are you using the plugin from the latter?
  6. z929669
    Wait ... you are correct. The plume should NOT be toggled in DynDOLOD Resources ... looking at the history for that page, it seems I made a mistake when updating it the least time, so fixing that now. I don't think it's necessary to regen LOD if you remove that plume mesh (or reinstall resources with/wo it toggled)
  7. z929669
    Thanks. The gen time difference looks to be significant even considering MOE of random variables that might impact this. Obviously, a lot more data would be needed for any robust statistical analysis, but these results are instructive, because they are expected. I'm adjusting the guide screens now for LOD4/32 (removing normal mipmap toggle). PS: According to the xLODGen OP ... ... so I will disable these as well, since this is the advice from @sheson, and I doubt there are testing results warranting they be toggled. So far, it's tentative "best practice" for these reasons. Again, I've not found discernible quality differences back when I was testing this stuff ... and terrain LOD is most important for full-LOD transitions of landscape heights and shoreline contours anyway. Object LOD is far more impacting as long as terrain LOD geometry is as accurate as possible compared to loaded cells. VRAM is just not that important any more, given GPUs these days and system requirements of the guide. People have access to this info and can make changes using their own judgement if they care to RTFM.
  8. z929669
    We made that change a while back, dropping BDRM in favor of the DynDOLOD-enhanced vanilla plume after we picked up WTT.
  9. z929669
    It's probably best to keep it untoggled for normals in LOD4 using testing to validate toggling them simply because it should theoretically reduce gen time, given that it's likely it doesn't matter either way. I just forgot to pay attention to that setting when updating the images. My guess is that untoggled for normals and diffuse on the map probably won't make any difference either. I'll add it to my list of to-dos if you don't object. Yes, this and Embers XD haven't been updated yet. I still haven't had a chance (taken the time) to look at either one. Embers gets updated all the time, and it's a pain to keep pace with the alterations of that FOMOD.
  10. z929669
    I don't see what you are referring to here, but if you mean to forward the changes in your screen from PAN_AIO_Big.esp into the Step Patch, overwriting those forwarded from AI Overhaul, then yes, this would be correct, thus merging CRF, AI Overhaul, and PAN_AIO_Big into the patch.
  11. z929669
    Thanks. I avoid Reddit, personally, since I hate the way conversations are (dis)organized and the interface.
  12. z929669
    Will need to look at what the plugin even does. It should be useless.
  13. z929669
    See above. @Mousetick posted screens from NIFSkope. They mirror the trend that sheson posted previously. As with all terrain LOD results in my experience, the differences here are minimal in terms of quality, and as @DoubleYou stated, the actual differences may be related to z-fighting, which must be captured in-game using video. I agree that performance impact could be noticeable on low-mid systems but probably not too much as @sheson stated previously. Because of the subtle differences and potential slight performance difference, I think the official advice is sound. I have updated the Step SSE xLODGen screens likewise and am confident that this will be optimal as long as z-figting isn't an issue on any shorelines where there is no z-figting in full, loaded shorelines.
  14. z929669
    I know you and Greg put a lot of time into this one ... way to go!
  15. z929669
    I'm not sure if you are running LE or SE. That's the first choice. Our LE guide is no longer maintained and some mods in that guide have likely been updated or lost, so we can't really help much with that. This is the SE forum, so that's presumed if you are posting here. My advice for a clean build the way you want it is to first follow the SSE guide exactly from scratch. If you already did that, then disable all extras, and be certain you have the Step SSE build working correctly per the guide instructions. Once you do that, then we can give some direction on modifying the build with mods you want.
  16. z929669
    Thanks for this explanation and these example shots. In theory, is this the best setting for performance-quality trade-off favoring quality (i.e., no z-fighting of coastline water observed in-game)? Is this ensuring no z-fighting "just in case", given previous setting is true? Is this favoring performance a bit, given previous settings are true? Finally, I'm assuming the settings for LOD8|16|32 I posted previously are 'good' for the p-q trade-off. It's quality of LOD4 we are mostly concerned about. LOD8: 525, quality=4 LOD16: 625, quality=6 LOD32: 550, quality=0 PS: And 'yes' underwater is of no concern, since it's not apparent in my experience for our build.
  17. z929669
    We don't mention Windows scaling for the same reason we don't mention hundreds of other random things that are not predictable ... too many instructions and even more problems with people RTFM. We try hard to minimize instructions, and it's widely recommended to use default Windows scaling. That's for 2D applications anyway, AFAIK, and used by people with visual impairment most commonly. PS: I've seen altered Windows scaling cause all kinds of issues with certain applications, causing lots of IT headaches chasing wild geese I also run 2560 x 1440 natively on a 32" QHD monitor and use that both in Windows and gaming at native scaling. I'm kinda old, I require readers now for the past 5 years, and I prefer the native scaling myself.
  18. z929669
    From what we've gathered, higher values at LOD 4 (or any level, really) theoretically should improve performance, right? If shorelines of water bodies in any LOD level look accurate enough at full-LOD transition, and there isn't any noticeable z-fighting at a given maximum value of Optimized Unseen in a given LOD level, doesn't it make sense in terms of optimizing triangles rendered to use the highest value possible? This is why we use the following values in the Step SSE guide ... so if things look good with these values on all shorelines, please provide a rationale for NOT using these max values at a given level in terms of quality-performance trade-off (note that some of these values could possibly be increased, since we didn't exhaustively test the exact 'sweet-spot' values at each level ... these appear to be 'safe' for the Step build): LOD4: 500 (Protect Boraders ticked), quality=2 LOD8: 525, quality=4 LOD16: 625, quality=6 LOD32: 550, quality=0 PS: In case it isn't clear from the above, I'm not arguing here, just asking if any of the above is incorrect thinking in terms of performance-quality: if it looks good with max values and those quality settings, then everything is A-OK and higher values are theoretically better performance?
  19. z929669
    I emphatically agree with Mouse's last. The skeleton is all that we use, because most mod authors use this mod to support what I'd call 'edgy' modding (not that I'm against it for the general public ... no comment, but it's off the beaten path of what Skyrim is all about, and we don't advocate anything that is inappropriate with respect to the original intent of the game). That being said, this skeleton supports all sorts of character-physics dynamics that align well with the original intent of this game. What people choose to use it for is none of our business, but we use it for realism of vanilla mechanics.
  20. z929669
    It should be noted that Zanderat found this with ERM installed, so it probably is a vanilla bug. We're taking a look at a potential fix with ERM (TBD), but it would be good to know what mountain/rock mod @tadastalalas is using. I suspect MM, but IDK.
  21. z929669
    I didn't notice much difference, but I wasn't testing for that specifically. See if it helps to kill driver-soft processes via task manager first. I have AMD and I kill all processes that have 'AMD' in the label before running xLODGen, TexGen, and DynDOLOD. This reduces processing time for me by 5-10x. Regardless, our recommendation is to use Child > Parent 'Low', since that's effectively what the settings have been historically. Even better if it speeds up processing time for some. We also use DynDOLOD DLL NG.
  22. z929669
    I suspect the quality of splash effects can't be (or just isn't) differentiated based on surface for any given mod with this effect (including WoW). Compared to splashes on stone, grass has no splashing, and water is different for example. Agree that adjusting/eliminating the splash size by weather classification is the best solution if splash quality by surface type isn't an option. I wouldn't opt to tie this effect to post-processing for the sake of consistency, since post-processing is an optional component of our guides.
  23. z929669
    I think this is the best solution then, since FO fonts have already been 'accepted'. I will mess with it though, because the console font in FO isn't a monospaced font, which is conterintuitive ... and I've been nagged by that for a while. Still lots of testing to do, so my first priority will be to determine the general look/feel of DDDM. So far, I vastly prefer it, but need inputs from others. It may be a while
  24. z929669
    See if posts in this topic are related to your issue.
  25. z929669
    Please use the tool to properly post topics in this forum: I do like this idea, so it may be something we pick up in the System Setup Guide if it works.
×
×
  • Create New...

Important Information

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

  I accept