I see! Thanks Edward storing the data to a stash worked for me aswel!

I see we can extract the keyframe and the value from the channel prima, but can we also extract the slope handels?

I did some playing around with this today.

I created this small hda. where you can easily view and edit the curves.

inside the hda there is only a stashnode. you can see the code on the screen. it's pretty simple.

I believe there is also a callback method that should be able to store the keyframes for you after editing them, but I was not able to get that to work.

monomon
In case anyone else comes across this thread, I found a way to create static geometry outside of sop, and pass it on via a stash node

Yes, this works thanks a lot! this is a very nice way to create geometry through python!

I am starting to understand what channel primtives are.

animation-data stored on invisible primtives with hidden "attributes" that we can extract and make visible through both vex ("chprim_" functions) and python using the channellist and channelprim functions. this way we can store the animation to geometry without having to store the actual vertex-positions for each frame seems very convenient and saves a lot of diskspace when dealing with a lot of animations. It's something that I have been wanting for a while, so I would love to learn more about it.

now the example that Kodra posted shows an example on how to convert those primitives back to animation curves where we can modify them using the animation-editor again.

however, I believe the example is not altering the primitives themselves at the moment.

I personally get the error that the output_geometry was not defined.
which makes sense, because it's created before the callback function.
But there is an issue with writing back even if we were to add a proper geometry reference to the callback function.

a callback function is not executed from a python-sop I believe so all the geometry that we try to modify is read-only.

How can we after altering the animation curves, store the data back to channel-primitives? I believe that is what kodra's example tries to do. But using the callback doesn't work for me so far.

Thanks for sharing your hip file! learned a bunch from it!

hroberts

hroberts
I'm very late, but one approach I saw in LABS nodes is using `chs("../code_string")` in VEX. This causes VEX to evaluate the string as if it was actual VEX code in the wrangle. For example, add this to a detail wrangle:

```
vector addToPos(vector p) {
return p + {1, 2, 3};
}
```

Then in any other wrangle you can run that code with chs():

```
// Append the code string and run it (like #include)
`chs("../your_wrangle/snippet")`

v@P = addToPos(v@P);
```

What!!
This is crazy!!

This is so much more usefull to me. Because it works so dynamically and keeps long vex code much much cleaner.
Thanks a bunch for sharing!

I wanted to see if I could have a tab be forced on the user. But I think you inspired me to go for a workaround!

did someone ever find this out?

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.

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?

Here I have a file that locks a matrix from rotating further than specified rotation angles.

I build a digitigrade IK leg yesterday (posted it on the discord server).
perhaps you can take a look at it to get some inspiration.

I'm pretty confident the same could be done to for more joints.

I am not sure yet how to do the limiting rotation part. I will take a look into limiting rotations today.

I took another look at it "no pun intended".

And I believe the last matrix is a point in space that is used to determine the "look-up".

I've got results when modifying the "translate" aspect of the matrix upwards.

I'm not sure if this is correct as I don't know why the look-up vector requires X Y and Z vectors.

you can do pretty much anything you'd want with apex in it's current stage.
Apex is literally just a bunch of different houdini-contexts thrown together into a system that allows for functions to be fired through attributes. Quite amazing.

I personally was not able to get the Look-at working, because I did not understand the 3 matrix inputs it required and I dislike finding anything in the currently existing rigs. I'm more used to a 3 vector input look-at constraint. There is probably a good reason for it requiring matrices.

But you are always able to create your own look-at if you'd want. here is an example I quickly build using vector inputs.

seeing that we can run vex in the apex graph makes me quite exciting.
should running vex inside apex still be considered optimal, performance wise? or should we notice slowdowns when using it compared to pre-existing nodes?

I have done quite a bit of rigging with kinefx in the meantime. it would be nice if I can convert my previous rig-logic work to apex rigs.

Hey there,

Allright, here we go.

the pivot inside the functions cracktransform and maketransform are actually more or less a function themselves.
For example in the function maketransform:

The pivot is applied like this:

Inside of a point attribute wrangle paste this code:

vector T = chv("T");
vector R = chv("R");
vector S = chv("S");
vector pivot = chv("P");

matrix m = maketransform(0,0,T,R,S);
matrix m2 = ident();

translate(m2,-pivot);
m2 *= m;
translate(m2,+pivot);

v@P *= m2;

if you create wrangle and apply this wrangle to a cube, you will start to understand it.

As you can see I did not use the "pivot" inside the maketransform function, I just recreated what it does behind the scenes.

The pivot is something that "alters" the actually stored transform.

In the function cracktransform it does the opposite of this. therefore it changes the rotationpoint of the matrix before extracting the data out of it.