unsupported animation target path weights

[wave-electron]

@kcoley

raise Exception('Unsupported animation target path! {}'.format(target_path))
Exception: Unsupported animation target path! weights

You can download this model from here. buster_drone glTF autoconverted format

To get this animation to build I removed the paths referring to weights in the glTF ascii file. However, the usda animation is distorted.

[kcoley]

Looks like this is an issue with morph targets not being implemented in this tool. I created an issue to track this feature request: https://github.com/kcoley/gltf2usd/issues/17

[wave-electron]

Great. Btw, I managed to get a simple transform animation created in Cheetah3d export to fbx file type and using the fbx2Gltf command tool build glTF file... which successfully converts to a usda file... animation also works as expected in Xcode beta6.

However, with another animation file using the same fbx conversion process the animation has mesh with scaling problems, the model is slightly more complicated but still a transform animation. I’m will try and reproduce the scaling issue and pinpoint what’s causing it.

[ox]

I am going to try to work on this, since I very much need these for one of my projects. Do you have any pointers for docs/methods to traverse? Or maybe a USD model with morph targets?

[kcoley]

@ox If you have some time, that would be great. Here are the docs on USD skeletons and blend shapes: https://graphics.pixar.com/usd/docs/api/usd_skel_page_front.html

And here are the glTF docs on Morph Targets: https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#morph-targets

@wave-electron referenced a model with morph targets in this issue, and I believe your carrot model also has them.
Here is a simple glTF sample model which also has morph targets and may be good to start with since it is simpler: https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/AnimatedMorphCube

[wave-electron]

@kcoley @ox Apple also has some sample python scripts for building usda files as part of their USDPython standalone library v 18.09. I have a live usdz example of skinnedMeshAnimation with weights.

skinnedMeshAnimation skinnedMeshAnimation.py.txt

Another Apple sample usda file soccerBall.usda.txt

[ox]

Reading the specs more I've found that there are two different kinds of weights in glTF: weights for morph targets and weights for joints. Weights for morph targets how much each BlendShapes affects vertices position, whereas weights for joints are the just how much each joint transformation affects the vertex at that point (WEIGHTS_0 in glTF). I think USD and glTF are very similar in how they do skinning though it seems glTF has stronger BlendShape support (USD doesn't support normal or tangent blends). This also makes me think #18 is a duplicate of this issue.

So first I would define a SkelAnimation for each Mesh (glTF Meshes can have multiple morph targets they blend between) with blendShapes. The tokens for the blendShapes would be each of the primitive's targets' accessor's names:

def SkelAnimation "skel-anim-a-mesh" {
  uniform token[] blendShapes = ["%(accessor[primitive.targets[idx].output].name)", ...]
  float[] blendShapeWeights = [0, ...]
  ...
}

Then for each Mesh to define BlendShapes using the vertices from the POSITION accessor (since USD doesn't support tangent or normal blends):

def Mesh "some-mesh" {
  def BlendShape "%(accessor[primitive.targets[idx].output].name)" {
    uniform vector3f[] offsets = <accessor[primitive.targets[idx].output].data>
  }
  ...

  uniform token[] skel:blendShapes = ["%(accessor[primitive.targets[idx].output].name)", ...]
  rel skel:blendShapeTargets = [<%(accessor[primitive.targets[idx].output].name)>, ...]
  ...
}

Could I define the following in the SkelAnimation to animate BlendShape weights per each target's input timestamp?

blendShapeWeights.timeSamples = {
  %(target.input.timestamp): [%(target.output[weightIdx]), %(target.output[weightIdx+1)],
  ...
}

Does USD just let you define .timeSamples for any property to let you animate it?

Does any of this sound right?

[kcoley]

@ox

This also makes me think #18 is a duplicate of this issue.

Yes, this would be a duplicate of #18 . And glTF does provide more options in terms of representing the blend shape data so some intermittent steps may need to be done during export to USD.

Could I define the following in the SkelAnimation to animate BlendShape weights per each target's input timestamp?

Yes, that should work theoretically.

Does USD just let you define .timeSamples for any property to let you animate it?

Yes, USD lets you animate any primvar, or primitive attribute property. You can even introduce new variables and animate them, though they will probably be ignored by USDZ in terms of working in ARKit

[ox]

@kcoley Could you elaborate more about what intermittent steps might need to be done? The thing that comes to mind is re-calculating normals since they are not blendable, but I might be wrong.

[ox]

So after a bit of fiddling I got far enough where I embed the Mesh in a SkelRoot, define a SkelAnimation on it, make BlendShapes on the Mesh and link everything up: gist. I think the next thing I need to do is map the output of the targets to the blendShape they affect. My changes are in progress on this branch.

[kcoley]

Hi @ox . Looks great! I'll check out the branch this weekend.

[ox]

Ok, so after a bit more work I managed to:

• correctly align blendshape names so they match in the SkelAnimation-defined names and those targeted in each Mesh's blendShapes token uniform
• correctly managed to fetch multiple blend shape weights for each keyframe by passing in the ratio of outputs to input frames

Check out the gist to see a USDA of the AnimatedMorphCube gltf model.

[kcoley]

@ox does the usda animate on your end?

[ox]

@kcoley It should but for some reason the timeCodes are wrong. It's not even rendering a preview for the model, but I think that might be the timecodes

[ox]

It doesn't seem to be just timecode related. Any kind of blendShape stuff seems to break the iOS renderer.