Just a note for the documentation. 10 million particles isn’t the limit for Pflow, it’s the limit per source. If I have two sources with all the events instanced save for the position seed, I can easily get 20 million particles.
10 million particles isn’t the limit for Pflow, it’s the limit per source.
<<
Thank you. That’s an important distinction I completely overlooked.
Here’s a shot done with 3 sources, identical except for the position operator seed. Rendered to disk, then loaded from disk with colors, rendered with motion blur. Not too shabby for an early attempt.
Nice work, Chad!
Here’s another test, this time setting the script float to make the bones more dense.
Woahh this is super nice Chad! Congrats!
Sorry for being so dumb. what does it mean, setting the script float?
I'm just starting up with Krakatoa.
Actually, good thing to bring up on the beta…
What’s the story on telling people about Krak? It’s been announced at Siggraph and at the ADSKUG, but most beta thingys are somewhat hush-hush. Can I talk to Oleg or other particle-type folk about this?
Back to the script float, each particle in pflow can have extra user-defined data attached to it via the script channels. I think you get a boolean, float, vector, and an integer. Anyway, Krakatoa can read in the per-particle vector as color and the float as opacity.
These channels need to be created, as they do not exist originally. Use a Script Operator, or Box#3 to add these. The Script Operator, however, is really slow when dealing with huge quantities of particles needed for Krakatoa.
So in this case I used Box#3 to do some texture sampling and applying the results to the vector and float channels.
More specifically, I read in the texture at each particle, and if the sample was within a certain range, I set the script float to be a high value, else I set to a low value.
Actually, good thing to bring
up on the beta…
What’s the story on telling
people about Krak? It’s been
announced at Siggraph and at
the ADSKUG, but most beta
thingys are somewhat
hush-hush. Can I talk to Oleg
or other particle-type folk
about this?
This is something David Marks should answer, but I am pretty sure you can talk to Oleg privately about Krakatoa, as he worked with the stand-alone version at Frantic LA on Superman Returns and has enough insight (and is probably under Frantic NDA anyway).
My private opinion is that as long as you show some amazing stuff outside of the beta and mention it was made with Krakatoa, it would be good publicity (unlike your posts about Deadline, if you know what I mean ;o))) ). But once again, Dave should be able to answer this.
Back to the script float, each
particle in pflow can have
extra user-defined data
attached to it via the script
channels. I think you get a
boolean, float, vector, and an
integer. Anyway, Krakatoa can
read in the per-particle
vector as color and the float
as opacity.
These channels need to be
created, as they do not exist
originally. Use a Script
Operator, or Box#3 to add
these. The Script Operator,
however, is really slow when
dealing with huge quantities
of particles needed for
Krakatoa.
In the near future, Krakatoa’s PRT format and internal memory structure will also support arbitrary, custom-defined channels.
Do you feel the way we use Scripted Vector and Float channels for color and opacity can be improved or need to change? We found no good way to use the boolean, integer or matrix channels so far, but with normals support coming, these might come in handy. If you have any ideas, please share…
Cheers,
Borislav “Bobo” Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
What’s the story on telling people about Krak? …
We did not make any non-disclosure agreements for this beta program, so even
though we have limited access, it is still a “public” beta.
We ask that any published images at least credit “Frantic Software” and
“Krakatoa beta”. You can discuss the product with colleagues provided that
you acknowledge the software is still in beta, and likely to change somewhat
prior to release. We aren’t ready to handle a huge flood of new beta tester
requests, but we would be happy to get some industry buzz circulating about
the product. We hope to release the software within a month or so, but have
not set a final date. I’d love to have some people waiting in line when we
officially release.
(Heck, this thing may be more popular than the PS3!! At the very least, it
will be easier to get and might even cost less!)
Which Deadline posts would you be referring to, Bobo?
The only thing I could come up with off the top of my head for the particle script data channels would be to allow the boolean to be used as a “visible to camera” channel. So you could have particles make shadows, but not be seen by camera.
Yes, the matrix channel would be useful with the normals, but I’m not sure how the normals are going to be handled. You saw my bizarre attempts at speculars, no?
Just ignore me, I am overreacting here. 
I guess we should wait until custom channels are added to the current memory architecture (we need them for a show, so they will probably come sooner than expected).
Then it would make sense to be able to map any PFlow channel to any type-compatible Krakatoa channel as needed. So if we would add a visible to camera channel in Krakatoa, you could map the boolean script channel to it when you want. Flexibility is good.
Specular Highlights are in the works, already implemented for ‘vertices as particles’. I assume we could use the orientation of the particle (X,Y,Z or the negatives of those) as normal vector OR overwrite with a custom normal via a script channel…
Cheers,
Borislav “Bobo” Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
really neat work and information here! i´ll have to give the more then one source approach definitely a try!!!
did i already mention how much i love the “save particle sequence” function? If not here i go 
hugs frantic software team