Sorry for all the questions - trying to get up to some kind of speed in very short order. I am half hoping the job won’t happen because of the learning curve, and half hoping it will to justify the curve. Playing with particles and KT is pretty fun
I have been playing with creating a shape out of smoke via density maps and and geometry emitters via particle flow. It’s working passably well, but then I read about PRT volumes which seemed a cool option. I have figured out (more or less) how to create a PRT volume of my shape and it will render in KT, but I have no idea now how to use those particles with forces etc.
How do I employ that PRT volume so that I can inertact with the particles - do I need to render the particles to disk and reload them in a PRT loader birth event or something like that?
Thanks!
The PRT Volume was meant mainly as a generator of static particle clouds out of complex geometry objects (see the Happy Buddha model examples in the help), as a way to fill animated geometry with particles on the fly without preserving any continuity between frames (see the Thick Smoke example in the help which shows a PFlow turned to Mesher turned to particles), and eventually as an INITIAL setup for Particle Flow simulations (PFlow Box #2 has a similar operator, but it leaks more).
So you could create a SINGLE PRT frame out of a PRT Volume saved to disk, then load that in a PRT Loader, potentially apply deformations (either on the PRT Volume itself or on the PRT Loader), add KCMs if necessary to change any channels you want and then pick in a Krakatoa PRT Loader Birth operator to create the same in PFlow to apply forces etc.
What I won’t suggest is trying to use a Krakatoa PRT Loader Update to load a sequence of PRT files saved from animated PRT Volumes because the PRT Volume does not produce an ID channel (although you could use the Index or generate your own with a KCM) and a particle on frame X with index N does not necessarily have a corresponding particle with the same index on frame Y - PRT Volumes would produce history-independent data where you cannot track a particle from frame to frame correctly.
So if you have a good way of creating an initial cloud from a PRT Volume, you could load it into the PFlow using Krakatoa Birth and Update operators (the latter one to load the additional channels you might want), but you should not try to load a sequence of frames.
Make sure the PRT Loader is set to Range N to N in order to reload the same file on each frame. Checking the “Load Single Frame Only” is not so good because the PRT Loader caches the data and does not send all updates you would get when using a Range.
I am just barely keeping up I think - but I did get the PRT volume loaded into a Pflow and it renders. I am only looking for a single frame to start with, but what I then want to do is dissolve the object into a stream of particles so hopefully that is possible? At this point I have loaded the PRT into a Pflow and hooked up a wind force, but it just seems to be moving and warping the whole particle cloud en masse, is there a way to have the loaded particles just act as a normal cloud (as if I had made them with a position object operator instead)?
I am sorry, I am not sure I follow.
If you apply a wind force, it will affect all particles unless the effect is controlled by a script channel or falloff or something else.
The PRT Volume cloud is supposed to just give birth to the particles. I don’t understand what the difference is to a regular PFlow with a Position op.
Sorry I should have explained that better. I was having trouble getting the forces to act on the the PRT generated cloud (via Pflow) in a way that actually moved individual particles. It was actually a scaling issue I think (an experience issue really) but I could not seem to do much other than move the entire shape around. By reducing the scale of the wind tubulence way down from where it was on the emitter version of the shape I was able to get it behaving as expected.
Still playing with it, but so far it so good.
I was also looking around for some way to see how many particles the PRT volume is creating, or the PRT loaders are loading up (either directly or via the Pflow operator) but couldn’t find anything. I’m doing a lot of trials to get a sense of how to control the visual “resolution” of these particle cloud objects and it’s hard for me, at this point, to assess whether I have enough particles (lower spacing in PRT volume? Generate some partitions for the PRT loader? Need to lower the density setting for rendering? etc. ). Right now it’s largely guessing and having a count of the particles would help me establish a better baseline I think. I’m sure the info is in there somewhere, could you point me in the right direction?
Thanks Bobo. I’ll try not to bother you via Skype unless I get really desperate
b
The trouble with PRT Volume and PFlow is that the PRT Volume can easily generate more particles than PFlow can handle.
The PRT Volume shows the count of its viewport settings in the viewport, but once you save it to a PRT file and load in a PRT Loader, the actual count is displayed in the last rollout of the loader - both the Disk count, the Render count according to the current settings, and the Viewport count. (the latter is also shown in the viewport)
The PFlow will respect the Render settings of the PRT Loader. To show the actual count of the PFlow, go to the Options menu of the Particle View and select Track Update > Particle Count.
Each event will show a tab with the current viewport count (and, while rendering, these will update with the render counts, too).
Once you render in Krakatoa, the actual count will be shown in the Channels rollout, by right-clicking on the PCache/LCache buttons, and if you have enabled the VFB Extensions in the Preferences, in the bottom left corner of the Extended VFB panel.
Thanks, that helps. Not sure how I missed the particle count rollout in the PRT loader For some reason I am not seeing any particle count in the Particle view, even with the Particle Count turned on (except in the standard birth operators, which show their total), but with the PRT total I should be good until I figure that out.
