TODO: changelog
TODO: putting the delegation to single-mesh into batch do*() APIs and
vice versa feels wrong as they're called even if the feature is not
supported, should be done by the driver instead
TODO: coverage is sad
Unlike most other options, where a plugin can support 3D but not 2D or
compressed but not uncompressed data, the "levels" option is orthogonal
to the rest -- if a format supports multi-level data, it obviously also
supports a case where there is just a single level, and if it supports
multi-level images, then it likely supports them for 1D, 2D and 3D, not
just some.
The bit pattern actually followed this reasoning already, but for some
reason I still went ahead and stamped out all possible combinations.
TODO: finish
TODO: OTOH, the ToData is probably better to not have a single bit
common for all, as it makes it impossible to say that e.g. 3D is just
ToFile and 2D and 1D is ToData as well (e.g. when the 3D slices would
need multiple files). So change that to different bits instead.
And not views, as ImageData contains extra metadata. Currently just the
importer state, but eventually that will be changed to a generic
key/value store for stuff like color correction, EXIF, gamma, etc., and
if the plugin interfaces would consume only views (which don't and won't
have such key/value data), the data would get lost.
A similar approach is being taken with the AbstractSceneConverter.
TODO: implement this to be more than just a TODO
For animations, scenes, meshes and images, where the memory impact is
measurable. For others such as materials or cameras the memory impact is
either unclear (depending on the final representation) or so small it's
not important.
Because yes of course dealing with a JSON just isn't possible
without having to make decisions between insufficiently imprecise
integers and unnecessarly overprecise doubles.
I.e., with the intention to be implemented in the best way possible,
without relying on some 3rd party library with murky corner cases and
questionable tradeoffs.
Not available on GLES2, similar to BufferAttachment but with the added
constraint that WebGL1 doesn't support invalidating attachments at all.
Not adding this for DefaultFramebuffer since that takes different target
values, and GL_DEPTH_STENCIL is not one of them.
This makes it possible to conveniently do things like
Containers::StridedArrayView1D<Float> array = …;
Vector4 vector{NoInit};
Utility::copy(array, vector); // or the other way around
which is especially useful together with the new JSON classes. In some
cases this means the function is no longer constexpr, but those weren't
constexpr because it was useful for anything, they were only because it
was possible. So this breakage shouldn't do any harm I think.
Certain Clang-based IDEs (CLion) "emulate" a compiler by inheriting all
its defines, which means one gets __clang__ defined but also __GNUC__
set to 11 or whatever, breaking all these assumptions.
While branching on a compiler is rather common, checking a particular
compiler version should be needed only rarely. Thus minimize use of such
macros to make them easier to grep for.
Yay, I can abuse/reuse the features I had to add to flextGL because of
GOOGLE!!!, and with only one additional patch to support local xml
files I can very conveniently include whatever entrypoints I need.
I realized those are too annoying when writing a glTF exporter which
contains a lot of switches over enums. And as further shown by the diff,
those were only inflicting additional pain in *all* switch statements,
nothing else, no other added value. And everywhere else the helpers are
the designated way to deal with those, so there's no point in having an
explicit enum value denoting start of a "custom range".
It wasn't even any convenient to have it in the enum, as the extra
effort needed for casting actually made it *exactly* the same length as
if I'd just use a separately-defined constant.
Like, it's a *debug printer*, why an inline call would matter in there.
Or maybe it's that the debug printer was done way earlier than the
helpers? ... and then copied, without a brain attached to my head, from
MeshData to the new SceneData?
Until now, these were only transitively tested in concrete plugin
implementations, meaning that if the base implementation would have an
error (such as accessing a null optional), it would only get discovered
when building a plugin, worst case a plugin in a completely different
repo.
Vladimír Vondruš