Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
Old 03 March 2007   #61
Bobo's Krakatoa Blog of the week

Last week we spent some time optimizing code and speeding up some areas of Krakatoa - although it feels very fast already, there is always room for improvement. In fact, particle sorting is now between 2 and 6 times faster depending on the situation and the used sorting method. So I sat down to do some benchmarking using one, ten and twenty million particles lit by a spotlight. The benchmark proved that Krakatoa scales in a linear fashion - in other words, if you increase the particle count 10 times, so does your render time. This is Good News.

The benchmark was performed in Max 9 32 bit running on WinXP 64.
Today, I sat down to do some testing in 64 bit. And there came the surprise.

You must have noticed all the "Will my Max render faster in 64 bit?" threads around? The usual answer is No. Imagine my amazement when the 64 bit build of Krakatoa performed ALMOST TWICE AS FAST on the same scene and machine - total render time for 10 million particles lit by a spotlight went from 42 seconds to 23 seconds, this is 1.82 times faster to be precise.

The explanation is simple - Krakatoa is heavily dependent on memory management. Drawing points in a buffer is not the biggest trick in the world, but loading, sorting and managing gigabytes of particle data is. Where 32 bit software has to live in a fragmented memory space and try to fit the data in small chunks around the available memory, 64 bit Krakatoa enjoys a single contiguous memory chunk.

So if you are still unsure about switching to 64 bit computing, soon there might be a reason to do so...

Finally, here is a cheesy piece of imagery made from those 10 million particles from the benchmark, but with 3 lights and some "boolean subtractions".

We just added the option to "sculpt" your particle clouds by carving them using arbitrary meshes - you can either include or exclude particles inside the specified volume. So instead of trying to fill a volume using Particle Object in PFlow which is a rather slow process, you can save a simple particle cloud (like a box or sphere) and then use a static or animated mesh to load only the particles inside or outside its volume. With 10 million particles and a mesh that fully encloses them, the difference in the loading time with or without "culling" is around 2 seconds (this means that each particle has to test against the mesh).
In fact, since in the typical case many particles would be outside the mesh and thus not loaded, lit or drawn, the "boolean" version would generally render faster than the simple particle cloud alone

Last edited by Bobo : 03 March 2007 at 06:05 AM.
Old 03 March 2007   #62
Lovely cheese Bobo. Great news / info. I'm def. considering the full out 64 bit upgrade this year. You guys are def. doing a great job on Krakatoa... thanks for the updates! Can't wait to get a slice!
Old 03 March 2007   #63
great news!

im currently upgrading all workstations and renderfarm to Xp64, what a ball ache. good to see this plugin getting closer to launch!
3D Generalist

Old 03 March 2007   #64
Thumbs up

Bobo this is absolutely fascinating!
Please keep giving us more info and updates on Krakatoa, it sounds an incredible tool.

This thread is almost getting to the stage of becoming a krakatoa blog! (which is a good thing)

Old 03 March 2007   #65
Originally Posted by Matt^: Please keep giving us more info and updates on Krakatoa

I've got a better idea:
Please give us Krakatoa!
Old 03 March 2007   #66
Originally Posted by noouch: I've got a better idea:
Please give us Krakatoa!

Good idea!

Just wanted to mention that Krakatoa will run in full-featured evaluation mode if installed without a license. The only limitation will be watermark on the rendered image (a la Gelato Pro) and the inability to render/save on the network without a license. We do not intend to limit the number of particles you can process.

In other words, the day we have a release version 1.0, you will be able to test drive it.
Old 03 March 2007   #67

VERY SMART marketing !
Hope to see it soon and the price is fair.
Old 03 March 2007   #68
That's awesome. Watermarks don't bug me much. ...i'm just really anxious to find out the price.
Old 03 March 2007   #69
Wow really looking forward for the release of Krakatoa.
Old 03 March 2007   #70
Originally Posted by muzbee3d: BOBO

VERY SMART marketing !
Hope to see it soon and the price is fair.

Just out of curiosity, what do YOU feel would be a fair price for this type of niche software?
(The price is not set in stone yet, so there is still room for discussion)
Old 03 March 2007   #71
Me and PhsycoSilence were talking for a few earlier... and we said somewhere between pftools box1 (200 US) and box3 (500 US) would be a good deal. Not having used it I first looked at afterburn costing 500, and though that is a different (yes i understand the differnce between them... it's just the closest thing i can compare it to) type of toolset I came up with that as a sort of max price. As far as I know afterburn has more options thus far, so as high as afterburn depending on the toolset, but I don't think any higher than that would be worth while. Of course I would also wonder what kind of network licenses would come with it as well.. and that can add or subtract to the price.

Old 03 March 2007   #72

Talented users will always find new ways to use this NEW tool beyond what it's creators ever thought of. With that in mind a lower entry price will get it out there much farther and faster, hence more demand will likely come from the new looks made with it. So to your question, 195.00 usd in the center with a + or - 50% range is fair for the first version. Updates can be priced baised on the voulme of 1.0 users, Get us hooked and pay yourselves later ! Looking forward to using it .

Old 03 March 2007   #73
having krakatoa in the plugin directory? priceless!

as i discussed with Ian earlier via ICQ it would be my plesure to buy it the day it comes out finally if itīs pricing is in the fair range for a plugin dealing with particles / FX as well. so something between 200 (flow box#1) up to 1,300 (TP) bucks... anyways, iīll own both ītil th end of 2007 hopefully. now itīs in frantic softwares hands if they ruin me or not

kind regards


Last edited by PsychoSilence : 03 March 2007 at 04:07 PM.
Old 03 March 2007   #74
Is Krakatoa just a straight up renderer or does it have extra tools to go along with existing pflow features?
Old 03 March 2007   #75
Originally Posted by a13xr3d: Is Krakatoa just a straight up renderer or does it have extra tools to go along with existing pflow features?

Historically, Krakatoa was a stand alone renderer first. This meant that we needed a way to get particle data, matte geometry, lights, cameras and so on out of Max to the renderer and back. This happened using a PRT file format which can save any particle-related data, a simple Mesh file format and an XML scene description format. On top of that, some of the particle data came from other applications like various FLOOD modules, so it was important to have a way to load PRT files not only in Krakatoa, but also in Max. This happened initially using custom Krakatoa Birth and Position operators for PFlow (the same operator could read RealFlow BIN and Gelato Spatial Database files).

Then the decision was made to implement Krakatoa as a Max 3rd party renderer and improve the integration. But the elements mentioned above were still around. This means that you can still save PFlow, Thinking Particles, Geometry Vertices, Max Legacy Particles etc. to PRT files AND load them back into Particle Flow or into the Max scene via a custom PRT Loader which is a geometry object that can read PRT sequences.

As time passed, we kept on adding tools to manage both particle systems in general and PRT Loaders / Files in particular and also added features to the PRT Loader to make it more flexible. In short, the Krakatoa + PRT Loaders can be seen as a custom caching system for Max Particles.

*Other than dedicated caching operators in PFlow or TP, this system writes to file sequences instead of a single large file so you can easily manipulate these file sequences, replace bad files without recalculating the rest, query the particle count or any other info on a specific frame by just reading some bytes from the header of the corresponding frame file etc.

*You can create multiple partitions of the same system with varying random seeds to increase density.

*You can reuse the same cached particles (or any combination of files as one PRT Loader can load an ARBITRARY number of sequences or single files) by creating any number of PRT Loaders in the scene.

*The PRT Loaders can be transformed (moved, rotated, scaled, and of course keyframed) so you can save a static particle system but then animate the loader in the scene. An option allows you to ignore the transformations so the particles would appear at the absolute position they were saved at.

*You can assign new materials to the PRT Loader to override any saved particle colors, thus allowing for even more flexibility when texturing your particle clouds.

*The Render Percentage can be animated, so you can not only load a portion of the particles from disk, but also animate this amount over time which can be used for custom fade in/ build up effects depending on the particle order and loader settings. For example, if you have a 64 segments teapot saved to PRT file, animating the Percentage while using Load First N Particles would build the object out of particles in the order of vertex generation in the teapot primitive. If you switch the loader to Load Every Nth Particle, the teapot will slowly appear as more and more particles across its whole surface become visible...

*The Timing of the Loader can also be Offset and animated via Playback Graph just like the PointCache2 modifier so you can save a straight particle animation, but then animate the Loader to playback at various speeds, backwards, freeze time over time for bullet time effects and whatnot.

*The loading of particles can be controlled using custom meshes (see previous post about the cheese) so you can render only a portion of particles defined by (animated) control volumes. This way you can carve out portions of your particles, reveal different parts over time (for example imagine a full human body particle system with a box moving up and down revealing only a small portion like an XRay)

Right now we are adding a sophisticated PRT Loader analysis utility which can show you graphically the memory usage, particle counts on disk and during rendering, missing frames and a lot more for the current system - this both inside Max or as optional HTML report.

Because PRT Loaders show the particles in the viewport like any other system, you can use them as a sort of a new unique particle system that uses other particle systems as the input source via PRT files.

Thus I would say that Krakatoa is a lot more than just a renderer. It is a new way to work with large quantities (dozens and hundreds of millions, depending on OS and RAM) of particles, where rendering is just a part of the feature set.

I must admit most of these added features were not planned for 1.0, but as we and our beta testers pushed the software in production, we found out that some additional options would help the workflow tremendously, so we added them.

Last edited by Bobo : 03 March 2007 at 08:39 PM.
reply share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright Đ2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Currently Active Users Viewing This Thread: 1 (1 members and 0 guests)
Forum Jump

All times are GMT. The time now is 12:33 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.