Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Whatever it changes is simple and could probably be covered by our patch if wanted, but I never looked closely at this and was never involved directly in testing it. Dropping it is certainly another option, IMO.
  2. z929669
    Picky confirmed deletion and that the workaround link should never expire, so we can just use that. Otherwise, it's just a plugin, and we can probably recreate the changes from scratch and host it ourselves.
  3. z929669
    Heya Roots. Thanks. We have a tool now for posting mod topics:
  4. z929669
    Yes
  5. z929669
    Thanks for taking the time to read and reply. It's much appreciated. I'll consider all of this carefully before responding if I need to.
  6. z929669
    All of this back and forth we are having on the alpha test threshold seems so unnecessary. We are unable to get explicit answers to explicit questions. The answers are always implicit based upon previous statements in posts or in the doc. I intuitively KNOW that all of my own confusion is because we have multiple conflating sources of alpha variance: Alpha-to-coverage threshold defined within the texture data itself NiAlphaProperty testing alpha threshold defined in the LOD model Alpha-to-coverage threshold defined withing the DynDOLOD atlas texture NiAlphaProperty testing alpha threshold defined in the BTO "LOD binary alpha fixed threshold" (is this the BTO??) '>' vs '≥' interpretation of NiAlphaProperty testing threshold, which can be different between #2 and #4 Therefore, I intuitively KNOW that my own understanding can come only with more explicit answers and examples that differ from the doc and what has previously been posted (largely quoting the doc). I understand if holding my hand is too much effort, so do not feel obligated. I'm basically only suggesting that a change from the present semantics and tactics of explanation could be improved for me and thus others like me (and thus may result in far less Q&A going forward). I mean no offense, but I must accept that I am incapable of full understanding without completing a minimum of 32 independent tests of my own once I get the funding. Here's what I assume: Texture Alpha: B/W value of a pixel (0-255) with 0 being black (transparent) and 255 being white (opaque). It's information in the texture. Alpha-to-coverage: Scaling algorithm used to extrapolate Texture Alpha downscaling to smaller-resolution mipmaps. It's information in the texture. Alpha-to-coverage Threshold: The Texture Alpha value '≤' at which a given pixel is opaque (white). It's information in the texture. NiAlphaProperty: The alpha-testing value '<' at which the Texture Alpha is opaque. It's information in the model. DynDOLOD could impact each one of these at any given time in its processing the resulting BTO and corresponding texture atlas, but I'm not entirely clear on which it impacts at any given time. All I think I know is that if UseMipMaps is in the Shape Name, then DynDOLOD does not make any changes to #2 and #3 (and probably not #1 either). Given that all of those 4 definitions apply to BOTH input LOD model/textures AND to resulting DynDOLOD BTO/texture atlas, there's additional degrees of freedom to keep straight.
  7. z929669
    I understand you want users to really read the documentation and your posts, but it's not possible to glean the necessary information requested without using assumptive inference unless explicitly stated. This is why we are both spending extra time on my now three follow-up questions. The answer I now more confidently assume explicitly stated: The object LOD atlas texture, DynDOLOD_Tamriel.dds <-- the placement of a billboard next to another texture on the object LOD atlas texture caused the mipmap artifact. The solution was to fix how billboards are placed on the this texture atlas. Thank you
  8. z929669
    Read the OP and forum rules? The suggested methods with links are provided.
  9. z929669
    Give it some time to see if it comes back. It could be hidden temporarily.
  10. z929669
    Thanks but replying with the doc text doesn't help me much. I was looking for explicit answers to my questions. I think I understand most of this, but could your reply directly to the following(?): Does DynDOLOD read NiAlphaProperty of say, 80, and then generate alpha-to-coverage using threshold 80?
  11. z929669
    Got it. Thanks So I assume you mean on the DynDOLOD atlas and not an atlas from the mod?
  12. z929669
    So since you did not mention the other values in the BTO for Texture Clamp, Glossiness, Specular Color, and Specular Strength, I must assume that you agree these settings could be adjusted in the LOD models to those values used in the BTO tree shapes? I would be servicing this issue if the mod (EVT in this case) had an issue, but your response tells me nothing about the 'problem'. I must assume that the change you added to the test DynDOLODx64.exe resolved the issue and that the mod is not the problem here? Or are you saying that there are third-party billboards mucking things up? So what was the cause of the billboard artifacts mentioned and the resolution?
  13. z929669
    Thing 1: So without Shape Name "UseMipMaps", DynDOLOD reads NiAlphaProperty of say, 80, and then generates alpha-to-coverage using threshold 80? Or that Shape Name has no impact on this piece of the process? Thing 2: This is done only if Shape Name "UseMipMaps" is NOT included in the NIF crown BsTriShape or regardless of this Shape Name being present? I assume the former from the definition: Yes, I know you have interpreted sheson's doc and responses with confidence, but I'm still not clear with my own interpretation of the same. Call me dense, I guess.
  14. z929669
    Texture Clamp, Glossiness, Specular Color, and Specular Strength are also changed for the trees in the BTO, so can I assume that all 3D tree LODs could adopt those (and only those) shader flags you mention and values for the four settings I mention here?
  15. z929669
    But wouldn't this be redundant in terms of precluding DynDOLOD's adjustment, since you are using the UseMipMaps shape name in the LOD models? Setting NiAlphaProperty to 128 seems justifiable, but I didn't think it would have any impact on DynDOLOD's treatment in translating alpha on the atlas trees.
  16. z929669
    @Mousetick @sheson I split this conversation into it's own topic under the child forum, because it has some useful info with specific context tangential to DynDOLOD Alpha 3.0 topic but nevertheless nice to have in a single topic. I think it's pin-worthy if you guys agree. Let me know if this splits out this discussion at the correct point or if I've otherwise missed anything else.
  17. z929669
    Maybe you're right, but the value would seem to be critically dependent on DynDOLOD's test value (128) and NiAlphaproperty value (128-129) being at least one greater than texture alpha test threshold so given that, alpha test threshold of 127 seems like it could theoretically be all the difference needed to cause the texture to go null transparent or not in the mesh. Very likely I'm wrong and testing on my part required, which I don't have the inclination at this time to do in a way that would convince myself.
  18. z929669
    I know we continue to go down a slightly OT rabbit hole here, so I can move the relevant posts into a DynDOLOD Support question topic of it's own for posterity once we're finished ... This makes a lot of sense to me now. Thanks I'm confused, since this is missing a variable/coefficient and has no perns indicating order of operations [ alpha * {blank} ] = (1 + (MipMapLevel) * AlphaFactor) ] If MipMapLevel = 0 then either: (1 + 0) * AlphaFactor = AlphaFactor OR 1 + (0 * AlphaFactor) = 1 ... so I'm guessing it's the second order of operations and the first '*' is just a typo? Then: [ alpha = 1 + (MipMapLevel * AlphaFactor) ] So alpha test function is set by NiAlphaProperty I assume, which must be > alpha test threshold in the texture data. (I constantly forget if it's actually the inverse of this statement) If so, then NVIDIA Texture Tools default of 127 is compatible (128 - 1 to ensure mesh function is > alpha test value). I'm not sure if this is industry standard, so NiAlphaProperty should maybe default to 129 to be safe, since we don't know what software was used to create the DDS and must assume that defaults are used for alpha test threshold.
  19. z929669
    Thanks both for the context for posterity and reference when I forget or others have the same question
  20. z929669
    Great to know. I like the inclusion of an equation, since it makes things simpler for me to remember. It looks like you are incorporating a small correction factor with ((0.5 + 0.01) * 255) = 130, and that is nice to have. Now my question is what is the analogous formula used by the DynDOLOD TexConv process? I assume it must be 0.5 * 255 = 128 (rounding from 127.5), and why the small correction factor is just enough to resolve in your use case? Does this theoretically apply to every use case where texture alpha mipmap thresholds apply (e.g., foliage, fur/hair, smoke, etc.)? Finally, what is the 'best' value for NiAlphaProperty in the mesh given a texture alpha threshold of 130? Would it be 128, 130, or something else ... or dependent upon the whim of the mesh artist and other factors? PS: I mentioned Paint.net because you could save the PNG after making changes via that program and then use something like NVIDIA Texture Tools (NTT) to save as DDS (instead of Ps or Gimp if those are not accessible/convenient). It may even have a plugin extension for NTT, but I haven't checked that for a while. Also, you can tell if Solidify was applied by looking at the texture without the alpha mask. I like Solidify C for foliage, since it extends the edge colors inside the exposed alpha in a radial fashion into the transparency so that mip levels don't get color bias if the mips are imperfect (which they always are as mip level increases). Incedentally, I've found that slightly darkening the resulting colors in the transparency also works very nicely for foliage (this is what vanilla does in most cases).
  21. z929669
    Lol, sorry, I misread the OP/forum. My input still stands though, but since I also don't play FO games or manage this guide, you may dispense with my advice and await @DoubleYou's input. He knows his stuff, so if he's recommending CAO for this procedure, then that's the way to go. Sorry guys!
  22. z929669
    Thanks for taking care of this. I haven't had much time to piddle around with modding lately. ... so am I correct in my interpretation of the OP that NGIO is not supported in the final play profile or is it simply suggested by the MA to use DynDOLOD Grass Mode 1 method (and corresponding DynDOLODGrassMode = 1 in NGIO) and not use NGIO at all under 1.5.97? ... so no support for those wanting to use DynDOLODGrassMode = 2 under 1.5.97? EDIT: after looking at your edits to the Grass LOD guide, I see that 1.5.97 DynDOLODGrassMode = 2 is supported, so the OP (and the Nexus mod Description) is a bit confusing for this use case. EDIT2: Just want to add that I don't advocate subverting the SSE update mechanic in order to run 1.5.97 --which effectively retards mod development, since nobody has NG-ified NGIO or created something similar for later runtime versions of the game. I'm just curious more than anything.
  23. z929669
    My workflow is similar to DY's, but I use Ps to do my work and NVIDIA Texture Tools Exporter to save my textures. Load texture in Ps Use existing texture alpha > Invert mask > remove background Use Solidify C filter (for foliage anyway) Invert alpha again or reload the texture after save Export via NVIDIA Texture Tools Exporter plugin (or stand-alone) with "Scale Alpha for Mipmap Coverage" checked if it's foliage or requires similar alpha/transparency. Threshold usually default 127, but sometimes lower, depending. Note that you can likely use Paint.net as well. I find Gimp to be unintuitive, so I only use it for things I can't do in other apps when following someone else's workflow for specific applications.
  24. z929669
    I don't use CAO at all and would not recommend it for most applications. It's possible the BA2 folder structure you are packaging is using an incorrect root folder in the archive. I also don't play FNV, so I'm not sure of the limitations/expectations with that game, but packaging in 7z seems like a better option. I package all mods as loose files for Bethesda TES games and use MO, and I know Skyrim/MO work fine with 7z archives as well. If FNV requires BA2, then you might want to try BSArchPro instead.
  25. z929669
    @Mousetick Your recent posts relate very much to what DY and I were trying to solve for Aspens Ablaze LODs. You may benefit from that discussion, but I think it's really all related to how the textures are saved with or without proper so-called "alpha-to-coverage" or "alpha scale mipmap coverage threshold" used in the application that generates the DDS by the MA. The NIAlphaProperty acts as a Boolean based on this texture threshold (AFAIK), which uses the same scale (0-254). Sheson's response to my post (also expand my post) DY's more thorough assessment of the problem than my original - there's several other preceding and subsequent posts in that discussion This post shows the consequence of using UseMipMaps when the MA-provided texture alpha thresholds are not great (#3) and how DynDOLOD's algoritm is better (#2) ... and arguably the best approach (unless the MA is doing custom painting at each mip level of correctly-saved textures)
×
×
  • Create New...

Important Information

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

  I accept