It looks like APEX has a curve solver (like vex does), but anyone knows exactly how to make it work?

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.

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?

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.

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.

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.

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!

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?

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)?

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

Oh okay... I completely misunderstood. I thought the four points were control points of the curve.

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?

Bump this. Can't figure it out either.

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.

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.

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.

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.

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?

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.

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).