-
Notifications
You must be signed in to change notification settings - Fork 442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skinned Mesh attributes #441
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here you have some models with more than 4 weights: https://twitter.com/zeuxcg/status/1194650202696605697
src/Magnum/Trade/MeshData.h
Outdated
* @see @ref jointIndicesInto(), @ref attributeFormat(), | ||
* @ref isVertexFormatImplementationSpecific() | ||
*/ | ||
Containers::Array<Vector4us> jointIndicesAsArray(UnsignedInt id = 0) const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think should always be the largest type (even if it will never be as big):
Containers::Array<Vector4us> jointIndicesAsArray(UnsignedInt id = 0) const; | |
Containers::Array<Vector4ui> jointIndicesAsArray(UnsignedInt id = 0) const; |
What's left for this to be useful is adding those to |
Sure, it looks straight forward enough to do so, and I'll have to eventually anyways, so why not rip off the bandage. |
@mosra I started implementing Skinning in Phong to test the additions to compile(), but this would blow up the PR significantly. Could we split Phong shader implementation, compile() and test off into a separate PR? |
Yup, good idea -- the Phong implementation also needs tests on its own, so it makes sense to do all that separately. |
Signed-off-by: Squareys <[email protected]>
Signed-off-by: Squareys <[email protected]>
Signed-off-by: Squareys <[email protected]>
Split Phong implementation into Squareys:phong-skinning, will create the PR for that once this is merged. |
* @ref Magnum::Vector4ui "Vector4ui", four joint indices that may affect the vertex. | ||
* Corresponds to @ref Trade::MeshAttribute::JointIds. | ||
*/ | ||
typedef GL::Attribute<7, Vector4ui> JointIds; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the Secondary
attribs documented here.
CORRADE_COMPARE(out.str(), | ||
"Trade::MeshData::jointIdsInto(): expected a view with 3 elements but got 2\n"); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The attributeNotFound()
and implementationSpecificVertexFormatWrongAccess()
tests need to be extended to check asserts in the new accessors.
* Corresponds to @ref Shaders::Generic::JointIds. | ||
* @see @ref MeshData::jointIdsAsArray() | ||
*/ | ||
JointIds, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering -- would it make sense to support also one/two/three-component weights and joints? I guess it would be useful for file size savings. Can you check if there are example glTF files with less than 4 weights?
This won't complicate the implementation too much, a similar thing is already done for colors for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The accessor is always a 4-component vector, so in case there is a file like this, it would have 4 but the unused components would be zero weight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In (unextended) glTF yes, but in general not. I don't see why glTF couldn't support SCALAR
, VEC2
and VEC3
also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, if it would make sense to support one/two/three-component weights, would I do that with JointIds1/2/3/4
? And I assume the respective changes in MeshData like for color3/4?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be just JointIds always, but allowing also one/two/three-component types instead of just Vectot4ui.
MeshData::jointIdsInto()
will then need to zero-fill the unused components like colorsInto()
does for three-component colors or positions3DInto()
does for two-component positions, yes.
typedef GL::Attribute<7, Vector4> JointIds; | ||
|
||
typedef GL::Attribute<10, Vector4> SecondaryWeights; | ||
typedef GL::Attribute<11, Vector4> SecondaryJointIds; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing #444, this PR should contain also the generic.glsl
changes and corresponding additions to GenericTest::glslMatch()
Merged with various changes as 7f94a6f and f447e99. The primary difference is that The builtin shader bindings slots stay four component, with the intention that (a) the shader is either compiled for an appropriate per-vertex component count, (b) a dynamic per-vertex component count is passed to it, or (c) the mesh is repacked to always contain the maximum number of components the shader expects. A major change with the builtin attribute is that they have a flipped order compared to this PR -- |
Hey @mosra !
here's some initial draft for Skinning stuff to start discussion.
Cheers,
Jonathan
Open Questions
1.Naming of Attributes
TODOs
Weights
andJointIds
to AttributeNames and Generic attributes.