I just had to test out that advection thing with tons of particles, and here is what I got so far.

http://vimeo.com/17095369 [vimeo.com]

Big thanks to Peter Quint and his tutorials on Vimeo !

/M

great look)

looks great
hardware configuration, simulation/rendering time, if I could ask?

I saw your comment in the vimeo list about accurate births being the longest compute component in your particle simulation.

Have you tried the now-common technique of taking your input geometry and using the Time Shift SOP in combination with a For Loop SOP to create multiple copies of the geometry in-between frames and birth from that?

I have my own asset that I use all the time now. Dead simple. The Time Shift SOP even supports re-timing of volume primitives, so anything input goes.

See the attached example file to pick up the asset. I rarely use accurate births any more.

10M particles? I did a quick 10 wedge pass at 3M advected particles per pass across 240 frames (30M particles) in 2 hours then rendered with each pass as a geometry delay load procedural in Mantra render as points in another 3 hours and with 12Gb of memory. Left a LOT on the table to go much higher.

I'll be showing this workflow setup from scratch (of course) along with a few others at the FMX masterclass on simulations this week. I try not to pluck through pre-built scene files when it's just as fast to construct the network and show the steps.

Jeff ,
is the master class going to be recorded ?

Rob

another way, to avoid accurate births, would be that one, first and second post

http://forums.odforce.net/index.php?/topic/12751-martins-sketchbook/ [forums.odforce.net]

Cool ! defently something I will be using instead of accurate birth.

BTW this is a 5 old month post, since then I did a 25mil test aswell here:

http://vimeo.com/17234865 [vimeo.com]

I compared these solutions, here is a file showing the result. Maybe I did something wrong but the last solution posted held up better in my test.

it's because you are using $F in your expression for sphere movement (in all sturb() expressions)
and therefore the interframe interpolation is stepped resulting in incontinuous particle emissions

just make sure to use $FF in your expressions

Aha yes, worked much better with $FF, and around subframes 35+ i starts to be hard to tell the 2 solutions apart.

Hey guy's great stuff, thanks for sharing.