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
Caching in POPs?
7874 11 3- Henster
- Member
- 196 posts
- Joined: July 2005
- Offline
- edward
- Member
- 7725 posts
- Joined: July 2005
- Offline
- Henster
- Member
- 196 posts
- Joined: July 2005
- Offline
- deecue
- Member
- 412 posts
- Joined: July 2005
- Offline
- Henster
- 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
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
- Henster
- 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
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
- EigenAlex
- 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
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
- Henster
- Member
- 196 posts
- Joined: July 2005
- Offline
- keyframe
- 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
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
- old_school
- 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.
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!
- Henster
- Member
- 196 posts
- Joined: July 2005
- Offline
- old_school
- 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
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