hello
I’m working on a project and urgently need to convert my object into dust. my goal is to bake shading information onto the particles first.
I’ve seen very cool result in reflection, transparency and material baking in your tutorials. ( like mini that you use in the demo’s)
is it possible to do it directly in maya? ( I recall you did this using Max and Brazil )
or can you please point me to a right direction how I can do this with krakatoa?
thank you in advance
Actually, these effects involve Camera Mapping the particles. You generate UV coordinates on a reference frame (typically at birth) and then keep that data around so that the color from the reference position sticks to the particle even if the particle is moving.
The Maya setup involves a Magma flow. Here is a simple example:
thinkboxsoftware.box.com/s/gukm9bkgqaw21eb9yhbc
You can watch more about this here:
youtube.com/watch?v=6JE7JdZ_-3I
thank you.
very helpful.
a couple of questions though.
1- the provided maya scene file has a different magma flow from the tutorial.
is it because the version is different and implementation of the nodes differs or is it just another (maybe better) approach?
2- I disabled the ApplyTexture and PRTMagma3, and for PRT Magma2 ,disabled color output as well to see just the emission output. but It renders black. in the tutorial It renders kinda yellow orange color.
3- the mini is 360 textured.
It is said in the demo that It is a sequence projected through a camera. what if I want to rotate around the model and I need a fully 360 textured model like the mini?
the provided scene file only applies one image at the birth time.do I need several magma flow or …?
thank you again
hi
If you can help me with these questions, that would be great!
thank you
The PRTMagma2 which performs the UV generation appears to be the same as the one seen in the video around 3:17.
The PRTMagma3 was never really used, but it is meant to fade off the particles as they move too far from the birth position.
I downloaded the file “KMY_Magma_CameraProjection_v001”, opened in Maya, selected the particle1 object, clicked the MOD icon to open the Modifier Editor. Only the top Magma entry PRTMagma2 was enabled (+), the other two entries were disabled. I opened the top Magma and changed the TextureCoord Output node to Emission. Then I enabled the Display of the particle system, went to frame 1 to generate particles and rendered in Krakatoa (it has Use Emission on, so it sees the Emission channel created by the Magma). I got the red/green/yellow/orange result as expected. Basically this visualizes the UVs as Emission colors.
No need to change anything - as long as the render camera is the same as the projection camera. Basically, we generate UV coordinates in camera space based on the 3D birth position of the particle. We render an animated camera moving around the car and save the sequence of images. We then generate the UVs on the particles and use the same animated camera to project the texture AND to render the particles. As result, the texture always remains aligned to the camera, and the particles change color as the image frames change over time. So from every viewpoint of the camera, you always get the correct perspective with the correct colors. But these colors stick to the moving particles and distort the object as the particles move. Any reflections rendered in the original animation will appear on the particles and appear quite plausible…
What you are not seeing is that if you rotate around the Mini, you will see all colors streaking along the projection camera direction. So it is not 360 degrees, it is totally fake. 
So in your case, all you need is an animated camera and an animated image sequence to project. The Magma flow remains the same since it is always based on the Birth position which does not change when the camera or the particles move on later frames…
thank you very much.
very clever and interesting technique. right now I’m doing exactly the same method.
a couple of question if you don’t mind!?
in the PRTMagma 2 , there is a node “Input value : 54.43” which is AOF of the camera. what are the other two multipliers. 0.0175 and .5 ( before Tan)?
and I don’t understand the last multiplier befor the output.
toCamera space (point) means the point at the left lower or the middle of view?
please tell me If I have to add two variables ( birth position , RGB pp) before particle creation or I can do it later ( like I did, I filled the whole object with particles. now I want to set initial state for particles. sorry the birth position at creation time now become unclear if I do so.
degToRad 1 → 0.0174533
*0.5 is the same as divide by 2.
Basically we take the Field Of View in Degrees of the camera, convert to Radians and take half of it.
Basically we calculate a value for U and V which is 0,0 at the center of the image, -1 on the left and at the bottom, +1 on the right and on top. We need to shift this range to make the bottom left corner the 0,0 origin of the UV map. So we first Add [1,1,0] which shifts everything into the range from 0,0,0 to 2,2,0. Then we have to Multiply by 0.5 (same as Divide by 2) to normalize the 0-2 range to 0-1 range. Hence the Multiply 0.5!
When a World Space Position is converted to Camera Space, a particle that is at the Camera Origin (where the “eye” is) will have a Position of 0,0,0. A particle that is 100 units in front of the camera on the -Z axis will have a value of 0,0,-100 and so on… Basically the Camera becomes the reference coordinate system.
Yes, both.
*Click on the left button (General), switch to the “Particle” tab, select birthPosition from the list and click OK.
*Click on the right button (Color), check “Add Per Particle Attribute”, click “Add Attribute”. This will give you RGB PP.
*Then create an expression to copy the birthPosition into the RGB PP at Creation. This way, the value will only be copied when the particle is born, and then stick around forever.
Hope this helps.
I just remembered that I wrote a more detailed explanation of that Magma flow half a year ago here:
yes…
That was very informative and helpful.
now I’ve simulated my particles. ready to render.
as usual I encountered a few problems.
although the walled object is filled with 2.5 mil particles, It seems dotted and I need more particles to fill the entire object so that It feels like a solid object. may be fill the object with around 3 or 4 mil particles. but it takes several hours.
on the other hand I though that partitioning might help!
but as far as the projection method goes, partitioning doesn’t respect to the birth position of the particles and maybe It jitters the already projected particles which results in blurriness … is this true?
Prtvolume does pretty good job in filling objects where Maya takes for ever to do it, but is there any way, to make these particles dynamic and use maya native fields?
Unfortunately, Maya Particles are rather slow when it comes to working with millions.
The Partitioning code should be able to work if you are using the Random Seed approach (changing the seeding of the initial particle distribution) as opposed to Jittering the particle positions after the fact. If your particle system uses a random seed to determine where the initial position will be, the Expression should capture the actual correct birthPosition. The Expression would see the wrong value if the Position was jittered after birth though.
What Partitioning settings are you using?
There is currently no way to advect PRT objects in any way using Maya fields and Krakatoa. Not even in the 3ds Max version of Krakatoa. We have a dedicated 3ds Max product called Stoke which does mainly advection (and a lot of field-based stuff in general), but it does not exist in a Maya version yet. Just for your amusement, here is an example of advecting an otherwise static PRT object: thinkboxsoftware.com/stoke-mx-and-prt-maker/
hello
thanks for your help.
I’v not reached the partitioning part because I’m getting a black image…
I think the birth position to rgb gives me the error. in fact there is no RGB in my particles because they are cached and they never be created to have rgb channel with creation expression.
there is a fun test I did with the particles.
sandGlass.mov (2.71 MB)
I am not a Maya guru, but I am quite sure you are supposed to generate the rgbPP from the birthPosition expression before caching. And Partitioning with Random Seed changes will not work at all if you are caching.
FORGET about Maya Caches when using Krakatoa.
Saving PRTs IS a form of caching, and Partitioning is a form or PRT saving. So you need a dynamic live Maya particle system which then gets cached to multiple PRT sequences and then you drop the Magma on the PRT Loader with these Partitions. As long as the RGB channel contains the birth position, the camera mapping should work regardless of how many Partitions you saved…
yes …
krakatoa has changed so many aspects of particles,as well as caching! in a very intuitive way.
I like PRT saving, reliable , more precise and much more flexible.
well It worked with the new born particles that has had the expression from the first place. I’m filling the object again with new particles. the bunny is filled like this , yes? ( turning the bunny to a surface emitter and let it be filled with particles, cause it is very well distributed particles all inside the bunny)
-I hope that initial state ( as opposed to cached particles ) is not a problem right?
thank you so much
In my example, all particles are on the surface of the bunny. The same was true for the Mini. Filling the whole volume would be a waste, but it would be a possibility if it weren’t so slow
Unfortunately, Initial State would prevent Partitioning from seeding particles at new unique positions.
The Jittering of the Position and/or Velocity in the Partitioning controls was added to handle Initial State, but you would get an incorrect birhtPosition in your rgbPP channel based on the Initial State and not on the jittered position. 
Yes, you can do that stuff using Magma.
In my example scene, the second (but disabled) Magma was set to fade off the particles gradually by measuring the distance between the birthPosition from the Color channel, and the current Position. It would set the Density to become lower as the distance increases. But you could use a Magma setup where the Emission color from the TextureMap applied to the particles over the projected coordinates from the first Magma is taken and blended with a Dust Color using a Blend operator and output again as Emission. Thus, as the particles move farther from their birthPosition, they would slowly lose the projection color and turn into the dust color… Similar with Velocity-based color blending.
Give it a try and let me know if you have problems!
thank you , here is what I get for now.
I did try to use the same flow but the flow has absolutely no effect on emission nor on Density.
I thought It might be input value of the divide ( which is set to 4, I lowered to 1 and crank it up to 10 ) it had no effect. I changed the other value of the power( before the multiply) to 2. and dissipation happens .
because my scene size and object size is similar to the bunny scene, the values for the divide, power,multiply… should work fine! but the values should be adjusted a little.
I think It is kinda working.
please tell me if I can improve the flow. is there anything else I can do about?
as the images show the dust color ( here is RED ), is very flat!, and this is very big drop off of setting “ignore scene light” On. lights add much more realism to the particles.
is there any way to implement the scene lights in rendering, cause it is very important.
in the tutorials about projection ( advanced dissolve effects ), there is a note at the end of it. The emission could be mixed with dynamic lighting to produce shadow at render time!
could you please tell me more about it… cause I need more pleasant looking particles rather than a flat particles.
thank you in advance
We are rendering with full Emission and Ignore Scene Lights checked because we assume that the projected color IS already illuminated and we don’t want any interactive light.
But you could enable the lighting as long as you reduce the intensity of the Emission over time, AND have a valid Color channel.
Now the problem is that we are abusing the rgbPP to store the initial position. So we will have to make some changes to the Magmas to provide a valid Color without losing the birthPosition data.
Basically, you will have to add another Magma to the top of the list and copy the Color into a new channel (you can enter a Custom Channel called “BirthPosition”).
Then in the existing Magma, set the Color Input channel to load the BirthPosition channel.
In the Magma that performs the blending of the colors, you can then set the Color channel to the same color as the emission when at birth position, and to red when far. Then also fade off the Emission down to zero by distance. As result, as the particles move farther away from the birth position, they will lose the Emission and gain red that will shade according to the light sources you have created. The lighting is up to you, but I suggest using a Spot.
thank you very much
-I created that first Magma… color → Birth position
I didn’t fully understand this part.
would you please explain a little more. are we still rendering Emission, I mean with this method we need Ignore Scene light On again? or color?
cause I changed the color to emission ( I think I’m wrong) and Ignore Scene Light Off, I got the wrong render.
the existing flow fades off the emission base on the distance.
Let’s forget the Magmas for a second and talk about how Krakatoa renders.
Krakatoa is a volumetric particle renderer. In order to render volumetrically with light attenuation, shadows, and scattering, it needs one or more Lights in the scene, and the Ignore Scene Lights to be OFF. If you want to render a dust color with interactive lighting and volumetic shadows, you need to provide a Color channel that will be scattered into the eye, and you need to reduce the Emission down to zero based on some factor (in your case, based on distance to the birth position, but it could be based on Age, Velocity, anything).
Your original setup for Camera Projection though had completely different (and incompatible with volumetric rendering) settings. We assumed that the texture projected on the particles carries pre-calculated lighting from another renderer, so all we want is fully self-illuminated (incandescent) particles with no lights, attenuation, shadows, scattering etc. So we abused the rgbPP/Color channel to store our birthPosition from the expression, and used a Texture map to write to the Emission channel to produce solid colors in the final rendering.
In order to marry the two approaches, we need to make some changes to the second approach to introduce the volumetric shading of Krakatoa back into the picture. So we need to
*Back up the Color channel into a custom channel (“birthPosition”) as a first step (new Magma you created)
*Input this new custom channel (“birthPosition”) in the old Magma flow to get the correct data for calculating birth-time UVs.
*Input the new custom channel (“birthPosition”) in place of the Color channel to subtract the current Position from the birthPosition.
*Fade off the “Emission” and “Density” channels over distance by multiplying by the factor you calculated.
*Add a new Output channel set to “Color”. Blend between the Red Color and the Emission color based on the distance factor value, and output the result as Color WITHOUT multiplying further.
*Disable the “Ignore Scene Lights” option and create one or more lights.
As result,
*At birth your particles will will have the same value for both Emission and Color and will have a Density of 1.0, producing solid fully emissive color.
*As the particles move away, they will start losing Emission - at distance of 4 units, the Emission will be zero. At that point, the Density will also be zero.
*As the particles move away, the projection color (taken from Emission) will be blended more and more with the Red color and will be output as the scatter color of the particle, producing volumetric shading with the scene light(s).
Things to play with:
*Disable the Density channel output node to see the result of the blending of Emission and Color over distance without having the Density fading off too.
*Once you also enable the Density falloff, consider using a different distance-based falloff for the Emission/Color blend, Emission fade-off and Density fade-off. This way, you could control separately the distance threshold and power for when the Emission will become zero, when the Color will become fully red, and when the particle will disappear due to 0.0 Density. You might want the Emission to become zero much earlier but still have some of the unmultiplied Emission in the Color channel before it blends to Red, and then keep the red color for a while before the particle fully disappears…
In your last screenshot,
*the left ? should switch to “birthPosition”.
*the right ? should stay “Emission”, but it should be just “Emission Multiplied By Distance Factor”.
*the right ? should also get another Output set to “Color” with the existing Blend feeding into it but without the Multiply By Distance Factor part.
*Then clone the whole Distance Factor sub-flow two more times and use one to control the Blending, another to control the Density fade off, and the third to control the Emission fade off.
Hope this helps.
thank you again. 
very helpful.
that was exactly what I was looking for.
ps: for this test I used simple fade out.
sandGlass Test.mov (1.26 MB)
