They are required to have the same format already, so flags make sense
as well -- what's the point of saving a multi-level cube map with one of
the levels being just a 2D array, anyway?
Array texture and cubemap (array) subimage queries get
ImageFlag*D::Array, cubemap whole image ImageFlag3D::CubeMap, cubemap
array whole image get ImageFlag3D::CubeMap and ImageFlag3D::Array. No
flags are checked when uploading images or when downloading images to
views -- using an array texture as a cube map and vice versa is a valid
case, and others are probably also, so there's no point.
The flag restrictions will come into place when ImageFlag*D::YUp / YDown
etc. are a thing.
With the intention that those will eventually contain also things like
YUp / YDown, PremultipliedAlpha and such.
This commit is mostly just busywork, wiring this into [Compressed]Image,
[Compressed]ImageView and Trade::ImageData and ensuring the flags get
correctly propagated during moves and conversions. Unfortunately in case
of Trade::ImageData it meant deprecating the current set of constructor
in order to insert an ImageFlags parameter before the importer state
pointer.
The only non-trivial piece of logic is when a 2D
[Compressed]ImageView gets converted to a 3D one, then the Array bit is
implicitly dropped, as 2D arrays of 1D images are not really a thing.
Instead, it's now possible to add new flags when doing the conversion --
for example to turn a 2D image to a (single-layer) 2D array image.
Ahem, missed those in 36ee7835d6. Yes,
putting compressed images into atlases is a desirable thing to do as
well, although it's now rather shitty due to lack of slicing.
Similar to what VertexFormat already has -- getting channel count,
channel format, sRGB and color vs depth/stencil properties out of a
PixelFormat value. Very useful for various image conversion plugins.
For consistency with how VertexFormat and other enum helpers are named.
The compressedBlockSize() and compressedBlockDataSize() is also renamed
to compressedPixelFormatBlockSize() and
compressedPixelFormatBlockDataSize().
While backwards compatibility aliases are in place, a breaking change
is that Image classes now look for pixelFormatSize() instead of
pixelSize(). This is used e.g. when passing GL::PixelFormat /
GL::PixelType to the image classes, instead of the generic PixelFormat.
While useful, it's unlikely that any project was defining their own
pixel format enum and pixelSize() for a D3D or Metal renderer or
whatnot, so the breakage should have no practical impact.
Together with the parent commit, it's now possible to do THE
UNTHINKABLE:
Containers::Array<Trade::ImageData2D> inputImages = ...;
auto out = TextureTools::atlasArrayPowerOfTwo({2048, 2048},
stridedArrayView(inputImages).slice(&Trade::ImageData2D::size));
An actual use case, in fact. Because why not.
Allows creating a StridedArrayView slice on the sizes to feed them to
various algorithms, instead of first having to copy the sizes out to a
freshly allocated array.
When for example only CMAKE_RUNTIME_OUTPUT_DIRECTORY is set, but not the
others, the original code skipped overriding the locations altogether.
This is a valid use case, as e.g. ARCHIVE and LIBRARY_OUTPUT_DIRECTORY
tend to mess with the way Visual Studio produces and consumes *.lib
files.
Furthermore, this now also handles CMAKE_*_OUTPUT_DIRECTORY_<CONFIG> in
a similar way, which is what Conan uses for example.
This is what commit ca722eac6e should
have been.
Sorry for breaking a non-deprecated MSVC build once again. The reason it
"appeared to work" for me was that on deprecated builds, Manager.h
includes Manager.hpp for backwards compatibility. On non-deprecated it
doesn't and MSVC ends up dying on a linker error. But the problem was
not related to extern templates, the problem was that there was a
compiler-specific ifdef in the cpp file which exported the class for all
compilers but MSVC, somehow. And so when I removed extern template from
the header, it still worked everywhere, except MSVC and except a
non-deprecated build.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
The boring dry usage info grew significantly, and listing it as the
first thing on the page would scare people off. Put the examples first
instead, and for the imageconverter and sceneconverter add --info
listing examples, as that's what is eye-catchy.
Mirrors what's done in sceneconverter already. Use case is for example
resizing an image for a concrete mip level, then passing it through a
BC7 compressor, and finally exporting into a KTX2 container.
Logic mostly the same as with MaterialAttribute::*TextureCoordinates --
attribute not present is treated the same way as if the layer was 0
(since that's what a 2D non-array texture is, a single-slice array), and
conversely if the attribute is 0 it's the same as if it would be not
present at all. Plus it also gets checked in queries for packed
textures, if everything is the same but the layer is different, then
it's not a packed texture.
The rest of the commit is just busywork for convenience APIs.
In particular, returning true only if some coordinate set index is
non-zero -- the main use case is to know whether we need a complex
shader with multiple coordinate attributes or not.
Only PhongMaterialData do that, others not.
Originally I copied this over from SceneGraph template classes, where it
was used to prevent the compiler from needlessly instantiating a
template that was already available elsewhere. But this is a different
case, the extern template is not preventing any instatiation of
anything, no code is inline, so it apparently should not have been there
at all, instead of being disabled for ḾinGW GCC and clang-cl, and then
subsequently discovering it also breaks MinGW Clang.
Since I'm not testing with MinGW Clang on the CI (only with MinGW GCC),
this went unnoticed for a while -- sorry.
Vladimír Vondruš