This is unfortunately a breaking change to compileLines(), which now
takes the output of generateLines() instead of a line mesh. There's a
new assertion that'll blow up if the code is used the previous way,
sorry for the breakage.
What's however very useful about this change is that now it's possible
to take those generated line meshes and concatenate() them together,
achieving what's otherwise not implemented yet, such as drawing several
disconnected line strips or loops together.
It's all still partially private (the custom mesh attribute names are)
and I'm marking both APIs as experimental now to hint that it's not in
the final form/functionality yet. In particular, the data layout
optimizations described in the shader docs aren't used by these tools
yet, and if/once the line-specific vertex attributes become builtin,
compileLines() will not need to exist anymore as compile() will handle
that directly.
What's especially nice is that the code snippets no longer need to
describe that there's "2 lights, 3 materials and 5 draws" because now
it's self-documenting.
Funny how even doing the *insanely complex* operation of extending a
MeshData with one extra attribute is still shorter than manually
populating the GL::Mesh.
First and foremost I need to expand the interface to support 3D
image conversion. But the interface was not great to begin with, so this
takes the opportunity of an API break and does several things:
* The `export*()` names were rather strange and I don't even remember
why I chose that name (maybe because at first I wanted to have an
"exporter" API as a counterpart to importers?)
* In addition, there was no way to convert a compressed image to a
compressed image (or to an uncompressed image) and adding the two
missing variants would be a lot of combinations. So instead the new
convert() returns an ImageData, which can be both, and thus also
allows the converters to produce compressed or uncompressed output
based on some runtime setting, without having to implement two
(four?) separate functions for that and requiring users to know
beforehand what type of an image will be created.
* The ImageConverterFeature enum was named in a really strange way as
well, with ConvertCompressedImage meaning "convert to a compressed
image" while "ConvertCompressedData" instead meant "convert a
compressed image to a data". Utter chaos. It also all implied 2D and
on the other hand had a redundant `Image` in the name, so I went and
remade the whole thing. As mentioned above, two of the enums now mean
the same thing, and are both replaced with Convert2D.
* Finally, similarly as changes elsewhere, I took this opportunity to
get rid of std::string in the convertToFile() APIs.
This is a -- long overdue -- breaking change to the rendering output of
this shader, finally adding support for lights that get darker over
distance. The attenuation equation is basically what's documented in
LightData, and the distinction between directional and point lights is
made using a newly added the fourth component of position (which means
the old three-component setters are all deprecated). This allows the
shader code to be practically branchless, which I find to be nice.
This breaks basically all rendering output so all existing Phong and
MeshTools::compile() test outputs had to be regenerated.
Making room for GenerateTangents in 3D, and keeping the 2D ones
consistent with 3D. Also renamed GenerateTextureCoords to
GenerateTextureCoordinates in the remaining places to be consistent with
naming in the rest of the APIs.
Pros:
* faster compile times (#include <tuple> is 13k lines, ugh)
* ability to have NoInit and ZeroInit constructors
* ability to do fuzzy compare
* named members, so we don't have to use mutable std::tie()
Cons:
* ... none?
The old Color[34]::Hsv is still a tuple and the new ColorHsv is
convertible to/from it (and even std::tie() works). These are all
deprecated (along with the <tuple> include).
Much easier to write (and explain!) than Shaders::VertexColor2D::Color{
Shaders::VertexColor2D::Color::Components::Three}. Ugh. Why again it
took me *years* to realize?
All functionality is now available through free functions. The classes
are now just deprecated wrappers and/or typedefs and will be removed in
some future release.
This better reflects that the functions modify a global state instead of
a shader-local state and so rebinding may be necessary (unlike with
uniforms, which get preserved).
The old set*() functions are now inline aliases to the bind*()
functions, are marked as deprecated and will be removed in some future
release.
And removing the bundled std::optional implementation. This finally
makes this library compatible with C++17. Since this would be a huge
backwards-incompatible change that would make everyone angry, the
following had to be done in case both CORRADE_BUILD_DEPRECATED and
MAGNUM_BUILD_DEPRECATED is defined:
* Under C++11 and C++14, Containers::Optional / Containers::NullOpt is
aliased to std::optional / std::nullopt. This is no worse than the
state before, when we also provided these symbols.
* Under C++17, where standard <optional> header is available,
Containers::Optional provides implicit conversion to it. Only one-way
conversion is supported, as there was fortunately no Magnum API that
took std::optional via parameter, and there might be some corner
cases that this doesn't cover. The goal is to have all examples
compiling with the old API, at least.
* There's a new test especially for this, which checks that both the
C++11 and C++17 ways of doing things work as they should.
The typedef and conversion is marked as deprecated, so it will spit out
many warnings to push users to upgrade. I hope I can completely remove
this mess soon :/
Yeah, sorry, I know, the enums are renamed for second or third time in a
row, first they were Image::Format, then ImageFormat, then ColorFormat
and now PixelFormat. But this time it's final and last time they are
renamed and now everything is finally consistent:
* ColorFormat::DepthComponent -- depth is not a color, thus
PixelFormat::DepthComponent makes a lot more sense.
* There will be PixelStorage classes, which will be stored in images
alonside PixelFormat/PixelType enums, making everything nicely
aligned.
* The GL documentation about glTexImage2D() etc. denotes the <format>
and <type> parameters as format and type of *pixel* data, so now we
are _finally_ consistent with the official naming.
I wonder why did I not choose PixelFormat originally. Anyway, the old
<Magnum/ColorFormat.h> header, ColorFormat, ColorType and
CompressedColorFormat types are now aliases to the new ones, are marked
as deprecated and will be removed in some future release (as always, I'm
waiting at least six months before removing the deprecated
functionality).
Each shader now has sample image, example mesh configuration and example
rendering setup. Also properly documented all attribute types and made
introductory chapter for whole Shaders namespace.
Vladimír Vondruš