Bobo,
I’ve been working with setting density in pflow and saving that as krakatoa options, but it only seems to work when I have only 1 event and have a delete operator in that event? If I have a collision and sent particles to a delete event can ip put my data operator and kraka options after the delete in the last event?
Fred
Fred,
The Krakatoa Options does not really do anything to particles. It is a kind of parameters holder which Krakatoa uses to decide what to do with certain channels in a given Event.
So the ORDER / LOCATION of the Krakatoa Options does not play a role, but its EXISTENCE does. Thus, it is a good idea to place the Krakatoa Options either in the Global Event (causing Krakatoa to see it as assigned to all PFlow Events in the flow), or instance it to every event in the flow. Once again, since the operator does NOT really OPERATE on the particles but just holds a paramblock to instruct Krakatoa how to deal with the Event, its location and order of execution plays no role. Krakatoa just goes to every event in the flow, asks for its particles and asks the event “do you happen to have a Krakatoa Operator assigned somewhere? If you do, let me see where to copy the data according to your flags…” In a way, the Krakatoa Operator is very similar in its behavior to the Display and Render operators in that it modifies the properties of the Event itself and does not touch particle data as such.
The Data Operators though are order-sensitive and behave like regular operators. If you have multiple events, you will have to make sure that particles have passed through at least one Data Operator before they are passed to the renderer so they can get their channels set and populated/changed correctly. Once again, you could use a Global operator to affect all particles in the flow if the data is flow-independent, or clone the Data Operator to multiple events.
That being said, I found it quite SURREAL explaining this to you since you were the one who came up with the whole PFlow concept to start with 
I think of you every time I use PFlow - you, Oleg and Brandon moved things in a very cool direction, producing what I consider one of the slickest UI paradigms ever!..
Well I’m embarrassed and flattered.
The reason I ask, is that I thought I was using it properly and I couldn’t get the density to exist in the particles at all. (BTW, how do you check if a prt seq has a certain channel)
Now I remember something from Afterburn where you had to have a delete operator in the event for afterburn to know when the particle dies, so I thought it might like that. (Basically on frame 5, we don’t know if the particle has hit the collision object, until frame 15, then we know they hit.)
Fred
Right, I missed the fact the Test was a collision. If it were, say, an Age Test, sending to an event with a Delete operator would cause correct calculation of the LifeSpan since it is clear when the particle is scheduled to die. But a Collision cannot be evaluated until it actually happens, so the initial LifeSpan of particles would be Infinite, and your density (Age/LifeSpan) would be a NAN.
Adding a Delete operator would initialize the LifeSpan to a valid number. You could set it quite high so particles would never really die due to it.
Regarding channels inspection, you can can see if a channel was actually saved to the PRT using the Sequence Browser in the PRT Loader (click the >> icon to open). But it does not show you the actual content of the file, only that a channel was allocated. The way I debug this is by writing out to a CSV file instead of a PRT (even just a portion of the particles). CSV is pure ASCII and you can look at all values in Notepad or whatever. We have logged a wish for a better tool to inspect values as part of the MagmaFlow editor, and possibly a MAXScript interface for reading data from PRT streams (so one/me could develop a simple listview or something like that to browse the content). We also have an inhouse viewer where we can load PRTs and click on particles to see all their channels and values, but that is unlikely to ship with Krakatoa anytime soon because it is a browser for anything (image sequences, mesh files, PRT files, fluid simulation levelsets and whatnot).
In general I would just save the Age and LifeSpan channels of all particles and deal with the Density calculations in MagmaFlow since you would have a lot more flexibility to tweak it AND preview it in the viewport…
Bobo,
I’m doing a little test here on this Age Lifespan channel thing. It seems that using an age test is problematic and does not save the channel properly? Im including a test scene. In this scene, im saving a sequence to disk, then loading it back with a prt loader and a magma flow. It renders black. If i change to a delete operator, everything works fine. Am i missing something?
Fred
Density AgeTest.rar (29.3 KB)
Looks like this is a PFlow limitation.
I always assumed it would work, but I just tested it with my own quick scene and it does not set the LifeSpan to a valid number.
I could not download your file due to firewall limitations (have to write a ticket to IT to download it for me), but in my simple test, I created a Standard Flow, added an Age Test and sent to an event with Delete operator. Printed the LifeSpan using a Script Operator (value was 1.34218e+007f) and also saved to a CSV file and looked into it (value was 0 for all particles).
Not sure how Krakatoa can solve this problem.
Can you post on the Orbaz forums and see what Oleg thinks about this? We could be doing something wrong…
Thanks, I will.
The Age was 0, or the Script Float was 0?
Seems like you could just use Script Float or whatnot to store the age for you.