I would like to propose an “app” sized plugin: Thinkbox PRT.
PRT would be:
PRT Render (Just the PRT saver from Krakatoa Unlicensed with chunks etc.).
Light Magma (none of the advanced Stoke level stuff just like Pflow Box#3 type stuff and force support).
Particle Geo Instancing with basic options (random, ordered from object list, facing card, cube, sphere, star etc…) from Frost (No particle meshing needed, that would be the frost upsell) and/or a PRT to VRay Proxy Object Plugin.
Sell it for like $50-$100.
Get people hooked on PRT. Solve lots of problems with Max. Save us artists from having to touch Particle Flow. Everybody wins. Essentially you would just be a drop-in replacement for all of the common Pflow workflows. I want to murder PFlow in an alley with a rusty pipe but I can’t justify over $1,000 + annual maintenance in Thinkbox products sadly to get rid of it for how often we do big particle stuff.
We have some way to go before the Stoke Particle Simulator can be considered a PFlow replacement beyond simple advection by velocity fields.
A first step is coming this Siggraph with Per-Step Magma evaluation. But I feel that TP-style Groups should also be supported before it becomes a viable PFlow killer.
Of course, I am not in the position to make any decisions regarding your request, I am just commenting on the technical aspect. We have been discussing the creation of our own particle system for years, we even had a PRT System object that was running 4x faster than PFlow simulating the same animation with the same forces on a 4 core + HT machine, but that was just a proof of concept. I fear the market segment is too tiny and not worth the effort, esp. at in that price range, but I could be wrong.
Well the Demo for Krakatoa already provides Magmaflow which is better than Pflow for 99% of the work IMO. I feel like you’re overstating Pflow’s capabilities haha. What do you feel that stoke/magmaflow lacks that Pflow has?
Well, Stoke in its current incarnation is equivalent to a PFlow with one Event containing a FumeFX Follow. Or a PFlow with one Event containing a Force operator and another Force operator with 100% Drag before it to kill the Velocity of the previous frame.
In other words, in PFlow, once a particle has a Velocity, it continues integrating along the way even if no force acts on it (which is very Newtonian, an object retain its motion until a force acts on it). In Stoke, all particles are implicitly in a fluid. If the field has no Velocity, the particles stop. So their Velocity is “borrowed” from the environment, not intrinsic. (That’s how the FumeFX Follow works in PFlow.)
So the original goal of Stoke Particle Simulator was to improve the specific case of PFlow+FumeFX Follow, and it does not provide the simple particle simulation that PFlow is normally capable of. As mentioned before, it also does not allow for simple grouping of particles in containers so that some operators or whole Magmas act on some particles and not on others. It could be faked with custom channels and logical tests in a single Magma, but it would make the flow quite messy, so I would rather have a better UI abstraction for that.
So IMHO (and this is more or less part of the current Stoke roadmap), we need to add at least grouping to the Stoke Particle Simulator before it is flexible enough. Also Stoke does not have real collisions right now, they should be a must, but would require calculating fluid occlusions in the current implementation, as just colliding with meshes would not do what we want.
Ah, I thought magmaflow included force spacewarps. You could do a ray-test and perform Newtonian bounce physics pretty easy in a magma flow though right that would handle collisions? I guess it would be a little harder though than I hoped to stay inside of PRT.
That prototype PRT System I mentioned implemented the integration using Magma as a proof of concept. But in PFlow the integrator is a core feature, you don’t need to advance Positions with a fraction of the Velocity on each step yourself, it just happens. If we are going to make a simple particle system, it should not require a PhD to get a particle moving
Another thing you cannot do in Magma right now - there is no way to spawn particles from other particles. All particles in Stoke Particle Simulator are generated from emitters, and in Krakatoa Magma you cannot really create particles, you can only delete them via the Selection channel and a Krakatoa Delete modifier on top. All particles come from a base object like a PRT Loader, or any of the other PRT objects.
So a PRT System where particles can be added, spawned and deleted without jumping through hoops would be necessary to match what PFlow does easily with Birth, Delete and Spawn operators.
I’m working with Vlado right now on our PRT workflow. He said you might be working on a Vray-Native instancer. Is that something that’s happening that you can talk about? Is it just extending Frost to support Vray Instances natively or are you bundling an instancer into Krakatoa or Sequoia or some other existing product? Is there a beta to test?
I did not use any of the fancy features of Frost like Magma control over shape index, animation offset, orientation etc. I had to keep it simple to be able to compare to the VRay Instancer on equal terms.
Note that Frost shifts some of the work into the shading stage, so its preparation step (which is still single-threaded) is MUCH faster than the V-Ray Instancer, but the shading is a bit slower. Also, Frost seems to use an order of magnitude less memory. Possibly even less, as VRay had a bug until end of last week where each instance without a material made its own default material, eating additional 3GB for every 1 million particles. But I assigned a single material to the teapot to avoid that, since my VRay build is older and still has the bug. I also checked the Mutli-Threading option in VRay Instancer which made it a little faster. It has a bigger effect with heavier meshes.
The recording is from today’s build, the one we have posted on the early Beta is over a week old and about as fast as the VRay Instancer. The quantum leap happened last Friday
The build I have supports animation offset already (each time sample produces its unique instance, so random offsets would increase the preparation time and memory usage somewhat). The current build does not have material ID / Multi-Material support yet, but that’s coming.
Yesterday I rendered 1 million Buddha statues (221K faces each) without any problems, the performance is approximately the same, and using 0.3 GB of RAM We plan to support VRay proxies too, but they are not working yet (just a bug, I think).
I will add you to the Beta group and send you a 2.0 license, please keep in mind the initial build we posted does not represent the current state of development…
Interesting, super overkill for what I need haha, but interesting. I might avoid using it just because we might update this project later and then be stuck without a Frost license. Vlado spit me out a custom build of Phoenix on Friday which has an updated PRTObject helper which converts a PRT into a standard max particle system to let the instance circumvent Pflow. Apparently according to the Krak docs PRTLoader exposes itself as an IParticleExt? So Vlado is currently looking into updating VrayInstancer to access a Thinkbox PRTLoader node directly through the IParticle interface or using your included C++ example project.
I’m curious though about in your frost example how much of that is the particle flow intermediary slowing things down and adding memory. The VrayInstancer with the Chaos PRTObject doesn’t have any partition support or time-remapping but it renders way faster since it shortcuts directly to the PRT Data. I tried using the Krak Birth and Update nodes this weekend with 800k particles and around frame 1,300 it was taking over an hour per frame to update which makes particle flow integration actually slower than the original particle flow sim cached out to PRT. Seems unnecessarily slow.
Yes, the PRT Loader exposes the IParticleObjectExt interface, however it checks to see if a workstation license of Krakatoa is installed without checking it out. So it is not completely free. OTOH, the PRT API we exposed for Kreso and Vlado to use does not require a license for simplicity reasons.
The million particles I showed in the video were already pre-cached when rendering - at least in the first two runs (VRay Instancer and Frost). Then I changed the particle count to 2 million and you saw the pre-rolling to frame 100 taking some time for the next Frost rendering (taking 40+ seconds). Then the particles were already in memory and rendered in Frost in 11 seconds. The VRay Instancer does not spend that preparation time loading particles, but preparing the instances. As mentioned, the initial build of Frost we posted 10 days ago used the same code based on the SDK example, and was taking the same time (or longer, since single-threaded). You can find the initial benchmark results on the Beta forum. forums.thinkboxsoftware.com/vie … 26&t=14515
With the current build, both memory usage and preparation time are an order of magnitude lower, at the cost of some render speed. We are still figuring out the optimal way to do this, while also supporting all features of Frost with custom geometry.
On top of that, fluid meshing in Frost 2.0 is up to two times faster, so that’s good news for everybody else
Ah, Ok. I assumed the PRTLoader was like the Xmesh Loader. Costs to render, free to load. What about the C++ api that ships with Krakatoa? Is that open or does it require a license check?
(Again, should offer a PRT loader/saver/magmaflow (w/forces) /instancer product. )
The PRT Loader checks for the existence of a Krakatoa workstation license when queried via the IParticleObjectExt interface. You can only get very basic data like Position and Velocity.
The PRT Loader is FREE if it is accessed via the PRT I/O interface. This would give you all the channels it contains. As explained in my previous post, the C++ API is actually free.
No, we are talking about the IMaxKrakatoaParticleInterface.hpp that comes in the API folder when installing Krakatoa. It is FREE.
I just expressed myself incorrectly, I did not even think about the free file parsing one (which is on GitHub).
