z929669

For top row, 3-5 looks like changes also to the full models in the foreground. Nothing was changed about the full models or the textures they are using? I think #2 is the best match with full. The goal should be getting the best match without having to use a custom texture, obviously ... but also without having to make changes to the LOD model NiAlphaProperty. Apologies for dropping off of testing. I spend daytime on weekends working on my house.

Thanks for this. In all of my testing, I suppose it's possible I mucked something up in one of my iterations. Back to the drawing board to reproduce on my end.

I meant this post. sorry.

... and still you fail to yield any quarter after I have done so at least twice. you are evidently always right. Whomever is debating you is evidently always wrong. You are beyond human, I am a mere human. You do not judge or assume at all, only me. Don't you see it? Re-read your posts. Much of what you say and how you say it is insulting to the person you are criticizing (not so much me as Tech, and I totally understand your calling out the "proper modding" thing.). I'm only arguing with you about how your posts are being interpreted by onlookers other than yourself. You use combative and snarky phraseology. There is no need for me to go to the effort of pulling it in this post, because it's evident if you objectively review. Here's another quarter: I do the same sometimes in small doses for emphasis. I think many people do. The only difference is that you don't yield any quarter at all and just keep on going. It's genuinely combative.

I set things up to test in a single run due to your suggestion to change NiAlphaProperty of specific aspen LOD models rather than all at once. This way, I should see a mix of the LOD trees I want to examine: Treeaspen01 - NiAlphaProperty=128, textures=birch03_c.dds, birch03_n.dds (4k) Treeaspen02 - NiAlphaProperty=224, textures=birch03_c.dds, birch03_n.dds (4k) Treeaspen03 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) Treeaspen04 - NiAlphaProperty=224, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) Treeaspen05 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) Treeaspen06 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) Treeaspen07 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) Treeaspen08 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) Treeaspen09 - NiAlphaProperty=128, textures=birch03_c_lod.dds, birch03_lod_n.dds (128px) To confirm the above, these are the LOD meshes used for this run: meshes.7z The texture appears 3x on the atlas (I'm not uncertain about the second line even though you attempted to explain). I also don't understand which is associated with what NiAlphaProperty. I expected two versions for each texture corresponding to the test list above (four scenarios). Is something off here?: textures\mx\birch03_c.dds,textures\mx\birch03_n.dds 256 256 12032 3840 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\mx\birch03_c.dds,textures\mx\birch03_n.dds=14 256 256 11776 3840 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\mx\birch03_c_lod.dds,textures\mx\birch03_lod_n.dds 128 128 13328 4096 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 Here's the three cutouts from the atlas saved as TGA so you can see the alphas (they are pretty similar): aspenAtlasCutouts.7z From LODGen_SSE_TexturesUsed_Tamriel.txt (not sure what this tells us): textures\mx\birch03_c.dds,14,textures\mx\birch03_n.dds, textures\mx\birch03_c.dds,8,textures\mx\birch03_n.dds, textures\mx\birch03_c_lod.dds,8,textures\mx\birch03_lod_n.dds, I started a new game to test. Here's the screen showing what I could identify as the thinner trees likely associated with #4 Treeaspen04 ... tough to tell with the overlap of trees, but I think it's evident that there are some transparency diffs among the LOD trees. The thick alpha trees are pretty evident and likely associated with treeaspen01-02: Completely different question/comment: Billboards were only atlased for 1-5 (although TexGen produces billboards in it's output for all of them). I'm uncertain how to interpret this: textures\terrain\lodgen\skyrim.esm\treeaspen01_0006a9e6_1.dds,textures\terrain\lodgen\skyrim.esm\treeaspen01_0006a9e6_1_n.dds 344 512 3524 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen01_0006a9e6_2.dds,textures\terrain\lodgen\skyrim.esm\treeaspen01_0006a9e6_2_n.dds 340 512 3868 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen02_0006c9d5_1.dds,textures\terrain\lodgen\skyrim.esm\treeaspen02_0006c9d5_1_n.dds 324 512 4548 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen02_0006c9d5_2.dds,textures\terrain\lodgen\skyrim.esm\treeaspen02_0006c9d5_2_n.dds 340 512 4208 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen03_0006c9d4_1.dds,textures\terrain\lodgen\skyrim.esm\treeaspen03_0006c9d4_1_n.dds 288 512 5832 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen03_0006c9d4_2.dds,textures\terrain\lodgen\skyrim.esm\treeaspen03_0006c9d4_2_n.dds 320 512 5196 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen04_0005fada_1.dds,textures\terrain\lodgen\skyrim.esm\treeaspen04_0005fada_1_n.dds 324 512 4872 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen04_0005fada_2.dds,textures\terrain\lodgen\skyrim.esm\treeaspen04_0005fada_2_n.dds 316 512 5516 2560 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen05_0007614b_1.dds,textures\terrain\lodgen\skyrim.esm\treeaspen05_0007614b_1_n.dds 104 128 13784 4096 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192 textures\terrain\lodgen\skyrim.esm\treeaspen05_0007614b_2.dds,textures\terrain\lodgen\skyrim.esm\treeaspen05_0007614b_2_n.dds 120 128 13456 4096 Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds 16384 8192

[TerrainManager] INI settings or DynDOLOD distance settings in MCM menu

But in your last post, you insinuated the I DID, else you would not have made the comment? Look at your quote of me and your contextual response in your previous post to which I responded. I mean: pretend you are someone that you are not and read your posts from that standpoint. Just objectively read what you have written along with the context you wrote it. In some of your previous posts. I know this ain't easy, because you ARE you, but I do this and often find that the things I write or say to other people could be misinterpreted due to my tone or choice or words (and the context in which I spoke/wrote). This is especially true if I AM annoyed by the post (which, frankly, happens with me ... I am can get annoyed by how people post, especially if it involves a flippant response to me and there is disagreement ahead of it. I'm human.).

These specific responses are incorrect and unnecessarily argumentative and sarcastic (which is itself unhelpful and indicative of annoyance). It seems to me that you have trouble acquiescing or in any inkling of a way admitting any fault or even the slightest acknowledgement that any of your previous statements could be --on their face-- interpreted as hostile. I adopted no such "annoyed and somewhat insulting tone" with you. I know, because I was consciously taking care not to. Giving a bit of quarter goes a long way. Try to be understanding, and really read what you post as if you are not you.

Great. I will take a look just as you say rather than continue with the logs/screens route. This approach is more certain.

I think the difference between 1 and 2 is a fluke maybe caused by the fogs but could possibly be due to some marginal effect of increasing NiAlphaProperty; however, since there is no change freom 3 to 4, I think its not NiAlphaProperty increase. Changes to NiAlphaProperty are not apparent in my testing. DoubleYou was testing some things in part based on a texture he had created with his own custom mips, and given he hasn't presented evidence to support, we can't really say that with a 256 resolution, increasing NiAlphaProperty from 128 to 224 has any impact. Clearly, from my evidence it does not (unless we question my evidence, which I do not). Did you find anything in the LOGs to illuminate? Blotchy alpha is my way of saying it's too think and washed out as demonstrated by the screens. The issue is that branches in LOD are too thick, aned making them thinner can only be done by decreasing AlphaFactor in DynDOLOD_SSE.ini to 0.125, or by reducing the texture resolution of the LOD diffuse. I think this is because the the change between mips with lower base resolution is more apparent. Regardless, changing NiAlphaProperty just isn't working ... I have taken that advice many times in the past, and it doesn't work with other trees either in my XP. Kojak747 had the same XP when we work working on his Scott pine. he finally resolve with texture changes. NiAlphaProperty had no impact. This was long ago, so I'm wondering if this behavior is just not working as expected. As you mentioned, using AlphaFactor is not viable for several reasons, and using custom LOD textures isn't either. I'd like to figure out why NiAlphaProperty isn't working as expected. My results should be entirely repeatable if you try yourself. I've linked to all files I used, and I put the 128k textures on the AA DynDOLOD Nexus page as well.

Have a look at this post for a fairly fool-proof way to match grass LOD to full with almost any grass. The tint settings are mostly for edge cases or for non-linear ENB shader effects.

Your last post seem like an attempt to say something by implication rather than your own statements ... scraping from the Citizenship Guide it would seem. You are both stating opinions, IMO, and I think my last post sums up your opinions correctly. I don't think there is anything wrong with either opinion, but I can see how some of the statements in Tech's first post on this topic made you bristle for reasons to which I allude in my previous post. Obviously, you can see how all of your responses to him have an annoyed and somewhat insulting tone. Feel free to post objectively, but continued beating of this dead horse will only come off as insulting (gentle warning).

Just finished testing with 128k diffuse/normals resized with mipmaps @127 alpha test from original full textures used in AA main mod. Hopefully, you can see that the alpha transparency is best when the source textures used by DynDOLOD for these trees is 128: I;m not showing changes in NiAlphaProperty, since it doesn't really have any impact. All are default AA values of 128 as full crowns. 4k >> 256 >> 128 PS: You can see where full trees transition to LOD when switching between these screens. Full is obviously at bottom of screen nearest the PC. Most apparent alpha diff in LOD are those trees at lower right, which are obviously LOD trees. For reference, this is an earlier screen I captured using the main mod AA textures (Autumnal Variety w/bigger treeaspen01-02) including normal with alpha opacity). Notice how the alpha is much too thick in LOD for these trees in comparison to lower res. I think this is apparent in the screens. All mesh rules used for all testing as follows: [Skyrim aspensablazeesp] LODGen1=cceejsse001-hstead.esm;08000BC2,Level0,Level1,Billboard4,Level2,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen2=cceejsse001-hstead.esm;08000BEB,Level0,Level1,Billboard4,Level2,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen3=cceejsse001-hstead.esm;08000B90,Level0,Level1,Billboard4,Level2,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen4=cceejsse001-hstead.esm;08000BD5,Level0,Level1,Billboard4,Level2,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen5=treeaspen05,Level0,None,None,None,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen6=treeaspen06,Level0,None,None,None,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen7=treeaspen07,Level0,None,None,None,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen8=treeaspen08,Level0,None,None,None,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen9=treeaspen09,Level0,None,None,None,FarLOD,Unchanged,1,Aspens Ablaze High Preset LODGen10=treeaspen,Level0,Level1,Billboard4,Level2,FarLOD,Unchanged,1,Aspens Ablaze High Preset

Updated both previous posts

Images are correct order. The differences you note in the screen are subtle (Obsidian Mountain Fogs can impact brightness in some places). In game, they are more apparent. Changing NiAlphaProperty in the second test did result in a small change to brightness, but alpha was still quite 'blotchy' in game. no apparent increase in transparency. Reduced resolution does increase transparency marginally, but NiAlphaProperty change in the final test had no visible impact at all. Best transitions and LOD matching full is in last two screens, since last two tests use the 256 px textures (first two use 4K from main mod). The main issue is color-bleeding in branches/leaves due to alpha scaling. Full trees get slightly thinner in loaded cells as distance increases, and the same is true in LOD4 as distance increases. I'm currently testing with diffuse at 128 px res. Will share result when finished. Main mod textures Reduced textures (open DDS, resize 4k to 256 in Ps, save using NVIDIA TT) - these LOD mod variants are also available for download from Nexus (linked previously)

Texture in question are birch03_c.dds and birch03_n.dds. Looking at texture in DynDOLOD output mod (not as many aspens as expected in the atlas) ..\textures\DynDOLOD\LOD (10 mip levels) A couple things to note about Aspens Ablaze main mod: It uses a diffuse with alpha opacity that seems to have custom mips to help achieve its look (4k) It uses a custom normal likewise, and the normal also uses alpha opacity (rather than specularity in the alpha) (also 4k) The NiAlphaProperty of all crown nodes is 128 We are testing with 'Autumnal' version (v2.35, no thickets or LOD from main mod) Testing LOD versions: Reduced poly crowns with same crown NIF parameters as full (v0.1) - logs 0.1 Reduced poly crowns (as in #1) with NiAlphaProperty=224 (v0.1) - logs 0.1-224 Reduced poly crowns (as in #1) with same crown NIF parameters as full and pointing to 256 px LOD textures (diffuse just resized, normal with alpha romoved and then resized (v0.2 ) - logs 0.2 Reduced poly crowns (as in #1) with NiAlphaProperty=224 and pointing to 256 px LOD textures (diffuse just resized, normal with alpha romoved and then resized (v0.2 ) - logs 0.2-224 Screens in same order as above: I think this demonstrates that lower texture resolution textures used in the crown LOD respond better to alpha scaling but adjustment of NiAlphaProperty threshold in the crown doesn't seem to have any impact. I doubt that the normal alpha plays a role. Textures are available in the download links above EDIT: Interestingly, the BTO NIF properties for aspens are applied to non-aspen trees on the BTO (pines here), and they are really different in the full/LOD models:

So in my and @DoubleYou's testing, we have found that NiAlphaProperty adjustments work, but only if the initial texture size is small enough. Beginning with a 4k texture, NiAlphaProperty as large as 224 has no visible impact. We had to extract the 256 mip (or resize the texture to 256) before we saw any impact on the resulting LOD alpha. You will probably have your own ideas, but I assume texconv can extract the 512/256/128 mip level as the basis for applying the AlphaFactor and the resulting tree objects (maybe safer to just resize the top level in case the MA has made custom mips). Then the NiAlphaProperty has room to impact.

I'm not sure what "Reequipping the Quiver/Bolt" infers, especially since it's not a checkbox but an integer. The number of arrows to reequip? I suspect that "Equip Stronger" bit is the conflict, but how would that make you think equipBestAmmo isn't working? I assume both do the same thing, so it would seem that equipBestAmmo=true would only appear not to work if "Equip Stronger" is unticked. Looks like the txt file in the mod explains it mostly: $UQ_ReEquipType Re-Equipping the Quiver/Bolt $UQ_ReEquipTypeInfo 0 = vanilla default, 1 = the last one equipped (default) and 2 = the most powerful on the list. $UQ_EquipStronger Equip Stronger $UQ_EquipStrongerInfo Enables the gear behavior of arrows/bolts when they run out. So the conflicting setting is "Reequipping the Quiver/Bolt" set to 1 (negates equipBestAmmo=true). Set to 2 overrides equipBestAmmo=true I've no idea what this means: "Enables the gear behavior of arrows/bolts when they run out."

OK, so I assume that equipBestAmmo works for this mod when set to 'true' but that if Unequip Quiver SE MCM is set to (?), then equipBestAmmo breaks? Can you confirm and determine what MCM setting/value(s) conflict?

Thanks for the explanation. Again, I did test AlphaCoverage=0.15 and 0.95 (default is 0.85) with TreeLODGenerateMipMaps=1 and saw no impact on any trees in object LOD (focusing on Aspens Ablaze though). Basically, the mipmap alpha threshold in LOD is too low, I think, so I will try raising the NiAlphaProperty in the LOD crowns from 128 (current) to like 176 and test. Thank you. As I mentioned, you might consider lowering AlphaFactor default value of 0.25, as I find that 0.125 works better for tree mods I have worked with recently (HLT, AA, EVT). Now this may not be the best baseline for other tree mods or tree types ... or vanilla. Just throwing the idea out there.

As far as I can tell, the animations under ../XPMSE rely on the plugin and are probably just file bloat without the plugin being active, but those under ../animations root replace vanilla. @Mousetick Do you care to confirm?

What is 'Quiver'? I see no conflicting 'ammo' config setting for Unequip Quiver SE mod ... maybe there is an MCM setting that conflicts?

@sheson I looked through the doc but didn't find any reference for the following settings. I'm hoping you can enlighten me. ; 0 = no mipmaps, 1 = texconv, 2 = internally ObjectLODGenerateMipMaps=2 TreeLODGenerateMipMaps=2 ; Texconv mipmap alpha coverage AlphaCoverage=0.85 ; Internal mipmap alpha factor AlphaFactor=0.25 I have discovered that AlphaFactor affects mipmapping of tree branch textures with lower values yielding thinner branches and more transparency. (FYI, I think cutting the default 0.25 in half yields better results with EVT and Aspens Ablaze ultra LOD). Changing TreeLODGenerateMipMaps doesn't seem to affect ultra LOD trees, and neither does AlphaCoverage when changing TreeLODGenerateMipMaps=1. Questions: Are either of ObjectLODGenerateMipMaps or TreeLODGenerateMipMaps settings tied to either of AlphaCoverage or AlphaFactor settings? Could you provide brief descriptions of these settings and the context to which each applies? (I have largely discovered this myself for AlphaFactor, but not the others)

I had attempted to convey this in my last post and largely failed, so I will try again: @TechAngel85's position (I assume) on "proper modding" being a manual rather than an automated methodology is born out of years of answering questions from those that do not want to RTFM and just want every mod they install to just 'work' and to affect the game according to some subjective assumptions ... and to work with any number of other mods in concert without any additional hassle. Many of these people make wild assumptions that a 'problem' exists that is attributable to a given mod or get frustrated and become insulting ... or continue asking bothersome questions repeatedly in lieu of gaining understanding from experimentation and self service. All because they just don't want to put in the effort to achieve a result independently. So if people do RTFM and follow instructions and learn some basics, their expectations would effectively be grounded to reality, and they might not generalize, assume, or assert blame incorrectly or unfairly. It's akin to the frustration of being the target of unreasonable expectations or assertions of 'blame' or a 'problem' when it is really on them to understand some basics (PC basics for one and a basic understanding of how the game and mods work). Rather than repeated hand holding and gracefully accepting passive or direct insults or suffering the time suck of constantly addressing what is addressed in the instructions or in previous post Q&A, it's natural to say things like "Don't expect me to constantly provide you with personal services when I have done my best to preempt all of your failures to follow instructions or seek out information that I have painstakingly created for you." OR "Please learn how to 'mod properly' so I don't have the responsibility of mitigating the misinformation you are ultimately spreading and thereby creating even more work for me." This is a significant "user class", and they are the most vocal with insulting complaints about how the mod author is somehow purposefully making their lives difficult or making some process inaccessible to the layperson. Very frustrating and annoying. Just review the DynDOLOD topic and sheson's infinite patience with such users (the worst posts are hidden for good reason). I believe @theblackman's position is that it's unreasonable to generalize that all of those that want to see an automated process are somehow unable or unwilling to "mod properly" in accordance with it's subjective and arbitrary connotations. Most users want to implement a mod build and play the game without hassle, and automation would expedite this. It doesn't mean that those with this desire are not smart or tenacious or DIY-ish enough to figure it out for themselves. They just prefer to minimize the manual labor, because they don't necessarily enjoy it. I find it easy to identify with either position, and I can easily defend either position, because each is largely subjective. The 'problem' we are witnessing here is semantics of delivering the subjective opinions. The inherent problem with automation in this realm is that automation relies on consistency. There is a lot of inconsistency in modding when you are talking about hundreds of mods that are independently maintained. Sometimes, this inconsistency breaks automation and troubleshooting is needed (whilst getting more or less politely prodded and sometimes abused by demanding users with unreasonable expectations born of their automated worlds full of conveniences and some sense of entitlement as unique snowflakes).

Heya Spock. You should be able to revive your account with the lost password functionality. Otherwise PM me if interested, and I can assist.