Jump to content

Mousetick

VIP-Supporter
 View Profile  See their activity

  • Posts

    1,268

  • Joined

  • Last visited

  • Days Won

    112

Everything posted by Mousetick

  1. Mousetick
    DynDOLOD Resources SE 3a45 In the following meshes: meshes\DynDOLOD\lod\trees\dlc1treewinteraspensnow01passthru_lod.nif meshes\DynDOLOD\lod\trees\dlc1treewinteraspensnow03passthru_lod.nif meshes\DynDOLOD\lod\trees\dlc1treewinteraspensnow05passthru_lod.nif it looks like the Crown and Trunk terms added to the shape names are reversed. Crown is attached to the trunk shape and Trunk is attached to the crown shape. Thanks.
  2. Mousetick
    The only thing that "plays nicely" with NGIO in his code is testing whether PrecacheGrass.txt exists or not, so that it can set different Skyrim INI settings depending on precaching or not. When not precaching, there is no way to tell whether NGIO is active or not, so whatever runs last at game startup "wins" I guess. You're welcome to test NGIO + GCH NG both active together for playing on 1.5.97, and report the results of various configurations in each. Exactly, that's an excellent reason to use this mod for playing on 1.5.97. You made my point. So then, what would be a good reason to keep NGIO?
  3. Mousetick
    No I didn't test 0.5 with GIMP. It's possible that it yields the same results as 0.51, I don't know. It seems each tool uses its own input value and formula to derive the alpha test value for the alpha-to-coverage filter. Z's Nvidia tool for example has an input value between 0 and 255, at least it's clear. Sheson found out that Texconv uses alpha-test-value=(input-value * 255) + 0.5, which rounds the fractional value to the nearest integer. We'd have to look at the GIMP source code to figure out what formula it uses. Both alpha-to-coverage and LOD binary alpha use an alpha test value. Alpha-to-coverage doesn't test individual pixels, it's much more complicated. But we can still use a ballpark guesstimate rule-of-thumb. If we use an alpha test value a little greater than 128 - that is the alpha test value of LOD binary alpha - for the alpha-to-coverage filter, then there should be very little loss of detail (we're talking about single pixels at such resolutions as mipmaps) between full model mipmaps and LOD mipmaps when rendered on screen. They should also look very similarly opaque or transparent.
  4. Mousetick
    Interesting. I haven't tried Texconv. For my tests, I only used GIMP's export to DDS feature, which has many bells and whistles, but doesn't support the newer compression formats. Yes you're right. I didn't use the correct word. The previous and next mipmaps levels appear to "crossfade" in-game.
  5. Mousetick
    All thresholds of what? Same as what? Which transition? Please be specific. I explained that I want to use NiAlphaProperty Threshold of 128. This is in order to preserve the alpha channel of the original branches texture's mipmaps when copied to the object LOD atlas, so that there are zero differences between the LOD mipmaps and the full model mipmaps.
  6. Mousetick
    I wanted to use 0.503 (0.503 * 255 = 128) but GIMP only allow 2 digits after the decimal point, so it was 0.51. I think that's fine (by the looks of it in-game) and it's probably safer to have some small margin above 128. Further tests would be required but I'm really tired of testing this stuff This was explained earlier by sheson: 128 so that DynDOLOD doesn't perform any adjustment. Also explained earlier by sheson:
  7. Mousetick
    You can still do anything you want with NGIO if you use NGIO for playing on 1.5.97, including using DynDOLODGrassMode=2. It's not clear what happens when both NGIO and this mod are used for playing on 1.5.97. Both hook into the engine to read .cgid files, both override Skyrim INI settings, one manually configured, the other one automatically. I don't care to try but I assume it produces unexpected results if not worse. So the idea is that if you use this mod for playing on 1.5.97, then you don't use NGIO at the same time. Or vice-versa, if you use NGIO for playing on 1.5.97, then you don't use this mod. Even if both worked together, it makes little sense to use both for playing. The usage instructions on the mod page are specific about using NGIO and 1.5.97 for precaching. They make no mention of NGIO or 1.5.97 for playing. Either by inadvertent omission or because the MA has not thought about this scenario. The main value of this mod is its autoconfiguration (which only supports DynDOLODGrassMode=1) and ability to read .cgid files for playing, including for Seasons. It also helps a little with the precaching process, not by much. So again, if using this mod for playing on 1.5.97, what would be the point of keeping NGIO?
  8. Mousetick
    Thank you both for putting me on the right track. I found that no Solidify filter was necessary in my case: it didn't make any difference, probably because the MA may have already applied such kind of filter. I found that using high alpha coverage caused the branches mipmaps of the full model to become blocky/blotchy/flat. Even 0.6 (0.6 * 255 = 153) was very noticeable. When the game switches from full texture to mipmap, or switches between mipmap levels, depending on viewing distance, it's very noticeable and jarring. I don't mind GIMP for how little I use it. Paint.net is nice and easy to use but doesn't have alpha-to-coverage feature when exporting to DDS. The perfect solution (for me) was "simply" to use 0.51 (0.51 * 255 = 130) for the alpha-to-coverage threshold of the mipmaps when exporting to DDS. This combined with UseMipMaps, and NiAlphaProperty Threshold = 128 (128 being the LOD "native" alpha threshold) in the 3D LOD models, makes DynDOLOD act as a full "passthru" of the original texture mipmaps to the object LOD atlas. I think it makes sense. The results are absolutely incredible. I cannot believe my eyes. I can hardly tell what is LOD and what is full model. The LOD Level 4 to active cells transitions are practically seamless for trees. I don't understand what exactly is going on when alpha-to-coverage threshold is 0.5 (0.5 * 255 = 127) and why UseMipMaps produces "bad" results with DynDOLOD that are impossible to fix with NiAlphaProperty Threshold. But it's not really important. The important point in my view is that mod authors who use alpha-to-coverage for mipmaps probably use the default 0.5 (127) threshold, which doesn't sit well with LOD binary alpha threshold of 128. I'm going to apply the same treatment to the snowy/ashy variants and to the aspen trees. We'll see if this "perfect" solution holds true.
  9. Mousetick
    That's very helpful, thanks. Fortunately the MA of the branches textures I'm using provides the raw images as PNG so I'm going to give this a try.
  10. Mousetick
    Here are the full logs if you wish to look at them: https://drive.google.com/file/d/1ZNmpBzlHU1rrC1c6wjzUTRdPlMxaG-Qj/view There isn't much to show in the console when looking at LODs, but here are the console shots of the tree full models that were discussed in previous post: As discussed and shown previously, the mipmaps generated by DynDOLOD look very different than the full texture mipmaps. They don't look bad, they're just different. Too different to not be easily noticeable and to be visually clashing with the full models. This particular very transparent, very thin texture is proving to be a really tough challenge to transpose into LOD's binary alpha. There are comments from users of that texture replacer mod reporting they tried DynDOLOD's 3D tree LODs "as is" and they thought they looked awful. I admit I can be somewhat of a mad perfectionist, but I believe it's on-topic and worth exploring possible solutions to accommodate this texture's peculiarity and work around DynDOLOD / LOD limitations or requirements. I'm not a texture artist and the mod author has been inactive for a while, so the process involves a lot of discovery and fumbling. Please don't hesitate to let me know if this is bothering you. I certainly do not wish to annoy you or abuse your time. If you're expecting DynDOLOD users in such case to "take it or leave it", that's totally fair but needs to be communicated clearly. Thanks.
  11. Mousetick
    Discussion topic: Grass Cache Helper NG by Shizof Wiki Link SKSE plugin to make the game load *.CGID files to fix bugs when using grass precache. Supports Seasons of Skyrim by loading *.SPR|SUM|AUT|WIN.CGID files according to current season. Also sets recommended ini settings automatically for easier grass precache generation and usage. Compatible with SE/AE/VR/GOG all versions. Streamlines the process of precaching grass with NGIO and using the grass cache at runtime or for generating LODs across game versions. Automates and simplifies configuration, removing many manual steps. Supports NGIO DynDOLODGrassMode=1 ONLY. Makes Grass Cache Fixes redundant and "obsolete".
  12. Mousetick
    Recap of essential info: DynDOLOD 3a148 / Resources SE 3a45 Vanilla tree meshes with Pine Branches Redone texture replacer Level0 at LOD Level 4 DynDOLOD Resources SE's 3D tree LOD models for vanilla trees Edited to add UseMipMaps to crown nodes In the process of adjusting NiAlphaProperty Threshold to make LODs thinner Now that the atlas textures are using the full texture mipmaps, I'm running into transparency/loss of details issues at smaller resolutions. Look at the trees near the house in the center of the pictures below. Notice there is no difference between 112 and 127, and at 128 the LOD is very very close to the full model, which is fantastic. LOD Alpha Threshold 112 > 127 > 128 > Full model However notice the trees further in the distance to the right of the house have been severely "shaved" at Alpha threshold 128. It gets worse with smaller mipmaps, looking at the trees far away at the foot of the mountains: It would seem that the full texture's mipmaps were not created with alpha-to-coverage, or they are, but with some kind of cutoff point for alpha around 127. Based on the following shots, does it look to you like the mipmaps have alpha-to-coverage? I see on Microsoft's Texconv page that the -keepcoverage option takes an "alpha test reference value". If the mipmaps of the full texture were generated with an "alpha test reference value" of 0.5, could this explain the observed behavior, i.e. no change between 112 and 127, and then "shaving" at 128? What value does DynDOLOD use when it generates the atlas mipmaps (i.e. when not using UseMipMaps)? Thanks in advance for your input.
  13. Mousetick
    No, I'm talking about UseMipMaps in the name of the BSTriShape of the crown of the 3D tree LOD mesh, and about the Threshold value of the NiAlphaProperty of that same BSTriShape. The past discussion is solely about 3D tree LOD models and their use of full model textures, TexGen and billboards are not involved at all. Correct.
  14. Mousetick
    After many, many tries and goof-ups I finally managed to make it work. I was about to give up but it finally dawned on me (yes, I'm slow) that UseMipMaps must be the solution: if both the full models and 3d LOD models use the same mipmaps, they should look quasi-identical at roughly the same viewing distance. Here are some results (CrownBrightness was reverted to 1 in DynDOLOD_SSE.ini): Baseline: Alpha threshold 224 without UseMipMaps Test: Alpha threshold 112 with UseMipMaps Atlas Texture: Baseline > Test This shows DynDOLOD's Lanczos filter and alpha-to-coverage do an excellent job compared to the full texture's mipmap, but somehow the mipmaps of the atlas texture end up very different, as seen in the next screenshots. In-game mid-morning: Baseline > Test In-game afternoon: Baseline > Test This is beautiful, I'm so happy. Thank you very much for your assistance and for bearing with me. Notes: I reverted the Alpha threshold to 112 for the UseMipMaps version, because with 224 the atlas texture and mipmaps were completely decimated, there was almost nothing left I need to tweak the alpha threshold again to correct the lushiness of the 3D LOD models and match it with the full models. I tried to rename the textures paths and filenames in the 3D LOD models in order to make UseMipMaps work, but it didn't work as DynDOLOD requires the same paths and filenames in both the full and 3D LOD models. I didn't want to edit the vanilla meshes, so I made sure to add UseMipMaps to all the 3D LOD models that use treepineforestbranchcomp.dds (treepineforest*passthru_lod.nif + treepineforestdead*passthru_lod.nif). The branches of the 3D LOD models still look rather flat, but I understand this is due to the LOD's binary alpha. There's nothing that can be done. Suggestion for possible future usability improvement: Since the suitability of mipmaps for use by 3D LOD models is an intrinsic property of the full texture, and does not depend on the mesh, it would make sense to specify UseMipMaps separately for specific textures (e.g. in a config file) rather than in each 3D LOD mesh. Thanks for reading.
  15. Mousetick
    'preferably' or 'absolutely'? I have edited all 5 treepineforest*passthru_lod.nif meshes but I know there is at least another one which uses the same texture. I don't see any difference in-game. Is there a way to check in the log(s) that UseMipMaps is taken into account? If this doesn't work out, I'll drop this and move on... ... to the last niggling "issue" before I reach tree LOD nirvana. The lighting effect on the branches of the 3D tree LOD crown is very nice as a whole, but is there a way to "tone it down" a bit? It looks too bright to me. I tried to counter-balance it by darkening the crowns with ; Vertexcolor multipliers for tree LOD models used in object LOD, see https://dyndolod.info/Help/Ultra-Tree-LOD ; CrownBrightness=1 CrownBrightness=0.75 but it's not the right approach, as it makes the snowy trees branches grey for example. Sometimes the lighting clashes with full model trees in the foreground which are not illuminated as brightly. Also it seems to affect the color? Thanks.
  16. Mousetick
    Yes that's true and I agree. But since LOD uses binary alpha and we don't care about transparency, we can remove the alpha by compositing the texture with a solid background. Before with Alpha > After compositing Anything that is not white background is 100 alpha (full opaque). Background is 0 alpha (full transparent). This can be combined with alpha threshold filtering, applied before compositing with the background. The gradation in shades and saturation is retained.
  17. Mousetick
    I didn't understand, sorry. Why would I need to change the alpha of the original texture, and what would I need to change it to? I don't have the tools to view/compare mipmaps, so this may be moot anyway. I'd read that before and thought it looked important and relevant to my situation, but most of it flew right over my head. I think it makes more sense now. So the full-on/full-off pixels in DynDOLOD's generated atlas texture are the results of alpha-to-coverage? The mipmaps of the original texture look ok to me in-game at roughly the same viewing distance as LOD Level 4: the branches of the full models are opaque and don't look "decimated". But perhaps the game itself uses alpha-to-coverage for compositing vegetation at small resolution? If that's the case, I'm screwed. Let me give the UseMipMaps a try. Back to NifSkope... So for example, in treepineforest01passthru_lod.nif, I would add UseMipMaps to the crown BSTriShape name: TreePineForest01_1:1 ScaleXY Crown UseMipMaps Does it look right? Thanks.
  18. Mousetick
    Ok. Out of curiosity, I tried Max tile size full = 512 which theoretically is overkill for my vertical resolution (1200). Even though it expectedly resulted in more details in both shape and color in the atlas, it didn't make any perceptible difference in-game (too far to see). I've increased the alpha threshold up to 224, from the initial 112. This makes the 3D tree LODs almost virtually indistinguishable in-game shape-wise from the full models with regards to skinniness, unless I really focus on them. So I'm pretty happy about the improvement. I'm now preoccupied with the overall/dominant color of the downscaled treepineforestbranchcomp[snow[l]].dds in the atlas. It seems "off" compared to the full texture, it makes the 3D tree LOD branches look "solid/flat" and "blocky" in-game. May I ask which resampling algorithm is used to generate the atlas texture? Comparison: original full 4K | paint.net Bicubic downscale to 256 | DynDOLOD downscale to 256 + alpha filtering Initially I thought DynDOLOD's version had a "brownish" bias (too much red), but the tints appear to be actually correct. It seems to me the actual issue is that the DynDOLOD version has very little gradation in saturation. Every pixel looks to be max saturated. RGB Perceptual Histogram: paint.net Bicubic downscale to 256 | DynDOLOD downscale to 256 + alpha filtering Thanks in advance for your input.
  19. Mousetick
    In the case of the downsampled and alpha threshold-adjusted version of treepineforestbranchcomp[snow[l]].dds generated by DynDOLOD for the 3D tree LOD crowns, is this texture considered "a single object LOD texture" or "a single full texture" for adding it to the atlas? So my takeaway from all this is that, since 3rd party tree LOD billboards should never be used and tree LOD billboards should always be generated with TexGen, there is no reason to ever use DynDOLOD's brightness setting. Thanks.
  20. Mousetick
    Thanks for your answers. Is there a DynDOLOD configuration setting, like there are in TexGen for Stitched/Rendered textures, to control the size of the generated 3D tree LOD model textures before they're added to the atlas? If not, what is the fixed size? Yes, that's all very clear, thanks. But that still doesn't address my query Let's see if I can formulate it differently: To an uneducated outsider reading the DynDOLOD documentation, both TexGen's Direct/Ambient and DynDOLOD Billboard brightness settings have, superficially, the same effects: TexGen: "Lower numbers mean less light strength = darker." DynDOLOD: "Negative Billboard Brightness values will make the billboard tree LOD darker." Each use their own method (external illumination of 3D model before rendering vs. transformation of texture pixels), but their result is descriptively and in appearance similar. In other words, these features/settings seem redundant to an uneducated outsider, which is the source of my confusion. But they must exist and be provided for separate reasons and purposes. So I'd like you to explain, with your expertise and insight, when should one method be used rather than the other, and why, and whether it makes sense to use both at the same time. Hope this is clearer this time? Thanks for your attention.
  21. Mousetick
    Well this goes to show I'm still very much ignorant. The pine branches LOD textures found in the DynDOLOD object LOD atlas clearly show they are a downsampled version of the original treepineforestbranchcomp.dds texture, taking into account the NiAlphaProperty threshold of the 3D tree LOD models. I have not run TexGen since one month ago. So they must be generated by something, which is neither TexGen nor LODgen. But what exactly shall remain a mystery. Maybe Texconv during DynDOLOD generation. treepineforestbranchcomp.dds > DynDOLOD_Tamriel.dds I'm sorry but this doesn't help at all. I was wondering how the Direct + Ambient lighting settings in TexGen, which indirectly affect brightness, and the Billboard brightness setting in DynDOLOD, affect each other in combination, and how/why one might be used rather than the other. https://dyndolod.info/Help/TexGen: https://dyndolod.info/Help/Ultra-Tree-LOD But it's ok. I appreciate the time and patience you've given me, especially during a week-end. I won't be bothering you any more and wasting your time with "stupid" questions.
  22. Mousetick
    I've gotten even wiser and now I understand the 3D tree LOD textures are generated by LODgen, nothing to do with TexGen. Duh! I initially tried NiAlphaProperty Threshold 112 -> 144, which made a small difference but not enough. So I cranked it up to 176. Comparison in DynDOLOD_Tamriel.dds atlas: 112 > 176 The 3D tree LOD models from DynDOLOD Resources are quite good by themselves, but the difference in "lushiness" between full model and LOD because of the textures was jarring, especially during LOD -> full model transitions: LOD on left half, full on right half: Before (112) > After (176) This is much better, thank you. I may need to crank the threshold up even more, we'll see. I need to apply the same changes to the snowy and ashy variants. And to the aspen trees too, with which I'm using a similarly very thin, very transparent texture replacer. The other hurdle I've been facing is the brightness of the tree LODs. I'm confused by all the options: Direct & Ambient lighting settings in TexGen. Billboard brightness* setting in DynDOLOD. CrownBrightness, TrunkBrightness and FlatTrunkBrightness settings in DynDOLOD_[GAMEMODE].ini: ; Vertexcolor multipliers for tree LOD models used in object LOD, see https://dyndolod.info/Help/Ultra-Tree-LOD CrownBrightness=1 TrunkBrightness=1 FlatTrunkBrightness=1 My understanding is that the CrownBrightness, TrunkBrightness, and FlatTrunkBrightness are used exclusively with 3D tree LOD, which is not affected by Billboard brightness. I'm going to try and lower them because I think my Level0 tree LODs look too bright compared to full models. Conversely Billboard brightness only affects the brightness of Ultra Tree LODs using billboards. What to do with the TexGen settings, how do they interact/combine with the Ultra Tree LOD Billboard brightness? Should they be left alone, at default, and brightness be adjusted only in DynDOLOD? * By the way, there is small typo in the tooltip for this setting: "Adjust brighntess of tree LOD billboards [...]" Thanks.
  23. Mousetick
    Good thing you said the changes can be seen in NifSkope. It appears the threshold needs to be increased actually. When I save an edited 3D tree LOD mesh from DynDOLOD Resources, NifSkope tells me "One or more blocks have had their Name sanitized". Is this going to be a problem? For example, treepineforest02passthru_lod.nif: 9 BSTriShape (Name) = 'TreePineForest02_LOD_FLAT:9' 13 BSTriShape (Name) = 'TreePineForest02_LOD_FLAT:13' 17 BSTriShape (Name) = 'TreePineForest02_LOD_FLAT:17' Thanks for your help.
  24. Mousetick
    It should be checked for LOD4 and LOD4 only. https://dyndolod.info/Help/xLODGen:
  25. Mousetick
    Thanks for your reply. Yes. That is correct. I warned you I didn't know what I was talking about. That was no joke. Now that I've gotten slightly wiser than previous post I can tell you what was shown in the screenshots are vanilla full models with a texture replacer (Pine Branches Redone), and Ultra Tree LOD Level 4 with 3D tree LOD models from DynDOLOD Resources. If I'm understanding correctly, this would require editing the 3D tree LOD models from DynDOLOD Resources in NifSkope and adjusting the NiAlphaProperty of the branches, in steps of +/- 16. Is this correct? Should it be increased or decreased in order to make the LOD texture look "thinner" (i.e. more transparent I guess)? Thanks.
×
×
  • Create New...

Important Information

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

  I accept