Change the texture asset origin convention to top-left (#6885)

Alexei Kotovrequested to merge
Capostrophic/openmw:sciencecompelsustoflipthesun into master

The ooga-booga variation of approach 2 described in #6885 where we flip everything but BC6H/BC7. This makes the problem that was previously DDS-specific KTX-specific, but allows to avoid most practical special cases and rendering state changes. The motivation is that there are dramatically fewer textures that use bottom-left convention by default (TGA, BMP, PNG, JPG) than the textures that use top-left convention (DDS, KTX by default) and we can flip the former as they're all uncompressed in memory. Also this is more compatible with the original engine(s) and glTF (theoretically). Also this allows using BC7 anywhere*.

This allows us to use DDS BC6H and BC7 textures as is, provided the used OSG revision and hardware support them. Currently BC7 support isn't provided in the OSGoS used for any public builds. Builds that use the bleeding-edge OSGoS can display BC7 images, but they're flipped.

DDS images are unflipped by default, non-DDS bottom-left convention images are flipped (TGA, BMP, PNG, JPG, possibly KTX). 3D DDS images always used top-left convention if they were used in post-processing.

Ideally, everything should look exactly the same except for certain special cases noted later. If everything has the right orientation, BC7 will also have the right orientation when used for any game element.
Numerous things flipped in this commit to guarantee the same visual results are the following:

Generated UV sets and particle systems

  • Terrain UV and blend maps. This covers ESM4 terrain and composite maps
  • Water UV, normal map (it used OpenGL convention) and simple water ripples
  • Rain particles
  • Sun and moon UV

NIF UV sets and textures

  • NiTriShapeData and BSTriShape UV (unflipped), NiUVController vertical offset
  • NIF internal images (NiPixelData) are unflipped
  • NIF particles are not flipped, they need point "down" for Morrowind compatibility

GUI UV sets

  • GUI widget texture UV and convention
  • Cursor*
  • Character preview inventory doll and race menu head UV and display
  • Loading screen scene image UV
  • Local and global map UVs (fog of war, unexplored and explored maps)
  • Saved game screenshot UV
  • Video widget UV

Forward pass shader-specific things

  • Tangent space handedness (bitangent direction)
  • Parallax vertical offset

Things where this is a breaking change:

  • Collada. The format itself doesn't enforce a convention, the user defines one, so Example Suite (models or textures) and anything else affected must adopt the changes. Also textured OSG files though I'm not aware of any in the wild.
  • Compressed non-S3TC images that must but can't be flipped. Their "technical" support is avoided. This is primarily KTX which we don't technically fully support yet; PortMaster texture workflow would need to be updated to use top-left convention KTX. Note stock OSG handles KTX orientation poorly so any top-left convention KTX files will look the same as they did before (i.e., wrong) and some of them won't work, the workaround works best with OSGoS post-ASTC fixes.
  • Any forward pass shader replacements that currently still use the original tangent space handedness and parallax convention
  • Probably those post-processing shaders that use textures, so post-processing API revision might need to be bumped

Random other things that appear to look the same with no changes required: shadows, though I can't test debug geometry display, screenshots, sun glare (it's symmetrical), random post-processing shaders I've bothered to check, cell borders, precipitation occlusion, sky blending, gamepad UI, map zooming, editor scene view, maybe other things that would obviously work regardless of the way textures are oriented where I didn't pay attention to the fact they're working.

Note the saved game format should be unchanged. Map and saved game images use the same convention, the change is purely visual, so the RTT images might technically be upside-down, as that was the easier way to handle this.

Note (*) the cursor texture is decompressed so that SDL can use it, which is... challenging... to do for compressed textures that aren't S3TC, so no BC7 support for that. Cursor creation quietly generates a white texture for non-S3TC-compressed formats. Not sure if we shouldn't throw instead, but it's not entirely in scope.

This does not require bleeding edge OSGoS though doesn't provide BC7 support on its own either. Obviously, due to the nature of this approach, anything rendering-related should be tested, I might well have missed something. But if this works out, (DDS) BC7 support would require little to no maintenance overhead since it won't be a special case anymore.

Another note is that S3TC support check in the image manager doesn't check one of the relevant extensions redundantly (the change got to upstream in 2015).

If this is acceptable, at some later point we could want to consider adding special state attributes to support Gamebryo texture transform animations and arbitrarily oriented KTX textures.

Yes I like to make lists how did you know.

Merge request reports