Just experimenting with the possibilities of converting geometry to particles for disintegration effects etc. I have been over the docs and it seems pretty clear and I have it working okay. A question though:
The PRT Volume workflow is pretty quick to get particles, but then you have to save the particles out, create a PRT Loader and reload, and then add that loader to a PFlow. Again, it works well, but I was wondering if there would be some way to just point the Pflow birth event directly to the PRT volume and save all those intermediate PRT Loader steps?
It is not possible yet, but it is something that has been discussed and I hope will be implemented in the future.
We have some plans to improve the existing and add more Krakatoa objects and make them work better together.
For now, saving and reloading is the only possible workflow.
Just curious about this particular effect then: I want to partially dissolve a figure for a still shot and because it’s only a 2D source/result it just means taking an image mapped plane and converting that to particles (rather than a 3d solid figure). I did a test run with a position icon operator and if I use partitions I can certainly get enough particles for the detail needed. Would there be any real advantage to doing this via PRT volumes/loaders? If not what sort of scenario would that workflow be better for?
In general, I don’t recommend using PRT Volume as source for PFlow except in some specific cases.
*It could be useful when working with Box #2 which is the PhysX extension to PFlow and does interparticle collisions. It has its own grid birth operator, but the PRT Volume produces cleaner results. The Box #2 operators prefer starting with a regular grid.
*When creating a SOLID 3D volume and you want to apply effects to it, like breaking it apart.
Otherwise, specifically for adding particles to the surface of a mesh, or giving birth via Texture control, PFlow has enough operators to do that natively.
Hi Bobo -
Just playing with this again, or rather something similar, and had a quick question: will it be possible at some future point to use PRT volume direclty as a Pflow source, without having to save out/reload with a PRT loader? PRT volumes are created so quickly, it would just save a lot of time if I could point Pflow to that instead. I trust there is a reason it doesn’t work that way, but thought I’d ask.
(I know you had suggested using Pflow to generate the particles, but I can’t figure out how to get a nice grid like I get with the PRT volume)
Another questions arising while working away: I’m using the PRT Volume>PRT save>PRT Loader route, and using the PRT Birth operator in a Pflow. The PFlow renders no problem (in Vray) when using a normal birth operator and a Position object but it won’t render when using the PRT birth operator. The Pflow shows up in viewport, and the PRT loader is finding the particles, but it’s rendering blank instead of my instanced shapes.
I’ve attached a screen cap showing the Pflow that works fine on the left, and the version on the right that won’t. You can see in the far right the viewport showing the Pflow is loading the particles, but no joy. Anything obvious I am doing wrong?
I actually cannot get it to render the Pflow even with KT. Not really sure what is wrong - the PRT loader renders fine on it’s own, but the birth operator is not happening at all.
Sorry for the delayed answer, but I just moved to Vancouver and I just got network access an hour ago
Not sure what might be wrong with the PFlow in this configuration, but you could try adding the Krakatoa PRT Update right after the birth to ensure all relevant channels are set up. If VRay is having an issue with that PFlow, it might be a deeper problem with PFlow itself and we are just triggering it.
Also one other thing to try - create a Mesher Compound Object from the PFlow and try to render that to see of VRay will see that.
Congrats on the move - I may end up moving to Vancouver before long myself. Great area for sure.
I did try the PRT update just to see what would happen, but it made no difference. I don’t think it’s a Pflow specific problem, because I can get that exact flow to render fine just by replacing the PRT loader birth operator with a normal birth one. It’s just the PRT birth that kills it, but that set of particles renders just fine via the PRT loader that the birth operator is point to.
