It is not related to Mesh itself at all, as the attribute indices are
defined in Attribute class. Use
AbstractShaderProgram::maxVertexAttributes() instead.
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.
In the future, when I get to implement proper DSA clearing, this won't
change currently bound framebuffer and thus it might be useful to be
able to call bind() right after, e.g.:
framebuffer.clear(FramebufferClear::Color)
.bind(FramebufferTarget::ReadDraw);
It's now possible to do the reading operation in one statement.
Previously it was needed to have mutable variable:
Image2D image{ColorFormat::RGBA, ColorType::UnsignedByte};
framebuffer.read(framebuffer.viewport(), image);
Currently:
const Image2D image = framebuffer.read(framebuffer.viewport(),
{ColorFormat::RGBA, ColorType::UnsignedByte});
To make this possible, the two-parameter Image and BufferImage
constructors are now made implicit.
Not sure why I chose to have offset and size in these two function, but
that's probably because I never used them in real code. The original
overloads taking pair of Vector2i are now marked as deprecated and will
be removed in future release.
Direct access to list of children is now provided through
Object::children(), list of features is provided in
AbstractObject::features(). In most cases the range-based-for is good
enough, the previousSibling()/nextSibling() and
previousFeature()/nextFeature() functions are for the cases where user
needs more flexibility.
Because everything that was previously done using firstChild() etc. can
be now done also with children().first() etc., there would be more than
one way to do the same thing. Thus the old functions are now marked as
deprecated and will be removed in some future release.
Using std::numeric_limits for the Double variants looks like an overkill
to me, but there apparently isn't any other way, except for crafting the
value manually using the exact binary representation (and hoping it will
be portable) or producing the value as result of division by zero or
something like that (and then working around the warnings and also
hoping it will be portable).
Constants::piHalf() is not longer to write than doing the division
manually and it has significantly smaller mental overhead. Also I chose
piHalf() instead of halfPi() to make it more discoverable through
autocompletion.
Float a = Constants::pi()*0.5f;
Float a = Constants::piHalf();
Float b = Constants::pi()/(2*countOfSomething);
Float b = Constants::piHalf()/countOfSomething;
Originally enabled just on OSX, apparently something similar is needed
also in Mesa. If the version is not user-specified, core GL 3.2 is
created on OSX, core 3.0 elsewhere. If that fails, the application falls
back to creating compatibility 2.1 context.
Hopefully I didn't break anything. The only difference on OSX is that
the application doesn't fall back anymore if the version is
user-specified.
This function was added to ARB_instanced_arrays spec very late and thus
some implementations don't provide it (one case being AMD drivers on
Linux). If that function is not available, the non-DSA VAO specification
is used instead.