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.
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>
Same as in the previous commit, most cases are inputs so a StringStl.h
compatibility include will do, the only breaking change is
GL::Shader::sources() which now returns a StringIterable instead of a
std::vector<std::string> (ew).
Awesome about this whole thing is that The Shader API now allows
creating a shader from sources coming either from string view literals
or Utility::Resource completely without having to allocate any strings
internally, because all those can be just non-owning references wrapped
with String::nullTerminatedGlobalView(). The only parts which aren't
references are the #line markers, but (especially on 64bit) those can
easily fit into the 22-byte (or 10-byte on 32bit) SSO storage.
Also, various Shader constructors and assignment operators had to be
deinlined in order to avoid having to include the String header, which
would be needed for Array destruction during a move.
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.
Those were temporarily added until Trade::AbstractImporter is ported
away from std::string, and that's done for quite some time already, so
these are no longer needed.
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>
With skinning the TransformationUniform*D structure will be reused for
two different UBOs and referencing it without the corresponding
bind*Buffer() API would be confusing. So just do that for all.
* No need to repeat the type for all variables, unnecessary redundancy.
* Reducing the amount of redundant local variables and if they stay
making their definitions more localized to where they get used.
* All uniform setters used the "initial value is" phrase instead of
"default is", this one didn't.
To make room for two more 16-bit skinning-related values in the
PhongDrawUniform -- joint offset for multidraw and per-instance joint
count for instancing.
Originally I made those full 32 bits because I wanted to provide an
option to have a 64-bit light mask there instead of an offset + count.
But the mask is not really driver-friendly as going over the bits and
skipping zeros was behaving like if each pixel was affected by 64 lights
-- an absolute perf nightmare. I might reconsider this again later, but
for now that doesn't seem to make sense, and I need to put the
skinning-related info somewhere without inflating the per-draw uniform
by another 16-byte vector.
Note that the order is *reversed* compared to the originally reserved
attribute IDs. This is because the "joint <id> has <weight>" order
feels more natural and consistent than "<weight> is assigned to joint
<id>".
Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>
Those were originally named set*Buffer(), but in the process of
finishing up ef9da0ec96 got changed to
bind*Buffer() to avoid a false impression that the buffer stays bound to
the shader instance forever (which it doesn't, same as with textures).
However the documentation didn't get updated, apparently.
A considerable chunk of the docs mentioned that there has to be one
ProjectionUniform3D per draw. Probably a copypaste error from the case
where there's a combined TrannsformationProjectionUniform3D, which *is*
one per draw. Sorry for the confusion.
There was also quite a lot of documentation content referencing the old
deprecated constructors. Fixed now.
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.
Because it was no longer bearable with three UnsignedInt arguments in a
row, especially when some of them are only available on a subset of
platforms. And it would get even worse with introduction of planned
features such as multiview or skinning.
Backwards compatibility is in place, as always. To ensure nothing
breaks, this commit still has all tests and snippets using the old API.
Vladimír Vondruš