XP64pro sp2
3ds max 2009 x64 sp1
1.5.0.37202
Using Pflow and the PRT Loader Birth. The viewport % doesn’t seem to work correctly. Setting it to 2% shows 0 particles, and setting it to 2.5% shows all the particles. So it acting as a threshold. Doesn’t seem to matter how many particles are in my PRT Loader, either.
Which viewport percentage spinner are you talking about? The PFlow one, or the PRT Loader one? You should probably turn the PRT Loader’s viewport display off completely since PFlow will be giving you a more accurate display of the particles.
In order to correctly load a percentage of particles in PFlow, you will need to have a valid ID channel, since it uses a hash of the ID value to determine which particles to load.
The Viewport settings of the PRT Loader should not affect anything when using the PRT Loader Birth, if they do its a bug. On the other hand, the Render settings will affect the particles seen by the PRT Loader Birth. In general, it is not a good idea to use the PRT Loader’s Load Percentage when it is sourcing particles for a PRT Loader Birth. If you do choose to do this, you will need to set the Render Load Mode to “Every Nth By ID” so that PFlow sees particles with consistent IDs.
Yeah, seems my ID is messed up.
Is there any function in Krakatoa to generate IDs? Based on the sort or something? Or do I have to use Pflow to enumerate the order off the .prt itself?
Doing the PRT Loader Birth to set the ID’s fixed the problem, but it’s a step I’d rather avoid in the future.
I believe the KCMs support an Index channel that will give you the particle’s index. You could use that to assign to the particle’s ID channel. I’m 95% sure it made it into the latest build.
Ah I see it. So Index is what, the order they appear in the PRT Loader?
The order they flow through the KCM. So if you are loading Every Nth, you will still see the indices 0, 1, 2, etc.
Yes, it made it into the latest build.
The Index Channel is INPUT ONLY and gives you a continuous value, so you could perform mathematical operations to particles based on their order of evaluation in the KCM. For example, I created some examples where the particles loaded in a shape of a teapot would swirl out into a spiral by blending positions from the file with positions calculated based on the particle index.
The ID channel is the Born ID of PFlow - each particle gets a UNIQUE ID which never changes as a particle is moving from Event to Event. You have to save the ID channel when saving a PFlow if you want to reload the PFlow and get matching animation. Also, the ID channel is used to track the Birth and Death of particles - the File Birth and PRT Loader Birth compare the IDs in two consecutive frames and only create particles that have not been created yet. The File Update and PRT Loader Update compare the IDs of two consecutive frames and mark particles that are in the PFlow but not in the next PRT file as “death row candidates” by setting the File ID channel to -1, allowing you to kill them with a Krakatoa File ID Test.
Using an ID channel is pretty much mandatory when using the PFlow Operators, and the ID channel is set as channel to save by default for that reason.
The Index in the KCM and the ID generated by Pflow using the PRT Loader Birth operator should be the same then? Assuming you are loading 100% of the particles into Pflow, etc.
Not necessarily.
The ID of the PFlow is generated in the order of creation, but the order in the PRT file is based on the particle containers.
For example, if you created 1M particles with a Birth operator and kept them all in Event01, the PRT would probably have the IDs matching the Index channel if you loaded all particles and passed them through the KCM.
But if you sent 50% of the particles to Event02, the PRT will contain all particles from Event01, then all particles from Event02 because that’s how it gets them from PFlow, resulting in some mixture of IDs. In that case, the IDs and the KCM Index channel would most probably be different. This is also true for MAXScript access - when you have a PFlow with two Events like described above, getting particles from the PFlow’s top-level particle container by index will show the particles from Event01 first, then Event02 and so on.
So the assumption is true only for the simplest of cases based on a one-event flow.
Right, but a Krakatoa PRT Loader Birth will at least start with the same ID as the Index would be in the KCM. What happens after that is the magic of particles. But at least with the Index in KCM we can generate ID’s on the fly if we so desire.