Hello,
I am running into an issue with the way the Face Graph is rebuilt whenever the facefx_poses.fbx and/or Batch-Export.txt is updated. I am using FaceFX Studio 2015.2.
Right now I am using a few FXCombinerNodes to add a constant value to some of the blendshapes on an actor (One of them is a squint, so I'll use that as an example.) This process seems to work just fine (The FXCombinerNode adds a constant value to the squint FXMorphTargetNode) until I update the facefx_poses.fbx, then the Face Graph rebuilds while synchronizing and connects every bone pose node in the graph into the squint FXMorphTargetNode. I was able to recreate this behavior with a simple test rig and a new actor in FaceFX. Anytime I connect an FXCombinerNode to an FXMorphTargetNode, when it will rebuilds it connects every bone pose node in the graph to the FXMorphTargetNode the FXCombinerNode is connected to. I can get around this by disconnecting the FXCombinerNodes I've added, updating the facefx_poses.fbx or Batch-Export.txt, then reconnecting the FXCombinerNodes, but I'd prefer to keep undo and redo steps out of the pipeline if possible.
I realize I can't just tell it not to rebuild because it needs to make the new connections for the updated poses from the facefx_poses.fbx or Batch-Export.txt, but is there any way to control how the Face Graph is re-built so I can tell it not to add all these extra connections?
Thanks!
In your picture, "Up", "Down", "Left", "Right" all drive the "Mesh_Top" morph target. This is because the "Mesh_Top" morph is driven in your FBX file on the frame numbers that define "Up", "Down", "Left", "Right".
It sounds to me like you want to control this some other way, (with the "Top Add" combiner node) so that "Up", "Down", "Left", "Right" do NOT drive the morph directly. Is that correct? If so, your best bet will be to edit the FBX file so that Mesh_Top is not driven in these poses (Set a key at 0). You can then manually add whatever setup you want in the face graph, and updating the FBX file will not change it.
You don't have too much control to do this some other way. The Scripts/FBX Importer/FBXImporter.py file has a subroutine _create_poses that is internally calling the exportframe command. Internally, this command will recreate the bone pose name specified in your Batch Export text file, and it will disconnect all links that originate from the bone pose node and terminate at morph target nodes. It will then link up only the morph nodes that are driven in the FBX file at that particular frame.
Because all of this happens internally in the exportframe command, you don't have any options as far as not performing the face graph linking operations. So I would modify your FBX file to remove the driving of the morph target instead.
Thanks for the reply! Yes that is correct, I'd like for the bone poses to not be driving the morph target node, but I don't have any keys on the morph targets in this test and they still get connected when I synchronize with the .fbx. I tried keying the morph targets to zero on frame 0, and keying them to zero on each pose's frame, I also tried checking bake animations off in the .fbx export from Maya just in case that was baking keys for those morphs on frames I didn't want it to, but had the same result with the bone poses being connected to the morph target node.
In trying different steps I did find something else though, this only happens if the FXCombinerNode is set to use a link function of Constant or OneClamp. With any other link function it doesn't connect the bone poses and the morph target node. Is there something different about connections using those link functions that would cause them to be rebuilt differently?
OK, I understand what you are experiencing now.
The export frame command is used to create the links, and it evaluates the state of the character at the current time, and it figures out which morph targets are active. It then creates a bone pose with the name supplied by the -name parameter, and creates links to the morph targets to reproduce the active morphs.
Normally the only source of morph target values comes from the ogre animation derived from the FBX file. In your case, the constant link function is creating a secondary source of animation data that we didn't anticipate when creating this system. When the exportframe command is called, it *always* thinks that the morph target is active at the current frame, so it is always creating a link to it.
I can't think of a solution to this problem other than to remove your constant link functions prior to updating the FBX file, then "reinstating" it after the FBX update is complete. If you plan on updating your FBX file a lot to iterate on how the morph targets are driven, the best solution might be to add these steps to the FBXImporter plugin so that they are automatically executed.
If you don't plan on updating your FBX file to get new values for the morph keys, you can just delete your path to the Batch export text file from the FBX Import options dialog. That will make sure that the exportframe command isn't called even if you do iterate on your FBX file to say update which vertices are moved in a morph target.
That would explain it! Thanks for looking further into this issue and following up with me, I'm glad to know what was causing that behavior. I think it is more likely I will be iterating and adding new poses to the Batch-Export.txt than changing the poses that are currently in it, so I will look into the FBXImporter plugin's files and see if I can find a good place to plug in that extra disconnect and then reconnect.
Thanks again!