The perf cost is just too great for these to be enabled always. The only
place where the assertions are kept always is in the batch APIs -- there
it's assumed the function is called on large enough data to offset this
overhead, plus since it's often dealing with large blocks of data the
memory safety is more important than various FP drifts which were the
usual case why other assertions were firing.
The UBO definitons are not tied to GL in any way, so they should be
available always. MeshTools::generateLine() now is as well, and this
made the tests fail to link on ES2 builds due to the debug operator not
being present.
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.
Done this way only in the Phong shader, everywhere else it's just the
MAGNUM_ASSERT_GL_EXTENSION_SUPPORTED() macro. Some WIP code that I
forgot to clean up?
So it's possible to have light culling enabled on, say, 64 lights, but
with only at most 3 applied each draw, allowing the shader compiler to
unroll the loop if it makes sense. This also better prepares for SSBO
support where the total light count would be unbounded and thus the
value ignored, and thus the value can be 0.
This prepares for SSBO support where the total count is unbounded (and
thus the value is ignored, thus it can be 0).
Also regroup the doc paragraphs so it's clear what's related to UBO
usage and what applies to classic uniforms as well.
I still expect the API to change slightly to accomodate for line
stipple or textured lines (such as possibly having different smoothness
alongside and across the segment), plus there are some TODOs that might
change how it behaves in certain corner cases.
Currently just the bare minimum, more features such as handling
multiple contiguous strips and loops inside a single mesh or an
overlapping layout will come later.
The shader requires the input data to be laid out in a rather specific
way, and there will be a dedicated MeshTools utility for it in the
following commits. For independence though, the shader tests use a
custom helper.
The initial implementation has certain corner cases which will be
eventually resolved. For now they are pinned down with repro cases in
the test. But apart from that, it's pretty much usable in practice.
Remaining join styles (round and miter-clip) as well as stipple support
will eventually follow as well.
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.
Apparently a framebuffer attachment can be bound only if it's actually
written to by a shader, thus instanced test cases that had it set up
always were failing with a GL error if the shader didn't have ObjectId
output enabled.
I unified both into a single renderSetup()/renderTeardown() routine,
where the ObjectId renderbuffer is attached always, but then only the
test cases that actually use it are mapping it explicitly. And clearing
as well, because apparently it can be cleared only if it's mapped. Huh.
Mainly important for Shader::addSource() to prevent it from creating a
needless copy, but doesn't hurt to do the same also for
uniformLocation(), bindAttributeLocation() etc. -- it'll avoid a runtime
strlen() in that case at least.
Vladimír Vondruš