Is it possible to spawn particles from an instanced shape particle surface?
I’ve tried the mesher technique but it leads to system meltdown! I think pflow changes the meshID of the particles randomly such that the mesher object crashes max.
I would expect I just need to write some sort of pflow script to spawn particles across the surface of a particular particle.
I asked the exact same question some days back but didn’t get any answert. I think there is no way to do this. I will be second to use ur script is you write one 
I would love to write the script if I even knew where to start!
Any idea if Orbaz’s Box 3 opens up the possibilities of achieving the effect?
Looks like it is possible… if you can translate Orbaz-speak into pflow-code!
http://www.orbaz.com/forum/viewtopic.php?t=757
With a little bit of trickery
You can construct a proxy particle system where the reference object for particle shape is used as an emitter object (with surface distribution) and zero speed. Then, during the spawning in your primary particle system you can query the position of a random particle from the proxy system, and perform the proper scaling and matrix transform in relation to the TM of your particle.
there’s a workaround.make particles move objects with a script, and then emit from objects…
Interesting. So…
[ul]
[li]I have a series of objects.[/li][li]A pflow system(pflow-A) that creates a particle at the pivot of each object…[/li][li]said objects are ‘driven’ by pflow-A[/li][li]and another pflow (pflow-B) system that emits from the objects at time (x) of pflow-A particle age.[/li][/ul]how do I get pflow-B to emit at a particular age of the particles in pflow-A and in the same order as pflow-A has ordered the particles?
This probably makes no sense to you 
I’ll try to post a scene and pflow when I get a chance to explain more clearly.
If you are to use a Script, then the best way would be to predefine your offsets. This is what the proxy system does using the method Oleg described. You could use Verteces to make is simple. Create an array with all the positions of vertices on the source object (make sure to offset by the source TM if it is not at 0,0,0). Then after spawning, reposition the new particles by the offsets within the array (randomly pick one) taking into account the current TM of the particle that spawned.
This should be fairly straight forward using Script, but it is pretty simple using Box3.
It’s fairly easy, First use Bobo’s particle motion to scene objects or a modified version of custom chunks, instead of instanced geometry, then bake the animation and remove the particle system. After that you can use your “baked” particles as emitters. If you’re not sure how to bake your particle animation you can look for the Rifter script floating around here somewhere or ask in the maxscript forums. If you can’t get help PM me. I’m at work now or I’d help more.
Hope that helps,
Bill
This works well if you don’t have too many particles, but if you have a lot, it will bog down. Not only do you need the new particle objects in the scene, you need them added into a Position Object Op set to Animated. It can slow down very fast.
Yep it’s a fairly complex and high end effect. You’ll need a good rig to run through this effect. I went to water cooled 3.6GHz quad core and 4gb of ram. You’ll need a professional level GPU as well. Or you’ll need alot of patience. This stuff is tons of fun but the deeper you get into it the more expensive it gets. I really need to step up to 8gb of ram cause caching to my Raptors (even at 10k RPM) is slow.
Well all I want is a simple ‘puff’ of particles when the parent particles reach a certain rotation. A short lifespan should keep the particle count low.
Thanks for all the advice, I’ll try to track down that rifter script.
haha…well, before buying a new expensive computer i would suggest box3 or TP3…
don’t know about box3 but i assume it can do it. containing TP3, it is some of the basics in it
don’t know what this all script things do discussed here, but what you could do also, if you just need this puff thing, but from surface(if it really must be from surface). then you could fake it
make particle A fly around or what ever they have to do. then at age prefered, make them spawn in all directions.
then again, drive your objects with these same particles A, and use them as U-deflector.
add a collision event, and make only these new spawned particles visible when they had collided with the udeflector.
only disadvantage: if you have a lot of different objects, you have to create a udeflector for each of them 
hope this helps
I think the comment on things slowing down was due to the particle count if you had a high particle count to begin with then made all those particles emitters. If done in a single pass it would be a major system strain. However there is no reason to do it in a single pass if you don’t mind compositing. Which adds another step in the production and more time. This would be an excellent system to set up for use with Krakatoa and give the trial a shot if you’ve never used it.
Yeah, the slowdown I was referring to is trying to use several hundred to several thousand objects as animated emitters. Using a Script or Box3 (easily capable of doing this) is a better way to do this if Mesher fails or you have too many particles to use objects with transferred particle TM’s.
Yep,
Run a 64 bit OS and Max 64 and throw all the ram you can at it. Or bake the emitters hide 90% of them and only emit to 10% at a time. Render to .png format then composite all 10 layers into your FX pass to use in your final composite.
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
