I’m trying to get a workflow down. This is what I’ve done -
create sphere with geovolume and a falloff map.
Save to PRT exporting Orientation.
Load PRT - falloff is preserved and renders
Use Krak PRT Loader Birth in Pflow
Add Krak PRT Loader Update, select Orientation and “user channel”
Add Material Static with falloff map in diffuse.
Doesn’t seem to display falloff correctly with loaded orientation.
Am I missing a step?
Edit: On a separate note, I was just trying to save the color (enabled color channel in channels list). When I try to load this .prt in the pflow channel op I get a ‘present but empty error’. Is this a problem being saved from a geovolume? I don’t think so since a PRT loader renders correctly with saved color. Why does this fail to load the color in pflow?
I will have to take a look tomorrow as I don’t have the latest build at home. I generally use Material Dynamic just in case.
If you add a shape, does it appear that the particles have the correct orientations?
As for the color error, this is a bug in PFlow. Somehow we have the fixed version at Frantic, but we don’t know whether that fix was ever included in Autodesk shipping versions and/or PFlow Boxes. What version of Max are you using?
3ds Max 2009 64-bit. I have a the trial for 3ds max 10, I can try to see if it reproduces there. I’ll also try the shape test to make sure the orientation is being loaded correctly.
I currently don’t have the creative extension installed, will also try that.
Edit: Creative extension fixes the color problem. However, I’ms till striking out with orientation. Shapes don’t seem to be oriented correctly so I’m either not saving or loading correctly.
First of all, thanks for the Creative Extension note! Good to know it solves the color problem.
Second, Orientation and Tangent channels are NOT being populated when saving out GeoVolumes. Only Normals and Mapping Coordinates are acquired.
Obviously, a Normal is not enough to provide full particle orientation data, so we don’t load it in PFlow. We could theoretically resolve the other two axes based on the up vector, so this is something we might look at. Or we could output correct Orientation data from GeoVolume again by using the up vector in addition to the normal.
The only workaround right now would be to grab the normals from the original mesh using a Krakatoa Geometry Lookup operator or a Box #3 Dataflow (ours is faster though ) Then you would send out the particles to a new event so they would not acquire normals on every frame.
I’m having some problems with a prt sequence using the pflow birth operators. A PRT Loader shows the animated particles correctly, so I know the data is there, but when I load it in a Krak File Birth, even with a Krak File Update->Channel Position its not animated. Is this a bug or …? Data was taken from an animated GeoVolume, but it’s strange the PRT loader displays properly and the Pflow operators don’t. Even a PRT Loader operator in pflow doesn’t animate.
The PFlow operators are meant to be used with valid ID Channel. A GeoVolume sequence does NOT have a valid ID channel (even if you saved one, it will contain 0) because on each frame, completely NEW and independent particles that have no continuity with the previous frame are created. So the PFlow operators cannot figure out which particle from the birth is which particle from the Update. In contrast, if you saved particles from a PFlow with a valid ID channel, loading them back via the Krakatoa PFlow operators would allow you to preserve this continuity information and get a particle moving correctly.
In theory, if a PRT sequence does not have an ID channel at all, the PFlow operators would try to use the Index (the order) of the particles to generate this continuity, but if you bent a mesh while saving the GeoVolume, there is no way to preserve the particle count and order throughout the volume and the results could be unpredictable.
So keeping in mind that the Krakatoa PFlow Operators workflow has gotchas and limitations, you will have to adjust your approach a bit.
For example, if you intend to deform a particle cloud, instead of saving a GeoVolume PRT sequence from a deforming mesh, save just the first frame, then load it in a PRT Loader, set the Range to start and end on the single frame, add a Krakatoa SkinWrap and deform the PRT Loader by the mesh. Save a PRT Sequence of the deforming particles without an ID channel. The resulting sequence will have the same particle count and since it is based on the same initial PRT file, loading this into PFlow using the Krakatoa Birth and Update operators without ID (by Index) might allow you to get the motion you want. Still, it might get tricky if you start deleting or spawning particles within the flow, so it would be useful to know what you are trying to achieve with the flow to find the right approach.
) Then you would send out the particles to a new event so they would not acquire normals on every frame.