I imported a sand grain sim from houdini via prt. I have the velocity in my prt file.
I would like to know what would be the best way to use that velocity to increase my particle count and still have have each particle moving slightly differently. Do I need to use Stoke or should I do it with frost and/or krakatoa (by partitioning)?
I guess using frost to convert to a mesh volume then using krakatoa volume to generate particles in the volume that would be driven by the velocity should work? thinkboxsoftware.com/krakato … and-frost/
I’m trying to use the frost krakatoa method like in the tutorial, but I have a problem:
I want to render the particle form the krakatoa volume with vray as regular particles. So I would need to pick the prt volume with the pflow krakatoa PRT birth and PRT update but I can’t pick it. Is there any workaround for this?
So I saved the PRT volume and then I could load it with a PRT loader and then pick it with pflow. It’s just long to save that many particles. Now I’m stocked because I have too many particles and my 96GB of ram is not enough…
There is no need for the Frost+PRTVolume trick anymore, since the PRT Cloner modifier can produce the same result without going through an intermediate mesh. It simply creates a grid and seeds new particles based on the existing ones.
I have been logging wishes to allow non-PRT Loader objects (esp. Stoke) to be pickable in the PRT Birth/Update in PFlow, but so far no go. PRT Volume makes little sense there because the particle count would change on each frame, there is no ID channel in PRT Volume, and there would be no way to track birth/death/update by ID. However, a Stoke simulation would be a good candidate for a source in PFlow.
Saving to PRT and using the PRT Loader is the only possible workaround right now if you want “real” particles via PFlow. But rendering them as meshes will push the capabilities of 3ds Max. That’s why Krakatoa was developed in the first place
Hi Bobo!
And thanks, great to know about the PRT cloner.
Autodesk is not even listening to you??? That’s a really bad sign! Autodesk is a bit slow to evolve that’s why I’m learning Houdini now! But I will always need to go in Max to render with V-Ray and use all the amazing Thinkbox products!
I think I need real particles because I want the look of sand where we see all the individual grains. If we can do that sort of look with krakatoa please tell me how…
Here is what I’m working on. It’s just a collapsing sand castle test I did to practice transferring stuff from Houdini to max. You can see the kind of sand grain look I’m looking for. Some grain are bigger and they cast shadow on each other and we can see each grain. I guess I could use krakatoa in the background if I was to add a dune landscape beghind.
(Open it in a new tab to see it in full rez please)
One question about the prt cloner: will it result in a slightly different motion for each newly added particles or will they just stick around the newly created one like if groups of particles were just parented to the original ones?
That has nothing to do with Autodesk, the joke is that it is up to us to allow those PRT objects to be pickable by the PRT Birth/Update. So I have to convince the Thinkbox developers it is a good idea. We have quite a long wishlist…
And about the PRT cloner, will it really uprez the sim with all the newly created particle flowing in the volicity field?
And I wonder why when I load a prt with around 3 millions particles, it’s very fast in the viewport, but as soon as I pick it with pflow it becomes really slow. I wonder if there is another way, by using frost or vray proxies to distribute the geo (for now sphere bu tI may model a more rocky sand grain).
Nope, the PRT Cloner does exactly what Frost+PRTVolume do, minus the mesh part.
With Frost, you make a field and then an iso-surface mesh, then PRT Volume produces a LevelSet from that mesh (so another field), and seeds particles in the field. If the mesh is changing shape, particles will be revealed in some voxels and disappear in other - they won’t move.
With PRT Cloner, the particles are put on a grid immediately, and have an influence radius (similar to how the Frost Radius affects the influence of particles), and new particles are seeded on the grid to represent the original particles’ properties like Color, Density etc.
But if the source particles are moving (e.g. sand castle collapsing), they will be moving through the grid, and the seeded particles will not follow them, but will be revealed as the influence field moves. So both approaches will produce the same look, which you probably don’t want.
Stoke could advect new particles to move with the original ones, but these new particles would have no knowledge of collision objects like the ground etc, so it might not be a perfect solution either.
I just made a test with the cloner and yes every particle has now a cloud around it moving with it. not really what I need. they just look like meatballs.
I thought it was working with the frost/prt volume method cause it was looking ok on a frame. But I couldn’t render the animation yet because pflow was not able to load all the particles for some reason so I was looking to replace plow by frost mesh instancing. i was stuck at the material Id distribution step. But now you are telling me the particles will just disapear and reappear elsewhere…
Maybe I will try with a Stoke sim. Or just go back in houdini and resim with a higher count and see if I can still convert it without problem. Maybe it will be faster.
Frost creates one huge mesh internally, just like PFlow. It might just be faster doing that.
We have discussed passing geometry instances from Frost to V-Ray as actual instances, which would be a lot faster. But we haven’t done that yet. Hopefully later this year…
Also, we exposed a PRT I/O API for anyone who would like to write a V-Ray scatter that uses PRT data as distribution guide, but I don’t think anyone had done that yet. So far only FumeFX 4 has added support for that API, but that is unrelated to your case.
I think resimulating in Houdini with a higher count would be easier than trying to produce plausible particles following the base particles. Some VFX shots could work with PRT Cloner or Stoke multiplication, but a simulation demo where each particle is always visible and any issue like lack of collision with the ground or other particles would be obvious will require full simulation.
Ok thank you so much for your always so complete and precise answers!
I was not sure if Frost was really passing instances to vray like multiscatter does (the vray forum thread is a bit old so I thought maybe Frost was now doing it without the need for another plugin like multiscatter). Passing instances seems to be the way to go. Can’t wait to see what you will come up with in that regard.
I resimulated in Houdini and meshed the PRT with frost. It’s not that bad for render time (around 15 minutes a frame for 5.3 millions particles) but it takes like 75 Gb of ram which prevent me from using my whole render farm.
I found something I already had that passes the instances to V-Ray. It’s included with V-Ray and it’s called VRayInstancer, but it works only with pflow and I can’t pick PRT! And pflow is just too slow even with just a prt birth and prt update. It’s a bit of a puzzle juggling with all the max plugins… docs.chaosgroup.com/display/VRAY … yInstancer
Anyway I just ordered Forest Pack Pro too, that one should do the trick until frost can do it.
