If i understand well from what i m reading and seeing soo far ( i havent have the chance to try it yet but hoping that will change soon) , Krakatoa will take a Particle Position in space , register every N particle velocitys , render a Colored Point on n number of them
and render them hyper fast… their is also the cool seeding spreading variance of result of calculations that can be simultaniusly simmed to then “composite” it and layer it back to front from camera space …
Now my question is :
Example : Let say the Particle dynamic is following a Fume Fx grid or a Flood Grid … Basicly , their is an Interface determined by a Fluid Solver based on its Fluid Dynamic properties etc… Would their be a Way for Krakatoa To Understand Certain aspect of the Density of the particles or surface Tensions to then fill Inside on rendertime millions and millions of points averaging Velcitys from their neighboor ?
Sam told me today that their is a way to add points on rendertime on a particle Density with some “paterns” of Volume positions around each particles but the Motion always shows up as beeing this way … some kind of a Low amount of Afterburn puff Result in alot of them overlapping but filled with Points …
Maybe i understand it wrong and its already possible … I would think that the potential of an accurate method like that could be extreamly usefull for alot of effects…
Example of what i m thinking off is : “Sable Movant”( i guess Sinking sand in English, sorry i dont know the exact word) … Imagine a Horse beeing sucked in a Pool of sand with a full Flood fluid collision from the horse movement with a setup mody and honey like . Adding trillions of points in the proper interface densitys and having the particle Based amount By it self define the Level of Accuracy and detail of the Final Average Velocitys interpolations would surely make an interesting and really fast to run shot ( i would imagine a Production time for something like that could be SimTime (2/4 of the totaltaskTime)+ 1.5/4 to 2/4 of Rendertime
Regards,
www.cgfluids.com
Krakatoa does do “Pufting” when you do DOF, but it doesn’t account for anything other than the particle’s position relative to camera. It’s fast and efficient, however.
With something like Box#3 you can do the volume filling, but it has to be pre-calculated to a PRT sequence, and is not made at rendertime.
Given the effort involved in sampling neighboring particles to determine density and average velocity, you might not want this done at rendertime, but pre-caching could be made MUCH more efficient than what Box#3 does. Box#3 is great for flexibility, but it’s only fast compared to particle scripting.
- Chad
If i understand well from what
i m reading and seeing so far
( i havent have the chance to
try it yet but hoping that
will change soon) , Krakatoa
will take a Particle Position
in space , register every N
particle velocitys , render a
Colored Point on n number of
them
and render them hyper fast…
Not exactly.
Krakatoa takes EVERY particle, its velocity and other properties and draws EVERY one, hyper fast. Only the PRT loader allows for Every Nth, but by default it is set to 100%, so if you saved 20 million, it draws 20 million.
Because Max cannot generate 20 million out of the box under normal conditions, we allows you to save the same system multiple times with different seeds as “partitions” to get higher quantities in the same volumes.
We do no interpolation at this point, but there were threads in the past about the idea - you can probably find them using the Search feature of the board.
We do no interpolation at this
point, but there were threads
in the past about the idea -
you can probably find them
using the Search feature of
the board.
Here it is - I searched for "interpolation" and found the original thread with comments from krakatoa's senior developer:
http://support.franticfilms.com/wb/default.asp?action=9&fid=23&read=434
Thanks for theese answers guys :
“Given the effort involved in sampling neighboring particles to determine density and average velocity, you might not want this done at rendertime, but pre-caching could be made MUCH more efficient than what Box#3 does. Box#3 is great for flexibility, but it’s only fast compared to particle scripting.”
I dont use pflow so i wouldnt know much about what your saying… But that gives me an idea , what if i do my density calculation in realtime in tp with some simple expressions and rules and dump that in a special group … Later on if i add Krakatoa on those groups only , will i be able to create those tons of point over those particles choosen ?
Or the Only way is to actually do what Bobo is explaining witch is to create the amount desired of particles from the particle System and then use partition if we want more and the normal workflow etc… ?
www.cgfluids.com
Dumping to a group in TP would work, but it depends on whether TP can handle the amount.
Say you want 40 million particles. You create one million and add the other 39 million particles in a TP group. While Krakatoa can render these particles if coming from PRT, it might not have enough memory to handle them if TP is also keeping them in memory.
The solution you were asking for initially would mean that Krakatoa would load one million particles but then render 40 million (or whatever) by creating new ones on the fly. Unfortunately, this is tricky as Mark mentioned, and would probably require more work without looking as good as real 40 million in, say, 10 partitions of 4 million each.
Drawing particles is fast (2 million/second on my machine, excluding loading and lighting). Loading particles is relatively fast, too. The main issue is disk space, but it is getting cheaper. So I think Krakatoa will be using explicit particles from partitions for a while unless we come up with something really smart.
We were discussing the possibility to use hierarchical particle systems where you simulate some small particle systems and save them to disk, then you simulate one master system and then replace each particle of the master with one of the saved particle systems. It would be good for star systems and such, but could be useful in general…
The hacks to make extra particles cheaply can be done with TP or Box#3 right now, the difference being the speed. As I said in the other thread, I want the Krakatoa developers to focus on the things we CAN’T do in TP or Box#3, like the memory handling and rasterizing. If they get bored and want to speed up some of the things we can do slowly, then that’s great, but I suspect there is always more work on the to-do list than there is energy available.
Except in Bobo’s case, where available energy seems to be in enormous supply.
- Chad
ok … that sounds clear… We are Right modifiing our caching methods that will help accomodate some of those itteration random based that krakatoa compatibility could offer…
I m looking foward for the next tp compatible build of krakatoa .
thanks everyone for the explications…
www.cgfluids.com