Ethatron

Okay ... how about a spitter-line which you can move between origdest? Just kiddin'. I mean I'd love such a feature, but I may have not much time for implementing it (I don't mean the key, the splitter ofc :P). I got a new job in two weeks, and it's going to eat all my time the first months (you know ...).

It looks like Serious HD rocksedgetrim01's alpha is a height-map, while Vanilla Skyrim rocksedgetrim01's alpha is a transparency-map ... Is this a modder misunderstanding? Or are there special NIFs floating around? Vanilla Skyrim rocks01 seems to be a height-map. Vanilla volcanictundraminerals looks super weird, looks more than a specular map than anything else, or an erronous texture. I guess all the files directly in landscape are actual height-map carrying, except the trim-file, all the sub-folders have transparency-maps.

Well, non-native english-speaker here. I have no clue which exactly is the semantic difference in unsing "opacity" and "transparency", I guess "opacity" gives more emphasis on the fact that something is opaque by default, though for example skin could be not really be called transparent, but calling it half-opaque also sounds strange ... The one extreme is "it's transparent" the other is "it's opaque", if you use one or the other word to go into the other extreme's direction isn't sufficiently standardized I suppose. In 3D we basically always say "transparency", in 2D (images, PNG, GIF etc) we also say "transparency", in web-design and with browsers they started using "opacity" (in CSS fe.), Photoshop and alike use "alpha" as a synonym for "transparency", it's a big mess ... FYI' date=' we are maintaining a working INI on the wiki that essentially will include our findings. We will append the updates to the end of each applicable section, and these will reflect our hacks to get a working result. From this, you will likely know the proper solution.[/quote'] Sure. Ah, yes. I forgot to reread the previous discussion-page. :) You have to renormalize with the Normal-filter in the filter-menu to really compare them unapplied. As I said, 565 can give you banding.

Yes' date=' but's just 2 of the 3 in the folder. First is okay as-is.

I was reviewing the discussion and I changed the following: * "effects/" by default is excluded from semantical processing, I added a few files back into the .ini though which I know contain transparency in the alpha * I added all the files in "sky/" to the .ini which don't contain transparency (aurora and constellation) * I let DDSopt choose a more pleasing matte-colour when transparency is 100%, though this may just obstruct the "problem" / the necessity to clearly identify special or buggy textures ... if you want to do wrong-transparency-assumption hunting you can continue with "update 3" Just check the textures with the updates and look if I didn't find all exceptions. As said, effects+sky shouldn't be an issue anymore.

The blood is weird, is the screen-effect blood of Crimson Tide good now? Means, did I include the right file in the .ini? Anyway, you know you can use the ini like it's yours I hope, if you want to make a STEP one feel free to, and distribute it (or I add it to the archive or the Nexus-list).

Yes, that's correct. I use an "Infinite" Response Filter for calculating the mips. "Infinite" in quotes because of course in computers everything is finite, but I fe. do an exact average of all of the texture for the 1x1 mip, not an average of the upper 2x2 mip, which means the response-length (the width) is all of the available input, which makes it practically identical to a real IIR. The reason is that textures are stored as integers with limited precision, and it is actually theoretically possible to get a black 1x1 mip from a bright texture when each successive mip->to->mip down-filter rounds down and thus gets a fraction darker each time. I also filter normal-maps in R^3 (3D-space), and do exact algebra on them, which means DDSopt's filtered normals are always as if you make a lower-resolution normal-map directly from the mesh.

You know something about colour-spaces? And/or about specific game data stuffed into textures? Colour mostly consist of multiple dimensions (RGB -> wavelength samples, red axis, green axis, blue axis), game data very rarely has multiple dimensions, normals are 3D-vectors. You can't rip RGB or XYZ appart, that's why I call them "joint" for you, because they are inseparable. More later ... :P

A.5: The .ini's purpose is two-fold. Defining the compression on a joint texture-type (3 channels can mean 3 independent channels, or colour or a vector, or xy + height etc.). And defining the content of the alpha-channel. As there is no 4 channel joint data-format in use in games that I know (CMYK would be one fe., even though even there it's arguable if K is really in dependency with CMY). So a texture is always "joint"+"extra", "joint" is always present, that's the seed-plane, and "alpha" is optional. You define compression on the seed. This are the supported seeds: ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be tangent-space normal-maps, enables specific compression ;Â Â taking unit-halfsphere property into account ; - [b]compression-format is supported here[/b] [NormalsTangentSpace] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be model-space normal-maps, enables specific compression ;Â Â taking unit-sphere property into account ; - [b]compression-format is supported here[/b] [NormalsModelSpace] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be color converted ; - [b]compression-format is supported here[/b] [DiffuseColor] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to be greyscale converted ; - [b]compression-format is supported here[/b] [DiffuseGrey]The supported extras are: ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to have an alpha-channel with opacity, enables specific ;Â Â compression taking this into account ; - [b]compression-format isn't supported here[/b] [AlphaOpacity] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to have an alpha-channel with foilage, enables specific ;Â Â compression taking this into account ; - [b]compression-format isn't supported here[/b] [AlphaFoilage] ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; - mark textures to have an alpha-channel with something custom, disables ;Â Â specific compression only working for opacity ; - [b]compression-format isn't supported here[/b] [AlphaCustom]All of them (seed + extra) have their own processing. Normals are normalized, tangent-space vectors are possibly stored partially derivative, opacity gives importance to colour (the more transparent the less important the exact colour-value), foilage is possibly made sharper. The settings (in the menu) correspond exactly to each of these types.

This is good about normal-maps: https://www.3dkingdoms.com/tutorial.htm While experimenting I detected that the _msns are apparently not regular (or not purely generated) object space normal-maps. If you have the Photoshop plugin of nVidia you can normalize the map and it looks very different. I suspect a smart artist played with contrast to somewhat weird effect, god can't they just be high profile and use zBrush ...? I don't think it's actually mathematically correct (like the 4444 normals that DDSopt produces).

Well, I started skimming with IrfanView, and the rule (alpha-channel == opacity maps) is pretty much followed ... except the textures are buggy. There are very very few non-opacity maps used. The dragons are examples, there the alpha-channel contains the disipation animation (when the dragons desintegrate). I'm not so sure scrollworktrim is a special case anymore, maybe the poster just used the old version. You really have to walk around and look what's going on I think. If you have the normal-map and the colour-map side by side (in the IrfanView thumbnail-browser) and you see there is something in the normal-map but the colour-map is black or only half filled, then you maybe got a case. I found this one: "dungeons\caves\cavebaseplants01.dds". Which means I look at all textures from the beginning to "texture/dungeons" and found nothing special. Then follow the ice-caves, it's likely they are all special ... BTW, if we don't do this cataloguing and I go back to the i-don't-care-about-opacity-pre5 then all these textures are becoming real low quality without probably noticing. Better it's black and we hunt them down, and log all the special texture-information for the modding community.

There is a glow-map instead of an opacity map in the alpha channel. Added to the exeption list. Confirmed' date=' another 5 character stupidity (wrong default compression format, was ATI2, LOL). Puh, this are actually buggy Bethesda textures ... These textures are shared between models which do not use an alpha-channel (mushroom fe.) and models which do (the moss is a stump decal). Now fully transparent stuff is ... nothing of course. So the mushroom becomes nothingness. If someone would paint the solid area white in the alpha-channel, it could pass as a foilage-texture type. The wood-block ("treepineforestcut01") is done correctly, the shrubs too (tundrashrub*.dds). Sometimes I almost think I can distinguish the texture-artists working at Bethesda by the care given to the textures. Some textures are just so wrong, and you can group them by wrongness, and I expect each group is made made the same guy. Added to the exeption list. [AlphaCustom] ; Vanilla Skyrim (spec. maps, not opacity) clutter\signage\riverwood\riverwoodsleepinggiantinn01.dds clutter\signage\riverwood\riverwoodsleepinggiantinn01.dds ; Vanilla Skyrim (glow maps, not opacity) clutter\scrollworktrim02.dds ; Vanilla Skyrim (this is a shared map, preferrably the mushroom needs a white alpha) landscape\trees\treeaspenaddon01.dds landscape\trees\treepineforestaddon01.dds landscape\trees\treereachaddon01.dds

A.2: That's tough. Let's try: "fixed textures": The number of corrupt textures that have been fixed, this are currently textures which are too short (few bytes missing at the end). I found one or two of those, I don't know which software creates these truncated textures."fixed files": A remnant of NIFopt, will always be 0. Refers to repaired models mostly."planar (1x1) textures": The number of textures which have only one distinct value. These textures may be converted to 1x1 size without loss. Though seems not all hardware likes that. Haven't yet understood what's the real cause."i/o delta": This is the global incoming to outgoing delta. Say you process a BSA, then it takes the size of a file inside the BSA (possibly compressed, then it takes the compressed size), and does the processing and writes it into another BSA. The sum of those differences is that value. If a DDS is not touched it still is possible to get i/o deltas != 0 because the zipper in BSAopt/DDSopt is about 10% better than Bethesda's. If you decompress a compressed BSA to directories, this delta is likely positive (out is bigger than in)."tex delta": This is only the recorded change in size from changes to texture-formats, resolution and mip-maps. The Gamasutra is okayish for understanding DXT, the others are unrelated.This one's extensive for modelers: https://wiki.polycount.com/NormalMap/ What exactly do you want to understand? The DXT artifacts (DXT3 vs. DXT5)? Why normal maps in DXT sucks?