It used to take an initializer list, not anymore. Will test this better
once I have to build e.g. AssimpImporter for some other reason -- then I
can use this function to prefer it for loading glTFs and see how that
manages.
Need that for configuring plugins -- originally thought I'd wait until
the class is reworked, but that isn't coming anytime soon given there's
insane pressure on other things, so I have to figure out a plan B.
The interface is the most barebones possible, exposing nothing that I'd
later plan to rename or remove. Just the least possible amount of APIs
to make it possible to configure plugins, and no custom type support yet
either -- if you need to write a vector, write it as a formatted string
instead, sorry.
To make it possible to test the APIs in isolation instead of through
the plugin interface, I added also a Configuration class. Also just the
least amount possible to cover the code with tests.
It was specific to Python 3.7, which is already EOL'd, so not much point
in investigating further. I won't deliberately make it broken there
though, so the order will stay maintained like this as much as possible.
They're unpacked to full floats on element access and packed back from
full floats on mutable access, which makes this all very nice and
transparent. Yay Python!
That's it for now, I'll postpone half-float and matrix types for later
when these are actually needed, as it needs extra testing for the
aligned variants too.
To not have to duplicate these for each and every case, enlarging the
surface for potential bugs. Also changing the signatures to number +
identifier, instead of identifier repeated number of times. Means the
compiler won't be able to deduplicate / overlap the literals in the
binary, but is much more maintainable.
For Numpy this causes the slices to be reported as actual typed Numpy
arrays instead of typeless tuples, which is good I guess? Not sure why
that wasn't the case before, or what is the difference, and how it will
behave for sparse types such as aligned matrices.
It was casting in the wrong direction, causing an unbound type to be
returned and also accessing the data totally wrong. Should have tested
this properly in the first place.
Otherwise people wouldn't be able to conveniently use os.path, which is
an undesirable pain point. And do this for all currently exposed APIs,
not just the AbstractImporter that caused a problem.
This reverts commit 28497ec2ca.
Because for some reason pybind11 on *some platforms* (or in some
configurations?) picks the integer overload even for enum arguments,
only because it's first in the overload set.
This is extremely brittle, but for now I don't know any better solution.
In concrete types. Yes. Well, some of them for now, I still need to
sleep on normalized and matrix types, how it makes the most sense to
expose those. Oh, and array attributes as well.
The Shaders classes now take a Configuration class instead of a
hard-to-distinguish list of arguments. But in Python we have named
arguments, so none of that is necessary -- I only made the arguments
explicitly keyword-only but the interface stays the same.
Vladimír Vondruš