AWS Thinkbox Discussion Forums

Prt volume does not save ID channel corectly

Hi
I am not sure if we are doing something wrong or if it is a bug.
It seems that the PRT volume saves all the IDs as “0” !. We found out after trying to get that cached PRT volume as PRT loader into Pflow.

regards

This is not an error, the PRT Volume does NOT have an ID channel since there is no way to track a particle from one frame to another.
For example, if you add a Bend to a Teapot, animate the Angle and convert the Teapot to PRT Volume, as you play back the animation, some particles will come and some will go depending on what voxels are filled by the mesh. An ID would describe a specific particle and track it through the animation, but in this case this is not possible.

In PFlow and TP, the ID tracks a particle from birth to death, and the ID is not being reused once the particle is gone. The Krakatoa PRT Birth and Update assume that if an ID was loaded once and the particle has died, it can never come again and will refuse to reload that particle if its ID actually comes along on a later frame. Since the PRT Volume is not a history-dependent simulation, it simply cannot track particles by Born IDs.

A workaround to create FAKE IDs would be to drop a KCM on top of the PRT Volume’s stack and feed the Index Input channel which describes the order of particle creation WITHIN THE CURRENT FRAME into the ID channel as Output. This will give you valid IDs within the frame, but it won’t necessarily ensure continuity throughout an animation of the source volume mesh, as some particles could pop in and out of existence depending on their voxel’s filled state, and loading such a sequence into PFlow would have trouble keeping up since once a particle with a unique ID is born and deleted, it will NEVER be born again. In fact, if the ID channel is NOT PROVIDED (as opposed to saved as 0), the PRT operators in PFlow will assume the order of particles (index within in the PRT frame) as the ID and do exactly the same as if you would have copied Index->ID via KCM.

In short, loading a PRT sequence generated from an animated volume mesh is not supported by the Krakatoa PRT Birth / Update operators, especially if the particle count fluctuates up and down. The only thing I would use a PRT Volume cloud for is a single frame birth, then letting the particle system to take over the animation via forces without any PRT Updates.

If you have any ideas about what we could improve in this workflow, please let us know.

This index is not random, is it? Meaning, if we rendered out two passes of PRT’s, and the PRT Volume was unchanged, the ID’s should be able to allow us to match up the resulting particles between the two PRT’s.

  • Chad

It is currently, but I’m not sure if I can guarantee that for future versions of Krakatoa. Currently none of the particle sources are multi-threaded so particles are generated in a deterministic fashion.

Privacy | Site terms | Cookie preferences