-
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
Animation path syntax for objects referenced by nodes #1346
Comments
Node-relative and 'property' qualifier don't seem to be complete in your examples. Which primitive's material is targeted? Same problem if more than one light was allowed per node. This doesn't seem to generalize well. glTF already embodies a single object referenced multiple times. By this I mean the way that any number of mesh primitives can refer to one material, many materials can refer to a single texture, and animation channels targeting node properties from the top level (weights is the exception (and most interesting for this discussion why?)). Data is always at the top level. Node-relative paths don't really follow that pattern; they imply that the data referred to is unique and breaks this model. Further authoring tools such as Blender and Maya share this data view and an animation is authored is on a "global" value it changes anywhere that value is referred. |
These follow the existing
That's a really helpful point, thanks. Part of my concern here was "throwing away" information that would tell the the client it can reuse a material, but if DCC tools can't author it that way, there's nothing lost. Here are a few additional ideas then, more similar to your original suggestion:
These are more verbose than arbitrary JSON pointers, similarly expressive, and (maybe?) more backward-compatible. The spec would define interpretation of the types; it is not self-defining like a JSON pointer. |
A semantic where all primitives of a mesh match a target isn't expressive enough. Imagine having a skinned mesh that has some primitives that I want to animate material baseColorFactor and other primitives I don't or with a different track. This form suggests that I would create independent nodes to target those material instance at once. Because of that I'd need to create a separate skeleton and pair the channels for skeletons for the animated material and the unanimated material mesh parts. The primary reason I like JSON pointers is it allows a glTF extension to define its own animatable properties without having to create additional schema and objects. In your light example above you don't reference KHR_lights it seems its implicitly added somewhere. How would a vendor extension allow targeting its properties which are allowed and which aren't? It seems like both JSON pointers and "type" enums would both just declare it in their extension document similar to how MSFT_texture_dds does for mimeType. Before we can narrow in on a syntax we like we should agree on if we are targeting as objects cloned at their node (weight style) or are we target top level objects (TRS style). |
FWIW, it could be specified per-channel: someone may need to apply the same animation to all instances of the top-level object. |
Ok, I'm happy to eliminate
Your point stands regardless, but note that two meshes can reference the same skin.
I agree that glTF extensions should not have to define additional schema for this, but if some one-time additions to the schema like
In any case a vendor extension should define which properties may be targeted and which cannot. I feel pretty strongly that if we can't enumerate animatable properties, we can't expect engines to implement consistent support.
Yes, I think both are similar in that respect.
I'm not sure what you mean by per-channel? A channel could say that animation applies to just one instance of a material, or to the shared top-level material? That seems too flexible, I think, as having just top-level object animation enables the same features with less complex implementation. |
Something like:
I wonder if something like a object clone indicator would be helpful for clients.
This way the node channel targeting wouldn't be needed; the path would just index the cloned material. |
In what context do you mean backward-compatible? Are you referring to having something in v.next that is still parseable 2.0 parsers? I'm assuming this just in the context of a 2.0 extension where we can redefine channels and targets in our extension object. |
I mean that a channel could target, e.g. material "prototype" or material "instance" (as in @najadojo's example above). DCC tools usually support flexible bindings. Also, targeting "prototype" may work as runtime optimization so that engines have some guarantees and don't need to clone animated objects. |
Even in an extension targeting glTF 2.0, it is preferable to allow the extension to be "optional". If the type of an existing property is changed, I think the extension would always need to be included in |
This why #1301 has its own channels list, no types are changed. |
I think this discussion is above but the current format has issues. Wouldn't it arguably be more open if the format changed to something like
Then based on
Where as now as you expand to new types of animation you have to just special case a bunch of stuff
|
The currently supported values for
channel.target.path
aretranslation
,rotation
,scale
, andweights
. All of these are properties unique to the mesh itself, rather than properties of referenced objects like materials, cameras, or lights.Eventually we will want to support animation of other properties (light intensity comes to mind), and will need to adopt a forward-compatible syntax for that. #1301 by @najadojo proposes one possible syntax, as part of an extension adding support for animating a broad variety of properties. I'd like to separate the syntax question from that PR and discuss it here — a universal property animation extension has a lot of moving parts and is something I want to consider cautiously, but I am confident that some property animation is needed eventually, and having a syntax agreed upon would allow us to more easily include animation from the beginning in future extensions like
KHR_lights
.The proposal from #1301 relies on JSON pointers to reference the affected object without going through a particular node, like:
Some other syntax ideas:
These all have tradeoffs:
The text was updated successfully, but these errors were encountered: