z929669

Nothing bad at all ... just maintenance overhead ;) I just wanted to confirm that there are no in-game visual anomalies. The CK issue is not ideal, but if the issue is not present in game, then it would not be a problem for 95% of all modders (user side). That may be why I never see any of these issues then, as I almost never go into the CK. I hate that application on so many levels (as I have hated the CS in the past). I understand wanting to provide a perfect product though. Just wondering, nevertheless: Has anyone here confirmed that 1x1 is the cause of the gray faces in the CK? Has anyone here seen the gray faces in the CK? If so, have any of those persons positively validated the issue by adding back the default face tint file and 'fixing'? EDIT: Actually, this saves me a lot of time looking for these issues in-game. I am not entirely sure how to see the issues in the CK though in order to trace if possible ...

There are hardly any truncated textures in Skyrim, but Ethatron pointed to a few. These might be affected as stated by the KatBits article, but I don't see how that article relates to 1x1 textures (other than 1x1 is not a power of 2). The point is that 1x1, being monochromatic, will not be distorted as the KatBits article suggests (although that article does not explain the issue very well), and sampling missing info from a monochromatic pixel seems elementary. Ethatron is really an expert on these things, and his statement is what I would go with. He states that downscaling monochromatic to 1x1 should increase performance (GPU memory), and the KatBits article seems to indicate that it decreases performance (GPU processor). Based on what Ethatron said, the GPU memory gain is probably significantly higher than any speculated processor cost. The only issue is the hardware. I don't think it will really make a difference, and most of the exceptions we have in the INI and that we impose on certain texture types (e.g., tintmasks), don't seem to have any solid evidence as being the best approach. I am trying to get some actual before/after screen examples of 1x1 texture issues. Now ... how the heck do we find objects in the game that use these textures to any noticeable degree? It sounds like faces are a good start, but we will need to verify somehow. maybe before/after screens of various faces. But we need to find the others outside of faces too I think. EDIT: The best test is probably to be as conservative as possible and optimize as much as possible and let user feedback help us to isolate the true use cases and make exceptions based on real evidence.

BSA extraction is OK for Neo and others with powerful machines, SSDs, and lots of modding XP. For those installing SRLE, this should be OK in order to match the guide to simplify troubleshooting & support; however, it should be made clear that extracting BSAs is not standard procedure in general and applies only to the specific guide the user is following (this prevents issues stemming from STEP users that extract BSAs and derail from procedures in that guide, creating more messiness when they have issues or need help ... custom == bad for support)

No, don't dumpt the PMs, just discuss the resolution here. One 'resolution' is to extract, but that does nothing to teach the user how to use MO properly. I am certain that if you and WDW followed that advice I posted just above and/or really read through applicable sections of the guide, you would see that it is very simple to do the needful without extracting any BSA or deleting any plugin. Neo prefers deleting I think because he is into conserving disk space. This is understandable, I guess, but disk space saved from removing dummy plugins is trivial.

If the BSA is checked, andMO is checked to manage archives, andthe BSA is installed with a mod that is activated in the left pane... then MO will load its assets. If it does not, then the BSA is messed up somehow ... re-download the mod maybe. Also, be sure to launch the game to the main screen (or the Skyrim Launcher) to initialize all mods into the MO virtual directory. Then check the mod by right clicking in the left pane > Information > Conflicts. If you see conflicts, then it is loading, and if you do not see the assets you expect in the game, then the conflicts should show that another mod is supplying the assets.

... and that loading mechanism is explained pretty well in the MO Guide, so check there in order to determine BSA-loading methods and how it works in MO.

In additionon to the 1x1 texture issue, I am trying to confirm my findings regarding the DDSopt INI. In my testing, I am finding that the INI entries do not confer any treatment changes unless one adds one of the four treatments to the texture path entries (e.g., ==BIT, =RAW, etc.) For example, landscapetreesreachtreebranch01.dds ... is an entry Ethatron placed under [AlphaFoliage], but even if I comment that entry (closing/restarting DDSopt between INI changes), there is no change to the behavior of texture processing. The result is identical either way. I have tried this with "Raise foliage-map opacity each mip -level" both checked and unchecked. (that setting does not seem to have any effect either way, so both the menu setting and the INI entry have no effect on the processed result as far as I can tell comparing diffs in Compresonator at all mip-levels) Can anyone confirm? (using pre-release v4)

I guess I am more interested in the appearance of said 1x1 textures in game. Performance is also interesting, but that is secondary. i just want to confirm that DDSopt-collapsed textures present qualitative issues in game. Has anyone seen this?

DoubleYou is the best person to help elucidate what is happening here.

OK, so you went through the logs I am guessing looking for "to 1x1" string or something like that? you won't ever get rid of small mip levels that way, but you will effectively up-size the small textures (but they will still get the 1x1 mip, presumably when upscaled to 16x16 if re-mipped) Example: D:Skyrim ModsMod_WorkingOptimizationSkyrim Vanilla Textures (cleaned source)texturesactorscharacterargonianfemaleblankdetailmap.ddsprocessing: Format : DXT1 to A8R8G8B8 Dimensions : 256x256 to 1x1 - 9 to 1 levelsnotes: Planar image detected, collapsing to size 1x1. Texture was compressed.delta: 43700 bytes lessI recall Ethatron saying something about this (which is not addressed in the OP; we are referring to mip-map levels there). The idea is that the original in the above case was 256x256 and monochromatic, so collapsing to 1x1 is theoretically no different in appearance when tiled (stretched?) onto whatever object would use that. The original parent object was 256 and also had all the mip levels (including 1x1, 2x2, etc.), so since there is no scaling issue for monochromatic, it makes sense to reduce. My problem is that I am not sure if Skyrim will even use 1x1 ('native' or a mip-map of the parent texture), and if it does, I wonder if tiling (and sampling) a bunch of these is detrimental to GPU performance even though it would seem beneficial to GPU memory performance. Or maybe they are just stretched? Stretching a 1x1 would seem to be hugely beneficial to using a single 256x256. I am just trying to determine once and for all if the above examples really are a problem and, if so, what is the effect in game? Same goes for tiny mip-maps below 4x4 (i.e., when viewing an object in game from 'far away' or at a very steep angle)

Wait, I am talking about mip-map levels here ... are you talking about the native texture dimensions? It would be very nice if we could eliminate all mips below 4x4 if possible.

So Optimizer Textures allows one to strip off lower mips according to user-supplied definition? Ethatron spoke of his 4x4 rule, but I don't think DDSopt strips anything other than 1x1 on 2:1 sized textures. let's get alt3rn1ty in here ...

Thanks for the info ... the link you provided indicates power of two ... so that would be 2, 4, 16, 64, etc ... so why are 1x1 replaced by 16x16 or 16x4? Can you provide an example of one of these textures and how it appears in game when 1x1 versus 16x16(4)? I have yet to find any issues with 1x1 in game, but I don't doubt that there could be issues. Will look into the OP of this thread to see if we ever asked Ethatron. EDIT: Ethatron did address this some time ago in response to our first question in the OP. He prefers to throw away all mip levels under 4x4 ... so that is fine, but I see plenty of 2x2 and 1x1 mip levels still (in DDSopt'ed textures) ... need to test other versions of DDSopt I guess, since the "Don't discard lower mip levels" does not seem to be working in pre-release 4.

In MO, plugins are not required to load BSA assets. MO loads such assets according to mod priority in the left pane when MO is allowed to manage archives, so extraction is only important (even for SRLE) where specific assets from one BSA archive must be interleaved with the assets of another or varying degrees of prioritization must be applied to different assets within a single BSA archive. Not a big deal really, but just wanted to point that out.

DDSopt extracts and repackages BSAs, and we already came to the understanding that extracting BSAs is actually not ideal in Skyrim (unless optimizing and repackaging) so I am not sure why there is still discussion or recommendations around here to extract BSAs in MO ... there are some exceptions, but in general, one should leave BSAs packed as long as conflicts can be managed this way. We used to recommend unpackaging all BSAs, but that has been determined as erroneous advice, given that MO allows for much greater control over load order of BSA assets, and those assets actually load faster into the game, even when compared to SSD. Perhaps I have missed something though since I have been out of that scene for the last couple of months?

See my prev post on applying filters, which thus avoids processing textures that are known or suspected to be problematic. The guide is being revised in light of the fact that the modding community has been given permission from Bethesda staff to modify any vanilla assets and distribute them under certain general and reasonable conditions. Well ... the permission was always there, but nobody had expressly asked the appropriate personnel (yes, you can thank me for that :P ). In other words, we no longer need to define for users how to optimize their assets themselves for licensing concerns ... we and others in the community can simply provide them. In light of this, we are going to simplify the guide as a general guide to using DDSopt and omit the idiosyncrasies of facilitating vanilla texture optimization by providing the complex detail that exists now. Stay tuned.

That is all in turmoil right now and under construction/destruction. If you use the following constraints prior to optimizing, you will be fine: Use the following filters (copy/paste into filter box on [browse] tab and click [Apply] to activate a filter before ticking/unticking files in the window). Filter masks changes to anything other than what the filter currently has applied, so if you want to see the overall result, click the root and select the *.* or blank filter and hit [Apply]: *facemods *facetint *tintmasks interface coastbeach0*_n.dds dirt0*_n.dds dirtpath0*_n.dds dirtsnowpath0*_n.dds snow0*_n.dds tundra0*_n.dds

OK, thanks for clarifying that. This mod is dead then until we get word back from the author

Well, with nothing in existence in writing, I think that we can defer to the Nexus TOS, so if that does not require that we get expressed permission to re-upload, and it bases things on mod permissions and is permissive where nothing is explicitly stated, then I think we can re-upload.

Yes, and more modification to where I was heading may be in order ... after you demonstrated (and I have confirmed) that DXT conversion occurs even when constraints compression formats are all set to uncompressed formats, I am growing more convinced that the following is the way to go with just about any texture that can be passed without issue (e.g., *facetint, *interface, etc). For those textures that require either special treatment or no optimization at all, the INI and the DDSopt filters can be used very simply. Optimal Hi constraints (as a baseline for vanilla or generally anything): Performance versions would simply reduce the resolution cap.

Due to my findings in my most recent work optimizing the vanilla base textures, I have determined that it is prudent to make some revisions to the relevant section(s) of the guide, which I have started doing. The problem is that there may be other areas of the guide that need to sync up with these revisions, and the batch scripts could probably use some minor revisions as well in order to sync it all up. @Kelmych You may want to go in there and review what I have done ... it relates to our discussion on the admin thread, and any edits i made can be rolled back; however, I think that we should combine our efforts and work towards the changes I have begun to make. For example, the uncompressed vanilla terrain color maps should be treated same as the high/very high uncompressed normals and not converted to DXT (accept for performance version, which may benefit if there are no artifacts produced in the conversion, which is highly likely). I think that categorizing in terms of ... Very HighHighPerformance... will mesh better with the terms 'Standard' and 'Performance', which are what we will be using for the STEP optimized vanilla textures. I also was confused by the idea of 1-3 versions of each performance group (originally: very high [V1-3], high [H1-3], and standard [s1-3])

There should be 14 blank lines in the log as indicated by 14 instances of ">>log.txt" inside the script. I updated the script to indicate 14 instead of 16. If there is no text in the log, then there were no processing errors.

However, the consensus (or which I am a part) seems to be in favor of keeping this mod in STEP, as it enhances landscapes and 'inconsistencies' to one person are 'enhancements' to others. There is no real concern about Terrain Bump (other than aesthetic and "best practice" opinions), and I think it will most likely stay in STEP. The noted inconsistencies were understood a couple of years ago when we picked up this mod, and the consensus then (as it seems now) was to use it, since it is an overall improvement in the opinion of several of the staff. More info about this mod and further discussion should continue on the mod thread.

Yes, I agree that the guide can be broken into a few pieces ... probably within a unique Guide subcategory even for association.

@Kelmych et al. I think the DDSopt guide is too big now for the tabbed layout. It would be much easier to get at information if there were a a floating TOC. Same goes for some of the other larger guides. Tabs are great for four or fewer tabs; also, it is a pain to link to specific sections of a tabbed page, so restructuring will benefit internal navigation and maintenance quite a bit. Any opinions?