-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Basis plugins to 1.15 #112
Conversation
TODO: tests
TODO: tests, docs
If zstd can't be found by FindBasisUniversal.cmake, compile with Zstandard (de)compression support disabled. At runtime, detect this and print a useful error (instead of "transcoding failed").
This sets the correct basis parameters depending on the image format. Can still be overridden by config values, if present. TODO tests
Array layers, cube faces and z slices are imported in an extra image dimension, ie. Image3D. Image type is exposed via texture(). TODO tests, docs, some extra validation on .basis files
basisu doesn't do it for us, only in .basis files
Removed from the basisu C++ API, can be replaced by swizzle=rrrg
basisu doesn't flip level 1 or higher
All mipmaps in basis are 2D, but they'd need to halve in Z for correct 3D mipmaps. Print a warning and import them as 2D array textures with mipmaps instead.
I realized that importing video files as a single |
…on, second attempt
I have a drastic suggestion: remove big-endian detection, hoping nobody ever needs it 🤠 On CMake 3.20 we can use |
Oh wait, so if you enable C it causes the C files to be compiled as C on static builds even though told to be compiled as CXX, and if you don't enable C the C files get properly compiled as CXX? Or is that C enablement independent of the problem with C files being compiled as C on static builds? |
# Conflicts: # src/MagnumPlugins/BasisImporter/BasisImporter.cpp # src/MagnumPlugins/BasisImporter/Test/BasisImporterTest.cpp
Yeah, without enabling C it would just ignore those files altogether, causing unresolved symbol errors. When I forced CXX without enabling C, I don't remember getting these C-specific errors. I don't know what weird interactions are going wrong but I'm thinking it might not be worth the effort. |
This is way too broken
…empt WSL is amazingly helpful for this
it requires CMake 3.7
I went ahead and disabled the endianness detection on CMake < 3.9 for now. Maybe worth revisiting for later, but I can't remote diagnose this without force-pushing and eating all your CI minutes 🙊 There's one weird error about |
Okay, I'm taking over with finishing the PR, this whole thing seems (again!) way more cursed than anticipated. |
and test the converted image, not the original(??) image
G is taken from the alpha channel, matching the recommended basisu -swizzle rrrg for two channels. We don't control this, it's done by the transcoder.
…eir own This fixes the use case of feeding an RG image + swizzle rrrg (as recommended by the basis docs). This would lead to the output becoming rrrr since BasisImageConverter already performed that swizzle. Also document the behaviour.
Merged as 809fc18...670133c, with some of my commits mixed in (external zstd dependency, fix to that C language enablement craziness, ...). The commits are regrouped and squashed into small enough logical chunks so it looks quite different from the patch set in this PR, but the total bulk of changes is the same ;) Thank you for the excellent work again! |
This PR upgrades
BasisImporter
andBasisImageConverter
to work with basis_universal 1.15 (more specifically, tagv1_15_update2
because that contains a few important changes).Not entirely finished with everything, but the majority is there, so feel free to give it a first review 🙇
New features
Along with the upgraded dependency come a few new features:
ImageData3D
basisu
itself can only generated 2D arrays for KTX2, anyway.BasisImageConverter
this is simply a new config option (defaults tooff
)sRGB
formats:BasisImporter
this is a flag read from the file header, affecting the output formatBasisImageConverter
it's detected from the image format and sets the correct parameters for the encoder. Can be overridden by config options, if desiredBasisImageConverter
Todo
Or rather: questions to @mosra
allow export of 3D images innope, but probably revisit once image flags are in, for cube and 2D array texture exportBasisImageConverter
? Is this a priority?the importer code got rather messy, should I write a small abstraction over the two transcoders to make the code legible again?eh, that'll just sweep the code into another cornershould we flip z in 3D images? Files have a y-flip flag so we could use that to deduce y-flip = z-flip, but I'm not sure how foolproof that is since thenope, "solved" now that we import 3D images as 2D array layersbasisu
tool doesn't do any z-flipping at all, regardless ofy_flip
being setBC7RGB seems deprecated since UAST, should this go away? Investigate what this means for the output datathey both mean the same thing, removing the RGB variantprint a useful error about PVRTC1 requiring power-of-two, instead of just "transcoding failed"? However, then we won't have an easy way to test the transcoding failing 🤡PVRTC is pretty ancient, not worth the extra effort.basis
files. The KTX2 transcoder does all that, but the basis transcoder is missing a few checks we need, e.g. all array layers having the same size., some of them seem obsolete and we should add some comments (just take whateverbasisu
itself says). Also: the docs say the config options follow thebasisu
tool, and the.conf
file says they follow the C++ API. The latter is true, but we should decide on one. I thinkbasisu
options would be more intuitive but require some extra wiring + tests...BasisImageConverter
sRGB handlingRelated issue: #110. Can be closed if this PR and the upcoming PR for
KtxImporter
Basis-forwarding are merged.