The set point transforms node is very handy everythin on a run time setup (aka your resulting rig) where performance is key. It will set all the tranform values for a given skeleton in one go. The given variadic input ports need to match with their name the given joint that the xform is supposed to affect. You are right though in case of a component script you actually need a different node. You can use can achieve the same right now with 2 nodes. skel::FindJoint --> that one gives you the joint num based on a given name string. That one can be easily promoted as a component script input. then you use the ptnum that you just got together with skel::UpdateJoint. Here you can now now update your xform value
I will add to our todo list that we add a single skel::SetPointTransform callback that allows to set a sing transform based on a name input, just to be in symmetry with skel::GetPointTransform and to make those steps a bit more convenient.
Found 25 posts.
Search results Show results as topic list.
Rigging » APEX Set Point Transforms Question
- esttri
- 61 posts
- Offline
Rigging » APEX Control Extract - no data
- esttri
- 61 posts
- Offline
alrighty i checked out the file.
The APEX Control Extract node seems to be doing what its supposed to to do. And so does control update.
The problem that you are running into seems to be more connected with the orientations of the joints of your animation skeleton. I can see that the orientation from your animation from frame 1 which you use for the rest is very different to frame2. You can see this very clearly on the hip control. The control is not rotating up as expected. That means that the default rotation offset that you are defining with the rigmatchpose this off, the translations countering that apparently though in your input animation thats why it looks as if its correct. As soon as you visualize the orientation axis of the joints though you can see it.
The problem just gets visually enforced by controls that just have their rotation promoted. That means that just the mismatched rotation will get updated but the translation that counters it at least a bit can not be set. That explains those big offsets.
So the best place to start is to looks whats going on with the rotation of your input animation I think.
I really hope that helps
The APEX Control Extract node seems to be doing what its supposed to to do. And so does control update.
The problem that you are running into seems to be more connected with the orientations of the joints of your animation skeleton. I can see that the orientation from your animation from frame 1 which you use for the rest is very different to frame2. You can see this very clearly on the hip control. The control is not rotating up as expected. That means that the default rotation offset that you are defining with the rigmatchpose this off, the translations countering that apparently though in your input animation thats why it looks as if its correct. As soon as you visualize the orientation axis of the joints though you can see it.
The problem just gets visually enforced by controls that just have their rotation promoted. That means that just the mismatched rotation will get updated but the translation that counters it at least a bit can not be set. That explains those big offsets.
So the best place to start is to looks whats going on with the rotation of your input animation I think.
I really hope that helps
Rigging » Sharing some quaternion functions in APEX
- esttri
- 61 posts
- Offline
Rigging » UV/prim aware AbstractControl
- esttri
- 61 posts
- Offline
Hi there. Ah the range parms currently just work for x and y as inputs. The spare parms are currently not really being picked up.
Rigging » Multi Parent Constraint + Hybrid Spine IK
- esttri
- 61 posts
- Offline
Ah this is great! I will also check out the vex snippets and see that we can add the missing math callbacks
Rigging » APEX Curve Solver?
- esttri
- 61 posts
- Offline
I was referring to the rig::SplintInterpolateTransform node. As already mentioned I would recommend not relying on the CurveIK callback. this one is n old prototype that got replaced with the given node and. So curveIK will be depreciated.
Rigging » A question about packed folder filter syntax/control shapes
- esttri
- 61 posts
- Offline
Ah yes that case is simply not handled properly in the FindGraphElement subgraph in case of multi element entries. I can fix that. now the rule was that apex path patterns always require a / to indicate the current folder level even on top level folders. I am simply softening that rule for certain input parm cases without affecting the overall path pattern syntax. But I will bring the topic up if it rather makes sense to adjust the overall pattern.
Rigging » APEX Curve Solver?
- esttri
- 61 posts
- Offline
Hi Tamte is indeed right that we have those multi outputs in order to avoid slows array loops in our rigs directly.
concerning the curve solver. Having a look at it the last time i thought the node mentioned was the rig::SplineInterPolateTransforms node. That one is currently the more suitable solution to solve curves. We are using that for example for electras spline. Rig:CurveIk is still relying on an old prototype.
You can provide a number of input xform values. those will be your driver xforms. the given output xform that can vary in number are the driven values along the curve that is auctomatically generated between the given control xforms. the curve order determines the curve resolution and is also dependent on the number of driver xforms.
concerning the curve solver. Having a look at it the last time i thought the node mentioned was the rig::SplineInterPolateTransforms node. That one is currently the more suitable solution to solve curves. We are using that for example for electras spline. Rig:CurveIk is still relying on an old prototype.
You can provide a number of input xform values. those will be your driver xforms. the given output xform that can vary in number are the driven values along the curve that is auctomatically generated between the given control xforms. the curve order determines the curve resolution and is also dependent on the number of driver xforms.
Rigging » UV/prim aware AbstractControl
- esttri
- 61 posts
- Offline
Hi there,
a few more answers from my side. And sorry for the late reply, I am recharging batteries a bit and stayed away from my machine for a bit.
Yes the state manages indeed quite a large number of graphs and a lot of these graphs get created or modified on the fly. That keeps our viewer state flexible fast and light weight. Managing the actual execution via graphs is a big advantage for performance. When it comes to modifying the graphs we execute then its a bit different because we are not running that on every mouse drag on playback, so we have a bit more wiggle room. So you can modify all of those graphs either via python or via other graphs. both ways are legit. Some sections in the viewport are currently managed with python as has been correctly observed.
One of theses graphs that constantly changes depending on what you do in the state is the scheduler graph. That one manages which bits of graphs/rigs are evaluated when. It is in a way the control centre of your interactive state. That scheduler gets especially important as soon as you have dependencies between rigs, e.g. by using constraints. The order of invocations and the updating of the data is all being managed here.
The controls are indeed nothing but graphs that define how the ui event is interpreted and translated to parameters that the rig understands. And every time you interact with a control that control graph is in fact dynamically added to the execution in you scheduler. So first the control graph is being evaluates and updates your current rig input parms and then the rig is being run with the updated parms.
The abstract control and the transform control are currently hard coded in in terms of the management around them. The actual core of them is still just a graph though. The state might be more opened up in the future. Ideally we would support that without the user needing to change the state code. This is what i meant with the fact that we have it on our radar
Coming more to the abstract control and node properties. Properties are nothing but custom metadata stored as a dictionary per node. You can store anything you want there. When the state creates controls then some metadate can be read from the node properties that can help define how that control looks. Configure controls is in the end just updating that dictionary per control node. The configure control node definitely needs the helper card, ill keep you posted once its added early January, when I am back.
Here is a quick description of what you can use to change how your control looks like. A bit rough, but it should give you an idea 😊:
properties: - dict
control: - dict
shapeoverride: str, - defines the shape name you want to assign to you control. the transform control has some default you can choose from. you see them in the dropdown of the configure controls node, you can also provide your own to a character if you pack them up using the second input of the configure controls node.
color: - vector3, matrix, defines the color of your control as a normalized rgb vector
shapeoffset: - matrix4, defines an offset of the shape that allows you to adjust the transformation of the control to fit more to your character
more specific for the abstract control
properties:
control:
parms:
lock_range: - int: 0 or 1: defines if you want to lock the min and max range of you control or if you want to go above it
x_max: defines the max value for the horizontal drag, if lock range is to you can not set a value higher than that. Otherwise it will be used as an orientation for the range when you drag on the given control in the viewport
x_min: defines the min value for the horizontal drag
y_max: defniens the max value for the vertical drag
y_min: defines the min value that can be set using the vertical drag, aka the y value to connected it to in the abstract control node in the rig
a few more answers from my side. And sorry for the late reply, I am recharging batteries a bit and stayed away from my machine for a bit.
Yes the state manages indeed quite a large number of graphs and a lot of these graphs get created or modified on the fly. That keeps our viewer state flexible fast and light weight. Managing the actual execution via graphs is a big advantage for performance. When it comes to modifying the graphs we execute then its a bit different because we are not running that on every mouse drag on playback, so we have a bit more wiggle room. So you can modify all of those graphs either via python or via other graphs. both ways are legit. Some sections in the viewport are currently managed with python as has been correctly observed.
One of theses graphs that constantly changes depending on what you do in the state is the scheduler graph. That one manages which bits of graphs/rigs are evaluated when. It is in a way the control centre of your interactive state. That scheduler gets especially important as soon as you have dependencies between rigs, e.g. by using constraints. The order of invocations and the updating of the data is all being managed here.
The controls are indeed nothing but graphs that define how the ui event is interpreted and translated to parameters that the rig understands. And every time you interact with a control that control graph is in fact dynamically added to the execution in you scheduler. So first the control graph is being evaluates and updates your current rig input parms and then the rig is being run with the updated parms.
The abstract control and the transform control are currently hard coded in in terms of the management around them. The actual core of them is still just a graph though. The state might be more opened up in the future. Ideally we would support that without the user needing to change the state code. This is what i meant with the fact that we have it on our radar
Coming more to the abstract control and node properties. Properties are nothing but custom metadata stored as a dictionary per node. You can store anything you want there. When the state creates controls then some metadate can be read from the node properties that can help define how that control looks. Configure controls is in the end just updating that dictionary per control node. The configure control node definitely needs the helper card, ill keep you posted once its added early January, when I am back.
Here is a quick description of what you can use to change how your control looks like. A bit rough, but it should give you an idea 😊:
properties: - dict
control: - dict
shapeoverride: str, - defines the shape name you want to assign to you control. the transform control has some default you can choose from. you see them in the dropdown of the configure controls node, you can also provide your own to a character if you pack them up using the second input of the configure controls node.
color: - vector3, matrix, defines the color of your control as a normalized rgb vector
shapeoffset: - matrix4, defines an offset of the shape that allows you to adjust the transformation of the control to fit more to your character
more specific for the abstract control
properties:
control:
parms:
lock_range: - int: 0 or 1: defines if you want to lock the min and max range of you control or if you want to go above it
x_max: defines the max value for the horizontal drag, if lock range is to you can not set a value higher than that. Otherwise it will be used as an orientation for the range when you drag on the given control in the viewport
x_min: defines the min value for the horizontal drag
y_max: defniens the max value for the vertical drag
y_min: defines the min value that can be set using the vertical drag, aka the y value to connected it to in the abstract control node in the rig
Edited by esttri - Dec. 19, 2023 17:35:55
Rigging » UV/prim aware AbstractControl
- esttri
- 61 posts
- Offline
Hi there, oh that's a beautiful use of it.
Thats a very good suggestion and very much possible. The abstract control is actual also nothing but a graph that interprets the ui event and translates it to control parameters. We are intending to flesh that one a bit more out anyways. So creating a graph that relies on uv values for the closes point on a prim should be possible.
And we still have it on our radar to support completely custom control graphs in the future
Thats a very good suggestion and very much possible. The abstract control is actual also nothing but a graph that interprets the ui event and translates it to control parameters. We are intending to flesh that one a bit more out anyways. So creating a graph that relies on uv values for the closes point on a prim should be possible.
And we still have it on our radar to support completely custom control graphs in the future
Animation » Electra posing tutorial
- esttri
- 61 posts
- Offline
As of tomorrow's build the selection for controls that are pure wires should be more readable.
Animation » APEX Scene Animate's cache behavior?
- esttri
- 61 posts
- Offline
I think the problem you are encountering happens when you are dropping and apex animate node directly under an unpacked character. As far as i am understanding that is what you are doing, right? It should also work in that case, so yes, it is a bug. But for now the very easy way of getting it working, is to add your character via the APEX Scene Add Character node to your scene. Then the update behavior works as expected
Rigging » APEX and Python - how to find point from node?
- esttri
- 61 posts
- Offline
working with the functions of the graph object is definitely the right approach and that API should be stable. And yes that section will be documented
Rigging » (rant) UE style of nodes stacking is a bit weird
- esttri
- 61 posts
- Offline
There is in fact a third way to create rigs: You can use the python api if you do want to avoid using graphs to procedurally modify your rigs.
Concerning the mentioned point about name dependencies: We provide a pattern syntax that allows you to filter nodes based on custom metadata, such a tags, properties, connection status, node type etc. that allows more flexible connection setups, so you are not bound to the initial string identifier as your only filter source.
The rig script can be very likely still be optimized in terms of performance. We can look into that.
Concerning the mentioned point about name dependencies: We provide a pattern syntax that allows you to filter nodes based on custom metadata, such a tags, properties, connection status, node type etc. that allows more flexible connection setups, so you are not bound to the initial string identifier as your only filter source.
The rig script can be very likely still be optimized in terms of performance. We can look into that.
Rigging » (rant) UE style of nodes stacking is a bit weird
- esttri
- 61 posts
- Offline
kodra
And honestly that you need to load subgraphs via an undocumented python function is... ad hoc at best, abominable at worse.
We are aware that portability is still an issue with subgraphs that are more intended for a local use. Uou can load them every easily without the python scirpt by putting the subgraphs into your home dir in an a folder called apexgraph/ then the subgraphs will be automatically picked up similar to the otl/ dir. Its a bit of a different story when that dir is relative to your hip file which means that you can not preload that subgraph before opening the file itself.
When it comes to stacking nodes. Yes some of that graphs are still be packed to tightly, which is more based on ui change for the node editor. Meaning nodes are displayed bigger now and some of the older layouts are now squashed. We will get to them bit by bit though and stretch them more out for better readability.
Rigging » APEX Curve Solver?
- esttri
- 61 posts
- Offline
Ah yes, we are currently missing one additional input parm that needs to be exposed on the curve callbacks that will help with the fixed length!
Vex would be the less favorable solution because it creates quite the performance overhead and it can slow your rig down!
Vex would be the less favorable solution because it creates quite the performance overhead and it can slow your rig down!
Rigging » Apex Graphs docs
- esttri
- 61 posts
- Offline
- It looks to me that the workflow is to setup the parameter names and joint's names on the
point_transforms
(SetPointTransforms type node in the example)manually. If I have, say, 30 joints/controls and I need to setup them and then decide to change the naming, would it be a pain? Is this question even relevant cus we mostly need to useAPEX autorig component
? - The
bone_deformation (sop::bonedeform type)
Does it need a more descriptive name for the first 3 inputs instead of thegeoinput0
?
You would need some way to map your xform to joint and we can not just rely on the name of the transform object because your xform might actually come from other math nodes so going for the name as the parm alias is a very stable way of getting that mapping working. The component scripts are definitely a very helpful starting point when you translate your skeleton over to apex nodes and especially with in creasing complexity of rigs manually editing the graph will become quite cumbersome and a lot less flexible fairly quickly.
The geo bonedeform input names come from the sob verb and i am not sure how much we can do there directly but i very much get your point and I will see what we can do there to make it better readable!
Rigging » skeleton node missing option?
- esttri
- 61 posts
- Offline
That is a very good point and we have that on our radar. Its a bit of a bigger endeavor though.
Rigging » [SOLVED] autorig transformdriver joints orient issue
- esttri
- 61 posts
- Offline
Rigging » Apex Graphs docs
- esttri
- 61 posts
- Offline
-
- Quick Links