Storing a bank of animations

[rich_lord]

Hi.

 

Id like to create a setup where I have lots of separate animation curves that I then read onto arbitrary attributes on points. So, in a simple case, id have lots of pre-prepared ease-ins, ease-outs, simple bounces etc. I'd normalize each of these curves so they all run for 24 frames and have values from 0-1.

 

Its easy for me to create the curve data. In the attached file I've keyframed the P.x attribute of a point, and then passed it into CHOPS. I read this later at various times into the pscale value of a load of points. It all works great!

 

I'm wondering if this is the best approach though, particularly at scale. If I have 100's of different animations I'm reading in, is this the way to go? Is there a way to access keyframed data at arbitrary times through VEX in a pointwrangle? I cant find any function that lets me do that. I dont seem to be able to access CHOPS from VEX at all.(in SOP context).

 

In an ideal world, i'd like to skip the CHOPS step altogether and just read the data direct off the points in a wrangle node. Is this possible?

 

Thanks for your help. 

16_02_12_trigger_anim.hip

[mestela]

Unless its really necessary to have your chops stuff be responsive to point positions, you'd be better off writing out all your variations to bgeo sequences on disk, construct file paths per point in a wrangle, and read it all in with an instance sop.

 

Even if you do really really need to have the chop setup be totally live, it'd be worth rethinking it so it doesn't have to be.

 

Eg, say the red cubes in this example needed special behvaiour in a certain area, I'd make another variation of that anim, write it out, and make sure that only those points in that region get to load that geo sequence.

 

See the attached example.

 

 

instance_anim_v01.hipnc

Edited February 13, 2016 by mestela

[rich_lord]

Ok - this file is amazing, thanks matt.

 

I haven't really used the instance node before, I didn't realize I could add geo to points in this way - that's going to really help me with this project. Also the method you are using to ROP all the geo was really useful to me also.

 

Unfortunately though, I need to keep the animation separate from the geometry, as I want to be able to apply the same animation to lots of different shapes.

 

I can add the animation to points first, by pulling it from chops. Then use the instancepath to reference the geo onto the points in an instance node. But i'm still wondering if pulling the animation from CHOPS is the best method. Its feels fiddly, and I'd much rather find a more direct way.

[mestela]

Ah ok, I misunderstood your original question; when you said 'animation', I thought you were referring to shape/transform animation, not what's basically a timewarp curve to apply to other animation sequences.

 

I'm sure there's a more elegant way to do it, but here's one way:

 

vex_time_lookup.hipnc

 

 

So here's my logic:
 

• Animate your sphere by branching to a bunch of transforms, range 1-24, keyfaming @P.x between 0 and 1 to represent the timewarp
• Merge em all, connectivity, trail of 24 frames, timewarp that freezes frame 24. We have each sphere animation now frozen in space and time as a motion trail
• add sop to create prim, using 'class' as the grouping attribute. Now we have a geometry curve that matches the time curve. Basically, we've done what the chops network does.

The wrangle to construct the instancepath string is a little obtuse, but basically the logic is for each point to randomly select one of the timewarp curves we've generated, and lookup the point that corresponds to the time we're after. Reading its P.x will give us the frame offset we want for the geo on disk.

 

As I mentioned, I feel there's a more elegant way (my gut tells me the point cloud functions should be able to do this for free, but I couldn't get it to work). Its nice to visualise the timewarp curves as geo anyway.

 

Btw, had to double take when I clicked from your username to your vimeo account to your day job. Portal 2 ruined all other games for me, the writing was so good, but equally important was the twisted design and animation style, that seems to be largely down to you and your previous work. Still my favourite game of all time, trying hard to keep my fanboy in check...

 

-matt

Edited February 14, 2016 by mestela

[rich_lord]

Thank you! I spent all morning stepping through the scene file and understanding it. The vertexpoint and vertexindex part was a little confusing at first, but I got it eventually. The idea of creating lines and sampling @P is pretty great. I guess its similar to CHOPS without using CHOPS.

 

I re-sorted a few things to be more understandable for me. I used the primuv VEX function to pull the data from the lines instead of the vertexpoint and vertexindex. Wouldn't I get a stepped range using that method if I slowed down the anim?

 

Also - I was a little worried about all the trail SOPs id be using, but I realized I could just ROP out this data in the same way you ROP'd out the geo in the last version. I haven't hooked that bit up in the example file as you'd need to re-render it, but it works great.

 

Thanks to your help, I have a way to do everything I need and stay in VEX land. It feels pretty clean too. I much prefer it to my original CHOP solution, and I bet its faster. Thanks for all the quality tips. Now I need to work on a set of tools to use the curves effectively.

 

Glad you enjoyed P2. I just started going through the cgwiki! That's some crazy good info in there. I imagine my weeks shot now reading that. 

vex_time_lookup_me.hipnc

Edited February 14, 2016 by rich_lord

[mestela]

Yep primuv makes way more sense, dur me.

 

Yep, you'll get stepping if you go slower than 1 with this setup. If you need to subsample you could write out your animation at a slower rate, and fiddle with the rest of the setup to be able to access those extra frames. Would need some fiddling so that you don't have to tie yourself in knots with decimal points and padding. Eg, if you want to support up to a 10% slowdown, I'd take the 1-24 framerange, and multiply it by 1000 so that it runs from 1000 to 2400. That way you can support incredibly fine rates if required, (eg, frame 1.05 becomes frame 1050), and its still easy to construct the strings.