Me? Thanks, but no.
The real amazing guys are Mark Wiebe, the Frantic Software lead and “father” of Krakatoa, and all the other RnD programmers involved in our software projects. (let me also mention Darcy Harrison who did some great work on Krakatoa the last couple of months and David Marks who moved from managing 3ds Max Beta Testing to managing Frantic Software Beta Testing ;))
I just help where I can (mostly on the scripting and User Interface design side).
In this thread I am only bringing you the “good news”, but I did not create this amazing tool, although I cannot wait to go to work every day to get involved in its development and testing!
Me? Thanks, but no.
Excellent write-up on Krakatoa, Bobo. Do you mind if I republish it at the Orbaz forum?
No, I don’t mind - the more, the merrier!
would u mind explaining how thats done in Krakatoa?
no luck in getting it to work so far :shrug:
Keep in mind I am working with the upcoming 0.9.5 build, so things might have changed a bit since 0.9.4.
There are two operators that can be used in Particle Flow to load Krakatoa PRT Files: Krakatoa File Birth and Krakatoa File Position.
*Let’s say you have created a teapot in the scene, bumped up segments to 64, saved a single PRT file containing all its vertices as particles.
*Now you want to use these particles as source in a PFlow and apply your own speed, forces, shapes, whatever.
*You create a default PFlow
*Replace the Birth operator with Krakatoa File Birth
*Pick the file you just saved
You should see PART of the teapot appear as particles on the Emit Time (default is frame 0). This is because a default PFlow is set to 50% Viewport percentage and 100K particles, but we have 131330 particles to load.
*You can check the “Evenly distribute loading” option and the 50% particles will be loaded evenly from the file, thus showing a full teapot. Otherwise, you would see the first N particles instead.
*You can, of course, also go to the PFlow Emitter and set Viewport to 100% and System Limit to 1,000,000 to allow for all particles to be loaded from the file.
*Optionally, you can also link the particles to a scene node to inherit its TM, thus you can translate, rotate and scale the particles at birth without additional operators.
Now you can use these particles as any other particles in PFlow, including applying forces, calculating collisions etc. We only used the initial particle cloud as the source in a Birth operator.
The other case is using actual particle motion (position and velocity) from a PRT file in a Particle Flow. Here is a typical case:
*Let’s say you have saved a whole PFlow animation to disk already, or the PRT files come from another source (at Frantic, this would be FLOOD, but the two operators support Realflow BIN files and Gelato SDB files, too).
*In a simple test, create 131K particles falling down using a default PFlow and save to disk as 100 frames sequence.
*Now create a new flow to load this animation into.
*You can create particles using any Birth operator you like, including Krakatoa Birth, but you don’t have to. Let’s say you have loaded your saved Teapot PRT file from the previous example, but want to apply the motion from the default falling particles to it.
*Disable all the Speed, Rotation etc. operators except for the Display.
*Replace the default Position operator with the Krakatoa File Position operator.
*Pick a file from the PRT SEQUENCE to use as the position / velocity source.
Now you have the following options:
*You can enable “Position Effect Per Frame”. This will load the positions from the file and assign them to the particles. The default Effect value is 1.0 which means that the position will be enforced on the particles, thus the teapot particles will appear as the rectangular stream of falling particles saved in the PRT sequence. If you reduce the effect value against zero, the effect will be less and less and your particles will turn more and more into a teapot-shaped cloud, at 0 there will be no effect at all and you will be back to a teapot.
*You can enable the “Velocity Effect Per Frame” in addition to the above - this will set the speed channel of the particles to the velocity value stored in the PRT file. At 1.0 effect value, your teapot particles will be both shaped AND moving like the rectangular stream of falling particles written to the PRT sequence. With less than 1.0, the velocity loaded will be scaled down until at 0 the particles will not move at all. Note that you can set the Display operator to LINES to show the magnitude of the speed vectors, then play with the effect value to see its influence.
*If you enable only velocity loading but no position loading, your teapot will appear as it was created by the Krakatoa File Birth operator, but its particles will move down like the particle stream, because their speed values will be set to those in the PRT sequence!
*You can apply ADDITIONAL speed-affecting operators like Forces etc. to alter the saved motion. For example, in Superman Returns we simulated some underwater particulate matter motion in FLOOD, then loaded in PFlow via these operators and applied an additional drift to the side using a simple Wind Force which we could adjust in realtime in the viewport ON TOP of the fluid simulated motion…
*Since the Krakatoa File Position operator also has a Bind To Node option, you can animate any scene object and then apply its motion to the particles by picking it in the operator! This gives you yet another way to animate your particles on top of the saved sequence positions.
In general, if you want to affect the particles with your own forces and even do collision tests etc, you might want to load the initial positions with the Krakatoa File Birth, then apply ONLY the Velocities per frame without enforcing positions from the sequence to allow the particles to move freely under force influence and deflector bouncing etc., while still inheriting the original velocities stored in the file.
Once again, I just did everything I described in 0.9.5 and it worked as expected. If it does not behave like this in 0.9.4, it might be some bug that got fixed in the mean time. The new build is coming soon anyway…
Thats awesome Bobo! tones of info here!!
Hope ya well mate!
Thanks dude, Happy New Year!
I know you worked with the stand-alone version of Krakatoa on SR, I bet you will not recognize the next beta we are cooking now - it feels like a quantum leap both featurewise and when it comes to UI organization. And since we are not keeping it under NDA or anything, I really felt compelled to spread the word. I haven’t even mentioned some of the coolest things we added in the last few weeks
I really felt compelled to spread the word. I haven’t even mentioned some of the coolest things we added in the last few weeks
Do tell, then… Since it isn’t under NDA…
We are all trying to scrape our jaws off the floor from what you have already told us…
There’s even more? You are starting to defy my imagination It seems that finally, the possibility comes to create really naturalistic particle scenes (huge amounts of particles, forming entities). Frankly, I wasn’t hoping this could come so soon! I am living in a happy time
Thx for the explanation, will get to testing that!
Cheers bobo, happy ny to you too dude
yeah been on the beta for a few months, in case you didn’t know I’m working with you guys again but from my studio, so doing a bunch of effects for a couple of shots you’re working on using Krakatoa for some funky particle effects
Great work mate! Hope to catch up with you guys at Siggy this year, been a while!
I knew you were on the project and on the beta, prepare for a new build tomorrow
It will blow your mind!
Just a note that the image shown on the current CG Workshops page was created not without some help from Krakatoa:
This is, of course, the Red Sun just about to blow away the planet Krypton.
Rockin’! I damn love such shots (elemental fury )
Wow, this is all looking so awsome, must get back into particles
Wow, looks amazing!
Might be a bit early but, are you planning to release a demo for trial?
and another question is about shading liquids, as I’d be able to import realflow bin files, will it be some volumetric shading similar to metaballs?
All our software (which in this case means our ONLY software, Deadline ;)) has a demo mode.
We have not discussed whether we will give a full featured version for 30 days like Max, or a feature-limited version forever (like a hard-coded limit of particles or something). But I am pretty confident there will be a trial version from the beginning.
As for shading, we are rendering points, but that does not mean we couldn’t shade surfaces of volumes. This is till a WIP though, but is coming.
Metalballs are out of the question though, Krakatoa was designed to be a volumetric point renderer.
I guess for some scenes using volumetric points will do as fluids, like really turbulent fluids with sprite and so.
Thank you for the prompt reply!
I’ll keep watching this thread with a lot of interest.
Normally, we mesh the surface of our fluids, since this is much more efficient for large volumes. But then there is the problem of water drops becoming smaller than the voxel resolution. In that case, a mixed approach combining “the best of both worlds” seems logical. In other words, we use particles for natural phenomena that are particle-based in real life - like smoke, silt, sand, small waterdrops etc. Creating an ocean simulation with particles would be highly inefficient
And then there are the non-natural phenomena like pixie dust and general magic - the additive density mode in Krakatoa is great for those
How are the shadows rendered in Krakatoa? With that amount of particles I guess there is no shadow rays casted from each particle? Are the particles sampled in some voxelgrid for shading?