PDA

View Full Version : Krakatoa


Pages : 1 [2] 3 4 5 6 7 8

paulselhi
08-21-2007, 01:17 PM
yes i have overide uncheked, i can get the particles to render in DS but not in Krak with the right colors

ulb
08-21-2007, 01:25 PM
I realize that for me the colors are ok only if Ichoose position by volume, they get somewhat averaged if i choose by surface, I'm still experimenting with that..

edit: actually its quite weird, the colors are sometimes ok, sometimes not, there must be a kind of bug in the mapping, that sucks.


I will try to come up with a simple tutorial regarding scripting color and density data in PFlow/Krakatoa and translating the same into Box #3 (which operates hundreds of times faster).I missed this one: it would be awesome!

OlegB
08-21-2007, 05:29 PM
actually its quite weird, the colors are sometimes ok, sometimes not, there must be a kind of bug in the mapping, that sucks.

Could be a problem with Box#1 licensing; you need to grab the latest update of Box#1 at the Orbaz forum.

Thanks,
Oleg B.

ulb
08-21-2007, 08:38 PM
Could be a problem with Box#1 licensing; you need to grab the latest update of Box#1 at the Orbaz forum.

Thanks,
Oleg B.Hi,

I finally could manage to make it work. No licencing involved here, i just use the render-demo and modify a bit the flow.

here is the little anim (xvid) made with pflow tools box#1 and krakatoa demos, with the simlpe flow used. I only used 300,000 particles because it was enough for what i wanted to test, but I could have rendered 20,000,000 if I had a bit more time for that...

I'm really excited by the possibilities to make great effects with those two products combined, I'll certainly try to get the funds to buy them, as they are both quite affordable!

edit: here is a pic from the same animation but with 20,000,000 particles, and with 1200*800 frames (only 18 sec/frame!):
[/url][url="http://img175.imageshack.us/my.php?image=test0042ss6.jpg"]http://img175.imageshack.us/img175/3365/test0042ss6.th.jpg (http://img402.imageshack.us/my.php?image=test0042os4.png)

ulb
08-22-2007, 05:47 AM
In short, we rendered the car in Brazil, then we projected the Brazil rendering onto the particles and rendered in Krakatoa. Each particle had its original object space position baked into a UV channel on the first frame of creation via a simple Box #3 Data Operator. Our camera map plugin has the ability to use a UV channel to convert object space into screen space, thus picking the color from the pixel corresponding to the 3D position encoded in the channel. So when a particle starts moving, its UV channel still points at its original position and takes the color from the non-desintegrated car rendering... This is why all colors including highlights follow the particle turbulence:
I have a last question about this: How can this method enable the transparency of the windows, like in the r&d video? It doesn't look like a compositing trick, and I'm not sure how it can be achieved.

Bobo
08-22-2007, 06:21 AM
I have a last question about this: How can this method enable the transparency of the windows, like in the r&d video? It doesn't look like a compositing trick, and I'm not sure how it can be achieved.

There is no transparency in the video. All you see inside the car is actually mapped on the surface particles and is completely opaque. The Brazil rendering had reflections, refractions and specular highlights. The Krakatoa rendering is like a solid canvas where all these effects are projected on and then distorted in space.

You could use Box #3 Data Operators to sample data from the surface of a mesh. So instead of camera projecting the colors, you would sample the color from the surface of the emitter mesh, and could also set the density based on the same principle, so particles on the windows would have lower density than the car body. You can also sample UV coordinates and many more things using Box #3. But in our Mini video, we really wanted the polished look of the Brazil rendering to be used and did not apply any lighting or shading inside of Krakatoa.

bnvm
08-23-2007, 04:46 PM
I have been playing around with the demo and have run into a problem. I am trying to assign the particles color and self illumination based on the particles age, basically I want to create a fire to smoke effect. I cant seem to get it to work with the particle age map, if I render with scanline everything works as expected but krakatoa only renders the particles with the color of the particles at 0% time. Can someone give some advice on how to set this up with krakatoa.

Also I am trying to get a smooth render of the particles, but it is very difficult to do. I always seem to have chunky renders and not a smooth soft cloud like renders, any advice would be appreciated.

Thanks,

-bnvm

dharrison
08-23-2007, 05:12 PM
I am trying to assign the particles color and self illumination based on the particles age, basically I want to create a fire to smoke effect. I cant seem to get it to work with the particle age map

Unfortunately one of the sacrifices we made in order to generalize our particle sources beyond just PFlow and the legacy particle systems was to remove support for Particle Age. I have a few ideas for fixing this problem, but the current version of Krakatoa does not support Particle Age materials.

~Darcy

bnvm
08-23-2007, 06:43 PM
Is there any other method for doing this dynamic materials for instance?


-bnvm

Bobo
08-23-2007, 07:23 PM
I have been playing around with the demo and have run into a problem. I am trying to assign the particles color and self illumination based on the particles age, basically I want to create a fire to smoke effect. I cant seem to get it to work with the particle age map, if I render with scanline everything works as expected but krakatoa only renders the particles with the color of the particles at 0% time. Can someone give some advice on how to set this up with krakatoa.

Also I am trying to get a smooth render of the particles, but it is very difficult to do. I always seem to have chunky renders and not a smooth soft cloud like renders, any advice would be appreciated.

Thanks,

-bnvm


One thing that I notice many people tend to do wrong is using very high density settings. The idea behind Krakatoa is to use millions of particles with very low density (around 1.0/-3) which accumulate into a smooth cloud. When a single particle is being rendered, you should NOT even be able to spot it with a naked eye! If your particles are visible individually, your density is probably too high.

So if you want to fade off some particle trail, the best way is to delete particles with a large variation of the Delete event so they fade off gradually, reducing the density down to 0.

You can also control both Density and Color using a Script Operator or a Box #3 DataOperator - Krakatoa can read the Scripted Vector channel as the color source and the Scripted Float channel as a Density source. We provide a special Krakatoa Options operator that can be used to copy the data from these scripted channels into the Color/Density channels. Of course, the Scripted approach is MUCH slower than using Box #3 (200 times, according to Oleg), but both should work. You could then define things like color changes based on velocity or acceleration, density changes based on position or age or whatever you like.

Obviously, in the future we would like to provide you with more powerful methods to control the shading using the available channels, but that's another story.

Bobo
08-23-2007, 07:58 PM
on ChannelsUsed pCont do
(
pCont.useAge = true
pCont.useLifespan = true
pCont.useVector = true
)

on Init pCont do ( )

on Proceed pCont do
(
count = pCont.NumParticles()
for i in 1 to count do (
pCont.particleIndex = i
pCont.particleVector = [1,1,1] * (1.0 - (pCont.particleAge.frame / pCont.particleLifespan.frame))
)
)

on Release pCont do ( )


This will vary the color of a particle from white to black over the course of its life.
For this to work, a Delete operator must be present in the flow to define the lifespan of the particle, and a Krakatoa Options operator must be set with MXSVector->Vertex Color checked.


And here is the same in Box #3 - it does not need the Krakatoa Options operator because it can write straight to the Vertex Color channel which Krakatoa uses as the color source if available.

(http://forums.cgsociety.org/attachment.php?attachmentid=117336&stc=1)

Bobo
08-23-2007, 09:26 PM
on ChannelsUsed pCont do
(
pCont.useAge = true
pCont.useLifespan = true
pCont.useFloat = true
)

on Init pCont do ()

on Proceed pCont do
(
count = pCont.NumParticles()
for i in 1 to count do
(
pCont.particleIndex = i
pCont.particleFloat = exp(-4 * (pCont.particleAge.frame / pCont.particleLifespan.frame))
)
)

on Release pCont do ( )

And this is the code for fading density over particle age. The exp() function is needed to counteract the exponential nature of the density, if you would use simply

pCont.particleFloat = 1.0 - (pCont.particleAge.frame / pCont.particleLifespan.frame)

you would get an exponential falloff.

Again, the Delete operator must be present to define the particleLifespan and the Krakatoa Options operator has to be set to copy MXSFloat->Density.

If using Box #3 instead, just write the density value to the Script Float channel and use the Krakatoa Options as with the scripted method.

Bobo
08-24-2007, 01:15 AM
Here is a quick example of Color By Speed (http://www.scriptspot.com/bobo/krakatoa/KRAKATOA_ColorBySpeed_DataFlow_tk101.mov)created using DataOperator in Box #3, but I have done the same before using Script Operators.


The magnitude of the speed of each particle is multiplied by a different scalar value and assigned separately to the Red, Green and Blue channel. In addition, the Blue channel is inverted, subtracting the result of the multiplication from a scalar, so when speed is low, blue is high and red and green are low, when particles accelerate, they turn hot orange / yellow.

This is just a simple demo. 100K particles per emitter, 8 passes motion blur, rendered in about 5 seconds/frame, 250 frames. (I replaced the original tk100 posted initially with one without the Gamma 1.8 which should look better).

Here is also the same animation (http://www.scriptspot.com/bobo/krakatoa/KRAKATOA_ColorBySpeed_DataFlow_tk102.mov) rendered with 1 million particles per emitter (4M total)

Note to Krakatoa users: Additive rendering scales densities linearly - switching from 400K to 4M increased the particle count 10 times, so I reduced density by one order of magnitude by changing the second spinner in the density controls from -3 to -4 and got exactly the same result, just smoother. When using volumetric shading, you don't even have to do that as Krakatoa will try to adapt to the changing particle count.

(http://www.scriptspot.com/krakatoa/KRAKATOA_ColorBySpeed_DataFlow_tk100.mov)

bnvm
08-24-2007, 02:07 AM
Thank you very much for the tips. I am going to look into orbaz tools since there is such a significant speed difference. It is nice to know this effect can be done. Is there any way to vary the self illumination of the particles? All of my test so far show that the self illumination is ignored when using volumetric shading with lighting.


-bnvm

t1042
08-24-2007, 07:06 AM
Hi!
i try to use krakatoa but i have some question. i don't know why when i use age test in PFlow and render with Krakatoa my max always clash. when i delete age test it work fine.
somebody can help me.
http://www.mediafire.com/?dedy9dkzegm

t1042
08-24-2007, 07:15 AM
and this is my test without age test
http://www.mediafire.com/?czxk3zbex3i

Bobo
08-25-2007, 01:49 AM
Thank you very much for the tips. I am going to look into orbaz tools since there is such a significant speed difference. It is nice to know this effect can be done. Is there any way to vary the self illumination of the particles? All of my test so far show that the self illumination is ignored when using volumetric shading with lighting.


-bnvm

I am afraid the current design of the shading and lighting stages does not allow for that.
Here is what happens:

*Krakatoa gets the particles from the particle system
*If the particle system has no material and no vertex colors, it reads the wireframe color (which in PFlow is the display operator's color)
*If the system has vertex colors, these colors are read by Krakatoa and loaded into the Color channel
*If the system has a material, the diffuse color of the material has to be evaluated for each particle. So Krakatoa evaluates the material in a shading context where the self-illumination is set to 100% and gets the pure fully illuminated color of the particle's diffuse channel incl. any maps added to the diffuse map slot. This color is then passed to the Color channel.
*Now Krakatoa has all particles with their colors and looks if Lighting is on. If it is not, it draws each particle in the color stored in the Color channel, thus giving you a flat, 100% self-illuminated cloud.
*If Lighting is on, Krakatoa calculates the light attenuation for each particle using every light in the scene.
*When the final pass draws particles to the image, the particle color from the Color channel is modulated by the attenuation and produces the final volumetric shading.

A possible solution to modify this pipeline would be to store a separate channel with a self-illumination factor generated during the shader evaluation and counteract the attenuation using it. I guess I can log this as a wish and we will see what will happen in the future...

Bobo
08-25-2007, 02:13 AM
and this is my test without age test
http://www.mediafire.com/?czxk3zbex3i

Sorry for the delayed reply - I just tested it at home and can confirm the crash, but cannot tell what is causing it. Will let the developers look into the problem on Monday.
Thanks for the report and for your patience!

EDIT: After several more tests, I narrowed down the crash to the Material Static operator. I opened the Material Editor to look at your shaders and when trying to navigate from the texture up to the base level of the Standard material (using Scanline as the MEdit renderer btw), Max just crashed, which means there is something wrong there. Will continue investigating. I guess that the Age Test only triggers some other problem, because replacing it with any other test did not prevent the crash, and I know from experience that there is nothing wrong with using Tests with Krakatoa.If I can pinpoint the exact problem, I will post again.

t1042
08-25-2007, 05:55 AM
Sorry for the delayed reply - I just tested it at home and can confirm the crash, but cannot tell what is causing it. Will let the developers look into the problem on Monday.
Thanks for the report and for your patience!

EDIT: After several more tests, I narrowed down the crash to the Material Static operator. I opened the Material Editor to look at your shaders and when trying to navigate from the texture up to the base level of the Standard material (using Scanline as the MEdit renderer btw), Max just crashed, which means there is something wrong there. Will continue investigating. I guess that the Age Test only triggers some other problem, because replacing it with any other test did not prevent the crash, and I know from experience that there is nothing wrong with using Tests with Krakatoa.If I can pinpoint the exact problem, I will post again.


thanks a lot for your reply. anyway i still like to use Krakatoa. it's cool!!!

Bobo
08-25-2007, 06:21 PM
thanks a lot for your reply. anyway i still like to use Krakatoa. it's cool!!!

Just to confirm - are you using the latest version 1.0.1.29090?
I came to the office today and could not reproduce the crash on our systems. We are running 1.0.1.29090 on Windows XP 64. At home, I had a pre-1.0 version running on Windows XP 32 bit. Will install 1.0.1.29090 at home and test again. No wonder we haven't seen this crash before if it does not happen on our machines.

Any info about your hardware, OS and software (Max version and Krakatoa version) might be useful.

Thanks in advance...

Kamid
08-26-2007, 05:33 AM
Any possiblity of be able to do reflection mattes for Krakatoa now or in the future? Didnt see any in the documentations

^^

Bobo
08-26-2007, 07:26 PM
Any possiblity of be able to do reflection mattes for Krakatoa now or in the future? Didnt see any in the documentations

^^

The simplest thing that comes to mind is implementing the automatic generation of cubic reflection maps or lat-long-maps from the viewpoint of any object which could be used as from-file reflect/refract maps or environment reflecfion maps. Also, generating flat-mirror reflections should be rather easy. We are already doing something like that for the attenuation maps, so adding output for particle reflection passes would be rather easy IMHO.

Also, Krakatoa already supports spherical lenses with Brazil 1.x cameras, so that might be somewhat useful for creating reflection maps.

While Krakatoa already contains a raytracing core used for things mattes, shadows from mattes, particle culling and AMPE effects, the current implementation draws particles in a much simpler way (which results in the high shading speed). But I would never say never, as we have serious plans for future development that might simplify certain things in the future...

t1042
08-27-2007, 03:42 AM
Just to confirm - are you using the latest version 1.0.1.29090?
I came to the office today and could not reproduce the crash on our systems. We are running 1.0.1.29090 on Windows XP 64. At home, I had a pre-1.0 version running on Windows XP 32 bit. Will install 1.0.1.29090 at home and test again. No wonder we haven't seen this crash before if it does not happen on our machines.

Any info about your hardware, OS and software (Max version and Krakatoa version) might be useful.

Thanks in advance...

I use duo Xeon 3.60GHz , 3.00 GB of RAM and window XP 32 bit.
max 9 and Krakatoa 1.0.1.29090. thanks a lot.

t1042
08-27-2007, 04:49 AM
I found that i might have problem with Mapping Object instead of age test. but i don't know how to use Box#3 to mapping.

Bobo
08-27-2007, 05:23 AM
I found that i might have problem with Mapping Object instead of age test. but i don't know how to use Box#3 to mapping.

I installed the latest 1.0.1.29090 on my home machine (but I do not have Box #1 here) and your scene renders without crash now (but obviously without the mapping).
I was getting a consistent crash with my pre-release beta version (even without the mapping). So we will try to debug this tomorrow in the office, but at this point it looks like it is not directly a Krakatoa problem as it happens during the PFlow evaluation.

Stay tuned...

t1042
08-27-2007, 05:33 AM
I installed the latest 1.0.1.29090 on my home machine (but I do not have Box #1 here) and your scene renders without crash now (but obviously without the mapping).
I was getting a consistent crash with my pre-release beta version (even without the mapping). So we will try to debug this tomorrow in the office, but at this point it looks like it is not directly a Krakatoa problem as it happens during the PFlow evaluation.

Stay tuned...

have u ever render my scene a whole sequence (frame1-150). because sometimes i can render 1 frame but if i try to render a whole sequence it's crash.
thanks for your help and quick reply.

Bobo
08-27-2007, 05:55 AM
have u ever render my scene a whole sequence (frame1-150). because sometimes i can render 1 frame but if i try to render a whole sequence it's crash.
thanks for your help and quick reply.

Yesterday with the old pre-release version it was crashing after 3 seconds on any frame. (but I think it was caused by an old bug). I will wait until tomorrow to test in the office - I could not download your file from the office on Saturday due to IT restrictions, so I will have to get it with me from home - will know more in about 12 hours. We have all PFlow Boxes installed there and if it crashes in an animation range, I will know then.

EDIT: I rendered the whole sequence on my office workstation without any crashes.
It would be useful to know whether that scene crashes when rendering with Scanline or mental ray... if it does, it is a PFlow issue and not a renderer problem.

ZivaS
08-28-2007, 09:45 AM
Great software! I have a question about Z-depth and velocity.
Is it posible to render Z and velocity to Open .exr or other formats (or Pass) to use them in Post? Or, can I render particles just with Krakatoas motion blur and extract Z-depth channel for post?

Thnx.

Bobo
08-28-2007, 02:25 PM
Great software! I have a question about Z-depth and velocity.
Is it posible to render Z and velocity to Open .exr or other formats (or Pass) to use them in Post? Or, can I render particles just with Krakatoas motion blur and extract Z-depth channel for post?

Thnx.

Krakatoa supports two types of Z-depth pass - Blended Z Depth and Blended Camera Distance. The former calculates the distance to the image plane parallel to the camera -Z axis (the way Max does this). The latter calculates the distance from the camera position to each point in space projected onto the image plane, so the distances are calculated radially within the field of view angle. In both cases, the result will APPEAR to be a white image, but if you right-click any pixel you will see that the floating point value stored is the distance in SYSTEM UNITS (so if a particle was 100 generic units away, the pixel would contain a value of [100.0,100.0,100.0].
This second method is identical to the way Gelato calculates its Z-depth.
(we are currently using both Gelato and Krakatoa on a project and this works well)

In a post application, you might have to scale down the exposure value if the values have to be normalized. For example, if you want your values normalized in the range from 0 to 1000, just scale down the pixel values 1000 times and a pixel containing the value 1000 .0 will now be 1.0, while a value of 0.0 will still be 0.0.

As for velocity, if you have Box #3, you could encode the velocity into a color channel and render a velocity pass. In fact, you could encode anything into a color channel. But it would require a calculation of the velocity into screen space so it might be a bit more complicated than what I was showing in the color by speed magnitude example earlier in this thread.

If you don't have Box #3, you could encode the velocity into the Script Vector channel and use the Krakatoa Options operator to copy that into the Vertex Color channel. This would be MUCH slower, but would still give you the results you want. You would have to render without lighting to get a flat color representing the speed, then use that in your post application.

I intend to write a couple tutorials related to this as soon as I find time...

Also, we have plans to implement various render elements in the future, so the calculation of such passes would not require any jumping through hoops...

Bobo
08-28-2007, 11:23 PM
I took the animation posted earlier in this thread and turned it into a small tutorial:

http://www.franticfilms.com/software/support/krakatoa/particle_color_by_speed_using_dataflow.php

I will write about how to do the same using Script Operators next...

SuperRune
08-29-2007, 11:53 AM
Hi Bobo,

I've had great fun playing with the Krakatoa demo, and we are planning on purchasing a license for a forthcoming project (if the client goes for the idea we have). One thing that surprised me though, I expected Krakatoa to be able to multiply the particle count by itself, sort of like the Maya cloud particle type - i.e. that it would render one particle as a cloud of say ten particles. Is that functionality available or planned?

Rune

Bobo
08-29-2007, 01:10 PM
Hi Bobo,

I've had great fun playing with the Krakatoa demo, and we are planning on purchasing a license for a forthcoming project (if the client goes for the idea we have). One thing that surprised me though, I expected Krakatoa to be able to multiply the particle count by itself, sort of like the Maya cloud particle type - i.e. that it would render one particle as a cloud of say ten particles. Is that functionality available or planned?

Rune

Well, Maya HAS to do that, because it would have hard time generating 5 million particles in the scene. ;)
This has been discussed a lot during the beta. It is not impossible to do, but it is difficult to do right. In fact, motion blur and DOF sort of do that - instead of drawing one point per particle, the motion blur draws the particle N times along the velocity vector using multiple passes and optional random placement, while DOF fills the circular area the particle would occupy with many samples of the particle with reduced density, so the final result looks like a fuzzy ball.

The trouble with multiplying the particle count is that it would be artificial, following some pattern. The main idea behind Krakatoa is to let you draw a dust cloud as such down to the last particle. This means that the precision at the edges is a lot higher than with comparable voxel-based approaches. Adding multiple particles procedurally would dilute this quality and make the cloud look more dense but less sharp, esp. when working with wispy smoke and so on. Our approach to Particle Partitioning at least ensures that each partition is generated from the same source using the same rules, just a different random seed, so the output is very comparable and accumulates as if the particles were born in one run. I understand that this pushes disk space requirements a lot, but Krakatoa was developed primarily for our inhouse effects and disk space is less of an issue (I hope our IT dept. does not read this thread ;))

We do not generate the millions of particles to get more density, we usually want them to get higher quality. The artificial multiplication of particles would make sense if we were unable to get the desired density, but would not help with quality at all, on the contrary.

To conclude, this is not a technical issue, but a concious design decision. If we ever see the need or get asked a lot for it, we could certainly do something about it. In fact, we have certain plans to improve the way particles are being drawn in the future, but I cannot discuss details yet.

SuperRune
08-29-2007, 05:53 PM
No problem Bobo, I fully understand your reasoning :) I just thought it would be a sweet option to have in those cases where volume and fluffiness is the goal - and not necessarily detailed wisps.

I am a fan of the camera-mapped approach, and have used it to do quick'n'dirty versions of waterfalls and smoke by mapping painted textures that look like particle clouds or volumes. But the camera-mapped stuff always fall apart when you rotate the camera/particles or some intersections gives away the texture planes. I imagined having fake volume particle clouds could be a nice way to workaround those issues. Then you could multiply one particle into a thousand and use that for what its worth :)

Looking forward to using Krakatoa more, nonetheless!

Rune

OlegB
08-29-2007, 06:51 PM
I imagined having fake volume particle clouds could be a nice way to workaround those issues.
IMHO, this workaround won't work. The issue is more complicated :(

Thanks,
Oleg B.

BrandonD
08-29-2007, 09:14 PM
I've gotten so used to doing the "add a cloud of sub-voxel particles around each particle" method at work that I'm almost scared to work anywhere else ;)

Glacierise
08-30-2007, 06:30 AM
Great tutorial, Bobo!

Bobo
08-30-2007, 11:14 PM
Great tutorial, Bobo!

And here is the MAXScript version of the same tutorial, for all you Box3less people ;)

http://www.franticfilms.com/software/support/krakatoa/particle_color_by_speed_using_maxscript.php

Surprisingly, the scripted version is "only' 3.6 times slower than the DataFlow version.
Of course, if you do some more complex maths inside or have to query geometry points and stuff, it could be well over 200 times slower. But for color or density calculations based on other particle properties like age, position, scale, speed etc, it is a fairly usable alternative.

A tutorial about controlling density by age should be next...

Bobo
09-01-2007, 01:32 AM
A tutorial about controlling density by age should be next...

...and it is now online:

http://www.franticfilms.com/software/support/krakatoa/fading_off_particle_density_by_age.php

This one contains both the Box #3 Data Operator and the Script Operator implementations of the effects. It is less colorful than the other tutorials, but people were constantly asking for it...

Bobo
09-03-2007, 10:04 PM
http://www.scriptspot.com/bobo/krakatoa_mini_logo.jpg

I am pretty sure PFlow #Box01 provides an operator to steal UV coordinates from any mesh, so that would also be a potential way to apply textures that match a model.


Ok, here is the newest tutorial which implements Camera Projection Mapping using Box #3 or alternatively a Script Operator (7 times slower!) and recreates the exact same effect seen in the Mini video without the use of an in-house Camera Map shader.

http://www.franticfilms.com/software/support/krakatoa/camera_mapping_particles_using_dataflow.php

Gravey
09-04-2007, 12:49 AM
Ok, here is the newest tutorial which implements Camera Projection Mapping using Box #3 or alternatively a Script Operator (7 times slower!) and recreates the exact same effect seen in the Mini video without the use of an in-house Camera Map shader.
Where is this mini video? I've seen that single frame everywhere but never a video. Can't find it on frantic's site either, maybe i'm not looking hard enough

and thanks for the tutorial bobo as always

Bobo
09-04-2007, 02:43 AM
Where is this mini video? I've seen that single frame everywhere but never a video. Can't find it on frantic's site either, maybe i'm not looking hard enough

and thanks for the tutorial bobo as always

Well, it was all over our booth at Siggraph, on the Frantic reel DVDs we were giving away there, and it is well hidden in an RnD reel on the Commercial Department's page as I mentioned several pages ago.
Go to
http://www.franticfilms.com/commercial/
then click on the Montage link. It is really small, but you'll get the idea.

Gravey
09-04-2007, 03:10 AM
cheers i'll check it out

paulselhi
09-04-2007, 03:41 AM
hi bobo, how would you go about getting the floor and other objects to reflect the newly mapped particles ?

Bye the way i am really impressed with the rendering blur it makes the teapot look perfect with only 2 million particles

Bobo
09-04-2007, 03:50 AM
hi bobo, how would you go about getting the floor and other objects to reflect the newly mapped particles ?

Right now, only through hacks.
One hack would be to create 6 cameras from the center of each object and render a "cubic environment reflection map" in Krakatoa which can be loaded into the old Reflect/Refract map in Scanline or any other renderer and would show the rendering of the particles as reflections. Mix it with a Raytrace map to get the rest of the scene reflected and voila.

We were thinking about adding some features to future Krakatoa versions to do something like this, or better, a single lat-long image for spherical reflections as we already do something like that for the Omni Shadows.

For flat reflections, all you would need is a camera transformed by the floor plane rendering the particles upside-down under the correct angle and then projecting the result back onto the scene in your renderer of choice. I will try a couple of tests and see how easy it is.

But we have some other ideas based on future technologies we are working on, let's see what will happen.

In general I have to admit that incorporating reflections of Krakatoa particles into other renderers is a rather weak point of the current version, but we had to start somewhere, and our post artists have never had any probelms faking reflections in Fusion using whatever we would render for them ;)

paulselhi
09-04-2007, 03:53 AM
lightwave has a material option akin to cctv whereby a mat can be based on the image seen by any camera, so you would place cameras at the object mid point and then use those cameras to automatically make mats for the objects

perhaps max will one day have something similar

PartiallyFrozen
09-05-2007, 03:05 PM
136.) It can render realflow sims.

http://farm2.static.flickr.com/1327/1330034963_d4b23251f5_o.jpg (http://partiallyfrozen.com/Movies/KrakRF.mov)

Mark Theriault
Technical Director
Frantic Films

noouch
09-05-2007, 04:38 PM
Looks like it would work well for foam/froth. I'm wondering, was every particle directly from realflow, or did you multiply them inside of pflow somehow?

JohnnyRandom
09-05-2007, 05:33 PM
136.) It can render realflow sims.

sweeeet!

Looks like it would work well for foam/froth.

I agree completely!

That has got to be the single most thing lacking with all fluid simulators, the ability got get some kind of internal air interaction with the fluid mesh. Every fluid sim I have seen just does not look right due to this.

I wonder is is possible to combine a realflow fluid mesh with a krakatoa particle flow? I mean so that there are two going on at the same time and somewhat appearing to be interacting.

PartiallyFrozen
09-05-2007, 06:33 PM
sweeeet!



I agree completely!

That has got to be the single most thing lacking with all fluid simulators, the ability got get some kind of internal air interaction with the fluid mesh. Every fluid sim I have seen just does not look right due to this.

I wonder is is possible to combine a realflow fluid mesh with a krakatoa particle flow? I mean so that there are two going on at the same time and somewhat appearing to be interacting.


You would be able to. I am just pulling in the RAW *.bin file into the PRT loader. So you could take that and also bring in the mesh and render a two pass. One would be the internal particles, and the other would be the mesh.

OR

Take the mesh bring it in and use it as a position object and or colision object. That would work but be wicked slow.


As for the foam idea, you could do it quite easily actually. Just use a clipping matte object through krakatoa and the PRT loader to cut out the particles you wouldnt need and then render what you need into a new prt loader. Then take that PRT and you can add some modifiers to it to give it better placement, sizing, and if need be FFD it to make it real nice.

mark

superhypersam
09-05-2007, 08:23 PM
PartiallyFrozen


were u able to get that level of density by partioning the realflow sim in Krakatoa (as with a basic pflow set up), or did u sim mass particles in realflow?


cheers

Bobo
09-05-2007, 08:46 PM
PartiallyFrozen

were u able to get that level of density by partioning the realflow sim in Krakatoa (as with a basic pflow set up), or did u sim mass particles in realflow?

cheers

RealFlow is particle-based. This is the native RF simulation, no tricks, just straight BIN loading and rendering in Krakatoa. Mark will check the actual count and post it when he finds a second (he is busier than me right now ;))

PartiallyFrozen
09-05-2007, 08:53 PM
RealFlow is particle-based. This is the native RF simulation, no tricks, just straight BIN loading and rendering in Krakatoa. Mark will check the actual count and post it when he finds a second (he is busier than me right now ;))

Ok so its exactly like bobo said. I simmed in realflow opened max, created a prt loader, picked the *.bin seq, hit render. No partitions. I did do a SUPER high particle count sim in realflow. That sim is actualy around 800 frames long and it took around 30 hours to sim. I think the counts were around 500,000 or so. Not 100% sure i will check when i get home.

superhypersam
09-05-2007, 09:04 PM
Thats what i figured, thx for the info.

I wonder if there is a workflow that would allow for a lesser particle count in realflow, and allow krak partioning too create the density.

Much like creating a coarse grid in Fume then using the fume follow operator, and krak to create a detailed version.

just a thought.

cheers

PartiallyFrozen
09-05-2007, 09:30 PM
Thats what i figured, thx for the info.

I wonder if there is a workflow that would allow for a lesser particle count in realflow, and allow krak partioning too create the density.

Much like creating a coarse grid in Fume then using the fume follow operator, and krak to create a detailed version.

just a thought.

cheers


Yeah i am not really sure at this point. I wish i had time to figure that out, haha. But i dont know because the partitioning changes the seed of the particles which gives it more girth. The realflow sim would just keep partitioning the same location of each point which wouldnt do anything helpful really. But it would be great to be able too. I know bobo had an idea....bobo?

Mark

Bobo
09-05-2007, 09:32 PM
Thats what i figured, thx for the info.

I wonder if there is a workflow that would allow for a lesser particle count in realflow, and allow krak partioning too create the density.

Much like creating a coarse grid in Fume then using the fume follow operator, and krak to create a detailed version.

just a thought.

cheers

Fume is different because it is grid-based and you can apply the velocity to any number of particles.
The alternatives would be to either emit particles in PFlow from exactly the same position and drive them with the RealFlow particles as proxies using a Box #3 Data Operator (but you would have to wait for the new and improved Krakatoa File Birth operator we are working on that will load full animated sequences), or to encode the RF velocities into a grid and drive the particles using that data (but there is no PFlow operator for that).

paulselhi
09-05-2007, 10:30 PM
getting back to the mapped particles tutorial i am having some problems with it. I replace the teapot with my own object and after some fiddling i can get a result to render. But then i save the max scene and later decide i want to adjust things, so i reopen max and now the particles lose their mappings, they render just as dots.

Apart from having to rebuild the whole scene is there something i am missing that is causing the mapping to fail ? As i said it works first time just looses the mapping when i reopen the scene

Bobo
09-05-2007, 11:01 PM
getting back to the mapped particles tutorial i am having some problems with it. I replace the teapot with my own object and after some fiddling i can get a result to render. But then i save the max scene and later decide i want to adjust things, so i reopen max and now the particles lose their mappings, they render just as dots.

Apart from having to rebuild the whole scene is there something i am missing that is causing the mapping to fail ? As i said it works first time just looses the mapping when i reopen the scene

Which method are you using? Box #3 Data Operator or MAXScript?
Those tutorials do not assign mapping, they project colors onto particles. So the question is - what color do the particles render in? Do they appear in the color of the Display operator in PFlow? Or white? Or black? Or some other color? This info could help debug the issue...
For example, when I first started writing the tutorial, I had some values wrong and got all particles to render in the color found in the center of the plane object, it was a shade of blue not found anywhere else so it made it obvious I was using incorrect positions when sampling the colors. ;)

paulselhi
09-05-2007, 11:02 PM
it is very hit and miss, i seem to somehow have got it to work, but of course when i reopen the scene it fails again, it must be an issue with the data operators, somehow moving them in the pflow stack and then putting them back seems to kick iit into gear.

This may be nothing to do with krak but i notice that on rendering using krak my alpha image is always far bigger than the rgb image, so the alpha is not a lot of use, ut extended areound my rgb by many pixels, any i dea what i am doing wrong there ?

Bobo
09-05-2007, 11:05 PM
This may be nothing to do with krak but i notice that on rendering using krak my alpha image is always far bigger than the rgb image, so the alpha is not a lot of use, ut extended areound my rgb by many pixels, any i dea what i am doing wrong there ?

Never seen anything like that. Can you post an RGB and an Alpha image to illustrate the result? Also, what format are you saving to and with what settings?

paulselhi
09-05-2007, 11:07 PM
Bobo i am using the pflow box 3 method, when they do render the particles are superb it is just that more often than not they do not pick up the colors via your plow data setup and will just rendrer as white dots

OlegB
09-05-2007, 11:12 PM
Paul,

it must be an issue with the data operators, somehow moving them in the pflow stack and then putting them back seems to kick iit into gear.
As for Box#3 (with Data Operator) - what do you have - ACAP or non-ACAP version?

Thanks,
Oleg B.

paulselhi
09-05-2007, 11:14 PM
Never seen anything like that. Can you post an RGB and an Alpha image to illustrate the result? Also, what format are you saving to and with what settings?

here are the 2 images. Now it may just be that i don't know enough about MAX !! I am using a clients machine and they are not avialbale to interrogate over the ins and outs of MAX rendering !!

http://www.black-and-white-to-color.com/stuff/test3.tga
http://www.black-and-white-to-color.com/stuff/A_test3.tga

don't know if these are showing up but here are the jpgs to see the size difference

http://www.black-and-white-to-color.com/stuff/test3.jpg
http://www.black-and-white-to-color.com/stuff/A_test3.jpg

http://www.black-and-white-to-color.com/stuff/test3.tga

Bobo
09-05-2007, 11:20 PM
here are the 2 images. Now it may just be that i don't know enough about MAX !! I am using a clients machine and they are not avialbale to interrogate over the ins and outs of MAX rendering !!

http://www.black-and-white-to-color.com/stuff/test3.tga
http://www.black-and-white-to-color.com/stuff/A_test3.tga

don't know if these are showing up but here are the jpgs to see the size difference

http://www.black-and-white-to-color.com/stuff/test3.jpg
http://www.black-and-white-to-color.com/stuff/A_test3.jpg

http://www.black-and-white-to-color.com/stuff/test3.tga

Oh wow, this looks scary. Never seen that difference, but who knows, it could be related to the fact you are saving TGA, possibly with pre-multiplied off and split alpha - will have to try here and see what that does.
Have you tried OpenEXR? Does the alpha look OK there or not? (It is the de-facto standard in the VFX industry nowadays)

paulselhi
09-05-2007, 11:24 PM
i have tried it will all combinations, tgas, tiff exr, premutipled seperate alphas and combined alphas..in fact i am going alpha stir crazy !!

Bobo
09-05-2007, 11:26 PM
Need clarification - are these RGB and Alpha from a Projection test? If yes, it is possible that the skull is projected incorrectly onto a much larger particle cloud. The projection sets only the RGB, the Alpha would be the size of the actual particle cloud. So if the projection is wrong for some reason (like the plane is the wrong size, or there is a bug somewhere in the Data Operator, or the projecting camera has a different FOV or position than the one used to render the RGB), the RGB can appear smaller than the actual particle "canvas".

If you hit the Override Colors and set all particles to White, do you get an RGB the size of the Alpha?

paulselhi
09-05-2007, 11:49 PM
ok let me do some more tests, it could well be due to cameras, what i did was texture the skull in cinema 4d and then rendered a view for the plane in max

I then saved out as fbx ( camera and skull) and took that into max and simply changed the camera in the data operator to the new camera and replced the mat on the plane with the new one

the reason i did this is that i already had the skull textured in c4d, my app of choice, i am veryt shaky with max and will have to bite the bullet and retexture it in max and see if it was a camera issue, but correct me if i am wrong but there is only one camera the view camera, i don't see any other hidden cameras in your scene file

Bobo
09-06-2007, 01:17 AM
ok let me do some more tests, it could well be due to cameras, what i did was texture the skull in cinema 4d and then rendered a view for the plane in max

I then saved out as fbx ( camera and skull) and took that into max and simply changed the camera in the data operator to the new camera and replced the mat on the plane with the new one

the reason i did this is that i already had the skull textured in c4d, my app of choice, i am veryt shaky with max and will have to bite the bullet and retexture it in max and see if it was a camera issue, but correct me if i am wrong but there is only one camera the view camera, i don't see any other hidden cameras in your scene file

Aha. FBX.
FBX is notorious for not transfering camera data correctly. (Same problem between Max and Maya, FOV comes over wrong).
In my example, I used the SAME camera to render the original image and the Krakatoa image, and used it also for the projection.
In your case, the RGB comes from C4D, while an imported camera (potentially different!) is being used for the projection and rendering.

The simplest thing to do is to make sure the FOV and Focal Length of the Camera in Max match the settings in C4D (I bet it does not). Focal Length and FOV are connected via the Aperture Width (mm) in the Render Scene Dialog in Max, which FBX "forgets" to take into account in some cases. Once you get your Max Camera to match perfectly the C4D camera, the projection should align with the particles. At least I hope it would...

(You should have stated ALL this information 5 posts ago - I spent some time to test Krakatoa's Alpha channel saving to TGA to make sure I am getting correct results, while you were using a completely different 3D application for part of the setup, and forgot to mention it... Wasting time, aren't we? ;))

paulselhi
09-06-2007, 03:23 AM
hey Bobo ..chill out..relax..keep your hair on !!! Yes indeed it was a camera issue.
now to show this to the c4d gurus in the hope that they may find a way to work with krakatoa, they are quite ingenious and may find a way to bridge

paulselhi
09-06-2007, 05:07 AM
Paul,


As for Box#3 (with Data Operator) - what do you have - ACAP or non-ACAP version?

Thanks,
Oleg B.

not too sure Oleg, i will ask the owners of the s/w later today, all i know is it's v 1.07 i think, i really don't know what ACAP and non ACAP are !!

OlegB
09-06-2007, 11:33 AM
i will ask the owners of the s/w later today

Do not bother :)

PLEASE with the future posts disclose such important information as the Cinama4D usage. You have really wasted a lot of time that Bobo could have used to write more tutorials on Krakatoa (and Box#3) usage.

Thanks,
Oleg B.

bealobo
09-07-2007, 08:49 AM
I have tosay that I've tested krakatoa for 5 minutes and I was impressed! you really did a good job!
I'm looking forward to have more time to play with it.
Cheers!

grury
09-07-2007, 10:42 AM
Hi Bobo, quick question:

Would it matter if the Floating License server machine is 32 bit, and we want to use some 64 bit machines to run Krakatoa.

Cheers

Bobo
09-07-2007, 02:39 PM
Hi Bobo, quick question:

Would it matter if the Floating License server machine is 32 bit, and we want to use some 64 bit machines to run Krakatoa.

Cheers

I am pretty sure it wouldn't matter - although I think we ship a 64 bit version of the license tools, we actually install the 32 bit FlexLM regardless of OS version since it is compatible. I am not a specialist when it comes to licensing, will talk to the developers to make sure that's right.

jabbermacy
09-09-2007, 07:51 PM
A 32bit license server is totally fine whether the host is 64bit or 32bit. Trust. We even run license servers in VMware for some applications to bypass some hardware incompatibility issues - 'virtualization' - it's the next big thing ;)

grury
09-10-2007, 06:55 AM
Thanks guys.

Bobo
09-13-2007, 11:54 PM
Studio Daily Krakatoa Overview Videos:

http://www.studiodaily.com/main/news/feed.rss/8500.html

vertigo
09-14-2007, 09:36 AM
Wow! These Tutorials look great! Especially the one with the Mini!

Bobo, I've got a question about the Mini-mapping though: Can it be achieved only by using the Box#3? Or is there any other possibility? Maybe a script operator? And what if we want to apply the mapping to movable objects, let's say a character, who then dissolves?

Thanks in advance!

Greets
vertigo

Bobo
09-14-2007, 02:16 PM
Wow! These Tutorials look great! Especially the one with the Mini!

Bobo, I've got a question about the Mini-mapping though: Can it be achieved only by using the Box#3? Or is there any other possibility? Maybe a script operator? And what if we want to apply the mapping to movable objects, let's say a character, who then dissolves?

Thanks in advance!

Greets
vertigo

You must have missed this:
http://www.franticfilms.com/software/support/krakatoa/camera_mapping_particles_using_dataflow.php

It would work with anything incl. characters, but with an animated object the workflow would be slightly more complicated because the particles would be moving with the surface and would have to update their position data conditionally until sent out to the event where they start dissolving. In the case of a static object, this data initialization happens only on the first frame...

vertigo
09-17-2007, 09:55 AM
Thank you for the link, Bobo. :thumbsup:

But it seems that the shown technique cannot be applied on moving objects or object groups (like many characters). And what if I had some camera motion around the character. Would that mix up the projection of the particles?

Thanks in advance!

Greets
vertigo

Bobo
09-17-2007, 02:35 PM
Thank you for the link, Bobo. :thumbsup:

But it seems that the shown technique cannot be applied on moving objects or object groups (like many characters). And what if I had some camera motion around the character. Would that mix up the projection of the particles?

Thanks in advance!

Greets
vertigo

You can have camera motion - see the Mini animation here:
http://www.franticfilms.com/software/support/krakatoa/downloads/CPember_MiniCooper_siggraph06.mov
Just make sure you project an animated sequence rendered from the same moving camera.

I don't see why you cannot project onto any number of characters - Krakatoa works with particles and does not care where the particles came from, it sees a single cloud of particles. So if you have N particle systems with N data operators or use a single flow to "particularize" all characters at once, Krakatoa wouldn't care. Alternatively, you could do it in passes as most people do in VFX and combine them in post.

Krakatoa is just a tool - it does not solve creative problems, that's the job of the artist. It just draws points. ;) There are limitations as there are workarounds, too. If you find a limitation you cannot work around at all, post a wish at the Krakatoa support forum and we might add some new feature to help...

plug3
09-19-2007, 02:10 AM
In Krakatoa can you assign different PFlow events to be saved to different files?

Bobo
09-19-2007, 04:57 AM
In Krakatoa can you assign different PFlow events to be saved to different files?

Yes and no. Yes, you can exclude/include events from rendering/saving by setting their Render operator to a different mode (for example Geometry, Phantom and Box modes can be excluded separately) so if you are interested in just the particles in one or more specific events and not in the rest, you can selectively save/render only those.
But you cannot save 10 events to 10 different file sequences in ONE pass, like hit one button and get 10 different sequences automatically. You would have to process the PFlow multiple times, each time saving another event to a different file sequence, so it is a bit slower than it could be, but still possible.

See the following FAQ entry:
http://www.franticfilms.com/software/support/krakatoa/frequently_asked_questions.php#Rendering_Specific_Particle_Flow_Events

PsychoSilence
09-19-2007, 02:58 PM
hy Krakatoa community,
i have a lil problem with the color by speed using data flow tutorial:
http://www.franticfilms.com/software/support/krakatoa/particle_color_by_speed_using_dataflow.php

it says:

Note that Krakatoa will use the Vertex Color Channel values of a Particle Flow if no material is
assigned explicitly to the Flow using a Material operator. Alternatively, you could assign the
vector calculated by the Data Operator to any of the other 99 mapping channels and use a Material
with a Vertex Color Map pointing at that channel assigned to a Material Dynamic operator,
but this setup would render slower because the material would have to be evaluated for each particle
on each frame. Using the Vertex Color Channel directly, the Krakatoa particle color channel is set
internally without the material evaluation overhead!

i wanna go the dynamic material way with vertex map in the diffuse/self/illum channel since i wanna be able to render it with scanliner/max8 too. but dont know how to assign the vertex color channel(s) to the vertex map? :cry::cry:

can anyone eventually bobo himself help out?

kindest regards,
anselm

Bobo
09-19-2007, 09:50 PM
i wanna go the dynamic material way with vertex map in the diffuse/self/illum channel since i wanna be able to render it with scanliner/max8 too. but dont know how to assign the vertex color channel(s) to the vertex map? :cry::cry:

can anyone eventually bobo himself help out?

kindest regards,
anselm

It just happens that I am rendering velocity passes using Data Operators, Vertex Colors and Scanline right now :)

Can you tell me what does not work?
Here is my simple setup for velocity pass in Scanline I am using on a project. You should be able to render the tutorial from the Krakatoa page the same way:

*Data Operator has a Stadard Input reading Velocity Magnitude.
*I connected the Float output with a Standard Output set to Vertex Color Channel.
*This gave me a Converter sub-op where I fed in 0.0 from a Scalar to Y and Z, so my vertex color is RED when particles are moving fast and black when not moving.
*I placed a Material Dynamic operator with a Self-Illuminated Standard Material and a Vertex Color map in the Diffuse Slot in the Emitter's event and Scanline renders the colors without problems...

I would assume Krakatoa would render the same setup. Where does it fail?

PsychoSilence
09-20-2007, 01:39 PM
hm...i still run max8 so i reproduced the tutorial from sratch which seemed to be a better practise anyways.

i attached a screen capture :(

kindest regards,
anselm

Bobo
09-20-2007, 02:30 PM
hm...i still run max8 so i reproduced the tutorial from sratch which seemed to be a better practise anyways.

i attached a screen capture :(

kindest regards,
anselm

You are writing to Vertex Color Channel, but your Vertex Color Map is set to Channel 1 (first UV channel), not to Channel 0 (Vertex Color channel, default). Either switch the Standard Output to Map #1 or change the VC Map to channel 0 to match the setup in the Data Operator...

PsychoSilence
09-20-2007, 02:54 PM
hm, tried that too :(

Bobo
09-20-2007, 04:09 PM
hm, tried that too :(

It works. I had to switch to Scanline though, but I am sure VRay will look the same in this case.

Your scene has a different scale, so your velocities were much higher than mine. The resulting vertex color data was WAAAAY above 1.0,1.0,1.0 (pure white). Thus, all your particles would look solide white.

You can enter a 0.05 Post-Multiplier in all Functions affecting the final value of R, G and B to redice your values to the range of 0.0 - 1.0 (right-click the Real-->Vector converter and select Show Data to see what colors are being generated.

You don't need a map in the self-illumination slot, but you have to set the Opacity to less than 100 (like 99) and then switch the Transparency mode to Additive in the Extended Parameters of the material - the Krakatoa example used Additive shading.

Also, the size of the shapes might be too small to be visible, consider increasing them to 0.2 while testing to get a better idea of the color, then increase the number of particles and go back to 0.1 size for the final shading.

PsychoSilence
09-20-2007, 04:56 PM
works like a charme now! thanks bobo :)

i totally overlooked the scene scaling... :(

entrancea
09-21-2007, 08:15 AM
I have heard that you can use Krakatoa to export Pflow Particles to Realflow...

entrancea
09-21-2007, 08:15 AM
Could someone please help me out as to how I can export Max's PFlow particles to Realflow4 as .bin file sequence?

Thanks a lot.

Bobo
09-21-2007, 02:55 PM
Could someone please help me out as to how I can export Max's PFlow particles to Realflow4 as .bin file sequence?

Thanks a lot.

*In Krakatoa, set the render mode to "Save Particles to File Sequence".
*Select a save file name and specify the .bin extension (alternatively, expand the Advanced File controls and enter the path there - you will see small buttons for quickly switching between PRT, CSV and BIN types).
*Save.

NOTE: RealFlow expects the file to have 5 trailing digits. Krakatoa will also warn you about this. You can save BIN files from Krakatoa with any name and numbers, but Realflow will only read the sequence if it has 5 digits.

We have heard of some problems with particles not moving correctly after loading in Realflow - if you find any problems with the files, please let us know!

entrancea
09-22-2007, 03:46 AM
Thanks Bobo:thumbsup: ,

I'll start my work on it today evening and once I export it I'll give you the feedback as to hows it works out.So like when I am saving it....say I wan to save it with the name "waterfall"....Then when saving in Krakatoa will I save it with the name "Waterfall_00000.bin"?

Thanks a lot,
Cheers

PS:-Bobo,could you please tell me as to how I could learn intermediate level Pflow scripting from?Are there any tutorials?Do you have any?Thanks a lot.

Bobo
09-22-2007, 04:23 AM
Thanks Bobo:thumbsup: ,

I'll start my work on it today evening and once I export it I'll give you the feedback as to hows it works out.So like when I am saving it....say I wan to save it with the name "waterfall"....Then when saving in Krakatoa will I save it with the name "Waterfall_00000.bin"?

Thanks a lot,
Cheers

PS:-Bobo,could you please tell me as to how I could learn intermediate level Pflow scripting from?Are there any tutorials?Do you have any?Thanks a lot.

Yes, waterfall_00000.bin or waterfall00000.bin are both legal file names in RealFlow. Krakatoa itself doesn't really care though. Even waterfall0100000.bin is a valid name - RF is hard-coded to always use the last 5 digits, so names like Circle0100000.bin are typical...

I wanted to note that this should work even in demo mode, so anyone with an evaluation installation of Krakatoa can use the saving feature - it is not affected by the licensing, so it is actually free!

As for PFlow, I was working on a DVD along these lines, but job and consulting work for Autodesk came in the way. I intend to finish it soon though. Scripting PFlow is VERY straight-forward. It is the PFlow knowledge you need, not scripting knowledge. You just want to tell your particles what to do, the syntax is rather simple.
An alternative is Box #3 by Orbaz which does the same faster and in a much more visual way.

entrancea
09-22-2007, 07:21 AM
As for PFlow, I was working on a DVD along these lines, but job and consulting work for Autodesk came in the way. I intend to finish it soon though. Scripting PFlow is VERY straight-forward. It is the PFlow knowledge you need, not scripting knowledge. You just want to tell your particles what to do, the syntax is rather simple.
An alternative is Box #3 by Orbaz which does the same faster and in a much more visual way.


Thanks Bobo.I would be looking forward for the tutorial when you release it:bounce: .And I will discuss with my employer to see if we can take Box#3 in for PFlow....What is special about box#3?And how much is the difference gap between Pflow with Box#3 and Thinking Particles?
I have seen Thinking particles interface and personally feel that Pflow is way user_friendly in comparison:) ....Though I am sure that if you practice the software a lot it will seem a lot more easier..he he..

Thanks and Cheers

entrancea
09-22-2007, 07:39 AM
Also I had a question that my default max PFlow particle amount is set to 1million.however I cant seem to increase it more than that.How can I max it up?

Thanks.

Bobo
09-22-2007, 05:15 PM
Also I had a question that my default max PFlow particle amount is set to 1million.however I cant seem to increase it more than that.How can I max it up?

Thanks.

The SPINNER in the PFlow Emitter is limited to 10 million, but it can be set internally to higher values via MAXScript. Krakatoa automatically increases this limit of all existing Emitters to 100 million when you open the Krakatoa GUI (but you will see the spinner showing 10). In Max 2008, this artificial limit will be lifted as we made it obvious that Max 64 bit can handle large amounts of particles as is.

A single Birth operator can create up to 10 million particles, but you can use multiple birth operators. Of course, we advise Krakatoa users to employ the Partitioning method for increasing the density instead of creating dozens of millions.

Bobo
09-22-2007, 05:23 PM
Thanks Bobo.I would be looking forward for the tutorial when you release it:bounce: .And I will discuss with my employer to see if we can take Box#3 in for PFlow....What is special about box#3?And how much is the difference gap between Pflow with Box#3 and Thinking Particles?
I have seen Thinking particles interface and personally feel that Pflow is way user_friendly in comparison:) ....Though I am sure that if you practice the software a lot it will seem a lot more easier..he he..

Thanks and Cheers

Box #3 makes PFlow operate in a very similar manner when it comes to controlling particles at the channel level, while still keeping the rest of the workflow simple. It is a visual programming environment where you can read, manipulate and write data from arbitrary channels, or even from different particle systems. See the tutorials I posted to the Krakatoa page:

http://www.franticfilms.com/software/support/krakatoa/particle_color_by_speed_using_dataflow.php
http://www.franticfilms.com/software/support/krakatoa/camera_mapping_particles_using_dataflow.php

What PFlow is still missing and what makes TP a great system is the fracturing and dynamics operators. These will be added via Box #2 which is in the works.

entrancea
09-23-2007, 02:30 AM
What PFlow is still missing and what makes TP a great system is the fracturing and dynamics operators. These will be added via Box #2 which is in the works.


So what your saying,I believe is that with the integration of all the Box#'s with PFlow,it will be at par with TP?When is Box#2 stated to release?

entrancea
09-23-2007, 02:51 AM
Also while using Krakatoa I saw that I couldnt use partilce age or gradient ramp mapping for my particles....why is that?I added the materials in the PFlow and also specified Krakatoa to use Material Editor Map Slot#1.....Is there something I am doing wrong here?

Thanks.

entrancea
09-23-2007, 04:41 AM
For sometime now I was thinking of creating my CG_name Logo ie "entrancea"....Last night I completed it....Its a Mid_Res 8.2mb quicktime video file....Could have uploaded a smaller file but would then have lost out on the detail.....Comments are appreaciated:).I used PFlow and Krakatoa for this.

Thank you.


http://download.yousendit.com/33DC86D34DCBBF8E (http://download.yousendit.com/33DC86D34DCBBF8E)

Glacierise
09-23-2007, 04:58 AM
So what your saying,I believe is that with the integration of all the Box#'s with PFlow,it will be at par with TP?When is Box#2 stated to release?

It is entering beta now, so it's not so far from release!

Bobo
09-23-2007, 05:17 AM
Also while using Krakatoa I saw that I couldnt use partilce age or gradient ramp mapping for my particles....why is that?I added the materials in the PFlow and also specified Krakatoa to use Material Editor Map Slot#1.....Is there something I am doing wrong here?

Thanks.

Regarding Particle Age Map, please read the Krakatoa Frequently Asked Questions:
http://www.franticfilms.com/software/support/krakatoa/frequently_asked_questions.php#Can_I_specify_Particle_Color_and_Density_Per_Particle.3F
The main reason is that in the Max SDK, the Particle Age Map is implemented in a hacky way (to say the least) and we attempt to stay away from unclean solutions, so we removed support for the Particle Age Map early on. We are working on a better solution for the future, in the mean time you can use Box #3 or MAXScript to get similar results.

Gradient Ramp should work though as long as it is applied in world space. If it is applied to a UV Map channel, you will have to make sure the particles have such a channel applied (using Box #1 to get UVs from a reference mesh, or Box #3 or MAXScript to set the values directly into the UV Channel)

entrancea
09-23-2007, 05:34 AM
Hmmmm....thats interesting....Well so I guess the only approach is gradient ramp and keying the colour change,or use Box# or a Script.

Thanks,

entrancea
09-24-2007, 02:57 AM
I was going through the earlier posts and saw Richard Dr. Baily (http://www.imdb.com/name/nm0047665/)'s awe-inspiring and regardless to say Jaw Dropping Spore Designs....truely inspirational.....Just wanted to know that were those completely done with Scripting?

Bobo
09-24-2007, 04:59 AM
I was going through the earlier posts and saw Richard Dr. Baily (http://www.imdb.com/name/nm0047665/)'s awe-inspiring and regardless to say Jaw Dropping Spore Designs....truely inspirational.....Just wanted to know that were those completely done with Scripting?

No, Doc Baily actually compiled his designs in C code - scripting would have been too slow for what he did. Since the particles were generated procedurally and accumulated additively (meaning that other than the volumetric rendering in Krakatoa, the particles could be drawn without being loaded at once into memory), his designs often consisted of many billions of particles. The initial version of our point renderer (which eventually evolved into Krakatoa) also did that - we might even re-enable that processing capability for additive shading in Krakatoa in the future.
Doc's work inspired us and we are very proud to have been influenced by his development. We worked successfully together on two movies (Stay and Superman Returns) and wish he would have lived to see Krakatoa today...
At the end of the day, there are several applications out there that allow people to create similar designs (even incl. Box #3), but it is not the technology, it is the ARTIST who is responsible for the outcome. This is why the Image Savant page still is and will remain inspirational.

entrancea
09-25-2007, 01:59 AM
Yes....True Inspiration......And will always be.....And Yes!Agreed!Its not the tool that creates the art but the artist who creates it and Doc's work inspired me a lot.....I bow to him:bowdown: ......I also wanted to know a little more about Box#3 and its Data Operator....Is seems like a Pandoras Box(sort-o-speaking:) )....what is the logic behind it?

Also I tried to export the Realflow .bin files from Krakatoa and it worked:thumbsup: ....

Thanks and Cheers.

Bobo
09-25-2007, 03:16 PM
I also wanted to know a little more about Box#3 and its Data Operator....Is seems like a Pandoras Box(sort-o-speaking:) )....what is the logic behind it?


Well, Pandora's Box was an Evil Thing, this one isn't ;)
You should go to http://www.orbaz.com , download the demo version and see for yourself.

In short, it is a visual programming environment where, instead of scripting your code using a text-based language, you define your program flow using sub-operators the same way you wire operators in Particle View. For example, if you want to read each particle's speed and scale the particle along the Z axis based on the speed magnitude, you create a Standard Input sub-operator and set it to read the speed magnitude, a Standard Output and set it to output the Scale Z, wire the output of the first subop to the input of the second sub-op and for every particle in the particle container where the Data Operator is placed, the speed will determine the Z scale.

The beauty of this approach is that it is easier to read than written code and is many times faster than scripted operators.

The Data Operators provide a large number of mathematical functions, operators for reading geometry data, collecting and everaging data about other particles, accessing data from OTHER particle systems in the scene (for example to drive hi-count particle systems with low-count proxy particles in a way similar to how you use SkinWrap to drive hi-res meshes with low-res ones) and much more.

In short, using Data Operators you can recreate all the operators that already ship with PFlow, and most of the operators you wish would ship with PFlow but do not. ;)

entrancea
09-25-2007, 03:27 PM
Well, Pandora's Box was an Evil Thing, this one isn't ;)
You should go to http://www.orbaz.com (http://www.orbaz.com/) , download the demo version and see for yourself.

In short, it is a visual programming environment where, instead of scripting your code using a text-based language, you define your program flow using sub-operators the same way you wire operators in Particle View. For example, if you want to read each particle's speed and scale the particle along the Z axis based on the speed magnitude, you create a Standard Input sub-operator and set it to read the speed magnitude, a Standard Output and set it to output the Scale Z, wire the output of the first subop to the input of the second sub-op and for every particle in the particle container where the Data Operator is placed, the speed will determine the Z scale.

The beauty of this approach is that it is easier to read than written code and is many times faster than scripted operators.

The Data Operators provide a large number of mathematical functions, operators for reading geometry data, collecting and everaging data about other particles, accessing data from OTHER particle systems in the scene (for example to drive hi-count particle systems with low-count proxy particles in a way similar to how you use SkinWrap to drive hi-res meshes with low-res ones) and much more.

In short, using Data Operators you can recreate all the operators that already ship with PFlow, and most of the operators you wish would ship with PFlow but do not. ;)




Oh Man!Way Cool.....Thanks a lot for the info Bobo.....I have already started working on it....:thumbsup:

JohnnyRandom
01-06-2008, 12:46 AM
Nice write up and recommendation (9 of 10 :)) in this months 3dWorld Mag (http://www.3dworldmag.com/page/3dworld?entry=b_3d_world_100_now) (Feb. 08)

Cheers guys:thumbsup:

floopyb
02-12-2008, 12:10 AM
How do people go about incorperating matte objects that use a decent amount of vray (or other microtriangle) displacement. Obviously Krakatoa cant render them correctly. Do you just use Standard max displacemnt with a tonne of meshsmooths?
Cheers

Bobo
02-12-2008, 01:18 AM
How do people go about incorperating matte objects that use a decent amount of vray (or other microtriangle) displacement. Obviously Krakatoa cant render them correctly. Do you just use Standard max displacemnt with a tonne of meshsmooths?
Cheers

Actually, Krakatoa can deal with that, provided you render a Z-Depth pass from VRay.
Then you can load that Z-Depth pass as "Initial Depth Map":
http://www.franticfilms.com/software/support/krakatoa/matte_objects.php#Load_Initial_Depth_Map_File_Sequence

Krakatoa will then occlude any particles whose Z-depth is farther than the value stored in the initial map sequence. Thus, particles behind VRay displaced geometry would not be rendered.

We developed this method to use in Gelato which we employed for fast displacement and stereo rendering on the upcoming "Journey 3-D" movie. Thus, the native Depth mode of Krakatoa matches that of Gelato - it uses generic units stored in a floating point image.
But we also provide Depth Map modes compatible with 3ds Max' own Z-Depth pass and with V-Ray's default Z-Depth pass. Please see the documentation for details. Obviously, you will have to enter the correct Near and Far values used in the other renderer for Krakatoa to match the same depth...

floopyb
02-12-2008, 01:51 AM
Ahhh, great to hear that Bobo. Cheers!

Chrysley
02-23-2008, 02:41 PM
Does krakatoa support motion blur for the old max particles? I tried it out but no matter what settings I choose, there's still no motion blur on my Parray particles saved to a PRT file. Also does density affect motion blur in any way? Coz I used low particle count with a "5.0 , -1" density setting.

jigu
02-23-2008, 03:06 PM
yes, Krakatoa supports motionblur. You need to turn on motionblur in krakatoa render diloge window.

Bobo
02-23-2008, 03:50 PM
Does krakatoa support motion blur for the old max particles? I tried it out but no matter what settings I choose, there's still no motion blur on my Parray particles saved to a PRT file. Also does density affect motion blur in any way? Coz I used low particle count with a "5.0 , -1" density setting.

I think you found a bug! (Congratulations!) ;)
Looking at the data saved from a PArray, it seems that the velocity is saved as units per tick instead of units per second. In other words, the velocity vectors are 4800 times shorter and of course it looks like the particle is not moving at all.
(You can see this by saving to a CSV file instead of BIN - CSV is just a Comma-Separated List text file).

Shows how nobody has really used the Legacy Particles with Krakatoa, this bug should have been discovered much earlier ;)

This should be fixed in the upcoming 1.1 update.

Regarding Density and Motion Blur, Motion Blur will decrease the apparent intensity of a moving particle because the particle will be spread across multiple pixels. If you are using, say, 16 passes MBlur, the particle will be drawn 16 times and each pass will be accumulated into the final result with 1/16 of its value. If a particle is not moving, the pixel it occupies would be filled as if there were no motion blur. But if it hits 16 different pixels, the final image will contain 1/16 of each pass and thus moving particles will appear dimmer.

If you have enough particles to accumulate, your settings would work ok, but these defaults were designed for rendering PFlow with 100K+ particles, while a PArray cannot generate more than 65K particles unless you partition it. So using higher density settings might become necessary once we fix the motion blur of Legacy Particles...

Chrysley
02-23-2008, 04:03 PM
I think you found a bug! (Congratulations!) ;)
Looking at the data saved from a PArray, it seems that the velocity is saved as units per tick instead of units per second. In other words, the velocity vectors are 4800 times shorter and of course it looks like the particle is not moving at all.
(You can see this by saving to a CSV file instead of BIN - CSV is just a Comma-Separated List text file).

Shows how nobody has really used the Legacy Particles with Krakatoa, this bug should have been discovered much earlier ;)

This should be fixed in the upcoming 1.1 update.

Thanks for the immediate reply. Just glad to be of help finding out the bug. Krakatoa is awesome!

Bobo
03-06-2008, 08:10 PM
Thanks for the immediate reply. Just glad to be of help finding out the bug. Krakatoa is awesome!

JFYI, this bug was fixed and Krakatoa 1.1.0 is about to be released early next week...

Daniel-B
05-11-2008, 12:43 AM
Here is a rundown of my test for creating water splashes with Krakatoa, or any other point volumetric particle renderer. It has not been perfected yet, as this is my very first attempt.

First off, I want to make it clear that I am not a particle artist. I haven't really learned how to do advanced particles yet. However, a friend of mine has. He supplied me with a few Krakatoa passes. We had brainstormed together on how to create water splashes like ILM did for Poseidon and the Pirates of The Carribean trilogy, and Digital Domain did for Day after Tomorrow.

Now, I created most of this look in compositing...so bare that in mind. I cannot help you create the Pflow or anything like that, because I don't know how. Also, I apologize, but this will be a long post. Here we go. :)

First I started off with a background plate, as you see below.

http://img.photobucket.com/albums/v58/PixelMagic/bg_splash.jpg

As we all know, large splashes of water heavily refract their backgrounds, so I used the particle pass's alpha to blur the background only in that area...like so...

http://img.photobucket.com/albums/v58/PixelMagic/bg_refract.jpg

Also using the alpha, I created an "ambient lighting pass" using colors sampled from the dark areas of the background plate.

http://img.photobucket.com/albums/v58/PixelMagic/ambient.jpg

Also, I used a separate lighting pass...

http://img.photobucket.com/albums/v58/PixelMagic/lighting_ambient.jpg

Combining the lighting passes, and the refraction, you get the final splash element...

http://img.photobucket.com/albums/v58/PixelMagic/splash.jpg


And the final...

http://img.photobucket.com/albums/v58/PixelMagic/final.jpg


I know the final doesn't look 100% photoreal, but this is just a test. Just something to remind you that different visual effects can be created when you think outside the box :)

feldy
05-11-2008, 02:19 AM
nice break down anyways looks cool

JohnnyRandom
05-11-2008, 03:12 AM
Just to say, nice, looks good:)

Bobo
05-11-2008, 05:37 PM
Here is a rundown of my test for creating water splashes with Krakatoa, or any other point volumetric particle renderer. It has not been perfected yet, as this is my very first attempt.

First off, I want to make it clear that I am not a particle artist. I haven't really learned how to do advanced particles yet. However, a friend of mine has. He supplied me with a few Krakatoa passes. We had brainstormed together on how to create water splashes like ILM did for Poseidon and the Pirates of The Carribean trilogy, and Digital Domain did for Day after Tomorrow.

Now, I created most of this look in compositing...

Beautiful!
In fact, you have discovered the main secret of Krakatoa - it is not a renderer for creating nice particle renders, but beautiful particles PASSES. The real magic always happens in Post ;)
We have plans to provide better output passes support in future versions of Krakatoa, since right now it is a bit tricky to get what you need (like diffuse, specular, lighting, z-depth etc.).

Thanks for sharing!

Daniel-B
05-11-2008, 08:17 PM
Beautiful!
In fact, you have discovered the main secret of Krakatoa - it is not a renderer for creating nice particle renders, but beautiful particles PASSES. The real magic always happens in Post ;)
We have plans to provide better output passes support in future versions of Krakatoa, since right now it is a bit tricky to get what you need (like diffuse, specular, lighting, z-depth etc.).

Thanks for sharing!

Thanks, Bobo. For what I was trying here, Krakatoa worked fine. I asked my friend for specular pass, and he said the menu had a specular and glossiness option, but it didn't really seem to affect the particles.

Man, this was so fun, I'm going to have to learn particles now....heh.

Bobo
05-12-2008, 01:24 AM
I asked my friend for specular pass, and he said the menu had a specular and glossiness option, but it didn't really seem to affect the particles.

For the specular shading to work, the particles must contain a Normals channel. It is populated with the X axis of particles in PFlow or with the surface normals of vertices when saving geometry to PRT. If no Normals channel was provided, no specular highlights will be calculated and the particles will generally render black because the default normal value would be an invalid vector [0,0,0].
For the next version, we are adding anisotropic shading controls. This would require a second tangent vector to work.

Currently, there is no good way to separate the specular from the diffuse. More control in this area is on our ToDo list.

ctp
05-13-2008, 09:33 AM
Just wanted to jump in and say what an exciting read this is!!! I have yet to try out Krakatoa, but I definitely will.
I've long been frustrated with the lack of serious particle render engines. Usually renderers support only a few features for particles and handle only small amounts and too slowly.
The best solution I've tried so far is Pixars Renderman, on a project where I rendered up to 30 million self-shadowing point particles, and had the render farm been fed more RAM, it would easily have dealt with a higher count.

But it's so good to see a render engine being developed specifically for particles. Huge amounts. And even inspired by Richard Bailey's work, which is another reason I'm looking for something like Krakatoa :)

Now, being a Maya user, working at an all-Maya studio, I'll have to add a shout to the calls for a version of Krakatoa for Maya ;)

Anyways, keep up the excellent work Frantic Films!

Bobo
05-13-2008, 02:48 PM
Just wanted to jump in and say what an exciting read this is!!! I have yet to try out Krakatoa, but I definitely will.
...
Now, being a Maya user, working at an all-Maya studio, I'll have to add a shout to the calls for a version of Krakatoa for Maya ;)


Thanks, Christian!

Krakatoa still has a way to go before getting where Renderman is (especially regarding the shading language ;) ). On the bright side, one can use the mathematical capabilities of Script Operators, PFlow Box #3 DataOps or Cebas Thinking Particles to generate color and density data per particle, so in a way the sky is the limit shading-wise. Still, we hope to add a built-in channel manipulation subsystem in the future.

Interestingly, before starting our own point renderer, we tried to use Entropy (which was more or less a Renderman-clone) to draw Doc's Spores and while it worked for testing purposes, it was much slower and a lot more unreliable.

Keep in mind that rendering is becoming just a fraction of what Krakatoa does, since it provides some additional tools to deal with particle data, deform and sculpt particle clouds (just wait to see what we are adding to 1.2 :twisted: ) and more. On the other hand, we know that there are many things that can be improved on the rendering side, and adding support for other 3D applications would also be a good idea. Unfortunately, we have to balance our resources as Krakatoa is being used by us in production and many of the features are added so I can hit my deadlines ;)

We had a customer who added PRT file support to XSI within a week, I am pretty sure we could get particle data out of Maya without much trouble. (one could already use the RealFlow BIN files to do that, I guess).
It is the rest of the feature set that is very tightly integrated into Max (because we know it well) that would require someone with the same level of Maya knowledge to implement there. Thus, providing the stand-alone version of the renderer and letting 3rd parties develop the bridges to it might be the way to go...

PsychoSilence
05-28-2008, 02:43 AM
i was wondering if there´s another way to have another particle system as matte object then wrapping a mesher compound around it(which dramaticly slows down my rich particle system...) or baking out the particles to meshes(which is not as acurate as the original particle system...).

(regular way describe in the krakatoa FAQ: http://www.franticfilms.com/software/support/krakatoa/frequently_asked_questions.php )

any input welcome :)

thanks in advance and kind regards,
Anselm

Bobo
05-28-2008, 03:44 AM
i was wondering if there´s another way to have another particle system as matte object then wrapping a mesher compound around it(which dramaticly slows down my rich particle system...) or baking out the particles to meshes(which is not as acurate as the original particle system...).

(regular way describe in the krakatoa FAQ: http://www.franticfilms.com/software/support/krakatoa/frequently_asked_questions.php )

any input welcome :)

thanks in advance and kind regards,
Anselm

Theoretically, we could allow PF Source Emitters to be specified in a Matte Named Selection Set so that their geometry would be used as matte instead of rendering the particles as points. In practice though, this approach would probably be as fast/slow as the Mesher - the system still has to be evaluated and its render TriMesh acquired. The Mesher does what Krakatoa would do internally anyway, the only difference is that the Mesher exists in the scene as a node while the other method would do the extraction directly. But it would be a real mess if PFlows could be selected as mattes, because in many cases they could be there by accident and it wouldn't be obvious to the user why the scene renders in unexpected ways.
Have you tried disabling the display of the PFlow and of the Mesher in the viewports to speed things up? How much does the Mesher slow down rendering compared to evaluating the same PFlow without the Mesher? (Talking about Scanline rendering of the system as mesh here)

Bobo
06-16-2008, 04:25 PM
Just a note that Krakatoa for Max has been updated to 1.1.1 and adds 3ds Max 2009 support incl. a custom VFB layout for tweaking your particle rendering.

You can find what's new here (http://www.franticfilms.com/software/support/krakatoa/1.1.1_release_notes.php).
You can learn more about the Krakatoa VFB for Max 2009 here (http://www.franticfilms.com/software/support/krakatoa/rendered_frame_window_extension.php).

http://www.franticfilms.com/software/support/krakatoa/images/krakatoa_vfb_extension.png


As usual, the software will run in nearly unlimited Evaluation mode (http://www.franticfilms.com/software/products/krakatoa/download/) (except for a watermark on the output image and no network rendering support) if installed without a license. This update uses the 1.1.0 license so no license update is required if you already own 1.1.0.

Nazgul
06-26-2008, 12:29 PM
Hi Bobo,

I want to get something clear. ;)
I have read this thread since the release of Krakatoa last year and you seem to mention that there is a stand-alone version of Krakatoa. Is it available?
When we purchase Krakatoa, do we get the max plugin and the stand alone or only one of those?

I'll try Steven Caron's prt exporter for XSI but it would really be nice to have a native version. ;)

Bobo
06-26-2008, 01:08 PM
Hi Bobo,

I want to get something clear. ;)
I have read this thread since the release of Krakatoa last year and you seem to mention that there is a stand-alone version of Krakatoa. Is it available?
When we purchase Krakatoa, do we get the max plugin and the stand alone or only one of those?

I'll try Steven Caron's prt exporter for XSI but it would really be nice to have a native version. ;)

Ok, let's get it clear.
The stand-alone version of Krakatoa exists and we do everything possible to maintain our code base in such a way that any change to the Max plugin version propagates into the stand-alone version.
BUT that version is currently NOT available for purchase and we are not using it in production anymore because Frantic is a Max-based VFX house and using the Max plugin version is an a lot much more streamlined process. Also, since switching to WinXP64 and Max 64 bit, the limitations of 32 bit memory address space do not apply anymore and we can render more than 50 million particles without running out of memory.
Using the stand-alone version required exporting both all particles and all geometry to external files, sending the data together with an XML scene description to the external renderer on Deadline and then waiting for results. Compare this to pressing the Render button and getting an image in the Virtual Frame Buffer (and in Max 2009, performing fast interactive updates while tweaking), and you will understand why the stand-alone is currently an artist's nightmare and the TDs domain...

Half of what makes Krakatoa for Max cool is the interface to the user. If we ever decide to support Maya, XSI, Houdini etc, we would probably use the stand-alone version, but somebody would have to write the bridge, which is a challenge on itself...

Nazgul
06-26-2008, 01:42 PM
Thanks for the informations Bobo.

I'll deal with XSI and MAX until someone finds the time and courage to make the bridge.
Cheers!

Gaetan
06-27-2008, 03:22 PM
I would like to make a disintegration character with pflow and rendering with krakatoa but my character have some UV textures on it, I would like to make the same than the "Mini cooper"
How can i tell Krakatoa to grab texture information from my model?
In the slot 1 material if i put a uv texture nothing appear in the rendering frame!
thanks
Gaetan

Bobo
06-27-2008, 08:42 PM
I would like to make a disintegration character with pflow and rendering with krakatoa but my character have some UV textures on it, I would like to make the same than the "Mini cooper"
How can i tell Krakatoa to grab texture information from my model?
In the slot 1 material if i put a uv texture nothing appear in the rendering frame!
thanks
Gaetan

Krakatoa supports UV channels, but you will have to write the data into the UV channel using one of the following methods:
*PFlow Box #1 has an operator to steal UVs from nearest geometry surface
*PFlow Box #3 DataOp allows you to write any data into any channel, including UV coordinates.
*Script Operators allow you to write UV data into any mapping channel. How you would get the UVs is a different story, possibly using the MAXScript methods exposed for texture baking.

I usually write UVs using Box #3 DataOps. See the Camera Mapping tutorial on our site for info on how to project UVs from a camera to simulate the Mini effect using Box #3 or Script Operator:
http://www.franticfilms.com/software/support/krakatoa/camera_mapping_particles_using_dataflow.php

Gaetan
06-30-2008, 12:47 PM
Hi! thanks a lot
I will try.
regards
Gaetan

Gaetan
06-30-2008, 12:54 PM
There is a way to render different size of particle in krakatoa?
thanks
Gaetan

Bobo
06-30-2008, 02:46 PM
There is a way to render different size of particle in krakatoa?
thanks
Gaetan

Yes and no (and we are looking into adding this).
*When using DOF, particles that are closer to the camera than the focal point will be drawn as disks with multiple random samples, making them appear larger.
*It is an often requested feature to be able to specify particle size and scale using the channels already available in PFlow etc. Without making any promises for when exactly this will be added, we are looking into it, as well as at a couple of other possible approaches.

In the current version, a particle cannot be larger than a pixel.

holycause
06-30-2008, 04:05 PM
In the current version, a particle cannot be larger than a pixel.

it means if your picture is bigger than during some tests, you ve to add particles for the final render?

like if during the tests, u use 1Mo particles for a 800*600 picture, you ll need 1.285Mo for a 1024*768 picture?

Gaetan
06-30-2008, 04:15 PM
Thanks!
I can't wait for a next version!
gaetan

Bobo
07-01-2008, 02:56 AM
it means if your picture is bigger than during some tests, you ve to add particles for the final render?

like if during the tests, u use 1Mo particles for a 800*600 picture, you ll need 1.285Mo for a 1024*768 picture?

The rule of thumb is NOT to change the resolution for tests, since Krakatoa does not get any faster when you drop the resolution. You should reduce the number of particles for test purposes instead and tweak the Final Pass Density settings to adjust the result. Since one million particles typically draw in about two seconds, we usually test with around one million, then bump up the amount by an order of magnitude and tweak the Density Exponent.

But you are right, changing the pixel resolution has an effect on the quality of the final render. That's why you should start testing with the final resolution already set for best results.

Of course, you could supersample or subsample the final image, rendering at a higher or lower resolution and rescaling to the final image after that. Sometimes it gives interesting results.

But the best results are from HUGE amounts of particles with VERY low denisty which accumulate to give a very smooth cloud where a single particle in a pixel cannot be distinguished at all. In my opinion, if you can recognize a single particle, your volumetric density is too high (same applies to Additve density, too). In a way, rendering in Krakatoa is like airbrushing...

holycause
07-01-2008, 11:30 AM
ok thx for your answer Bobo :D

Gaetan
07-03-2008, 01:00 PM
Do you know if I can make the same with TP?
thanks
GT

Bobo
07-03-2008, 01:59 PM
Do you know if I can make the same with TP?
thanks
GT

Do what exactly with TP? Most of the things you can do with PFlow and Krakatoa can be done with TP and Krakatoa (except for the loading of PRT files, and the material support is not refined enough yet). Can you explain in more detail what you want to do in TP?

Gaetan
07-03-2008, 02:05 PM
yes! the teapot tutorial in your web site, can i make the same?

Gaetan
07-03-2008, 02:34 PM
>>Krakatoa supports UV channels, but you will have to write the data into the UV channel using one of the following methods:

Here we don't have the orbaz Plugin. but we have TP! we both TP last two week, so we start to learn.

my question is , can I render the teapot with the UV from TP driven by the teapot with Krakatoa?

gaetan

Gaetan
07-03-2008, 02:50 PM
well!, if the material is not refined enough yet, it's mean that the uv is not suported by TP?

it will be cool to have the prt loader in TP!

regards
GAetan

fandalis
07-04-2008, 10:53 PM
Hi Bobo, i'm a compositor and just new to 3d particles. i saw this vifehandtest dissintegration while browsing youtube and was really impressed!!! i am now researching and studying krakatoa and trying to render something similar to it. The teapotvolumedissipate.mov is also a great example. i have tried the tutorial "exploring shading options" in franticfilms website but can't render something similar on my end. Can you explain further this, "Teapot primitive render as a PARTICLE CLOUD" written in the tutorial intro. Thanks a many!!!

Fandalis

Bobo
07-05-2008, 04:38 AM
Hi Bobo, i'm a compositor and just new to 3d particles. i saw this vifehandtest dissintegration while browsing youtube and was really impressed!!! i am now researching and studying krakatoa and trying to render something similar to it. The teapotvolumedissipate.mov is also a great example. i have tried the tutorial "exploring shading options" in franticfilms website but can't render something similar on my end. Can you explain further this, "Teapot primitive render as a PARTICLE CLOUD" written in the tutorial intro. Thanks a many!!!

Fandalis

Here is the original file (Max 9) of the exploding teapot for you to play with:
KRA_TeapotExplosionDemo_Max9.zip (http://www.scriptspot.com/bobo/krakatoa/KRA_TeapotExplosionDemo_Max9.zip)

If you would disable the Color Override in the Krakatoa GUI, it will render using the assigned material in the same cellular map colors shown in some of the rendering examples.

Play with the file, modify it, tweak the Krakatoa settings and see how it works...

fandalis
07-05-2008, 03:07 PM
Wow! This will surely teach me a lot. thanks a many and more power to your team!!! :beer:

Bobo
07-22-2008, 03:34 PM
>>Krakatoa supports UV channels, but you will have to write the data into the UV channel using one of the following methods:

Here we don't have the orbaz Plugin. but we have TP! we both TP last two week, so we start to learn.

my question is , can I render the teapot with the UV from TP driven by the teapot with Krakatoa?

gaetan

I finally found time to check this out (our TP licenses were used up in the last weeks).
The main limitation of TP is that is depends on the shapes of particles a lot for many thing it does. It does not abstract particles into points in space as much as PFlow does. This is a good thing when it comes to the main strenght of TP, the dynamic simulation of mesh particles, but it makes using it with Krakatoa much more difficult. Material data, UV data etc. are generally handled through the mesh shapes of the particles and not necessarily through particle data channels. Thus, it is tricky to get UVs from TP to Krakatoa directly, but you can get the resulting color into the Krakatoa Color channel for sure, or just calculate your own color inside of TP using whatever operators it provides for color data manipulation.

For example,

*Create a Teapot
*Create a TP system
*Add a Group called "Teapot", add a DataChannel called "Color" of type "Color" to it
*Add a Dynamic Set called "Birth"
*Add a Born Operator, create 10000 particles, send them to the "Teapot" group.
*Add a Node Helper, select the Teapot as the node.
*Add a Surface Pos Helper, connect Node Output to Node Input
*Add a Position Operator, connect Particles In/Out, connect Position Out from Surface Pos to Position In in Position Op.
*Add a TexmapColor Helper, connect UVW Out from Surface Pos with UVW in of TexmapColor.
*Add a DataChannel Op, connect Particle Out from Born to Particle In of DataChannel Op.
*Connect Color Out of the TexmapColor Helper to Color In of the DataChannel Op.
*Drop a texture map into the TexmapColor and make sure it is set to Explicit Map Channel 1 in the Material Editor.

At this point, the colors of your particles rendered in Krakatoa will show the colors of the texture map in TP, based on the UVs stolen from the surface of the teapot where the particles were placed.

I guess we could add special support for a user DataChannel called TextureMap of type Point3 in future versions of Krakatoa to allow you to write UVs to it and save it out to PRTs.

While TP rocks for dynamics simulations of fractured meshes (the one thing PFlow does not do yet), it really lacks in the area of data channel management of point clouds with no mesh shapes assigned to them, the thing Krakatoa depends on most.

floopyb
07-24-2008, 03:26 PM
We have recently finished some cut scenes for "Space Chimps" the game. We used a lot of fume and krakatoa throughout the whole project. Hope you enjoy!

480p version of the intro cut scene:
http://www.zerooneanimation.com/projects/downloads/01_spacechimps_desertintro_480p.mov
720p version of the intro cut scene:
http://www.zerooneanimation.com/projects/downloads/01_spacechimps_desertintro_720p.mov

Another shot in 720p:
http://zerooneanimation.com/Clients/Public/SpaceChimps3.mov

And our showreel is here:
http://www.zerooneanimation.com/projects/downloads/01_spacechimps_showreel_480p.mov
http://www.zerooneanimation.com/projects/downloads/01_spacechimps_showreel_720p.mov
or just check out www.zerooneanimation.com (http://www.zerooneanimation.com) for more of our stuff!

Thanks to Bobo and the krakatoa development team for allowing us to create these FX!

Ls3D
07-24-2008, 05:13 PM
Very impressive! Just completely stunning CG work there.

-Shea

CapitanRed
07-28-2008, 06:52 PM
I get an issue when saving particles from TP to .prt in the partitioning mode. I do that locally, and press the generate all particles locally button.
if I press the save particles button in the main controls rollout, it does this in few seconds for 130 frames.
the exact same sim takes minutes per partition. Is there a reason? or workaround (not changing the seed manually) ?

Bobo
07-28-2008, 07:26 PM
I get an issue when saving particles from TP to .prt in the partitioning mode. I do that locally, and press the generate all particles locally button.
if I press the save particles button in the main controls rollout, it does this in few seconds for 130 frames.
the exact same sim takes minutes per partition. Is there a reason? or workaround (not changing the seed manually) ?

I have a suspicion, but I will have to check a bit closer to see what is going on.

Just for the fun of it, could you go to the Presets and History rollout of Krakatoa and disable both options (Save Render History and Save Image Sample)?

I noticed that when rendering a single frame in TP (esp. a very late frame), once the frame is rendered TP performs a full update of the system as result of some post-render-frame notification. I am not sure what broadcasts that notification (if it is Krakatoa itself, it might get disabled when turning off the above two options).

The Local Partitioning option uses a FOR loop calling render() individually for each frame. I have the suspicition that after each frame, TP does a full update of the system, and the farther it goes, the slower it gets.

I will work on this in the afternoon and will let you know if I find any workarounds or solutions.

Bobo
07-28-2008, 08:32 PM
I have a suspicion, but I will have to check a bit closer to see what is going on.

Ok, I was wrong. The reason for the slowdown appears to be this: Each time you call the MAXScript render() method on a single frame of TP, it updates from the beginning. Thus, on frame 100 a single render() call causes all 100 frames to be pre-rolled before the frame is saved. In contrast, PFlow keeps the previous frames cached so incrementing one frame and calling render() causes only the last frame to be updated.

On the other hand, when calling something like (render fromframe:0 toframe:100), TP updates the particles continuously based on the previous frame and thus avoids this exponential time increase.

The possible solutions to this would be:

*We could call the render() method with a start and end instead of a for loop. Unfortunately, this would make it impossible to display any progress data as it would run outside of MAXScript control. But it could be a special TP-compatibility mode where you would get feedback only after each partition has finished, or alternatively as a progress bar at the bottom of the 3ds Max UI. I could do this by just modifying the KrakatoaGUI.ms and it would be a patch you could install on top of the existing version.

*We always intended to reimplement the partitioning feature as a function in the C++ code of the renderer and just call it from MAXScript. That function would deal with all the overwriting existing files, outputting feedback and so on. Unfortunately, this would be part of a future version of Krakatoa and would not fix the immediate problem.

If the first approach is something you could live with (no fancy color bars in the UI to show the progress, but faster saving of TP partitions), I will look into adding that option.

CapitanRed
07-28-2008, 08:51 PM
thanks bobo, your support is awesome!
the patch sounds sexy, no need for the colorbars ;)
btw, it's not hurrying, I just tested it out and remarked the slowdown.

oh, one more thing. TP updates after rendering in other renderers too...if that helps somehow...

CapitanRed
08-11-2008, 01:09 PM
still exploring krakatoa and there was a tought in my head and I tought maybe you like the idea.

I've cached out many dynamic sets from TP into one prt sequence. now when I load them, It would be nice if I could load particle groups separately.
the other option which I have now is to turn off and on all the dynamic sets and cache them out separately.

another thing I tought about is that theoretically it would be possible to randomize particles while loading...
there is a positionVector and a velocityVector...so one could offset particles along the velocityVector and around the paritcle...or am I wrong?
I'm not a programmer at all, so I don't know where difficulties would appear. Just tought that this could be a possibility to do it on rendertime, so we don't have to save out multiple sequences.

anyways...the tool is awesome. Simple to understand, straightforward workflow and the UI with all it's features is sweet!! many thanks to franticFilms :)

holycause
08-12-2008, 12:08 PM
don't forget your question about the particle age map ;)

CapitanRed
08-12-2008, 12:50 PM
well, you have to use the scriptfloat at the moment in pflow.
I'm not sure if Krakatoa can read a TP-datachannel...can it?

Bobo
08-14-2008, 04:21 AM
still exploring krakatoa and there was a tought in my head and I tought maybe you like the idea.

I've cached out many dynamic sets from TP into one prt sequence. now when I load them, It would be nice if I could load particle groups separately.
the other option which I have now is to turn off and on all the dynamic sets and cache them out separately.

Since Krakatoa 1.1.x supports the TP Groups on/off switch, you could simply turn some groups off when saving the particles. Saving particles in Krakatoa is considered a form of rendering, so if you disable a particle group, it should not save out.



another thing I tought about is that theoretically it would be possible to randomize particles while loading...
there is a positionVector and a velocityVector...so one could offset particles along the velocityVector and around the paritcle...or am I wrong?
I'm not a programmer at all, so I don't know where difficulties would appear. Just tought that this could be a possibility to do it on rendertime, so we don't have to save out multiple sequences.


What you describe is what Motion Blur does in Krakatoa :)
In v1.1.1, you can use something like this (http://www.franticfilms.com/software/support/krakatoa/partitioning_existing_file_sequences.php)...
In the upcoming 1.1.2 which we are demoing at Siggraph, you will be able to partition any particles from any source (even geometry vertices) without using the above hack.



anyways...the tool is awesome. Simple to understand, straightforward workflow and the UI with all it's features is sweet!! many thanks to franticFilms :)

Glad to hear that!
We were stunned to hear at Siggraph what movies Krakatoa has been used in lately... Looks like it is slowly finding its place in the industry. But we always wanted it to be accessible to the average user.

Bobo
08-14-2008, 04:23 AM
well, you have to use the scriptfloat at the moment in pflow.
I'm not sure if Krakatoa can read a TP-datachannel...can it?

Currently it can read a data channel of type Float called "Density" and a type Color called "Color".

jigu
08-14-2008, 05:13 AM
We were stunned to hear at Siggraph what movies Krakatoa has been used in lately... Looks like it is slowly finding its place in the industry. But we always wanted it to be accessible to the average user.

Can you tell us in which movies krakatoa were used lately?

CapitanRed
08-14-2008, 01:53 PM
ME:
I've cached out many dynamic sets from TP into one prt sequence. now when I load them, It would be nice if I could load particle groups separately....
Bobo:
Since Krakatoa 1.1.x supports the TP Groups on/off switch, you could simply turn some groups off when saving the particles. Saving particles in Krakatoa is considered a form of rendering, so if you disable a particle group, it should not save out.

I asked that, because I wanted to be able to control density per group. then I realized that from the UI this isn't possible even with many prtLoaders. but now as you said that...
Currently it can read a data channel of type Float called "Density" and a typeColor called "Color". ...we can have density and color per particle per frame :bounce:
sweeeet!! ;)

thanks a lot!

Bobo
08-14-2008, 02:52 PM
Can you tell us in which movies krakatoa were used lately?

I guess I could. Keep in mind it was used to enhance shots, so don't expect to even see the Krakatoa pass while watching the movie. ;)
We have now "Iron Man", "The Mummy 3" and of course Frantic's own "Journey To The Center Of The Earth 3-D" work which btw was used to close the Stereo projection part of the Autodesk User Group.
I know details only about Journey 3-D where we used Krakatoa for the mist passes on the ocean, some background rain, the wake of the raft and the bioluminecent trails of the fish under water (APME-shaded based on the ocean surface). In fact, if you watch the 3rd Krakatoa introductory video from last Siggraph posted on Studio Daily, the FumeFX-driven particles I used on a path there were the biolum trails of the razorfish. We created a few of those and deformed them to the paths of the fishes using PathDeform WSM, thus reusing the same simulation multiple times on different trajectories and saving disk space. ;)

JohnnyRandom
08-14-2008, 11:10 PM
Bobo showed of some sick/slick features they have been working on (I'll leave it to him to say what they are). Hope they all get implemented. :D I'll spill the beans on one, think more even more customizable interface...

jigu
08-30-2008, 12:00 PM
I have question about slowing down particle motion.

I am rendering one sequence with fast moving particles volume. I need to show it in slow motion. Until now I was using video post to extend the animation of certain fragment of timeline in max. But now when I render that with krakatoa. It's crashing after two frames. But it wasn't before. I must had done something wrong with that. (In beta time, I also experienced crashing with video post) ... So now I am rendering normal way 100 frames of animation and it's working fine with motionblur and DOF. But not with video post.

EDIT : Anyway found the error and rendering with video post fine now.

But still is there anyway other than video post in max? or something "Nth ticks" rendering instead of "nth frames" in max to render without using video post? or better do in post?

SoLiTuDe
08-30-2008, 08:24 PM
if you're using a prt, it has the playback graph option, where you can speed up, slow down, and reverse the particle playback... it works great.

jigu
08-31-2008, 04:29 AM
if you're using a prt, it has the playback graph option, where you can speed up, slow down, and reverse the particle playback... it works great.

Hey thanks Ian. I looked at it but didn't know that.

I am definately gonna try that way.

Bobo
08-31-2008, 05:12 AM
Hey thanks Ian. I looked at it but didn't know that.

I am definately gonna try that way.

The Playback Graph is definitely the way to go.
It extrapolates the position and velocity of the particle using a floating point graph, the closest frame and its position and velocity, so the results are very usable even if you use extreme values. Of course you can apply any tangents to your keys for special effects like speedups, slowdowns, ping-pong effects or Matrix-like bullet-time freezes.

JohnnyRandom
09-16-2008, 05:06 PM
Messing around with Fume and Krakatoa

Krakatoa Pass 8mb QT (http://4rand.com/TEST/Krakatoa/andFume/KRK_VaporizeMOV.html)
http://4rand.com/TEST/Krakatoa/andFume/vaporize_thumb.png

BTW the playback graph kicks a--! so do PRT loaders:D

superhypersam
09-16-2008, 05:50 PM
I guess I could. Keep in mind it was used to enhance shots, so don't expect to even see the Krakatoa pass while watching the movie. ;)
We have now "Iron Man", "The Mummy 3" and of course Frantic's own "Journey To The Center Of The Earth 3-D" work which btw was used to close the Stereo projection part of the Autodesk User Group.
I know details only about Journey 3-D where we used Krakatoa for the mist passes on the ocean, some background rain, the wake of the raft and the bioluminecent trails of the fish under water (APME-shaded based on the ocean surface). In fact, if you watch the 3rd Krakatoa introductory video from last Siggraph posted on Studio Daily, the FumeFX-driven particles I used on a path there were the biolum trails of the razorfish. We created a few of those and deformed them to the paths of the fishes using PathDeform WSM, thus reusing the same simulation multiple times on different trajectories and saving disk space. ;)

was also used on "There Will Be Blood" for the oil rain and oil guysers, over a terabyte of sim data, yikes!

jigu
09-16-2008, 05:55 PM
was also used on "There Will Be Blood" for the oil rain and oil guysers, over a terabyte of sim data, yikes!

wow! that sounds lots of frames with lots of particles... terabytes of Krakatoa PRT files or realflow sim data?

grury
09-17-2008, 12:25 PM
Hi,

Is there a way to increse the count of particles when importing a RealFlow bin sequence? Or at least change the seed so can render multiple passes.

Cheers

Bobo
09-17-2008, 01:47 PM
Hi,

Is there a way to increse the count of particles when importing a RealFlow bin sequence? Or at least change the seed so can render multiple passes.

Cheers

Yes, there are in fact multiple ways to do this.

The old way is described here:
http://www.franticfilms.com/software/support/krakatoa/partitioning_existing_file_sequences.php

The new way is implemented in v.1.1.2 which we are about to release to public in the next couple of days. In short, 1.1.2 lets you add a high-frequency (Scale of 0.1, Fractal) Noise Modifier to ANY particle source that supports modifiers, which includes geometry objects and PRT Loaders. Then you can partition them as usual (since the Noise Modifier provides a Random Seed). The Noise Strength values can be used to define 3 max. jitter radii. Since PRT Loaders can load BIN files natively, you can partition RealFlow sequences directly without the above hack.

Or you could sim the same system multiple times in RealFlow, but I am really JUST KIDDING :)

grury
09-17-2008, 01:59 PM
Thanks Bobo.
I guess I'll wait for the new update.

Another question: Is there any difference in using Krakatoa Birth rather than RealFlow Birth Operator?

Thanks.

Carlos

Bobo
09-17-2008, 03:41 PM
Thanks Bobo.
I guess I'll wait for the new update.

Another question: Is there any difference in using Krakatoa Birth rather than RealFlow Birth Operator?

Thanks.

Carlos

I have never used the RealFlow Birth operator so I cannot really answer that. I hope after trying out both methods you will be able to tell us the difference.

The Krakatoa File Birth only creates particles based on the difference between two particle file frames (current and next) in PRT, CSV or BIN format. It looks at the IDs in the current system and the IDs in the file and creates those particles that are currently not in the system (we use our own FileID channel for this, so the Born IDs of PFlow do not matter, you can add your own particles using other Birth and Spawn operators).

The Krakatoa File Update operator can then be used to load arbitrary channels into type-matching channels of PFlow (for example you can load the Velocity channel into the ParticleSpeed of PFlow, but you could dump it into any other Point3 channel instead). The other thing it does is comparing the FileIDs in the current system to those in the current file and finding which particles should NOT be in the system anymore. These are then marked with -1 in the FileID channel.

And then you get the Krakatoa FileID Test operator which can send out particles with specific FileID channel values. So you could send particles with FileID < 0 to another event and either Delete them, or just show them in a different color or whatever you want.

So our system for loading dynamic particle counts consists of 3 modules and you can customize the way they work any way you want. For example, since the Krakatoa File Birth loads Positions and Krakatoa File Update can load both Positions and Velocities, you could turn off the Positions in the latter and your particles would be moving just based on the velocities stored in the files, allowing you to add new forces like Wind and perform collisions. Or you could check Positions in the File Update and keep the particles where they were in the sim. Or you can blend the values or mix them additively. It is a kind of a toolkit for loading particle data into PFlow, the loading of RealFlow files is just a side effect of its functionality.

I am not sure whether it is better than what RealFlow provides, nor whether it is faster. But it is surely rather flexible.

jigu
09-18-2008, 04:09 PM
Hi,

I have 3 PRT loaders in the scene and I want to have motionblur only on one PRT loader while other two shouldn't have motionblur. Is it possible to have motionblur on particular PRT loader? so it will generate motionblur passes on that particular PRT loader. Other two PRT loader uses massive particle counts and I don't want to have 4 passes of motionblur on it, it's adding rendering time.

Thanks,

Regards,

Jignesh

JohnnyRandom
09-18-2008, 05:03 PM
Nice little write up in the Q&A of issue 115 of Cinefx with Eric Brevig about Journey 3d.

He mentions how difficult the ocean shots were, and how pleased he was with the interaction of all the elements.

Cheers guys :)

Go, Go, Krakatoa:D

Bobo
09-18-2008, 06:32 PM
Hi,

I have 3 PRT loaders in the scene and I want to have motionblur only on one PRT loader while other two shouldn't have motionblur. Is it possible to have motionblur on particular PRT loader? so it will generate motionblur passes on that particular PRT loader. Other two PRT loader uses massive particle counts and I don't want to have 4 passes of motionblur on it, it's adding rendering time.

Thanks,

Regards,

Jignesh

Krakatoa has to perform multiple render passes to get motion blur, so there is no way to draw some PRT Loaders once and other multiple times. The only way would be to render them in separate passes and comp them in post, if that is even an option.
If a particle stream does not contain velocity data, the particles will be drawn N times in the same place, so the final result would be no motion blur on those particles (unless the camera is moving), but that would be useful only if you want the LOOK of no-motion blur, it would NOT save any render time as all particles would draw as often as the passes spinner dictates.

olipoli1
09-22-2008, 03:29 PM
hi guys

i wish every software had a developer as devoted and helpful as Bobo so thanks in advance.

Anyway Im quiet new to pflow in max since I usualy work with maya so maybe thats the cause of my problem but here it is:

I fallowed the tutorial about partitioning existing particles, on your (FFlims) website and it was quiet straight forward i managed to load my previously saved particles which I animated with fumeFX. I created the flow to load the particles with a speed operator set to rand3D with some values and the other krakatoa operators the tutorial mentions. I generated the partitions (20) but as I guessed before I rendered the partitions combined in a PRT loader and they rendered like litle blobs of particles randomly scaterd around the original particles from the simulation. So a particle now looked like a bigger spherical cloud of particles, which diameter was based on the values set in the speed operator... I dont know if its clear what Im trying to explain but Ill upload some renders. Also alternatively I tried to set the speed operator to inherit previous but it seems on the render that it somehow didnt show up in the partitions. Maybe there are other ways to create random positioning of particles for partitioning, I saw you mention something with a noise field which I will read again but I apreciate any help, THX

Bobo
09-22-2008, 05:53 PM
hi guys

i wish every software had a developer as devoted and helpful as Bobo so thanks in advance.

Anyway Im quiet new to pflow in max since I usualy work with maya so maybe thats the cause of my problem but here it is:

I fallowed the tutorial about partitioning existing particles, on your (FFlims) website and it was quiet straight forward i managed to load my previously saved particles which I animated with fumeFX. I created the flow to load the particles with a speed operator set to rand3D with some values and the other krakatoa operators the tutorial mentions. I generated the partitions (20) but as I guessed before I rendered the partitions combined in a PRT loader and they rendered like litle blobs of particles randomly scaterd around the original particles from the simulation. So a particle now looked like a bigger spherical cloud of particles, which diameter was based on the values set in the speed operator... I dont know if its clear what Im trying to explain but Ill upload some renders. Also alternatively I tried to set the speed operator to inherit previous but it seems on the render that it somehow didnt show up in the partitions. Maybe there are other ways to create random positioning of particles for partitioning, I saw you mention something with a noise field which I will read again but I apreciate any help, THX

Hi!

Your explanation was very clear, no problem.
The method (as you can see from the screenshots on that page) is meant to increase the density of a particle cloud that is already relatively dense. The results you are getting are more or less correct, but since the distance between your particles is much bigger than the jitter radius you used, you get these small puffs of particles. If you had 10 or 100 times more particles already before you started partitioning, the distances between them would have been relatively small and adding random jitter to the original positions would have solidified the original system without showing that much of puffing.

In general, we partition systems containing between 100K and 1M particles to get orders of magnitude more particles. It looks like you started with orders of magnitude less than that, so the result is not very polished.

The main idea behind Krakatoa is to render a huge amount of barely visible particles into a smooth cloud that looks more like smoke than like dust particles (unless you are after a dust effect). As a rule of thumb, if you can see a particle as a single pixel with naked eye in your final rendering, your density is probably too high. (I can see all your particles ;)) I understand that driving 100K particles with FumeFX might be a bit slow, but art requires sacrifices :)

As for the noise field method, the upcoming v.1.1.2 which we released to Beta testers two weeks ago and might be released to the public this week has the option to partition PRT Loaders with a Noise modifier on top, avoiding the whole PFlow trickery you had to go through.

olipoli1
09-22-2008, 10:47 PM
hi Bobo

Thanks for the answer, I see your point but in the same time I have to clear out that the render I posted was a test I tried because of my suspicion abut the subject. I originaly have a 800k pflow system driven by fume fx, and as I was doing test renders I realised that the initial "detail" of the animation is degrading with the more partitions I make. Thats why I built the test scene from which I rendered the posted image. What I mean is that If you have a nice curl of particles in the original sim, there every particle folows its path based on the rules of the calculations. If I randomly place copies of the simulation, I introduce noise to the original simulation if this is near the truth. If I trie to picture a sharp point or edge of particles and I use the partitioning technique on that, the edge becomes "blunt" if its a correct example.

OK
I just re-read your post before I posted mine:) and the part about the jitter radius finaly made some sense. If I get it correct then you mean that for instance the speed operators speed value hase to be bigger than the space between the particles in the original sim.
But anyway just to clarify, the image I posted was only a test to examine the behaviour I suspected. I will make some renders from the actual project to post just to show where I got the idea from.

Bobo
09-23-2008, 01:48 AM
Hi again,

Well, if you are partitioning a PFlow containing a FumeFX Follow, there is usually no need to use the random jitter method, as long as you can randomize the operators related to the initial positioning of your particles. (Note we even have a switch for FumeFX operators in the partitioning rollout)
We have partitioned FumeFX flows directly before without any need to jump through hoops. The quality would not degrade because all particles would move through the same simulation grid, the only difference would be the initial placement (and any other operators you might want to influence along the flow).

The method on our site and the Noise trick we introduce in v1.1.2 are hacks meant for external simulations like RealFlow or particles taken from mesh vertices that are normally not partitionable.

We have done lots of production shots with FumeFX-driven particles and partitioning (mostly for "Journey To The Center Of The Earth 3-D") and the only problem we found was partitioning on the network - FumeFX would overwrite its sim data when sent to Deadline. This might have been fixed in the mean time.

olipoli1
09-23-2008, 08:29 PM
OK sorry I was a bit confused about partitioning or saving out fumeFX driven p flow particles with Kraka because I thought that I have to cache the particles with pflow when Im actaly simulating the fume grid. all I had to do is to export the velocity chanel from fume and then it can be partitioned if Im geting this right. As for other tipes of particles like real flow the random method should work fine I guess, maybe the nature of the fluid sim or at least what you would use krakatoa for in combination with water, like foam and spray rendering, can be represented nicely with the random method.

Just because Im already in this post I had another idea I might ask your opinion about. Is it posible or wise to use the real flow generated mesh to cull parts of the same real flow generated particles which are inside the mesh? Would this be good way to genarate foam from the particles which are above and on the surface of the water? I guess its not the correct way but maybe easier than scripting... so anyway I only talked about my problems with Krakatoa which in the same time is unbelivable and awsome keep it up

Bobo
09-23-2008, 10:41 PM
Is it posible or wise to use the real flow generated mesh to cull parts of the same real flow generated particles which are inside the mesh? Would this be good way to genarate foam from the particles which are above and on the surface of the water? I guess its not the correct way but maybe easier than scripting... so anyway I only talked about my problems with Krakatoa which in the same time is unbelivable and awsome keep it up

Depending on the complexity of the mesh, the culling may or may not work as expected. Normally, we support CONVEX volumes. It sometimes works well with concave ones, but we do not give any guarantees that it will not leak on random frames... Also, the particle count from a RealFlow sim woudn't be that high so I am not sure how many particles would be left after culling. We prefer to do foam as maps (but we typically do not use RealFlow since we have our own tools for fluids). Feel free to experiment and let us know if it worked.
If you look at this example
http://www.black-and-white-to-color.com/stuff/comrf.mov
found here
http://www.black-and-white-to-color.com/ipbsfx/index.php?showtopic=2116
you will notice that the whole water tends to look like foam.
The guy tried incorrectly to partition RealFlow particles which of course does not increase the density unless by using the tutorial approach you used.

Btw, is your Profile location a real typo or did you mean to imply people in Budapest are nude? :eek:

olipoli1
09-23-2008, 11:15 PM
I wish people especialy, girls would be naked in Budapest, since they are world famous beauties:) but seriously I think I miss typed it than it kind of caught me.

Glacierise
09-30-2008, 11:02 AM
Now I am very sorry to take you off the naked ladies topic, but since Bobo is too shy to post it - new Krakatoa version's out! And check this thing out:

http://www.franticfilms.com/software/support/krakatoa/krakatoa_geometry_lookup.php

Some quotes:
"Krakatoa Geometry Lookup Operator...
This bonus operator introduced in v1.1.2 uses the same kdTree acceleration structure as the Krakatoa Geometry Test, the PRT Loader's Culling feature and the Krakatoa Matte Objects feature. It provides a very fast way for finding the closest point from a particle to a geometry surface and acquiring the surface properties including face index, barycentric coordinates, surface normal and texture mapping coordinates. ...

The Krakatoa Geometry Lookup operator is similar to some existing operators or workflows already available in Particle Flow, but
The Krakatoa Geometry Lookup operator is typically two to three times faster than comparable operators found in Particle Flow Tools Box #1 and #3 and many orders of magnitude faster than using the Speed By Surface + Rotate In Speed Space combination of standard operators.
It is currently the only operator available for Particle Flow for acquiring smoothed normals from geometry, respecting smoothing groups and vertex normals.

Birth of 1M particles, Position Object Surface with 100,000 faces, 2 Omni Lights
Rendering Without Normals : 7 seconds (2 seconds PFlow Update, 5 seconds Krakatoa rendering)
PFlow Speed By Surface > Rotation Speed Space > Speed = 0 : 14344 seconds (2 seconds particle birth, 14337 seconds PFlow Update, 5 seconds rendering)
PFlow Tools Box #3 Data Operator : 39 seconds (2 seconds particle birth, 32 seconds data operator, 5 seconds rendering)
Krakatoa Geometry Lookup > Normals to TM : 16 seconds. (2 seconds particle birth, 9 seconds surface lookup, 5 seconds rendering)
Rendering either one from PFlow Cache: 5 seconds.

As you can see from the above example, the normal acquisition of 1 million particles from 100,000 faces takes 9 seconds using the Krakatoa Geometry Lookup operator, which is over 3.5 times faster than a Data Operator and 1593 times faster than the standard PFlow setup which took almost exactly FOUR HOURS.
"

Now I think, 4 hours to 16 seconds is, hm, kinda impressive? :D

Edited: Spelling :D

OlegB
09-30-2008, 11:58 AM
It is currently the only operator available for Particle Flow for acquiring smoothed normals from geometry, respecting smoothing groups and vertex normals.
Box#3 > Data Operator > Geometry sub-operator > "Closest Point By Normal" option is for smoothed normals from geometry (with smoothing groups); the option "Closest Point By Surface" disregards smoothing groups information.

Glacierise,

Can you send the setup with Box#3 to Orbaz support? Looks like it's a very good scene for profiling the Geometry sub-operator.

Thanks,
Oleg B.

Glacierise
09-30-2008, 12:35 PM
Hi Oleg,
I was just quoting the Frantic website, Bobo's the guy you need to call for that scene.

P.S.: Go Orbaz! :scream:

Bobo
09-30-2008, 01:50 PM
Box#3 > Data Operator > Geometry sub-operator > "Closest Point By Normal" option is for smoothed normals from geometry (with smoothing groups); the option "Closest Point By Surface" disregards smoothing groups information.


My bad, will fix the docs. Sorry for the misinformation!

dementol
09-30-2008, 02:03 PM
Hi!, i'm new in krakatoa and want to ask something

i'm learning how to use it, so i followd the tutorials on the site.

I have a FumeFX src and a PFlow with FUMEFX FOLLOW. I run the simulation of fume and get the shape with PFLow. The i add krakatoa and put 4.000.000 particles in PFlow.

I do 10 partitions of krakatoa, so i get 40.000.000 particles. I put an PRT Loader and then render.

My question is, the render takes 8 hours for an animation of 150 frames. It's this correct or i have to put some operator or tweak something in krakatoa to get less render time?

The Simulation is not to complex it's just a fumefx simulation standard.

When i go home i wil post an screenshot.

Thnx in advance!

P.S: sorry for my bad english

Bobo
09-30-2008, 02:16 PM
Hi!, i'm new in krakatoa and want to ask something

i'm learning how to use it, so i followd the tutorials on the site.

I have a FumeFX src and a PFlow with FUMEFX FOLLOW. I run the simulation of fume and get the shape with PFLow. The i add krakatoa and put 4.000.000 particles in PFlow.

I do 10 partitions of krakatoa, so i get 40.000.000 particles. I put an PRT Loader and then render.

My question is, the render takes 8 hours for an animation of 150 frames. It's this correct or i have to put some operator or tweak something in krakatoa to get less render time?

The Simulation is not to complex it's just a fumefx simulation standard.

When i go home i wil post an screenshot.

Thnx in advance!

P.S: sorry for my bad english

I assume you mean that the actual rendering part is taking that much, not the saving of the partitions?

8 hours * 60 min = 480 min / 150 frames = 3.2 minutes / frame or 192 seconds.
*This is a lot for only 40 Million particles, unless you are illuminating them with many lights.
Each light has to sort all particles and calculate the attenuation information for shadow calculation, so that could affect render time.
*Also, the loading of the particles from disk takes some time. If you saved with the default channels setup, half of the channels might be unneeded. Usually, all you need is Position and Velocity as you can control Color and Density through the PRT Loader and ID is needed only if you intend to reload into Particle Flow. Normals are wasted unless you do specular highlights. Removing these channels before saving will reduce your memory per particle and produce PRT files half the size, speeding up I/O.
*If you are using Matte objects, we have to perform 40M ray intersections with the scene geometry to determine whether a particle is visible or not.

As you can see, it really depends on what is in your scene and what is in the files.

Without lights and matte objects, I would expect 40M particles to render in about a minute.

Open the Krakatoa Log (either from Preferences or using the MacroScript we have provided) and post the Statistics for a single frame - we output the time it takes to do the different stages like loading, sorting, matte calculations and drawing on screen.

dementol
09-30-2008, 02:21 PM
thnx for the quick response bobo

the partitioning take 3 hours to finish, it's too much?

in fact, i have 3 spotlights with Shadow Map each one. And yes, i saved with the default channel setup. I guess it newbie mystake. But like everything, is error and learn.

When i go back in home (im in the work) i gonna check the log

thanx!!

Glacierise
09-30-2008, 02:21 PM
Did you turn the pflow off after loading the cached particles?

dementol
09-30-2008, 02:22 PM
Did you turn the pflow off after loading the cached particles?

yep, i turned off the PFLow and FumeFX.

oh wait, i just check out the "Enable particle emission". This is correct?

OlegB
09-30-2008, 03:00 PM
Bobo,

Bobo's the guy you need to call for that scene

Could you send the Box#3 scene to Orbaz support please?

Thanks,
Oleg B.

Bobo
09-30-2008, 04:48 PM
Bobo,
Could you send the Box#3 scene to Orbaz support please?

Done! Check your email.

Bobo
09-30-2008, 04:56 PM
thnx for the quick response bobo

the partitioning take 3 hours to finish, it's too much?

in fact, i have 3 spotlights with Shadow Map each one. And yes, i saved with the default channel setup. I guess it newbie mystake. But like everything, is error and learn.

When i go back in home (im in the work) i gonna check the log

thanx!!

I would not call these errors, we have enabled those channels as defaults for a reason.

If you disable the channels you don't need, your partitioning time might go down, too. Also, the PFlow update includes the time needed by FumeFX to apply velocities, while the actual saving to disk might not be that long. If I understood correctly, you had 150 frames * 10 partitions, or 1500 frames to save. 3 hours is 10800 seconds / 1500 frames = 7.2 seconds per saved PRT frame, so that sounds about right. If you have multiple CPUs, you could launch several copies of Max and partition in parallel since PFlow and Krakatoa are largely single-threaded.

dementol
09-30-2008, 05:45 PM
ok, so, i have a Q6600m Quad Core CPU.

It's better to open 4 differents Max and partition the particles in each one?
because i see that krakatoa has a button named "Use all cpu's" or something like that.

It's not the same?

i don't understand whats that about "Pflow Update" u mean PFlow in max 2009 or something like PFToolBox?

BTW, i refer to an error like "my error". :)

Bobo
09-30-2008, 06:32 PM
ok, so, i have a Q6600m Quad Core CPU.

It's better to open 4 differents Max and partition the particles in each one?
because i see that krakatoa has a button named "Use all cpu's" or something like that.

It's not the same?

i don't understand whats that about "Pflow Update" u mean PFlow in max 2009 or something like PFToolBox?

Not the same.

"Use All CPUs" is in the area for Deadline submission. BUT, FumeFX might cause problems when attempting to partition on the network, so you can open 4 copies of Max and run a sub-set of the partition range to use all your CPUs. For example, first copy does partitions 1 to 2, second does 3-4, third does 5 to 7 and the last one does 8 to 10. This will give you the same 10 partitions but in a fraction of the time as all CPUs will be loaded. But keep in mind that FumeFX will have to read data from disk in all 4 copies and you will need enough memory to run the 4 copies at full speed.
Particle Flow is generally single-threaded, and most parts of Krakatoa 1.1.x are also single-threaded, except for some file I/O and the sorting.

"PFlow Update" means "The time Krakatoa spends waiting for Particle Flow to update its particles and pass them over". When you are saving, there are two parts of the process - Krakatoa asks Max for particles, causing PFlow and thus also FumeFX to do what they do, then Krakatoa dumps the data to disk. The first part can be more time consuming than the second. That's why I said that Partitioning is not necessarily something we can speed up much because it depends on 3rd party products we have no control over.

dementol
09-30-2008, 06:47 PM
ok, i understand now

later im gonna try open 4 max separately

thank u very much bobo!

Glacierise
09-30-2008, 07:44 PM
On the firing up n max copies and partitioning - is there an automatic way to do that? I open 4 maxes, set their affinity to one core each (doesn't work if I don't), and then start it, which gets a bit tedious :)

dementol
09-30-2008, 07:47 PM
On the firing up n max copies and partitioning - is there an automatic way to do that? I open 4 maxes, set their affinity to one core each (doesn't work if I don't), and then start it, which gets a bit tedious :)


mm i don't think in that, you're right.!

OlegB
09-30-2008, 08:01 PM
My guess is with 4 copies of Max open and running, you are going to hit another bottleneck, namely writing data/files to hard drive - unless you have superfast HDD system with across-HDD-stripping and dedicated HDD controllers.

Thanks,
Oleg B.

Glacierise
09-30-2008, 08:22 PM
It will depend on what's heavier - the load the flow puts on the CPU, or the load Krak is putting on the HDD :) I think that approach is better when the flow is heavier. If it's not - a single core would do, and you wouldn't need to run many copies anyway, would you?

Bobo
09-30-2008, 08:33 PM
It will depend on what's heavier - the load the flow puts on the CPU, or the load Krak is putting on the HDD :) I think that approach is better when the flow is heavier. If it's not - a single core would do, and you wouldn't need to run many copies anyway, would you?

This is correct. I actually assume that the HDD read access would be a bigger hit when using FumeFX because all copies would be accessing the same simulation data. The actual velocity assignment is rather fast and does not load the CPU that much.
Still, chances are that 4 copies will save faster than one.

Gaetan
09-30-2008, 09:00 PM
Hi! there is a simple scene than a can load showing the new
Krakatoa Geometry Lookup operator V. 1.1.2 please.

I'M tried this operator but nothing happen???

need help!

Thanks

Gaetan

Bobo
09-30-2008, 11:07 PM
Hi! there is a simple scene than a can load showing the new
Krakatoa Geometry Lookup operator V. 1.1.2 please.

I'M tried this operator but nothing happen???

need help!

Thanks

Gaetan

There is none yet, I intend to write a tutorial about it soon.
The Krakatoa Geometry Lookup is a sort of a utility operator. It steals surface data and dumps it into some channel to be used in Box #3 or Script Operators.

The only exception is when getting the normal and converting it to a TM.

So here are the steps to use it for orienting particles:
1.Create a PFlow
2.Use a Position Object or similar operator to place particles
3.Add a Krakatoa Geometry Lookup operator, select the geometry to align to
4.Uncheck Point Position>Use, Barycentric Coords>Use
5.CHECK Normal Vector>Use

At this point, your particles should be oriented to the surface normal of the closest point of the selected geometry. You can visualize them by using a Tetra shape and Display operator set to Geometry. If the particles are far away from the geometry (and not distributed using Position Object>Surface), you might have to increase the Max.Search Radius value in the Krakatoa Geometry Lookup, but my tests show that the value does not really affect performance much, so you can bump it up a lot.

The other features of the operator are meant for advanced users (TDs and such). Some of these might be implemented as Box #3 sub-operators in the future, but with the current approach we were able to get it working fast and for anyone using PFlow even without Box #3.

grury
10-01-2008, 01:52 PM
The new way is implemented in v.1.1.2 which we are about to release to public in the next couple of days. In short, 1.1.2 lets you add a high-frequency (Scale of 0.1, Fractal) Noise Modifier to ANY particle source that supports modifiers, which includes geometry objects and PRT Loaders. Then you can partition them as usual (since the Noise Modifier provides a Random Seed). The Noise Strength values can be used to define 3 max. jitter radii. Since PRT Loaders can load BIN files natively, you can partition RealFlow sequences directly without the above hack.

Hi Bobo, just installed 1.1.2, but I'm having trouble figuring out how to apply the Noise Mod to create random seeds.
Somehow Krakatoa PFlow-File Birth isnt loading up this specific sequences, have tried with others and works fine, but on this specific ones, I can load em as Single Frame Only. I'm using RealFlowFileBirth instead.
On other hand I'm not sure if its possible to use Modifiers on PFlow??

Basicly I have 3 sequences from RealFlow that at a certain point will be sent to a new PFlow event, so RF Particle Loader isnt an option.

Any sugestions?

Thanks in advance.

Carlos

Bobo
10-01-2008, 02:35 PM
Hi Bobo, just installed 1.1.2, but I'm having trouble figuring out how to apply the Noise Mod to create random seeds.

You DON'T use a PFlow. That's the main point of the change - you can partition even a Teapot with a Noise modifier on top and its vertices will jitter!

1. Create a PRT Loader.
2. Load your BIN or PRT sequence into it
3. Add a Noise Modifier on top.
4. Set Scale to 0.1, enable Fractal
5. Set Strength for X, Y and Z to the radius of jitter you want, for example 0.1 or 1.0 or something like that.
6. Enable the changing of Seeds in PRT Loader Modifiers in the Partitioning rollout.
7. Partition!
RESULT: Each saved PRT sequence will have its particles slightly jittered compared to the original PRT or BIN sequence due to the high frequency noise added to the Loader.

dementol
10-01-2008, 02:48 PM
hey, i rendered the 40 millons particles.

u may think it's a easy thing but i'm happy :D

http://www.vimeo.com/1859084

there's something wrong when the "Mushroom" starts, like a noisy wave coming from down, but i think it's a problem with the fume simulation

grury
10-01-2008, 03:05 PM
You DON'T use a PFlow. That's the main point of the change - you can partition even a Teapot with a Noise modifier on top and its vertices will jitter!

1. Create a PRT Loader.
2. Load your BIN or PRT sequence into it
3. Add a Noise Modifier on top.
4. Set Scale to 0.1, enable Fractal
5. Set Strength for X, Y and Z to the radius of jitter you want, for example 0.1 or 1.0 or something like that.
6. Enable the changing of Seeds in PRT Loader Modifiers in the Partitioning rollout.
7. Partition!
RESULT: Each saved PRT sequence will have its particles slightly jittered compared to the original PRT or BIN sequence due to the high frequency noise added to the Loader.

Oh thats great...easier than I thought. Thanks a million.

Bobo
10-01-2008, 04:14 PM
Oh thats great...easier than I thought. Thanks a million.

Here is the tutorial I just wrote:

http://www.franticfilms.com/software/support/krakatoa/partitioning_existing_file_sequences_and_vertices.php

JohnnyRandom
10-02-2008, 03:34 PM
^ interesting :)

hey, i rendered the 40 millons particles.

u may think it's a easy thing but i'm happy :D

http://www.vimeo.com/1859084

there's something wrong when the "Mushroom" starts, like a noisy wave coming from down, but i think it's a problem with the fume simulation

Nice :)

That "rippling" is totally your fume sim, you can get rid of most of it with a smaller voxel size. IE lower your grid spacing.

dementol
10-02-2008, 03:36 PM
Nice :)

That "rippling" is totally your fume sim, you can get rid of most of it with a smaller voxel size. IE lower your grid spacing.


thnx!, i'm gonna try lower the grid size

Glacierise
10-02-2008, 04:27 PM
Cool test, as usual with the Krak tests :D Besides of increasing the sim res, you can lower the influence of the FFX follow, so PFlow will 'interpolate' the particles' positions. I'm gonna take a look at the new krak geometry lookup now, should make a cool test ;)

Gaetan
10-02-2008, 06:34 PM
Yes! thanks a lot for all!
GT

holycause
10-05-2008, 06:58 PM
i was wondering if some of you have trouble with the macrorecorder on max 2009 X64 since they installed krakatoa?

Bobo
10-05-2008, 07:56 PM
i was wondering if some of you have trouble with the macrorecorder on max 2009 X64 since they installed krakatoa?

Can you explain what you are experiencing?
Unfortunately, we don't use 2009 in production, and I consider the MacroRecorder "broken" since its introduction in Max 3. So I would not know if it were broken since I have never ever used it.
You shouldn't either ;)

But seriously, if you suspect Krakatoa is causing problems, uninstall Krakatoa and see if things change. If not, it might be another plugin causing the trouble, or Max itself.

olipoli1
10-05-2008, 08:08 PM
Hi again

I'm trying to finish a scene where I wish to use krakatoa for water blasting out from a wooden barrel which hits the ground and breaks apart... sounds easy enough:) so I got the set up I partitioned a realflow particle sequence a few times with different speed operator settings to get a nice dense structured effect.

The first problem is that, I tried to do what the tutorial says, about copying the channels data to be able to generate correct motion blure for the offset particles, but I don't have pflow box tools and I don't realy know what to write in the scripts operator dialog to accomplish the copy operation...

The other thing is, that besides this problem I rendered a few test passes to try compositing them... I also use a fumefx grid in the scene to create some dust effect for the impact of the barrel. I rendered the lit scene withe the barrel and then I made a pass for the fumefx dust and I had the krakatoa splash rendered in a different pass as well. The problem is that I dont know how could I cut away the parts of the dust that is being occluded by the karakatoa render. Like I had to cut parts of the barrel away from the dust with a matte material, I cant figure out how to do the same with the water splash... since there is no way I can render them together. Would the ambient PME feature be any help to this? I dont know since I havent used that and dont realy know how it works:) or do i have to manage to do this somehow in post by using a z depth pass and alpha channel operations... but I couldnt figure out an actual workflow for that either...

huh thanx in advance I hope it makes some sence

Bobo
10-05-2008, 08:46 PM
How are you rendering the FumeFX effects? Using Atmospherics, or PFlow particles?

In general, you will have to use some form of Matte in Krakatoa. You can matte out particles by creating a Mesher object out of the PFlow geometry and selecting it as Matte object.
Krakatoa also supports matting by a Z-depth map sequence. For example, when combining particles with render-time generated geometry like V-Ray displacements and such, you can save a Z-depth out of the other renderer and load it into Krakatoa. Then Krakatoa will only render particles that are closer to the camera than the Z-depth value.

Unfortunately, I don't think there is a good way to get a Z-depth pass out of an Atmospheric effect, so if you are rendering FumeFX as volumetric effect, I don't know if you can do much about that.

holycause
10-05-2008, 09:32 PM
hi Bobo,

thanks for your answer,
about the macrorecorder, the upper part stay empty.
Normal way, when the Enable option is active, it should capture most of my actions and generate the ms commands.

like on the picture below

http://www.holycause.com/divers/MacroRecorder.jpg


I re-installed max and the plugins separately and when i added Krakatoa, the problem was there again.

olipoli1
10-05-2008, 10:41 PM
thx Bobo

Yes I thought that this Is a problem...

"How are you rendering the FumeFX effects? Using Atmospherics, or PFlow particles?"

I dont understand you exactly here, do you mean if Im rendering particles driven with fume fx? Because no, I need the volumetric effekt for the dust, or I'm getting something wrong...

Oh and one other thing: how is it posible to maintain the same type of AA and motion blure results accross different types of render engines? For instance how could I get a Krakatoa pass to match a motion blured beauty pass from Vray? Also edges could have a problem matching In compositing if AA is not the same for the mattes for the different layers... I hope this doesnt feels problematic only for me... but actualy I hope it does, and than someone could help me out:)

Bobo
10-06-2008, 02:38 AM
thx Bobo

Yes I thought that this Is a problem...

"How are you rendering the FumeFX effects? Using Atmospherics, or PFlow particles?"

I dont understand you exactly here, do you mean if Im rendering particles driven with fume fx? Because no, I need the volumetric effekt for the dust, or I'm getting something wrong...

Oh and one other thing: how is it posible to maintain the same type of AA and motion blure results accross different types of render engines? For instance how could I get a Krakatoa pass to match a motion blured beauty pass from Vray? Also edges could have a problem matching In compositing if AA is not the same for the mattes for the different layers... I hope this doesnt feels problematic only for me... but actualy I hope it does, and than someone could help me out:)

Nope, you are not alone here. Currently there is no perfect solution to the AA problem, but we are looking into possible solutions for future releases, specifically for V-Ray which we are using more and more in-house since the end of Gelato. In 1.1.2, we added better support for the image distortion of the physical V-Ray camera, but we know there is a limitation to how well the Krakatoa pass can integrate with certain types of scenes and we are working on solving it with the kind assistance of Chaos Group.

Bobo
10-06-2008, 05:43 PM
hi Bobo,

thanks for your answer,
about the macrorecorder, the upper part stay empty.
Normal way, when the Enable option is active, it should capture most of my actions and generate the ms commands.


We were able to reproduce the problem in the office. It works in 2008, but in 2009 (which we simply recompiled for without any special changes) it seems to be killing the MacroRecorder.

We are looking for the cause of this and will post a fix if we find a solution.

holycause
10-06-2008, 06:07 PM
Ok, thanks for this informations

Abdel
11-05-2008, 03:34 PM
Here's something i created with 4 miljon particles, cashed 2 partitions (about 13gb of data)..

http://img528.imageshack.us/img528/4438/framewq7.jpg (http://www.youtube.com/watch?v=UMvXUByGYac)

http://img241.imageshack.us/images/thpix.gif (http://www.youtube.com/watch?v=UMvXUByGYac)

olipoli1
11-15-2008, 09:31 AM
hi all

just a simple question: I'm not a very experienced max user so I cant figure out how to render the krakatoa generated attenuation maps projected back on to the geometry without the geometry self shadowing itself because I dont need those shadows since they are already there on the background plate. Simply how can I get ONLY the projected black/white image? I tried with different passes and matte/shadow shaders but it seems like that the projection is not considered a shadow by max...

thx

olipoli1
11-15-2008, 09:35 AM
ok sorry I just figured it out: light's attributes>advanced effects:ambient only :)

Bobo
11-16-2008, 02:47 AM
http://jigu.cgsociety.org/blog/

Daniel-B
11-16-2008, 03:26 AM
I had a feeling that was Krakatoa used in Quantum of Solace. Nice job.

PsychoSilence
11-16-2008, 06:51 AM
I was actually ask by them to do that job but was already hired where the good stuff comes from :D can´t wait to see the movie, i´m sure u did an awesome job, jigu!!!Congrats and respect!

jigu
11-16-2008, 07:10 AM
@ Bobo : Thanks for linking to my blog.

@ PixelMagic : Thanks for appreciating.

@Anselm : Thanks man! I much appreciate your response. Guys like you, Ian ... all are great inspiration to me.. Yours works always inspire me to try something new. :)


Jignesh

Glacierise
11-16-2008, 07:30 AM
That was absolutely fantastic. Saw Quantum of solace yesterday, the intro blew me away, I was totally certain it was a Krakatoa work. Great job, absolutely great!

JohnnyRandom
11-16-2008, 05:34 PM
Going to see it today, will come back with detailed report:D

PsychoSilence
11-16-2008, 10:09 PM
@ Bobo : Thanks for linking to my blog.

@ PixelMagic : Thanks for appreciating.

@Anselm : Thanks man! I much appreciate your response. Guys like you, Ian ... all are great inspiration to me.. Yours works always inspire me to try something new. :)


Jignesh

You just made my day :)

JohnnyRandom
11-17-2008, 02:01 AM
Props Jigu! nice work ;)... pretty good movie too:D

Bobo
11-17-2008, 04:50 AM
Now this is a rather interesting coincidence, or is it?

As you probably remember from the beginning of this thread, the first version of what we now call Krakatoa was written back in 2004 to render the billions of particles for a movie nobody really saw called Stay (http://www.imdb.com/title/tt0371257/).

Guess the name of its director (http://www.imdb.com/name/nm0286975/)!

jigu
11-17-2008, 07:07 AM
Thanks Hristo and Johnny. I'm glad you liked the works. :)

JohnnyRandom
11-17-2008, 03:19 PM
Now this is a rather interesting coincidence, or is it?

As you probably remember from the beginning of this thread, the first version of what we now call Krakatoa was written back in 2004 to render the billions of particles for a movie nobody really saw called Stay (http://www.imdb.com/title/tt0371257/).

Guess the name of its director (http://www.imdb.com/name/nm0286975/)!

Heh, that is an interesting coincidence :)

What were the shot(s) in Stay? Out of curiosity...

Bobo
11-17-2008, 09:13 PM
Heh, that is an interesting coincidence :)

What were the shot(s) in Stay? Out of curiosity...

The whole Brooklyn Bridge sequence against the end of the movie.
http://www.franticfilms.com/vfx/projects/view_project/?id=28

JohnnyRandom
11-17-2008, 10:06 PM
Those stills were cool, hoping to see a glimpse on the trailer, may have to go rent it.

Which sparks another interesting coincidence...I haven't seen this in years, truly a particle junkies lasting inspiration :)

http://www.imagesavant.com/index.html


Man where does time go?

Sorry for the OT

JonathanFreisler
11-21-2008, 02:04 PM
yeah sweet, i sore Quantum of solace last week (i watched it pre release ^^ - because i'm special) grats dude, really cool stuff. I did watch it thinking "hhmm what was this done in"

mxrzone
11-25-2008, 04:32 PM
http://www.vimeo.com/2297647
Please criticism :beer:
Thank you very much

Bobo
11-25-2008, 05:10 PM
http://www.vimeo.com/2297647
Please criticism :beer:
Thank you very much

I am getting "Sorry this video no longer exists". I am not sure if it is really removed or my firewall is preventing me from getting it.
The thumbnail looks great though, I would LOVE to see the video. Could you upload it somewhere else or even post it on the Krakatoa support forum (http://support.franticvfx.com)?

grury
11-25-2008, 07:53 PM
http://www.vimeo.com/2297647
Please criticism :beer:
Thank you very much

Very nice and stylish. visually is right there, but i think it could be a bit more dynamic in terms of movement, feels a bit slow and floaty. maybe the morph could be a less linear, with slight overlap/fallow through on the particles.

Still, very nice.

JonathanFreisler
11-25-2008, 11:09 PM
yeh very cool dude.

But i agree with grury, the animation of the crow could be improved, then it would kick ass.

mxrzone
11-26-2008, 02:30 AM
I am getting "Sorry this video no longer exists". I am not sure if it is really removed or my firewall is preventing me from getting it.
The thumbnail looks great though, I would LOVE to see the video. Could you upload it somewhere else or even post it on the Krakatoa support forum (http://support.franticvfx.com/)?

Sorry Bobo
I don't even know the reason why. :(
please reconnect~

Bobo
11-26-2008, 03:14 AM
Sorry Bobo
I don't even know the reason why. :(
please reconnect~

Must have been the firewall in the office.
Went home, tried again, worked! :)

Good stuff!
The scale of the turbulence is probably a bit too small, and the older particles disappear too early and abruptly instead of slowly dissipating and losing density over a longer period of time. But I like it a lot!

jigu
11-26-2008, 03:29 AM
Hey Lee, cool effect man! Agree turbulance looks a bit low. But I liked as it is gives mystrious effect. I have seen this black smoke kinda effect in next harry potter film trailer..but I don't remember exactly.

EDIT : I found the link to that trailer. It's a different but it has black smoke.. looks cool..
http://www.traileraddict.com/trailer/harry-potter-and-half-blood-prince/trailer-b