-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
proposal for morph & interaction with skin #164
Comments
I'll start on this next week |
@kmammou thanks Khaled, can you open a specific issue to track this ? Also we will make sure to integrate morph compression but to provide a better answer we need to implement/specify this first with raw data in glTF. |
done |
No this is is not a duplicate :) this is to track the morph feature raw (i.e) the base proposal without compression. #165 is with compression. |
Ah, OK. |
Any updates here? No rush, just trying to keep my implementation moving. |
Tony's working on it, had some recent emails with him, I'll send them over to you. |
Morph proposal imminent... meantime here is the recap of our conversation on the interaction between skins and morphs: For simplicity, I suggest we keep "instanceSkin" for a skin applied to a mesh, and add an "instanceMorph" property at the same level (as property of the node). There can be interactions between a morph and skin applied to the same mesh, so we need to specify what that interaction is. In COLLADA the spec suggested that an implementation apply the morph transformation(s) first and then do the skinning. I recommend we specify the same semantics for glTF. This is good for many animation scenarios, but some packages (like Poser) actually allow the order to be changed (e.g. skin first, then morph). I would like to add this capability after version 1.0. For ultimate flexibility, we could allow glTF to store an array of controller transformations on each node, perhaps with the order being implicit based on the order of the array, perhaps instead using some kind of ordinal. Other properties may also need to be supplied; this area is very TBD. We could do this in a backward-compatible way by simply adding a "controllers" or "animations" property to the node, that contains this information. "instanceMorph" details coming soon (tomorrow hopefully) |
@tparisi do we have example JSON for |
no - later today. |
Related to #210 |
@fabrobinet post 1.0? |
Is this a good example of a node instantiating a morph with skinning ?
I agree with Tony on that we can assume the morph to be applied first followed by the skinning. |
Updated in #826 |
over to Tony
The text was updated successfully, but these errors were encountered: