Attention TP users!
We have enabled Krakatoa to read color and density data from TP User Channels.
The User Channels have to be named according to Krakatoa’s expectations and also have the correct type to be used:
For Color - create a User Channel named “Color” and set its type to ‘color’
For Density - create a User Channel named “Density” and set its type to ‘float’
You can write any data into the two User Channels using the TP math operators and Krakatoa will take these as Particle Color channel and Particle Density channel automatically.
For example:
*Create a Thinking object
*Select the “All” Master System
*Enter “Color” in the Data Channels field
*Set type to “Color” and press [ADD]
Result: CH0: Color (Color)
*Now enter “Density” in the Data Channels field
*Set type to “Float” and press [ADD]
Result: CH1: Density (Float)
*Add a Dynamic Set to the Master Dynamic
*Add a Position Born OP
*Add a Data Channel OP and select Channel 0
*Wire the Particles into the Data Channel OP
*Enable the Color Input of the Data Channel OP
*Add a Color Helper and wire the Color output to the Color input of the Data Channel OP
*Add a Random Helper and wire the particles into it
*Wire its Value to the Red input of the Color Helper
*Clone the Random Helper, change its Random Seed and wire into the Green input
*Repeat the same for the Blue input
If you would render now, each particle will have a random color with R, G and B using random values between 0 and 1
You can do the same with a Data Channel OP set to Channel 1 and one Random helper controlling the density.
Of course, you can wire in ANY data into the Data Channels, the above Random example is just to show how it is done…
This is fantastic news, I will test and pass on the results!
Good work u crazy frantic guys!
Dear Bobo , Obliging User to Assign Data Channel On “All” Group is nonsence for heavy Tp users… The First step in the implementation should be Simply to have Tp Group Picker For Wich groups To apply the Krakatoa Effect on … this is the MOst important thing to access tp…Allowing Multiple Group Picking is Also important … Then the rest is cool and makes me want to use Krakatoa more often ( except i dont get why you have to Hardcode "Density " or Color as a Data Channel is either a Float of a Scalar , color etc… You can Clamp the Color Value from Krakatoa to only access Apropriate Data Channel and with a Small String Imput field let the user specify witch Data Channel he wants to use for X ) Same thing for 0 Data channel hardcoded… Tp has a Stand Material on each Geometry Instances , Or Standart Geometry , and it even have a material class … we can math randomisations of materials/colors from Within tp and assign this color to any data channel … having to pick a helper to get the color from is weard …
I hope im missunderstanding the workflow suggested…
my 2 cens…
www.cgfluids.com
Obliging User to
Assign Data Channel On “All”
Group is nonsence for heavy Tp
users…
That is just his example. You can specify the channels for individual groups if you like.
The First step in the
implementation should be
Simply to have Tp Group Picker
For Wich groups To apply the
Krakatoa Effect on … this is
the MOst important thing to
access tp…Allowing Multiple
Group Picking is Also
important …
We have a system like this for selecting which TP groups to actually render, but I think you misunderstand. The color and density extraction is not an effect. Krakatoa merely looks for custom channels named Color and Density when extracting particles. This is a workaround since there is no way to access the material information of each individual particle.
except i
dont get why you have to
Hardcode "Density " or Color
as a Data Channel is either a
Float of a Scalar , color
etc… You can Clamp the Color
Value from Krakatoa to only
access Apropriate Data Channel
and with a Small String Imput
field let the user specify
witch Data Channel he wants to
use for X ) Same thing for 0
Data channel hardcoded…
If I understand correctly, you would prefer a mechanism in the Krakatoa GUI to assign a channel number to the Color/Density data. It seems more straightforward and less error-prone to use the channel names. Is there any reason you would want to extract the color of a particle from a channel not named “Color”?
>That is just his example. You
>can specify the channels for
>individual groups if you like.
>If I understand correctly, you
>would prefer a mechanism in
>the Krakatoa GUI to assign a
>channel number to the
>Color/Density data. It seems
>more straightforward and less
>error-prone to use the channel
>names. Is there any reason you
>would want to extract the
>color of a particle from a
>channel not named "Color"?
The answer to this question for me is in this first phrase of your answer .. If user wants to be able to add multiple Groups ( AkA: Snow , Sand , Drips and Smoke ) , user wants to Assign a Different Randomess per Particles ( DC ) to each of those groups Wtich means DC SnowColor , SandColor , DripsColor and SmokeColor could be the named desired carried per Each Particles respectivly to their groups .. Their is no question that using 1 signle thinking particle icon Per scene is an IMPORtant part of solid and complex TP setups ..
www.cgfluids.com
"Krakatoa merely looks for custom channels named Color and Density when extracting particles. This is a workaround since there is no way to access the material information of each individual particle.
"
Their might not be a way for Krakatoa to get material Information For each particles but their is a way per group to access them right ? So i don’t understand how if each particle caries its own DC of specific color it wouldn’t be translated to the rendering through this Per particle Dc ? i m confused i think… if you think all my worries are actually misunderstanding then i need to load this version soon and check it out 
My informations from sam and joe where that no Group picking where possible ( yet ? ) … but maybe i missed something …
thanks
www.cgfluids.com
Rif, here is the short story:
The TP SDK does not allow us to access MATERIAL data per particle. We talked to Edwin and so far we have not heard of a way to access the actual material assigned to a particle. We would have preferred to access the diffuse color of whatever material you have assigned to your particles, but being unable to do that (not a Krakatoa problem, we asked Cebas to add support for material access via the SDK with no result so far), we went with a workaround because the TP users asked for one.
So we decided to allow Krakatoa to read user-defined color and density data from the Data Channels. We do something similar with the Scripted Float and Vector channels of PFlow where we let Krakatoa use them as density and color so people can write scripts or DataOps to define whatever colors they like instead of applying materials and maps to the particles.
Of course, as you know, channels in TP can be assigned per Group, so I went with the simplest EXAMPLE and assigned a custom channel to the All group. Forgive my stupidity. I should have known better having read the CGTalk FumeFX thread. 
That being said, I just found some BUGS in the Thinking Particles Rollout of Krakatoa 1.1 - the buttons appear to be wired incorrectly and Krakatoa seems to ignore the settings from the TP groups. We will be looking into this early next week - it used to work before.
Now you can assign a channel called “Color” to any of your groups and if the type of the channel is set to Color, too, it will be used as the particle color. Thus, my example could be like
*Create Particles with two Position Born OPs
*Send them to two groups - one called “Red” and one called “Blue” for example.
*Create a Data Channel called “Color” in each group, set the type to Color and ADD
*Create two Data Channel Ops and connect each Position Born to the Particle input of each one of them.
*Enable the Color input of both Data Channel Ops.
*Create two Color Helpers, set the one to Blue color, the other to Red color
*Wire the Color output of the two Color Helpers to the Color inputs of the two Data Channel Ops.
This should give you a group containing particles whose data channel stores the color red, the other group with a DC with color blue. Instead of solid colors, you can pipe in ANY colors you might be able to calculate using the various Ops and Helpers of TP and these colors will appear as the particle color, PER PARTICLE. If a particle moves to another group, it will get whatever color the Data Channel ops for that group will assign to it. So the assignment is done per group, but the color value is per particle, so each particle can have a different color, like in my previous example with the random values.
Since a particle can be in only one group at any given time, it can have only one color value - if you move a particle from group Snowflakes into group Groundsnow, it could change its color according to the group, but there is no necessity to assign a channel named “SnowflakeColor” to the one group and “GroundsnowColor” to the other, both will be called “Color” but can contain different data.
I am not sure whether this was clear or not, please let me know.
I think this is great and clear Bobo thanks for the explanation … i will definitly try this out when its installed in our end Ill try to discuss this material issue with edwin after 3.0 releases , its been a big crunch on their end atm …
"Of course, as you know, channels in TP can be assigned per Group, so I went with the simplest EXAMPLE and assigned a custom channel to the All group. Forgive my stupidity. I should have known better having read the CGTalk FumeFX thread.
"
Ha your not stupid at all , sorry if in any way my statement made you feel this way , it wasnt the goal … your probably no question about it more clever than little me heh… And for the Cgtalk post , speacking of stupidity , theirs one guy on this planet that should stop pretending and start making his own and some fantastic work with some humility thats all …
cheers and thanks again …
www.cgfluids.com
No problem.
Some more details:
Krakatoa uses named channels internally - both for rendering and for data storage in PRT files. It supports arbitrary channels just like TP, but expects certain channels required for rendering to be named according to a specification, so “Color” always contains the color data, “Density” is always the particle density and so on.
We felt that it would be most straight-forward to ask the user to name the color and density DCs in TP according to the same pattern we use inside of Krakatoa. Otherwise, we would have to provide a complicated UI inside of the already heavy Krakatoa GUI to define which of potentially many channels of Color or compatible type should be used as the Color source.
I wouldn’t be surprised if some day we would implement a dedicated Krakatoa Op inside of TP to expose more features in a more customizable way. In fact, that was something we discussed as a possible workaround, but then realized that the DCs would be a much simpler way to get the desired flexibility with much less effort (we are talking about two weeks ago, so we actually got this exposure of Color and Density in less than a week).
Btw, I already fixed the button wiring in the Krakatoa TP rollout internally. The buttons were assigned to exactly the opposite functions, the add button was removing and the remove button was adding, but double-clicking was correct so I never noticed - I usually double-click.
A first glance over the C++ code responsible for disabling specific channels did not reveal any obvious errors, so I will leave it to Darcy who implements these features to debug it next week.
Do we have a way to change all Generators seeds randomly with tp as well ? ( the way you guys do it with pflow and Deadline)
www.cgfluids.com
Do we have a way to change all
Generators seeds randomly with
tp as well ? ( the way you
guys do it with pflow and
Deadline)
Yes, any TP operator that exposes a property “RandomSeed” to MAXScript and does NOT have the string “NOSEED” in its Comments field will be affected just like PFlow and Legacy particles. Deadline is not really needed, this works with local Partitioning, too.
Of course, should any of you TP users find any bugs related to this, please let us know - that’s the point of the whole Beta program after all
awesome
just fyi, I can only get Color to work if it’s a DC on the All group, not working on children (will test more & report).
nice work!
I tested with a sub-group and it worked, but keeping in mind there are still some issues with groups management, anything is possible.
We will keep on working on the TP issues until everything works as desired before releasing 1.1…
Cheers,
Bobo