And, exactly as expected, there's many cases that used the (implicit)
ValueInit while NoInit is a better choice. So yeah, minor speedups in
various places such as GL image download.
All that work to reduce header dependencies and yet here it's full of
them, somehow.
Well, given the fallout in various GL tests now I wonder if I should
just chuck the rest along with the state allocation as a PIMPL.
These are all just minor off-by-one errors, nothing to worry about.
Except maybe for that one case with MeshTools::compile() but the rest of
the image renders fine, so it's not like I'd have some critical issue
there.
Less error-prone because of full type safety and much nicer overall. The
test code originates from a time before slice-to-a-member-function was a
thing and then it got just copied everywhere without much thought.
Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
Not that C++ STL and exceptions would be anything to take inspiration
from, but there's std::out_of_range. Python IndexError is also specified
as "index out of range", not "bounds".
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Interesting, didn't know this kind of feature support was possible. I
guess it's still better than no GLES3.2 at all. Also, it's a phone from
2017, so probably not all that important to care about anymore anyway.
Also fixes a WebGL error in the tests. I suspect it might fail elsewhere
as well. Nevertheless, this still doesn't mean that it would be
impossible to use dynamic joint count with UBOs -- simply pad the UBO in
that case.
Given that I made a breaking change by returning Containers::String
instead of a std::string, I can take it further and replace also
std::pair with Containers::Pair -- it won't bring any more pain to the
users, they have to change their code anyway.
Co-authored-by: Hugo Amiard <hugo.amiard@wonderlandengine.com>
It's not a GL error, and allows the application to compile just a single
shader for all skinned meshes, not one for each skeleton size. Together
with the dynamic per-vertex joint count this means the app only needs a
single shader for all skinned meshes, which is nice.
High-level docs with examples will be written once there's corresponding
support in MeshTools::compile() *and* in importer plugins, as skinned
meshes are usually brought in from files, never set up directly.
Co-authored-by: Squareys <squareys@googlemail.com>
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.
Fails spectacularly -- the geometry shader is aware only of instanced
object ID, and of vertex ID not at all. The former was a corner case
TODO while I was adding non-instanced object ID visualization in
033e56ec23 and which I kinda forgot about,
the latter was discovered while trying to fix the former.
Fix in the next commit.
Hah this took a while, as there was no texture scaffolding in place at
all. Thus all this had to be added and tested for the first time:
* 2D textures
* 2D texture arrays
* Texture transformation uniforms
* Texture transformation UBOs
* Instanced texture offset
This also means that MeshVisualizer can be used to visualize arbitrary
(single-channel) integer textures now, not just render meshes with
object ID textures. Yay for feature parity!
Forgot that gl_VertexID includes the base offset in the multidraw
scenarios, so we need to take all vertices into account, not just the
largest view. The wraparound would cause nasty output differences among
drivers.
Mainly to have feature parity with Flat and Phong -- otherwise switching
to draw a wireframe on an instanced mesh would be too annoying. Also, if
we have multidraw there already, why not instancing as well.
Vladimír Vondruš