Now it's a field and its corresponding object mapping, instead of
field and "objects":
- Goes better with the concept that there's not really any materialized
"object" anywhere, just fields mapped to them.
- No more weird singular/plural difference between field() and
objects(), it's field() and mapping() now.
- The objectCount() that actually wasn't really object count is now a
mappingBound(), an upper bound for object IDs contained in the object
mapping views. Which is quite self-explanatory without having to
mention every time that the range may be sparse.
Same as with MeshData2D/3D, the original ObjectData API and plugin
interfaces are preserved to keep existing code as well as existing
importer implementations working. As Magnum's own importers will get
updated to the new SceneData workflow, a backward compatibility layer
provided that translates it to the subset that the legacy ObjectData
understands.
With this commit, both existing plugin code can build (and test against)
the new workflow, and any ports to the new workflow can test against the
legacy interfaces. Except that for now the compatibility layer doesn't
deal with objects that have more than one mesh or for example a light
and a camera attached, this will be done in a separate step.
Memory-maps the file and uses openMemory() instead of openFile(). For
efficient data formats (such as glTF) can avoid reading the whole blob
if only the metadata or a part of the file is needed (for example the
peak usage for --info-materials with the Buggy.glb example model went
from 8.5 MB to 991 kB, as it reads just the JSON at the start and never
even pages in the buffer blobs at the end).
This currently only works for standalone files, files that reference
external images etc. would need to have file callbacks implemented. And
it's Sunday and I'm lazy.
Using openMemory() instead of openData() allows the implementation to
assume the data will stay in scope for as long as needed, which can
prevent unnecessary copies in some plugin implementations.
It warranted a new flag, DataFlag::ExternallyOwned, to describe this
kind of memory. I couldn't reuse Owned as that's used for allocations
owned by the instance, which is too little for certain future use cases.
For example returning *Data instances referencing an Owned memory would
mean the user has to assume the memory is gone when the importer
instance is gone, and that's generally not true for memory passed to
openMemory().
Originally I thought I would do this later, but then realized the
existing plugin implementations would need to get all updated again to
be aware of the new flag, with some being forgotten, and it's just
easier to do the whole thing in a single step.
This makes it much less annoying to pass arbitrarily typed data, such as
std::uint8_t or char8_t and what not. It was already done like this for
the new shader converter plugins, where the input is often 32-bit ints
for SPIR-V.
OTOH the internal virtual API is kept with ArrayView<const char>, as
that makes it easier to operate on by the implementations.
This allows to better describe memory ownership and transfer it instead
of forcing the plugins to allocate their own local copy if the import
happens in-place on the imported data. Right now that's mainly for the
openFile() use case, which implicitly allocated an Array with file
contents only to pass it to openData() which then made a copy because it
could not make any assumption about data scope.
In other words, certain plugins (TgaImporter, KtxImporter, DdsImporter,
CgltfImporter and possibly others) will now have their peak memory usage
*halved*.
Because it was getting annoying to scroll through the output, especially
with shitty files that duplicate materials etc. The --info is now a
shortcut for specifying all other --info options together.
Yes, this is only ever provided by an ANGLE extension, and as you might
have guessed, The Great Google Overlords didn't bother caring to have
this supported outside of their browser.
Unlike most other extensions, this one has to be explicitly enabled in
Emscripten in order to be used. Which thus done as part of other "driver
workarounds" done on startup. To avoid that, the extension can be
explicitly disabled, and thanks to the previous commit the disabling
will be performed before the extension is attempted to be enabled.
And update docs in Matrix[34]::rotation() and related functions to note
this. This is a breaking change that may cause existing code to start
asserting.
There's now 24 overloads for unsigned types and 24 for signed types,
which is all possible combinations. Not adding an ability to cast
between signed and unsigned as I'm not sure what should be done there.
And add a comment explaining why we don't check the pointer for empty
meshes -- otherwise empty interleaved meshes would fail with stuff like
Trade::MeshData: attribute 0 [0xc:0xc] is not contained in passed
vertexData array [0x0:0x0]
which ... helps nobody.
Because a MeshView might not be the best thing to have when you are
submitting a batch of thousand draws. It takes a strided array views to
allow for more flexibility, but can also detect if the input is already
contiguous and use it as-is.
UNFORTUNATELY the GL 1.0 legacy still continues to stink and so there
has to be a 64-bit-specific overload which is the *actual* variant that
doesn't allocate because glMultiDrawElements takes a `void**` for INDEX
OFFSETS and it's IN BYTES! Which foolish soul designed such a thing back
in the 1860s, I wonder. There's no reason to not have an index offset
in elements because all indices have to have the same type ANYWAY. And
yes, I wasted about three hours debugging driver crashes because I
THOUGHT this parameter takes offset in elements, not bytes.
Also note: on 32-bit platforms this depends on latest Corrade with the
CORRADE_TARGET_32BIT definition. Spent an embarrassing amount of time
wondering why all local builds but Emscripten work.
The multi-level APIs still don't check anything regarding level sizes
and order since for example *.ico has no restrictions at all. But the
rest (like non-zero size) is a restriction for all file formats I'm
aware of.
TgaImageConverter test had to be adapted, I expect a lot of breakages in
plugins tests as well. But user code should be fine I think. Also
reduced the rather excessive dimensions in AbstractImageConverterTest,
since the allocation requirement now made the default Emscripten heap
OOM.
Because::This::Is::Colon::Cancer. Also rename Cube to CubeMap and get
rid of the comment that said cube map images are six consecutive 2D
images. Now it's one 3D image instead because that makes more sense, in
the very rare case we'd need to have six different images again we could
probably add a CubeFace value or some such.
We have half-float vectors and matrices, so why not these as well. Not
sure for what all is the angle precision usable, but at the very least
it could be useful for compact meshlet occlusion cone / AABB
representation or rough animations.
This is already done for the AbstractImporter and the new
AbstractShaderConverter, as there's a common use case of checking just
the filename for input/output path or file type detection and then
delegating to the common implementation working directly on data.
Minor but very important convenience feature, especially useful when
dealing with command-line apps. This now works:
magnum-imageconverter a.png a.jpg -c jpegQuality=0.75
The AnyImageConverter gets the jpegQuality option and then
automatically propagates it to the concrete plugin (which is either
JpegImageConverter or StbImageConverter), possibly warning in case the
target plugin doesn't recognize given option (i.e., doesn't list it in
its default configuration). Previously the user had to always specify a
concrete converter implementation using -C, which was rather annoying
and nonintuitive.
In cases when specular highlights are not desired, results in 30%
speedup (on Intel) and ~25% speedup on AMD, compared to setting the
specular color to transparent black.
Testing was easy thanks to already having a ground truth image for this
case.
Vladimír Vondruš