Hi,
I would like to add as many particle system as I want in a single PRT source. Right now it’s required to create many PRT sources for different particle system.
Regards,
Jigu
I am not sure I follow. Can you be more specific?
You are not talking of the PRT Source object but of something else, right?
Please give examples with steps.
I wasn’t clear. I meant, right now I can only pick one particle system in PRT source. I would like to add many in one single PRT source. (Just like I can add many Particle system in Frost or Blobmesh)
Still don’t know what you mean. Are you talking about PRT Volume picking more than one mesh?
Or are you talking about MagmaFlow InputParticles picking more than one system (not gonna happen).
If you are talking about Krakatoa PRT Birth and PRT Update in PFlow, please say so.
“PRT SOURCE” is a special object for bringing in data from external applications. If you are using that, give example.
I am talking about “PRT source” object.
Here are the images that will explain ::
screencast.com/t/vdkB5alO5FMs
screencast.com/t/dWKqfxYrqFbX
I would like to add more particle system in one single PRT Source object instead of duplicating or creating another PRT Source. Or am I missing something?
Would simplify things, especially where Bobo mentions that you can’t pick multiple particle objects in a KCM. There’s no easy way to merge point objects.
PRT Source allows the duplication of a PRT Loader just because we needed a way to test its basic functionality. The PRT Source is intended to be used to import 3rd party data (like our Kinect plugin, Chad and Ben’s own particles etc.). It turns out PRT Source does not bring any speed or memory benefits when cloning a PRT Loader, instancing the PRT Loader has the same effect.
What kind of PRT objects do you use with the PRT Source?
I think that a PRT Maker with N particles at 0,0,0 and a PRT Cloner modifier on the stack picking multiple PRT objects could work as a way to merge several PRTs into a single stream, but I am not 100% sure it would do what Chad wants. Will have to test that.
Oops my mistake, I thought I could convert any particle system in PRT format using “PRT Source”. (thought this way I don’t need to save particles for KCMs) 
Tested it and it works! 
*Create a PRT Maker, set Count to 2, uncheck View Count.
*Add a PRT Cloner modifier
*Uncheck Compenstate Density > Enabled to preserve the channels.
*Pick two PRT objects (PRT Loader, PRT Volume, PRT FumeFX or whatever)
RESULT: The picked objects will be diplicated as a single stream in the PRT Maker. You can increase the number of particles and add more PRT objects to combine any number of them into a single stream.
Since the Color channels of the incoming objects are multiplied by the Color channel of the PRT Maker (default white), you can add a Magma modifier below the Clone and TINT the color of the combined streams.
The Position, Orientation and Scale of each clone can be controlled by Magma modifiers affecting these respective channels below the PRT Clone modifier.
What if I don’t want to save particles and convert it to PRT directly in max? How should I do it?
Where are the particles originally coming from?
It’s coming from pflow or any legacy particle system. I wouldn’t want to save particles and just convert it to PRT.
My first impression was that PRT source was to convert any particle system in PRT format instantly without saving particles.
You basically want to have:
A “live” particle system and be able to use a KCM (or some other Krakatoa modification) with a PRT Object that accesses that live particle system.
That how I understand what is being asked. Is that correct?
Yes, But actually it wasn’ that! I am still noob to KCMs 
I tried to render Particles quickly with “Krak atmospheric” but couldn’t convert pflow particles to PRT without saving it.
Huh, well that is odd, why doesn’t KrakAtmos support everything Krakatoa supports?
Sounds like a feature request 
Why can’t PRT source take anything to convert it in particles? For example, if it can pick any geometry and convert Geometry in particles (reading surface vertex/points) and same for legacy and Pflow particles. Another thing I would like to see like instance partitioning for pflow particles to increase particle counts. This way I can have pflow particles in low counts, whereas PRT source will cache pflow particles in memory and do partitioning at render times and thus increasing more particles ( I have 24GB of ram, this can be useful)
There is no technical reason why the Krakatoa Atmospheric does not support non-PRT sources.
The main reason was that a PFlow would actually render geometry in the other renderer unless specifically modified not to.
But we will look into adding that ASAP.
We had plans for separate objects like this:
*PRT PFlow for converting PFlow into particles
*PRT Surface (or PRT Geo?) for surface distribution
They just weren’t so high on the priority list because you can already do most of this using PRT saving, PFlow itself (surface distribution), and PRT Maker (pretty much anything surface-related if you know Magma well enough).
Keep in mind this year was a bit tricky for developing a new version of Krakatoa - I wasn’t with the company for half of the development process (I joined Thinkbox two months before Siggraph, and was on vacation one of them). Darcy moved from Winnipeg to Vancouver. It is a wonder we pulled a 2.0 release in the time we had. So please bear with us - more Good Stuff is coming faster than you think.
PRT Source is not what you think it is. It is the simplest object in the bunch which takes an existing stream of particles coming from a 3rd party application and shows it in the viewport and passes it to the renderer. It supports KCMs. That’s it.
The fact it reads a stream from PRT Loader is a side effect of us testing it with it because we did not have an external 3rd party application to test with. It is NOT meant to turn objects into particles. It does not cache in memory, it clones the data. It is just a bridge to other applications outside of 3ds Max.
Thanks! Yes, that explains everything and clears my misunderstanding.
Though I would like to see something to keep particles in pflow at lower and increasing counts at render time via caching first low counts in memory and doing partitioning on it. (mostly becoz sometimes we have to delete saved particles due to space problems)
I am not in need of any of this features now. But something I thought if possible, and was trying to know workflow for it.
ultimately though jigu, i think it would save lots of time loading the saved PRTs and applying KCMs to them vs trying
to do a live stream. I understand the disk space problem, but its always easy to save the original particle source,
same out the PRTs, use them, delete, and if needed again, re-save.
the time along accessing the PRTs would be so much quicker than figuring out a convuluted live stream process with
the current available tools it seems. but im also a noob