Caching in POPs?

   7874   11   3
User Avatar
Member
196 posts
Joined: July 2005
Offline
Hi,

This isn't very likely but maybe someones got a nice solution.

I'm always finding in POPs that I want the values from the frame before. Is there a way of storing these values? I've done it a couple of times before ( something like making duplicates of the particles then letting each other update each other if not equal ) but its a scary mess!

Any Ideas?

er.. might give an example actually..


I've got this deforming geometry which is being covered in particles, had some effect applied to the particles, then their positions copied back to the geometry.
The positions of the particles from the deformed geometry are updated using a point() function. This updates the position but does not affect the velocity. To calculate the velocity you need the position of the particle from the previous frame. Hope this makes sense!

Cheers
Henster
User Avatar
Member
7725 posts
Joined: July 2005
Offline
Why can't you just use the point() function to read off the velocity attribute at the current frame?
User Avatar
Member
196 posts
Joined: July 2005
Offline
When bringing in the velocity attribute from sops to pops returns the value of the normal. I want the velocity that was required to push the point from its origin to its destination.

$VX = ($TX - $OLDTX) / $FPS

Something like that I want to do.

?
Henster
User Avatar
Member
412 posts
Joined: July 2005
Offline
can't you just take the derivative of your point positions?:

length($TX,$TY,$TZ)

or

sqrt(($TX^2)+($TY^2)+($TZ^2))

or

slope chop

…?
Dave Quirus
User Avatar
Member
196 posts
Joined: July 2005
Offline
Using length would just return a position vector whereas the value I want is dependant on time.

Slope chop would be a good call if the animation was purely coming from a keyframed curve. If the animation is coming from a VEX function or from the particle system itself then it hits problems… Also having a different channel for every particle could be hazardous for my computers health

Cheers
Henster
User Avatar
Member
196 posts
Joined: July 2005
Offline
Hmm. Think I may have thought of it.

By taking the the particles into SOPs using a trail sop to calculate the velocity then returning the particles to POPs.

Its not really the universal solution I was thinking of. (not just velocity)

I'm really want to use the cache sop so any variable can be stored. Is there an expression to grab what you want from the cache sop from any frame?

Something like:

cachepoint(op_string, frame_index, point_number, attribute_string, attribute_index)

Hopeful?

Cheers
Henster
User Avatar
Member
639 posts
Joined: July 2005
Offline
Hey,

I think that what you might like to try is to bake the sequence of geometry onto disk and read it back in. This allow you to do offsets. However, the only kind of motion blur you'll be able to get out of this is probably velocity blur – no deformation/transformation blur, I don't think.

It won't be as disk efficient, but it sure does make things easier.

Cheers,
A
User Avatar
Member
196 posts
Joined: July 2005
Offline
Thanks for the replies.

Saving the geo does the job perfectly…. bit of a pain though.

Cheers
H
Henster
User Avatar
Member
1529 posts
Joined: July 2005
Offline
Heya Henster,

With regards to caching out particles to disk and the associated motion blur issues…

You can use two file SOPs, one at `floor($FF)`.bgeo, and the other at `ceil($FF).bgeo`.

Pipe both outputs into a blendshapes SOP, and add a “blend1” channel (so that you end up with two blend channels in total). put `$FF%1` in the expression field of blend1 and leave blend0 at the value “1”.

Presto. Deformation motion blur.

Cheers,

Gene
User Avatar
Staff
2540 posts
Joined: July 2005
Offline
Here's a clever trick to access an attribute's value from the previous frame using Position as an example:

location POP: just birth a single particle for now
|
attribute POP
Name: ppos
Type: vector
Value: $POSX $POSY $POSZ
|
attribute POP
Name: pos
Type: vector
Value: $TX $TY $TZ


I love to show this example to intermediate to advanced particle users to show them that the order in wich you wire POPs is important. In this case, you need two attributes to pull the trick. The first attribute POP depends on the second subsequent attribute POP to set the proper value that it picks up after the particle simulation goes through the time step. You would think that POPs would error out but it doesn't (most of the time ).

No hassles of having to manage dependent files on disk.
There's at least one school like the old school!
User Avatar
Member
196 posts
Joined: July 2005
Offline
That is a clever trick!!

I'm convinced I'd tried that as well! Prehaps I wasn't careful enough when placing subsequent pops after/before the “trick”.

Cheers
Henster
User Avatar
Staff
2540 posts
Joined: July 2005
Offline
Yeah, I'm full of it… or is that full of that kind of stuff. ops:

You can take it to the nth degree by passing ppos in to a new attribute pppos created above by another attribute POP and on and on. Just like passing a bucket of water up the chain, each one in turn storing the previous frame's values.

Works on any attribute. I use this trick to cache any SOP attributes as well. Putting the pop SOP in-line makes it pretty stream-lined.



-jeff
There's at least one school like the old school!
  • Quick Links