kodra
He meant a more direct way to call VEX in APEX, not relying on sop::attribvop.

I've submitted a RFE.

I talked to the apex team about that and they told me to avoid using vex inside apex since it would slow down the rig cook time.

guilhermecasagrandi

kodra
He meant a more direct way to call VEX in APEX, not relying on sop::attribvop.

I've submitted a RFE.

I talked to the apex team about that and they told me to avoid using vex inside apex since it would slow down the rig cook time.

I mean... for numerical operations and simple loops, sure... but aren't many SOP verbs compiled vex-based stuff anyway? So it makes no sense to me that we're supposed to call sop::XXX but not write vex.

That being said, I still don't know how to make my own SOP (HDA) a node that can be used in Apex. Not sop::invoke, but a node of itself. Does anyone have this figured out?

Frankly, I dont like the idea of Vex being the solution here - to me, it'd be more practical, if a APEX TransformOp node can do dynamic parenting (which is basically a dynamic Pivot) in the Viewer State.

THAT sounds more procedural to me, than the community sharing Vex snippets.

Thinking more as I type this out, if the TransformOp had some kind of soft radius (influencing packed primitive transforms) and that can also be limited to a specific axis, then, that'd be enough to do it.

usually this kind of rigs are easiest with history dependent constraints (sort of like lightweight realtime scrubbable "simulation" for individual constraints/transforms), which Houdini supports only in Blend Object, all new rigging incarnations (CHOP constraints, KineFX, APEX) are so far omitting those and are rather doing some hacky workarounds

since it's not only that you need "dynmic parenting" during the viewer state, you really need it during playback and the goal is to avoid hacks like stashing offsets and whatnot as that is a nightmare or impossible to edit, since any tweak to previous frames would misalign the stashed offset, etc.

Another approach could be storing all the configurations that you want for the entire sequence that you want to play back. Sort of like feeding a motionclip into the rig and telling it where to playback in the motionclip.

edward
Another approach could be storing all the configurations that you want for the entire sequence that you want to play back. Sort of like feeding a motionclip into the rig and telling it where to playback in the motionclip.

I get where you going with your thinking here…but, to me, we might as well keyframe everything and play that back, or its very similar to exactly as you described, KineFX + MotionClip(s).

When the FabricEngine guys wanted to get into rigging, I challenged Helge to the same standard, a Rubix Rig/Dynamic Parenting. What Helge came up with was exactly that, but, (as I’m trying to do here), it (the solution) had more utility than just a Rubix Rig. Helge showed the solution using a roller coaster - one control in viewer state twisted the tracks + all cars on the tracks, while another control in viewer state moved the cars along the track: demonstrating, the parent/pivot of the cars was based on the active control.

The innovation here is: proximal parenting in APEX

But Yes, you need a way to persist the manipulation across the timeline, cuz, no matter what, the end result is an animation.

TwinSnakes007
I get where you going with your thinking here…but, to me, we might as well keyframe everything and play that back, or its very similar to exactly as you described, KineFX + MotionClip(s).

My thought here was just to respond to @tamte that all the necessary feedback could be done first before giving it to the rig as a way to avoid simulation inside the rig.

Going back to the original challenge, what do you expect to be the controllers to be for the user here?

edward
My thought here was just to respond to @tamte that all the necessary feedback could be done first before giving it to the rig as a way to avoid simulation inside the rig.

You don't want to avoid it
The point is that it works as you animate in realtime, recooks from the beginning only when something changes earlier
But since it's only for individual transforms it's super fast

The advantage is that it can sample any other transforms at previous time samples and also other such transforms/constraints can be dependent on them in the same rig, so it allows for truly dynamic parenting and other types of rigs like rolling ball, etc, to be done without animating blindly and then doing simulation layer and then attach things to simulated transforms and do another simulated layer and potentially afterwards continue with hand animation, etc
Such segmented approach is hard to deal with, especially for animators
Not talking about heavy sims, just traditional history dependent constraints like dynamic parenting, flipless ik or twist bones especially for long tubes etc., stuff you want to naturally see realtime during animation without feeling like you have to sim anything