APEX Curve Solver?

   3186   22   5
User Avatar
Member
274 posts
Joined: March 2011
Offline
It looks like APEX has a curve solver (like vex does), but anyone knows exactly how to make it work?
User Avatar
Member
274 posts
Joined: March 2011
Offline
I've managed to make the curveIK to work, but I'm not sure it's use, since it doesn't seem to be used as KineFX's curve solver.
User Avatar
Member
213 posts
Joined: June 2023
Offline
guilhermecasagrandi
I've managed to make the curveIK to work, but I'm not sure it's use, since it doesn't seem to be used as KineFX's curve solver.

What do you mean and how you make it work?
User Avatar
Member
274 posts
Joined: March 2011
Offline
kodra
guilhermecasagrandi
I've managed to make the curveIK to work, but I'm not sure it's use, since it doesn't seem to be used as KineFX's curve solver.

What do you mean and how you make it work?
At least I thought It was (almost) set correctly, but not sure. A lot of guesswork going on here.
Edited by guilhermecasagrandi - Dec. 6, 2023 09:38:33

Attachments:
curveik.png (246.9 KB)

User Avatar
Member
1 posts
Joined: Oct. 2017
Offline
You can use RunVex node to call solvecurvejoints(). But you need to include entire source with all dependencies because the snippet does not support #include <kinefx.h>.

I would like to know if there is a proper APEX way to do this. Specifically I need to setup a non-stretching spine.
User Avatar
Member
274 posts
Joined: March 2011
Offline
barabanimator
You can use RunVex node to call solvecurvejoints(). But you need to include entire source with all dependencies because the snippet does not support #include <kinefx.h>.

I would like to know if there is a proper APEX way to do this. Specifically I need to setup a non-stretching spine.

This curve IK should do that if I'm not mistaken. Just don't know how to use it.
User Avatar
Staff
64 posts
Joined: May 2021
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!
User Avatar
Member
274 posts
Joined: March 2011
Offline
esttri
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!

Good to know, thanks. Do you have an ETA for the fix?
User Avatar
Member
448 posts
Joined: Aug. 2019
Offline
I'm still quite confused. The CurveIK nodes takes 4 points as input, and output 4 points?

How does it make sense? I thought it should output a curve (point array)?
Edited by raincole - Dec. 31, 2023 10:42:46
User Avatar
Member
8617 posts
Joined: July 2007
Offline
raincole
I'm still quite confused. The CurveIK nodes takes 4 points as input, and output 4 points?

How does it make sense? I thought it should output a curve (point array)?

well, it takes any number of input matrices and outputs any other number

even though I agree that an array output would be more procedural and I assume it'd be easy to add in the future, but I assume based on the talks that the current intention is to defer procedural layer to be in the Builld Graphs which would generate rig with specified amount of output transfomrs rather than having the rig logic running a for loop over an array for example
Edited by tamte - Dec. 31, 2023 10:58:50
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Member
448 posts
Joined: Aug. 2019
Offline
Oh okay... I completely misunderstood. I thought the four points were control points of the curve.
User Avatar
Member
448 posts
Joined: Aug. 2019
Offline
I spent a lot of time trying to recreate what guilhermecasagrandi did but I just can't make it work.

So far it just takes some points as input and output identity transforms. None of its inputs does anything. Changing curvedoes nothing. Changing curvexformdoes nothing. No error or warning.

I really wonder how you guys discover how to use these nodes... Could someone provide an example .hip?
Edited by raincole - Jan. 3, 2024 06:25:10
User Avatar
Member
213 posts
Joined: June 2023
Offline
Bump this. Can't figure it out either.
User Avatar
Staff
64 posts
Joined: May 2021
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.
User Avatar
Member
213 posts
Joined: June 2023
Offline
esttri
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.

Sorry, I still don't get it. Actually I don't get it at all. The CurveIK's inputs are:

- a geometry (curve)
- a single xform (curvexform)
- any number of xforms

So the "any number of xforms" are driver xforms. What are driver xforms of a curve? Like a NURBS' control points? Breakpoints? A Bezier's control points?

And what curveshould be? A curve primitive? A polyline?

And what the single xform curvexformis for? The curve's global transformation?

You meantioned "curve order". Which input determines this? There isn't an int input called curveorder or something.

There are 3 inputs and I don't get even one of them. Honestly a single working .hip here would be worth more than a thousand words.
Edited by kodra - Jan. 22, 2024 12:05:35
User Avatar
Staff
64 posts
Joined: May 2021
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.
User Avatar
Member
213 posts
Joined: June 2023
Offline
Oh okay, I see. I'll take a look at the newer node. Thank you.

That being say, I still think APEX can benefit from a node that doesn't solve as a spline, but as a typical cubic bezier curve (where a segment is decided by two end points and two control points). It might not be as general as a spline, but I think UI-wise cubic bezier curve is the most understood thing across animators.
Edited by kodra - Jan. 22, 2024 21:09:37
User Avatar
Member
10 posts
Joined: April 2021
Offline
A little Bezier-rig based on kodra's suggestion.
I currently build this completely using one vex node (inside the apex graph).
I know it was mentioned before that vex would slow down the rigs. Currently this still updates with 120 fps. what is the best way to test my rig's performance? do rigs get more expensive as frames are added?
Edited by UtilitasArts - Feb. 7, 2024 12:09:31

Attachments:
BezierSpineRig.hiplc (665.5 KB)
Screenshot 2024-02-08 000746.png (775.9 KB)

User Avatar
Member
10 posts
Joined: April 2021
Offline
My issue with the rig::SplintInterpolateTransform is that the matrices flip for certain angles. and it's difficult to control this behaviour. this is something I tried to solve for my own rig. Here I have a video that shows the issue.

Attachments:
2024-02-08 00-31-44.mov (4.3 MB)

User Avatar
Member
213 posts
Joined: June 2023
Offline
esttri
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.

Is it possible to have evenly twisted resampled results from rig::SplineIntepolateTransforms? I always get this weird uneven twists (the middle part is twisted by 90 degrees, but the second xform is twisted by about 30 degrees).

Attachments:
Screenshot 2024-02-11 002545.png (546.5 KB)

  • Quick Links