Small mesh/armature/animation improvements #31
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This removes support for skinning.
…r an unexpected type
of the Blender camera, while the `aspectRatio`, if present, affects the resolution instead of the `angle_x` (since the latter is computed from the `angle_y` and the resolution in Blender)
...using just one cache-lookup function instead of one for every different type of object.
RGBA vertex colors are supported (required) by Blender 2.79 it appears.
Based on creating first a virtual forest that mirrors the scene graph we're about to create in Blender. Details to be documented later... if it works out :)
Skinning is now working (again (again))...
Messy and VERY slow for the moment, but functional so I'm commiting it for my own reference.
Comments explained the main reasoning behind the bone function. Also switching from keyframe_points.insert to the add/co loop gave a **huge** performance boost.
This is for faster slicing. This doesn't make any apparent impact on import times but hopefully it saves some memory ^^;
...because 4-component vertex colors are assumed. Should we use some shims to papers over the Blender version differences and get greater support? I don't have access to !=2.79 vresion atm though so it doesn't matter for now.
They don't point the right way or anything but they're there :)
But have an option to just put everything into the current scene too (I like that better).
This prevents loading the same one multiple times.
Using the groups from the exporter, thus relieving us form writing all our own node groups. The group for Specular Glossiness is also part of the serialized data, so supporting that is getting closer.
We add superfluous COLOR_0 layers to any mesh that uses a material that is ever applied to a primitive that has a COLOR_0 attribute. This let's us add an Attribute node to those materials without the problem of solid red colors coming in. COLOR_1, etc. are still not supported (well, they're imported of course, they just don't influence the materials).
- Avoid creating dummy vnodes for meshes when possible. - Rotate cameras to their (correct?) position - Some slightly tighter docs. - Some more robustness in realizing vnodes; it would probably be possible to use an armature for the whole forest again with minimal code changes
Animating non-bone locations should work now. Curve clean-up should be working too.
The vtree beneath an armature should now be all bones except possibly at the leaves, and we should realize them correctly(?) now. Also fix a typo with mesh names.
Avoids confusion with the similarly named node_groups stuff.
Support for pbrSpecularGlossiness was added here too.
Such as they are, anyway.
...by using multiple attributes sets. We anticipate here, since though there is a PR for this, it hasn't been merged into the spec yet.
If the accessor was used again later in the glTF, we would have seen a modified array since we hard-modified the accessor elements. Avoid doing this.
If the joints were eg. [0,0,0,0] and the weights were [1,0,0,0], previously we would overwrite the weight for 0 three times so it ended up as 0. Now it will correctly be 1.
We hardly have to do anything since Blender will already handle DDS textures so we might as well. Untested though.
Untested.
I initially thought the pose TRS was computed from (final TRS) *
(rest TRS)^{-1} (ie. the opposite order of multiplication from what
I now believe is correct.) Under this scheme, the pose components
could depend on multiple final components, which required bringing
the curves under a common domain. But under the correct order of
multiplication each pose components depends only on its corresponding
final component (and the rest TRS) so that turns out to have been
over-complicated and, thank God, we can finally get rid of it!
Though, alas! it does not fix Monster.
This ensures that COLOR_0 is always the first (and ensures Blender thinks its the default, for eg. TEXCOORD_0 and UV maps?) and avoids any gaps in the sequence of X.
- Pick better bone lengths (when the bones are rotated the armature actually looks plausible now) - Report a warning when bones had non-unit scalings in the glTF
Also fix a typo that mysteriously did not prevent Blender from figuring out what the fcurves were targeting.
For example, try rotating the bones in CesiumMan or Monster by 90d in the X direction to get the skeleton to look correct. I am somewhat uncertain of the math for this.
See KhronosGroup/glTF/issues/1395. Observe the difference in AnimatedTriangle or the low-poly fox.
Just so the user knows. Very minor, theoreteical fix for bone lengths too.
The restriction about overlapping armatures is lifted and we no longer require a skeleton property.
This makes it more like what you'd by adding keyframes by hitting I
Fix a typo that created superfluous actions. Always make the first animation the one that plays by default. Fix setting of the default action on armatures. Don't let Blender delete unused actions.
Merged
ksons
added a commit
that referenced
this pull request
Oct 17, 2018
ksons
added a commit
that referenced
this pull request
Oct 17, 2018
|
Reverted as I squashed the history which makes it difficult to merge the subsequent PRs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@ksons Something bad happened when you merged the last PR and you lost the git history and people like cinghiale didn't manage to get credited as contributors. It made it really difficult to merge master into this branch and it's also why Github is listing all the commits from the last PR again. This PR has all the history intact so if you can do a normal merge this time that should be fixed 👍