For generic code, which would otherwise have to invent some SFINAE
"use castInto() if the types are different and Utility::copy()
otherwise" nastiness in every such case, and that's just annoying.
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.
Otherwise it may be hard to guess which of them is failing. *Ideally*
the assert would also contain the stride vs type size, maybe I do
that next time I spend that much time investigating why it asserts.
To perform conversion of an already-indexed TriangleStrip to Triangles,
for example, without having to perform an expensive deindexing using
duplicate() first.
To be consistent with what the generate*Indices() APIs expect -- it
doesn't make sense for this API to silently round down while the other
would fail for the same input. In particular, the primitiveCount() may
be used to calculate allocation size for an array to pass to
generate*IndicesInto(), and thus it should use the same rules.
The restriction didn't make sense. Disallowing 1 input vertex for lines
or 1/2 input vertices for triangles sure, but 0 vertices should work as
the expected behavior is obvious.
Before it was checked only inside generate*IndicesInto() the function
delegates to, which was too late as the arrays would be allocated with
an insanely high size at that point.
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.
The GL::Renderer::setClearDepth() and setDepthRange() APIs now use the
non-clamping NV entrypoints if available. The float overloads do that
too, to avoid differences in behavior depending on whether these
functions are called with a float or a double type.
The glDepthRangedNV() and glClearDepthdNV() behave differently from
glDepthRange() and glClearDepth() -- they don't clamp. There doesn't
seem to be any change in recent GL related to this, so this extension is
still valuable for improving depth buffer precision. Or, alternatively,
it's possible to use the glClipControl() API from GL 4.5 to achieve the
same.
I need alpha to coverage for rendering line caps with MSAA, took it as
an opportunity to expose the other related features as well. Fun how I
survived 12+ years without needing those.
Instead of having them wrapped in extra functions for
extension-dependent functionality. The only case that stays is the line
width range implementation, as the raw variant looked too ugly /
dangerous otherwise.
Every time I push an innocent change it ends up breaking the
non-deprecated build, such as 34a91cf458.
Sigh, I really need to clean up the backwards compatibility ifdefs...
"Funny" how this is the only API where I can't use glCreateTextures().
Like, it would have been so easy to just stop teaching glGen*() and
all their quirks and "this ID exists but it's not an object until you
bind it somewhere actually" to people altogether, BUT NO! FFS.
To match ARB_texture_view from from GL 4.3. Not sure why there's two of
them -- I was looking into the spec files, and the EXT variant seems to
be based on the OES variant but doesn't seem to add any change (or, no
change is listed), however the OES variant has number 218 while EXT has
185 so it's actually newer?! No idea what's happening there.
Vladimír Vondruš