Heya Folks!
I’m starting an ad soon which is going to be very heavily particle based and use a lot of krakatoa (snow + avalanche rendering). I’ve been using pflow and box 1 for a long time now and I’m finding some things aren’t quite good enough for what I want to do. Also not having a disk cache option without box 3 is a huge problem. I’ve written a script to bake pflow into regular scene objects which needs a bit more work but I’m not sure if it’ll do the same job as having an internal cache. For all of the big particle folks out there what are your opinions on tp vs pflow? since cebas are doing a discount on tp for fume users the price isn’t much of an issue.
Also how is krakatoa doing with tp considering it’ll only be doing snow fading on and off - what’s the performance like?
Im using both tools in production.
Im a big fan of Tp, but its not currently
playing well with Krak!
For what your doing I would highly recomend box 3 and pflow.
The workflow is nice an solid, and box 3 allows u to do some tricky stuff with denisity and movement.
Nothing u could not do with TP, the intergration is just not there yet.
cheers
TP does collsions better, but we use mostly Box3 for anything else. We also have the sub-operator SDK, which is new, and that helps.
- Chad
Yeah the collisions and fracturing seemed like a major draw for tp but disk caching would benefit everything I do with pflow - it’s a shame cebas don’t do demo versions at all. I’ll start messing around with box 3 and see how far it gets me - thanks folks.
Well…
We’ve used Cebas disk caching and Oleg disk caching, and frankly, both are terrible.
Krakatoa disk caching is the way to go. There’s a PRT loading pflow operator, too.
I want something that saves a file per frame, and with partitions, I can accumulate particles through iterations. And I can lock, version, back up, etc. Both the Cebas and Box 3 disk caches are “automagical” and I don’t like that.
TP also have much better shape support. Box 3 has NOTHING for shapes beyond what you get in Box 1 or standard Pflow. Not likely to make a difference for Krakatoa use though.
- Chad
Krakatoa disk caching is the
way to go. There’s a PRT
loading pflow operator, too.
The PRT File Format was not designed as a caching format, but as a format for particle transport between applications. We had to move data between several components of the Flood suite, between Max and Krakatoa Standalone, from Flood back into PFlow and so on. So it had to be universal, extensible, simple enough to be written and read by any application without software-specific data inside, compact enough (zipped!) to allow billions of particles to be stored on the network etc.
The fact it could be used for caching particles was a side effect, not the main goal, so I don’t know if it is fair to compare dedicated cache formats and PRT.
But we are happy you like it! :o)
I just like being able to deal with the particles like I do with PC2’s or EXR’s. You have actual files that get locked and loaded and such. Box3 has a mysterious disk cache that does “something” but you don’t know what. Blech.
I need to play around more with the PRT birth operator in Pflow. See if I can’t use that to handle my “crop PRT to a box region” thing I want, and compare the workflow to the PRT loader objects.
- Chad
I need to play around more
with the PRT birth operator in
Pflow. See if I can't use
that to handle my "crop PRT to
a box region" thing I want,
and compare the workflow to
the PRT loader objects.
You might want to wait a bit with that - we plan to rework the PFlow operators as their code is very old compared to the rest of Krakatoa. Also, loading stuff into PFlow generally means making it slow...
What exactly do you need the "crop PRT to box region" for? We could add an option to the PRT Loader to only load particles that are inside a specified bounding box if you feel it is needed. Might be easier and would be orders of magnitude faster.
[EDIT] Wish logged as defect 4067.
I made a reference to it in the “can’t reduce graininess” topic.
For now, I just want to be able to set 2 point3’s, a min and max to define a bounding box, outside of which particles from the PRT are not loaded. Maxscript would be fine for this for now, but eventually, an interactive manipulator would be helpful too, perhaps with arbitrary plane or whatnot. But 2 point3s would be enough for now.
- Chad
I made a reference to it in
the “can’t reduce graininess”
topic.
For now, I just want to be
able to set 2 point3’s, a min
and max to define a bounding
box, outside of which
particles from the PRT are not
loaded. Maxscript would be
fine for this for now, but
eventually, an interactive
manipulator would be helpful
too, perhaps with arbitrary
plane or whatnot. But 2
point3s would be enough for
now.
- Chad
How about an arbitrary VOLUME?
We implemented it as “Particle Culling” in the PRT Loader. You can pick any geometry objects with more or less convex hull and cull particles at loading time based on the object’s volume. Of course, you can also invert it and load only what is outside of the volume, so now you can cut holes into your particle clouds. Obviously the node can be animated (both transformed and modified) so special effects like XRay scanners, revealing particles over time, filling fancy volumes with already animated particles and whatnot are possible…
This option uses a similar technique as the matte objects culling, so it is like a pre-loading matte. It is pretty fast, too.
Only drawback is that at this point you cannot see the culling the the viewport, but seeing the actual geometry used to remove particles should be a good reference.
We will see if it would be possible to implement display of the result in the viewport, but at this point it is a wishlist item.
Volume culling would be further down on the list, but I’m glad you pushed it up. 
The question though, is speed.
Culling based on ((position.x>min.x $$ position.x<max.x) && (position.y>min.y $$ position.y<max.y)) && (position.z>min.z $$ position.z<max.z) seems like it would be LOADS faster than getting a scene node mesh.
- Chad
Volume culling would be
further down on the list, but
I’m glad you pushed it up.
The question though, is speed.
Culling based on
((position.x>min.x $$
position.xmin.y $$
position.ymin.z $$
position.z<max.z) seems like
it would be LOADS faster than
getting a scene node mesh.
- Chad
It is as fast as matte objects are when rendering. It builds a Kd-Tree from the geometry and does one ray cast per particle. With typical geometry, and lots of particles, it appears to be fast enough.
A benchmark:
Loading and rendering 10 million particles (no lighting): 42 seconds.
I created a box, placed it around the PRT loader so it includes all 10M particles. Each particle has to perform a check against the box to get rendered. Time: 44 seconds.
So we got 2 seconds difference for 10 million particles when ALL particles pass the test.
I made the box smaller so only 1.5 million passed the test (the rest still had to check against the box, but were outside) and got 17 seconds rendertime, because there were 8.5 million particles less to sort and draw…
I think you will like it :o)
Borislav “Bobo” Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
Now get this:
Same benchmark, 10 million particles, Max 9 64 bit: 23 seconds pure rendering, 28 seconds with a box where each particle passes the test. This is almost twice as fast compared to Max 9 32 bit on the same system!
Not using Max 9 64 bit with Krakatoa is officially a crime now :o)
According to our lead developer, this is caused by the contiguous memory space management in 64 bit (vector). The 32 bit management structure (deque) creates smaller chunks of memory and has an added overhead.
Borislav "Bobo" Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
I suppose this also means we need to worry about memory speed as much as CPU speed.
- Chad
What I really really really like about this system is the possibility of reuse.
For an example I can make a basic dirt explosion or mist. And get a ton of uses for it.
I can reuse across projects if possible.
Or duplicate this effect in the same scene and offset the time for variation.
Krak is the best.
What I really really really like about this system is the possibility of reuse.
For an example I can make a basic dirt explosion or mist. And get a ton of uses for it.
I can reuse across projects if possible.
Or duplicate this effect in the same scene and offset the time for variation.
Krak is the best.
Trying beta 13. Is the viewport supposed to show the culling or no? It’s confusing not seeing the culling.
- Chad
We attempted to implement it for the viewports, but it opened a whole can of worms and we decided not to at this point.
For now, you cannot see it in the viewport, but if you switch to large dots (I know you hate them, but go complain to Autodesk or NVIDIA) then the particles will be correctly Z-Depth culled and the culling geometry would give you a good idea of what is going to be rendered.
We would love to get this working in the viewports, but it is by far not as straight-forward as it is for the renderer.
Please note the known bug about transforming the culling volume after being added to the Loader I posted on the download page.
Current workaround: You have to change the position controller of the culling object to Bezier_Postition to be able to move correctly with the transform gizmo. Once again, Autodesk’s bug, but we will try to fix it.
(the SP versions of the PRT Loader I uploaded will assign a Bezier_Position to the culling node automatically btw.)
Is it a problem with the arbitrary volume culling or would any culling not work?
- Chad
Is it a problem with the
arbitrary volume culling or
would any culling not work?
I must admit I don’t remember the actual reasoning behind the decision, but when a programmer tells me it is not trivial, I tend to believe him ;o)
I am sure there is a way to do it, we just decided not to go for it at this point because it seemed more complicated than expected.
Will try to reevaluate tomorrow and see if anything can be done in the short term.