Caching Particles Question

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  01 January 2013
Caching Particles Question

Let's say I have an animation that is 25000 frames long. And I have a PFlow setup where 500 particles are created on frame0 inside an object volume and they never do anything in the entire animation... they just remain static. (These particles are used by Afterburn to render puffs in each particle location).

When I am working in MAX, if I advance the time slider to some frame such as frame 15000, the PFlow updating progress bar shows at the bottom of the screen and it takes awhile before it gets to 100% and updates the screen.

In this case where the particles are static, it seems like there should be a way to have it just use the particle positions of frame1 throughout the entire animation and avoid this updating delay. Is this possible?

In the case where particle locations are changing per frame, I can see the need for an update per frame. When slave machines are net-rendering, what happens when they go to render a PFlow? For example, if the slaves are rendering a segment out of the total animation (such as frames 8000-10000) what happens regarding PFlow? The slave goes to render frame 8000 and the updating occurs before rendering can begin? So there's a wait while the updating occurs and when it's finished, the rendering happens. So what happens when frame 8001 is rendered? Does the updating have to happen all over again? Or is it fast because only one additional frame must be updated?

I'm trying to understand what methods are available to make the net-rendering as fast as possible (and PFlow interaction within MAX as fast as possible too).

(I have all the Cache operators but haven't used them much).

Thanks for the ideas!
__________________
Sincerely,

Mike Truly
-----------------------
Truly Media
970.349.5651
www.trulymedia.com
 
  01 January 2013
Originally Posted by Mike Truly: Let's say I have an animation that is 25000 frames long. And I have a PFlow setup where 500 particles are created on frame0 inside an object volume and they never do anything in the entire animation... they just remain static. (These particles are used by Afterburn to render puffs in each particle location).

When I am working in MAX, if I advance the time slider to some frame such as frame 15000, the PFlow updating progress bar shows at the bottom of the screen and it takes awhile before it gets to 100% and updates the screen.

In this case where the particles are static, it seems like there should be a way to have it just use the particle positions of frame1 throughout the entire animation and avoid this updating delay. Is this possible?


Should be. The trick is to turn off all of the operators in the flow that you do not need. So in a simple setup if you leave Render+DiskCache (global)+Display on any updating should be kept to a absolute minimum.

Originally Posted by Mike Truly: In the case where particle locations are changing per frame, I can see the need for an update per frame. When slave machines are net-rendering, what happens when they go to render a PFlow? For example, if the slaves are rendering a segment out of the total animation (such as frames 8000-10000) what happens regarding PFlow? The slave goes to render frame 8000 and the updating occurs before rendering can begin? So there's a wait while the updating occurs and when it's finished, the rendering happens. So what happens when frame 8001 is rendered? Does the updating have to happen all over again? Or is it fast because only one additional frame must be updated?

I'm trying to understand what methods are available to make the net-rendering as fast as possible (and PFlow interaction within MAX as fast as possible too).

(I have all the Cache operators but haven't used them much).

Thanks for the ideas!


It will have to update in order to get to frame 8000, as mention above updating should be at a minimum and quite fast.
__________________
poof ~>Vimeo<~
 
  02 February 2013
Sorry it's taken awhile to get back to this.

John, thanks very much for the ideas.

Here's the part that is frustrating about this. There are 25000 frames! If I use DiskCache, I will have 25000 cache files in a folder all so I can advance the timeslider quickly ... the particles don't do anything in the animation! They just are born in place... and they are only there to provide locations to AfterBurn so AB can generate puffs in those locations. In this case (and I realize this is probably not the normal particle situation) it sure would be nice if there was a way to tell PFlow 'just use this frame1 cache file throughout the animation'.

Since AB can only use particle systems to generate the locations from (would be nice if you could feed AB a point cloud to create puffs from)... in this case it is better for me to not use PFlow but rather use standard particles since there is no 'updating' penalty. You can jump from frame1 to frame18000 instantly with no 'updating'. Render slaves can start rendering the puffs without any delay from 'updating'. Interacting with AB tests on different frames is like lightning because there is no PFlow 'updating'.

Thanks again for the ideas. I will definitely use them on other PFlow projects.
__________________
Sincerely,

Mike Truly
-----------------------
Truly Media
970.349.5651
www.trulymedia.com
 
  04 April 2013
If you baked the particle flow at frame zero, can AB read the data off a baked helper or
mesh object?



Originally Posted by Mike Truly: Sorry it's taken awhile to get back to this.

John, thanks very much for the ideas.

Here's the part that is frustrating about this. There are 25000 frames! If I use DiskCache, I will have 25000 cache files in a folder all so I can advance the timeslider quickly ... the particles don't do anything in the animation! They just are born in place... and they are only there to provide locations to AfterBurn so AB can generate puffs in those locations. In this case (and I realize this is probably not the normal particle situation) it sure would be nice if there was a way to tell PFlow 'just use this frame1 cache file throughout the animation'.

Since AB can only use particle systems to generate the locations from (would be nice if you could feed AB a point cloud to create puffs from)... in this case it is better for me to not use PFlow but rather use standard particles since there is no 'updating' penalty. You can jump from frame1 to frame18000 instantly with no 'updating'. Render slaves can start rendering the puffs without any delay from 'updating'. Interacting with AB tests on different frames is like lightning because there is no PFlow 'updating'.

Thanks again for the ideas. I will definitely use them on other PFlow projects.
__________________
Mark R. Pigott
Sarnia, Ontario
 
  04 April 2013
I just did a test. Create a empty flow and drag in a intial state birth.

create an initial state on frame zero from ur original pflow source. turn ur original flow off.

The intial state should be faster!
 
  04 April 2013
Sorry it's taken so long to get back to this... am on other projects now.

Thanks for the ideas!

I was able to use standard particle systems to generate the AB puffs for that project... this worked very well.

I'm not sure yet whether AB can read from a baked pflow... will have to look into this. Will also have to test the 'Initial State' operator as it sounds like it would do what I need.

Thanks again.
__________________
Sincerely,

Mike Truly
-----------------------
Truly Media
970.349.5651
www.trulymedia.com
 
  04 April 2013
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 12:34 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.