I have a pFlow set up that I am trying to partition faster using Stoke. When I partition it with Krakatoa partitioning it looks great, but it take a long time.
Is there any advantage or disadvantage (other than not being able to change the channel after the fact) to first using Save Particles to save out a couple million particles from PFlow, and THEN using Stoke to multiply those VS. using the pFlow as the source and velocity field for Stoke and doing it that way?
In the latter case I am guessing pFlow is recalculated over and over for partitioning? Thus this method would be slower? But I also guess this method would be more accurate to the original simulation.
Stoke was designed mainly to accelerate the advection of particles in PFlow when driving them with a FumeFX Follow. So you can advect in Stoke directly using a FumeFX simulation INSTEAD of using a PFlow at all.
When it comes to partitioning PFlow itself (one that does not use FumeFX), the best way is still using the Krakatoa Partitioning. This is the only approach that will give you precise results. Also v2.3 of Krakatoa lets you generate more particles using Repopulation at render time, and in some cases this might be good enough, too.
If you use the PFlow as Velocity source in Stoke, you will get a SIMILAR result, but it won’t be exactly the same, because we discretize the velocity values of particles to a grid, and this always causes some detail loss. If you can live with the results of driving Stoke particles with PFlow particles, then you should just dial in the count that you want and run the simulation once. If you really need multiple partitions (to benefit from multiple sequences management and potentially faster loading from SSDs), then you are right that running multiple partitions would reevaluate the PFlow again and again and probably add overhead. So saving once to PRTs and then using that as the Stoke source might shave off some time. But saving to PRT from Krakatoa spends too much time zipping up PRTs, thus it might be actually slower than just running the PFlow live…
I must admit I have never benchmarked this specific case, and I cannot tell what approach would be faster. If you have the time and inclination, you could run a simple test and find out
I did try Stoke, using the PRTLoader I had exported as a single partition from the pFlow. I was nor getting acceptable results unfortunately. So I am resulting to partitioning the pFlow. The pFlow live is pretty slow, at least on the first couple of frames where the particles are born. It’s not terrible after that, but I also want to net render. So I would be wasting a lot of overhead recalcing the pFlow when net rendering (not to mention this seems to lead to inconsistent particles sometimes - Is pFlow supposed to be completely deterministic?).
Using partitions loaded in a PRTLoader the particles load and render fast, especially with motion blur. It is just the act of partitioning that is slow.
What was the problem with the PRT Loader approach? Did you save all vital channels like ID, Velocity, Age and LifeSpan? I would expect a PRT sequence saved with all channels to produce similar or the same results as a live PFlow…
The PRTLoader worked great. What did not work so great was trying to advect particles from a PRTLoader with Stoke (using that same pRTLoader as both the particle source, and velocity field).
You are still not describing WHAT exactly happened.
What was wrong? Did it not emit at the right times (based on Age and ID channel)? Was the Velocity wrong?
A general “it does not work” won’t help us understand the issue and fix it, or help work around the problem
LOL. OK. I will have to try it again. Basically, I saw the particles were not moving the way I had engineered them in the pFlow. I will have to try it again when my deadlines are over, and see if I can see why. Perhaps I did not have the velocity grid fine enough.
That is the problem with doing commercials. You sometimes just have to get stuff out the door, and you don’t always have time to troubleshoot everything
I’ve been playing around with pflow sims and stoke and i found something that can help. First thing, is the simulation until (default is 100). So, check this first… the second thing is try to reduce velocity scale to 20%… my values to achieve the same velocity/behavior are .1 or .2 (i found that because i usually use the scale geometry in realflow to 0.1 while importing data from 3dsmax, and that affects the stoke data interpretation)
