Krakatoa

[system]

Nice one man, as allready said work on the turbulence a bit then its pure rock´n´roll
Reminds me a bit of the X-Men Night Crawler thing. I like the overall mood of the scene, the Asian background and the Ink fits very well. Im anxious to see an update of it.

greetz

[mxrzone]

Thanks guys for advice

some more updating (Ink bird)

1. low turbulence
2. older particles disapper too early

but!, some more problem, :eek:
“abruptly instead of slowly dissipating and losing density over a longer period of time”
I don’t even know the reason why dissipating particle

I used 3ds max9(64bit) and Krakatoa+Fumefx+Particle Flow and os Vista(64bit / 8G ram)

[Bobo]

Thanks guys for advice

some more updating (Ink bird)

1. low turbulence
2. older particles disapper too early

but!, some more problem, :eek:
“abruptly instead of slowly dissipating and losing density over a longer period of time”
I don’t even know the reason why dissipating particle

So the Delete is set to 80 frames +/- 30, which means a particle will live between 50 and 110 frames. Sounds reasonable. You could try to play with that variation and see if it changes anything. The only other operator that could theoretically delete particles is the FumeFX Follow which has an option to kill particles if they leave the sim bounds. Could that be involved?

A couple of additional hints:
*PFlow allows you to multi-select operators by holding down SHIFT or Ctrl. When you do this, all operators’ rollouts will appear in the Parameters pane, so you don’t need multiple screenshots
*Krakatoa does NOT need any geometry to render PFlow particles. So the Shape Operator set to Vertex is not really needed for Krakatoa to see and render the particles. If it is there for another reason, then great, but you can save a bit of memory by not assigning any Shape to your particles when rendering PFlow in Krakatoa.

[mxrzone]

So the Delete is set to 80 frames +/- 30, which means a particle will live between 50 and 110 frames. Sounds reasonable. You could try to play with that variation and see if it changes anything. The only other operator that could theoretically delete particles is the FumeFX Follow which has an option to kill particles if they leave the sim bounds. Could that be involved?

A couple of additional hints:
*PFlow allows you to multi-select operators by holding down SHIFT or Ctrl. When you do this, all operators’ rollouts will appear in the Parameters pane, so you don’t need multiple screenshots
*Krakatoa does NOT need any geometry to render PFlow particles. So the Shape Operator set to Vertex is not really needed for Krakatoa to see and render the particles. If it is there for another reason, then great, but you can save a bit of memory by not assigning any Shape to your particles when rendering PFlow in Krakatoa.

thanks Bobo, very useful additional hints!
May I ask a question? “dissipating particle” mean…
FumeFX Birth 01 => Rate 2,500,000 // Bird(body) dissipating particle starts with the 250frame
FumeFX Birth 01 => Rate 6,000,000 // Bird(body) dissipating particle starts with the 100frame
FumeFX Birth 01 => Rate 10,000,000 // Bird(body) i don’t see bird to the stage, no more particle creation
i want to flying bird from start(1frame) to finish(250frame)
at present,start(1frame) to finish(180frame)

[grury1]

A couple of additional hints:
*PFlow allows you to multi-select operators by holding down SHIFT or Ctrl. When you do this, all operators’ rollouts will appear in the Parameters pane, so you don’t need multiple screenshots

One learns something new everyday…priceless.

@mxrzone: Couldnt you perhaps send particles (dissipation) into another Event and enherit the motion from your initial Fumefx creation event. This way u would have a lot more control on how your particles would move/dissipate.

[JohnnyRandom]

Cool ad, Sand by Krakatoa

http://www.studiodaily.com/main/technique/casestudies/10330.html

[Glacierise]

Cool stuff

[Bobo]

Chad Capeland from Anatomical Travelogue posted this interesting “piece of mind” to their research blog:

http://www.anatomicaltravel.com/research/2008/12/fun-with-voxels-squishy-brain/

[Glacierise]

How is that thing made? Krakatoa, really?!

[JohnnyRandom]

Dude, Chad does some crazy stuff I couldn’t get the “squishy brain” to play in firefox, it only worked in IE for me…strange

The Squishy Brain is kinda freaky:D

Dr. Frederick Frankenstein: [to Igor] Now that brain that you gave me. Was it Hans Delbruck’s?
Igor: [pause, then] No.
Dr. Frederick Frankenstein: Ah! Very good. Would you mind telling me whose brain I DID put in?
Igor: Then you won’t be angry?
Dr. Frederick Frankenstein: I will NOT be angry.
Igor: Abby Someone.
Dr. Frederick Frankenstein: [pause, then] Abby Someone. Abby who?
Igor: Abby Normal.

LOL

[grury1]

EDIT: By changing G/F Life on the RealFlow loader (Particle Size tab) from the default 20, to a higher number, it worked fine…

 I'm having problems rendering/saving RealFlow particles using Krakatoa.
 I have several passes of particles working just fine, but with a specific one it gets to a certain frame and Krakatoa only renders or saves a fraction of the particles.
 Bellow is a screenshot of the viewport and the render result.
 
 [http://www.grury.me.uk/krakatoa.jpg](http://www.grury.me.uk/krakatoa.jpg)
 
 The only way I managed to load this sequence is via RealFlow Particle loader, but although it does load the whole sequence on the viewport, on frame 152 it drops a huge chunk of particles, during rendering, not in the viewport. If I try using Krakatoa PRT loader or Particle Flow, no particles get loaded, unless I tick Load Single Frame Only.
 
 Anyone experienced anything like this before??
 Thanks
 
 Carlos

Edit: If I render using Scanline or Mentalray it renders just fine

[friedpixels]

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.

Guess the name of its director!

Thanks for the mention – we have been quite mum on the title sequence until lately due to the politics of being able to talk about / show work from the movie until a certain time period! I’m sure all of you understand that! Thanks again bobo for the help during our initial setting up of stuff on our end here to work with krakatoa/deadline. Also without Jigu I would have been lost, you were very much of help and it was a fantastic collaboration!

During our research for QoS we did bump into krakatoa and realize the connection between Marc / Stay and Krakatoa. We thought it was a good tribute to Doc Bailey and his amazing work!

Sorry we’ve been quiet but I promise some good behind the scenes and info is about to pour out! Cheers!

[Erka2]

I’m having some problems trying to render hundreds of instanced objects as matte for particles pass. I’m getting “bad allocation error”. Is krakatoa capable of rendering of big number of instanced objects as matte?
Btw, even scanline renders same amount of objects, but it’s pretty big.

[Bobo]

I’m having some problems trying to render hundreds of instanced objects as matte for particles pass. I’m getting “bad allocation error”. Is krakatoa capable of rendering of big number of instanced objects as matte?
Btw, even scanline renders same amount of objects, but it’s pretty big.

Need some more info -
*what Max version?
*32 or 64 bit?
*How much RAM?
*How many polygons in the matte objects?
*How many particles?

Krakatoa uses a kd-tree like most raytracers for the matte objects, there might be something going wrong with memory allocation. If you remove half of the matte objects from the selection set and render, does it still crash?

EDIT:

I just loaded 50M particles occluded by 6.5 million faces using 25 instanced teapots with 64 segments each into Max 2008 64 bit.
Memory usage for the particles was slightly less than a GB, the matte objects took around 700MB.

Here are the render stats from the Log:

PRG: Rendering frame 0
STS: Section “Retrieving Particles”:
STS: Total 00h 00m 20.484s Called 1 times Avg 00h 00m 20.484s
PRG: Rendering 50000000 particles.
STS: Section “Render:Matte Objects”:
STS: Total 00h 01m 44.171s Called 1 times Avg 00h 01m 44.171s
STS: Section “Render:Sorting Particles”:
STS: Total 00h 00m 07.422s Called 1 times Avg 00h 00m 07.422s
STS: Section “Render:Drawing Particles”:
STS: Total 00h 00m 32.860s Called 1 times Avg 00h 00m 32.860s
PRG: Finished rendering frame: 0

I would expect the same setup to crash in 32 bit with a memory error. YMMV.

[Erka2]

It’s 3ds max 2008, 32 bit, 3Gb Ram. Actually polycount was pretty low (optimized objects). I have tried to recreate this case on empty scene with big number of instanced spheres - and it worked like it should. After some changes to pflow and 3ds max restart - now everything works fine. So it is some kind of another problem (but it was pretty repeatable before pflow rework - as soon as I was adding matte sets - getting that error).

[Bobo]

It’s 3ds max 2008, 32 bit, 3Gb Ram. Actually polycount was pretty low (optimized objects). I have tried to recreate this case on empty scene with big number of instanced spheres - and it worked like it should. After some changes to pflow and 3ds max restart - now everything works fine. So it is some kind of another problem (but it was pretty repeatable before pflow rework - as soon as I was adding matte sets - getting that error).

Keep in mind that Krakatoa, Max and PFlow have to share (and fight for) memory in 32 bit address space. The usual approach (if you have enough HDD space) would be to dump the particles to PRT sequence first, then render with Matte objects with the PFlow off.
This would ensure that Krakatoa does not have to fight with PFlow for memory resources.

As with most parts of Max 32 bit, it is not about how much memory you have, but how fragmented it is. Sometimes a memory operation could fail because the specific chunk size cannot be allocated due to fragmentation. This problem does not exist in 64 bit due to the enormous available memory address space, even if the physical memory is not that much.

In general, Krakatoa might cause paging if it runs out of RAM in 64 bit, but would never crash , just get a lot slower. That’s why we recommend 64 bit for serious Krakatoa work. (oh, and it is twice as fast, too).

In cases like yours, you should try restarting Max, caching particles out and tweaking the flow to use less memory. Krakatoa generally uses a lot less memory than the PFlow that created the particles. So dumping to PRTs and loading the cached version can reduce the memory requirements a lot (depending on what channels are required by Krakatoa features, a particle can use from 14 to 40 bytes.)
Since the Matte Objects are evaluated after the loading of the particles in memory, it is possible that with the PFlow and Krakatoa Channels already there, there was no room left for the kd-tree…

[Als]

Hi,
do I need max to test krakatoa, or there is a way to (just) use krakatoa and realflow instead?

Thanks

Als

[Erka2]

In cases like yours, you should try restarting Max, caching particles out and tweaking the flow to use less memory. Krakatoa generally uses a lot less memory than the PFlow that created the particles. So dumping to PRTs and loading the cached version can reduce the memory requirements a lot (depending on what channels are required by Krakatoa features, a particle can use from 14 to 40 bytes.)
Since the Matte Objects are evaluated after the loading of the particles in memory, it is possible that with the PFlow and Krakatoa Channels already there, there was no room left for the kd-tree…

Thank you, Bobo. I’m trying to use caching as much as I can before we’ll have a chance to move to 64 bit systems. I will use it for sure on same scene if I’ll have such problems in future.
Thanks again!

[Bobo]

Hi,
do I need max to test krakatoa, or there is a way to (just) use krakatoa and realflow instead?

Yep, Krakatoa is currently available as a plugin renderer for Max 9, 2008 and 2009, 32 and 64 bit. You can theoretically download the 30 days demo of 3ds Max from the Autodesk site, get the Evaluation version of Krakatoa from the Frantic Films site and play with them for a month to see if they are worth having…

[Als]

Yep, Krakatoa is currently available as a plugin renderer for Max 9, 2008 and 2009, 32 and 64 bit. You can theoretically download the 30 days demo of 3ds Max from the Autodesk site, get the Evaluation version of Krakatoa from the Frantic Films site and play with them for a month to see if they are worth having…

Thanks a lot, sound like a great idea…

Als