-
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
EXT_animation_map extension proposal #1137
base: main
Are you sure you want to change the base?
Conversation
Awesome! We'll help spread the word to get you some feedback. |
Related collada extension already available (maya) https://www.khronos.org/collada/wiki/Animation_clip_OpenCOLLADA_extension |
In your example you mapped two animations (0 and 3) to the "enter" semantic. In such case (multiple animations mapped to the same semantic) how the animations will be played:
|
@pjcozzi We need to register |
@space2 I added some clarification. I believe they should all be played at once, though we could add a type modifier to allow you to play them in sequence, or random if desired. I think playing at once default is good because you could imagine a glTF scene with multiple meshes and a separate animation targetting each. @lexaknyazev by "object" i mean a literal json object in the array, not a glTF object. Is there a more clear term i could use here?
What interpolation would there be? Since there is 0 time between the last frame and first frame i would assume no interpolation.
I think so. Do you see any problems with that? I could see this being useful if we add the 'sequential' play modes suggested by @space2, so that you could have multiple sequential animation lists. |
also how does naming prefix work? This is an extension proposed by us at FB but i don't think there's anything FB specific about it. |
@lexaknyazev @space2 perhaps we should default to sequential playback of the animations in each binding object animation array, and just let people add multiple entries for one semantic to play them in parallel. |
My question is about this "object":
Does it mean the whole scene? Or should implementation perform lookup from
That means that for looping animations, the first and the last frames must have the same values, right? |
Ah i see, yes that is unclear. I was assuming the target of the animation channel but now that i think about it that could add undue complexity to the clients (for an animation that targets a bunch of bones, and we expect clients to union all those bounding boxes for those bones meshes). Perhaps it would be better to supply a target Node for any animation with interactivity?
Yes i think that's up to the animation author to create properly looping animations, i don't think it should be the job of the engine to try to fix that. I could also imagine a non-seamless animation, think a bubble that rises from the ground over and over again, and it looks like a new bubble each time. |
Yes.
There was an effort to add pre-computed bounding boxes to skinned meshes. Maybe we should revisit that. |
I added an optional
Does this seem satisfactory? Pre-computed bounding boxes seems very useful, we're already fighting some performance problems trying to compute things on the client (we will get around this by pre-computing it on the server but it would be nice to have it already available in most models). |
Please use plural for array ( I assume that any node from that list should trigger the animation, since it could be difficult for user to, e.g., grab 3 objects at the same time. On the other hand, there could be use cases for simultaneous conditions (e.g., gaze at several objects at once). |
updated. that assumption is correct, i specify that any node can trigger the event. The use case for simultaneous conditions can be added later with another property (simultaneous: true or something) but i think we can leave that out for simplicity now. |
See #1139
@msfeldstein a vendor prefixed extension like For this extension, it is very likely that engines like three.js, Babylon, and Cesium would be interested in implementing it so we might end up wanting to use the |
"animations": { | ||
"type": "array", | ||
"items": { | ||
"type": "number", |
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.
number
-> integer
"nodes": { | ||
"type": "array", | ||
"items": { | ||
"type": "number", |
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.
number
-> integer
To follow existing glTF schema usages, please consider adding these properties to
|
@sbtron will be reviewing with the rest of the working group when they begin meeting again next week |
Excellent let me know if you need anything from me
…On Tue, Mar 27, 2018 at 11:17 AM Tom Mignone ***@***.***> wrote:
@sbtron <https://github.com/sbtron> will be reviewing with the rest of
the working group when they begin meeting again next week
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1137 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJ1b993J-36U1lm0hcxplnf_WcAK_Ztks5tioIngaJpZM4QLzIM>
.
|
The extension spec says
Does it mean that in the case like the following one all four animations must be playing at the same time? If so, the description should be more sound. {
"extensionsUsed": {
"EXT_animation_map"
},
"extensions" : {
"EXT_animation_map" : {
"bindings": [
{
"semantic": "ENTER",
"animations": [0, 3]
},
{
"semantic": "ENTER",
"animations": [1, 2]
}
]
}
}
} |
yes, it looks like you're applying 4 animations to the ENTER semantic. I'm not sure how to change the description for clarity do you have a suggestion? |
Just wondering, has this been added to Facebook? If so, is there any documentation on how to apply animations (armature / vertex) and incorporate it into a GLB for Facebook? |
@punkoffice No, Facebook does not yet support animation from the core glTF spec. This extension (not required for animation in glTF) in particular should not be implemented unless and until it is out of draft status. |
I created a test asset semantics.zip to exercise the implementation of this extension in Windows Mixed Reality. |
It's implemented in Windows MR home?
…On Thu, May 31, 2018 at 4:54 PM Jamie Marconi ***@***.***> wrote:
I created a test asset semantics.zip
<https://github.com/KhronosGroup/glTF/files/2060503/semantics.zip> to
exercise the implementation of this extension in Windows Mixed Reality.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1137 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJ1b6t5it3wTSrriOzgXiiEamKG1IjYks5t4ILGgaJpZM4QLzIM>
.
|
Yes we added it in our most recent update. Capabilities documented at https://docs.microsoft.com/en-us/windows/mixed-reality/creating-3d-models-for-use-in-the-windows-mixed-reality-home#animation-guidelines |
Now that there is a shipped implementation, what can we do to finalize and solidify this extension? @sbtron |
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.
Because the scope here is narrow and multiple vendors are interested in implementing, I think my concerns above can be considered resolved.
This extension is unusual compared to many others, in the sense that most of its implementation details are left undefined. That's OK with me, as I assume it will be most useful for application-specific situations, and we're guaranteed that models using the extension will load fine in engines that don't support it. But still, we should try to track and codify standard semantics and their use, if that seems to be turning into a pseudo-standard of its own.
* **LEAVE**: Trigger a single shot animation as the object is leaving the scene or viewport | ||
* **ALWAYS**: Constantly loop an animation | ||
|
||
The following semantics require a list of glTF Node objects to specify interaction targets. The event is triggered by acting on any of the nodes listed. If the nodes are omitted, it can be assumed that the entire glTF Scene is the target. |
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 find this confusing — the section is labeled "example semantics", which leads me to believe it is not normative, but the language here claims these semantics "require" a list of nodes and presumably must be used in a particular way.
I'm guessing that none of this section's content it is meant to be normative, but either way I think this should be spelled out somewhat.
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.
Ah i see the confusion here. The semantics above can operate without any target nodes since they act on the entire object, whereas the ones below need some more info (which nodes to act on). Perhaps better wording would be "Semantics can have a list of nodes indicating which nodes the semantic should act upon if needed". Lemme try to rewrite this
"type" : "object", | ||
"definitions": { | ||
"semanticBinding": { | ||
"type": "object", |
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 not sure how to read these schema definitions so I'll just ask... can a bindings object have extras
?
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 believe anything in a gltf schema can have extras right?
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 that case, semanticBinding
definition needs to contain
"allOf": [ { "$ref": "glTFProperty.schema.json" } ],
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.
done, thanks
@donmccurdy thoughts on these changes? open to other wordings. It might also make sense to formalize a subset, things like ENTER/LEAVE/ALWAYS are very simple, and useful in almost any context i can think of, while things like GRAB are only for vr-with-hands and probably not ready to be formalized. |
actually after talking to @sbtron it sounds like it might be better to formalize the semantics listed, and let any other usages be considered non-normative, updated the spec to be stronger in that wording |
In Windows MR we now have the ability to specify an animation reset state on the binding by appending |
ah that might be worth specifying in spec (your addition makes things like enter animations not-compliant). Can you elaborate on what those suffixes mean? I assume DONT_RESET means to hold the final frame of the animation when it finishes, which would be good to add a how does RESET_ON_START work? CSS calls this animation-fill-mode:forward, THREE calls it clampWhenFinished:true |
The reset refers to the key frame time. When the suffix is |
Honestly i don't have enough info about exactly how this should work, i figured things like an ENTER animation will have its final frame match the rest position, so i didn't consider something like this. Perhaps we can move that to a separate property or extra and try to finalize it later? |
An extra is fine for this data but it highlights "semantic" is only meaningful in the context in which its applied and custom values should be allowed. That is unless we more completely define the semantics and how they apply to different client conditions. For example I assume ENTER, POINTER_ENTER, and GAZE_ENTER all mean the same thing to the FB feed viewing of a glTF. What does PROXIMITY mean in that context or any 3D in 2D context? I'd also like to have a way that we can extend semantics easily. say if we want to use a joystick or other gesture to start playback. |
ENTER means the model has entered the scene, POINTER_ENTER is a user
interaction. Would it be clearer if i renamed ENTER to APPEAR?
…On Tue, Jul 10, 2018 at 12:03 PM Jamie Marconi ***@***.***> wrote:
An extra is fine for this data but it highlights "semantic" is only
meaningful in the context in which its applied and custom values should be
allowed. That is unless we more completely define the semantics and how
they apply to different client conditions. For example I assume ENTER,
POINTER_ENTER, and GAZE_ENTER all mean the same thing to the FB feed
viewing of a glTF. What does PROXIMITY mean in that context or any 3D in 2D
context? I'd also like to have a way that we can extend semantics easily.
say if we want to use a joystick or other gesture to start playback.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1137 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJ1bxN6I9GNlQ0yDBwGL9KsZG3Gt5Hhks5uFPpsgaJpZM4QLzIM>
.
|
@donmccurdy are we close to being able to merge this as a draft? |
I'm not opposed to merging this as a draft, but not sure whether the thread above is resolved. Will leave that to @msfeldstein and @najadojo, fine to merge when they're ready. Some of the suffixes, e.g. Also wondering if it might be worth following vertex attribute semantics in requiring application-specific semantics to be prefixed with a |
It sounds like @najadojo is cool with moving the suffix stuff to an extra property which would unblock that. The underscore suffix for non-standard semantics seems fine. @najadojo you ask "For example I assume ENTER, POINTER_ENTER, and GAZE_ENTER all mean the same thing to the FB feed viewing of a glTF. What does PROXIMITY mean in that context or any 3D in 2D context?" ENTER is different from POINTER_ENTER and GAZE_ENTER, pointer enter and gaze enter don't mean anything in the feed context since there is no pointer or gaze. It should just be ignored. Same with PROXIMITY, if you're not in ar/vr or have some other way to understand proximity then that animatino would be ignored. |
@msfeldstein @najadojo is this extension in use at Facebook? Is this PR ready to merge or does it need more discussion or changes? |
It hasn’t shipped in any products at Facebook. I believe Microsoft is using
it however
…On Fri, Jan 25, 2019 at 2:10 PM Patrick Cozzi ***@***.***> wrote:
@msfeldstein <https://github.com/msfeldstein> @najadojo
<https://github.com/najadojo> is this extension in use at Facebook? Is
this PR ready to merge or does it need more discussion or changes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1137 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJ1b1EV6UjzOdHudyEa3EtOHVvssLxSks5vG4DYgaJpZM4QLzIM>
.
|
That is correct Windows Mixed Reality is using this extension. Though we do have some current limitations and modifications that are not part of this extension description. Our documentation can be found at Animation guidelines. |
Thanks for the quick response, @msfeldstein @najadojo!
@sbtron @najadojo do you think someone at Microsoft would be willing to update this so we can merge it? |
I'd like to propose an extension we use at facebook to mark up animations to have semantic meanings, so client applications can know what to do with all the animations packaged inside a model. The simplest use case is to target an animation to be the 'enter' animation, and clients will know what to play when the model first appears (think a flower opening, or person waking up). More complicated use cases could be specifying idle/walk/die/birth animations for game assets.
It would be wonderful if this could be shared across the ecosystem so models can be more dynamic without requiring scripting.