• Page
• Discussion
• View source
• History

From Odwiki

Oversampling for Sequenced Geometry Read in From Disk

When asking POPs to accurately collide particles with geometry, which is being read in frame by frame from disk, - there's often problems as no data is provided for subframes...

(e.g.) POPs asks is this blob of yogurt colliding with the dog's face at frame 3.5 ?

As you're only providing data for frame 3 and 4, the collision may not occur at all!

So instead, use two File SOPs, both attached to a Sequence Blend SOP where the first reads in;

/foo_directory/dogsface.`clamp(int($FF),1,300)`.bgeo

Or if you are using padded frame no.s ... dogsface.`padzero(4,clamp(int($FF),1,300))`.bgeo (Here we are using the $FF expression which can retrieve the float frame number.) - and the second reads in;

/foo_directory/dogsface.`clamp(int($FF+1),1,300)`.bgeo 

Notice that we're asking this expression to look at the next frame... The clamping is to prevent the expression trying to retrieve frame 301.

So now we have the two sets of data we need to retrieve frame 3.5. In the Sequence Blend, we are blending the point positions of frame 3 and 4 together in order to get data inbetween, using the expression;

 Blend Factor: $FF-int($FF)

• When POPs asks for frame 3.5 it will blend by a factor of 0.5; (3.5 - 3)
• When POPs asks for frame 3.7 it will blend by a factor of 0.7; (3.7 - 3) and so on...

You can view this blending by turning off 'Integer Frame Values' in the Global Animation Options (on the timeline)and setting the 'Step' to 0.1

Other things that could be included here in the future are

• Using the distance attribute from the Collision POP to pre-empt collisions
• Using the Peak SOP to create a bounding area around the object, - forcing POPs to only calculate collisions for nearby particles
• Selecting only useful collsion geometry by creating a Normals-dot-Velocity SOP which defines oncoming geometry - allowing you to delete the backfaces.

---

Back to Effects