-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Simplify skinning to always expect VEC4 joint/weight accessors. #8846
Conversation
Thanks for the pull request @emackey!
Reviewers, don't forget to make sure that:
|
@@ -4388,7 +4388,7 @@ function applySkins(model) { | |||
computedJointMatrices[m] | |||
); | |||
if (defined(bindShapeMatrix)) { | |||
// Optimization for when bind shape matrix is the identity. | |||
// NOTE: bindShapeMatrix is glTF 1.0 only, removed in glTF 2.0. |
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.
CC CesiumGS/gltf-pipeline#403 - ultimately bindShapeMatrix
should be removed in upgradeVersion
.
I'm seeing a crash for materials-common models like https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/1.0/BrainStem/glTF-MaterialsCommon. Though to be fair, master doesn't animate it correctly. |
Thanks, forgot to actually test Both should be fixed now. |
Wait wait wait... just spotted something odd. In the completed vertex shader, the log depth system is not told about skinning deformations. Uh?
|
OK I'm out of my element with the logDepth stuff, and it's unrelated to this PR. But in master, I know that skinned models don't have proper depth buffering. And in this vertex shader output, I can see that the But the code that generates that code is... interesting. Can't quite follow the logic there yet. Can anyone more familiar with logDepth advise? Specifically:
|
Yes, looks like if the workaround is pulled, some glTF 2.0 models are fixed (like BearOnBalloons from #6416), but models with non-normalized bone weights are then broken (such as the glTF 1.0 version of CesiumMan). I'd rather see the glTF 2.0 models work than the 1.0 models, so it may be time to pull that workaround. That could be a separate PR though from this. |
@emackey agreed, can't really justify keeping that workaround in just for some skinned 1.0 models. |
All looks good here. |
A few weeks ago I was implementing skinning in a desktop product, and looked to Cesium's implementation for some inspiration. This is a story of what I unearthed.
In glTF 2.0, the
JOINTS_0
andWEIGHTS_0
accessors are specified to be vertex attributes of typeVEC4
only. But in glTF 1.0, this was left unspecified. Normal software that writes this stuff always wrote VEC4 data, but our intrepid intern at the time took the loose specification to mean that any type of accessor could appear there.As a result, a complex block of JavaScript writes skinning GLSL vertex shader code for any conceivable layout of joint+weight data, including the possibility of using a per-vertex matrix of references to joint matricies. There is no known sample or test data that does this, and indeed this code was not covered by unit tests for any case other than the
VEC4
case alone.In this PR, I've replaced all the crazy skinning-shader-writing code with a copy of the correct output for
VEC4
which should always have been the only allowed case. As a precaution I put in a sanity check to disable skinning on a mesh in case an invalid format is ever found in this field.I tested this with the four old sample glTF 1.0 files, to confirm they all use
VEC4
, and yes, they do and they work correctly. I also briefly tested with a glTF 2.0 file, but I'm not as concerned there since the spec is a little tighter.I expect no change in behavior, this is just a simplification (and removal of untested, presumed-dead code for dealing with matrices of matrices).