View Full Version : How to combine two particle systems into one?

06-05-2005, 10:17 AM

I was wondering if it is possible to combine two particle systems into one.

The problem I have is about blobby particles. blobby particles work only within the same particle system.

So my idea was that maybe I could sample all the positions and radial size values of system_01, emit a new particle with the exact positional and radial data in system_03.
Do the same for system_02. then hide the two "driver" systems (system_01 and system_02).

When all the particles are in system_03, I can turn it to blobby because all the particles are in the same system.
I think this solution would be slow. So I was wondering if there are perhaps other ways?

maybe: put some sort of metaball mesh onto each particle, or merge the particle systems somehow (like the way Houdini's system can work).

Maybe someone knows of a node based particle system for maya? Has anyone ever written this (even if it's written by a company and it's only in-house)?


06-05-2005, 12:37 PM
you can create 2 or more particle systems and emit them from the same emitter

06-05-2005, 12:38 PM
Although not at liberty to unveil too much, I have been writing some add-ons for Stroika (http://www.kolektiv.com/) that might be of assistance. Just tell me some more about your intentions.

Also, couldnt you use a conditional on the emitterId attribute to achieve something similar?

(Kan je es een specifiek voorbeeld geven, uw uitleg klinkt nogal enigmatisch ;-))

06-05-2005, 01:58 PM
Or, in slight variation to westiemad's tip, you could use 2 emitters emitting into 1 particle system where you could use expressions to color them differently but still remain the blobby-functionality.

06-05-2005, 04:16 PM
I'll show what I'm working on, maybe it's easier that way:


so it has some expressions and at the moment there are two particle systems. -though you can't see it in the movie.

I want to make the particles appear as drops of ... water or something similar. I don't want to use realflow, because I want to try it in Maya. "the hard way" :).

So two emitters into one particle system works, but not in this situation.

The way the drop system works:
- particle is emitted from emitter into pRain
- particle collides with surface, emits a new particle into pDrop
- the parent pRain-particle gets killed, the drop particle slides down the surface until...
- the drop particle reaches a certain angle to the normal of the surface
- the drop particle emits a new particle into pRain and parent pDrop-particle gets killed
- pRain can collide again with the surface (loop happens again), or with the floor.

So there are two systems, and they should look as one.

-I do want to add splashes later on, so then there will be three systems, maybe four if I also add tails to the drop particles.

So how can I combine all these systems into one? -- or make them appear as one (blobby mesh).

My intentions are purely educational :) - I'm not planning on making money out of this. My other intention would be to perhaps programme a node based particle system for Maya... because I think that would be a great addition. But that's something for the future and that's a big 'maybe'. Why can programs like 3ds max, cinema4d, Houdini have such great 'intuitive' particle systems and Maya not...

@drGonzo: Leuk om te weten dat iemand nederlandstalig aan het andere eind van de wereld ook met dit soort zaken bezig is :)

06-05-2005, 04:23 PM
there's something else that might be possible if all particles are combined into one system:

wet maps.

06-05-2005, 05:50 PM
I think that's probably a pretty decent way to go about it, and for what you want, I think the third particle system route is also about the only way to do it. I'd build in a switch (like something that checks a custom attribute on a locator or something) so that you can easily turn on/off emission into the third particle system, and only do tests based on the first two. I might worry about memory issues if you end up having to do a lot of this, but if you're on a decent computer, you should be able to work around that.

06-05-2005, 06:13 PM
tnx ! the switch is definitly a good idea.

I don't know about memory issues. I'm used to baking my particles to disk.
I presume that when I bake pRain and pDrop at the same moment, memory should be ok ( I got 1 gig of ram).
If I then reload the scene and start emitting in the third particle system, I presume there's less memory required because the first two systems are stored on disk ? Or is this assumption incorrect?
In theory I shouldn't have to bake the third system, because the other systems are baked... but I think it would still be better to bake it anyways... I'm not sure how things like motion-blur work on blobby-particles when they are generated this way... because every frame the old ones are killed and the new ones created.

I think it would also be cool if maya could bake the geometry of blobby particles that normally gets generated at rendertime. I have no idea if this is possible, but I think it's the most stable solution before rendering. -Realflow uses this approach as well.

@drGonzo: I checked out the kolektiv site, very interesting things. very inspirational :).

06-06-2005, 02:52 PM
Are the stroika plug ins still alive?

There is no mention of version upgrades or anything that would lead one to believe they only work on Maya 5 :)

06-06-2005, 04:23 PM
so, instead of emitting new particles from your old ones, you can keep using the old particles. for example, you can create a per-particle integer attribute that maintains the particle status - "0" before it collides, "1" after, "2" as it reaches a certain angle on the surface. depending on the per-particle integer value, your particles behave differently.

some thoughts,

06-06-2005, 08:17 PM
@sunit: your method is indeed interesting, but I think it can become tricky when dealing with multiple surfaces. I'm looking into particle event procedures at the moment, because for now that seems to be the only way to "know with which surface the particle collides with".
The system I was using before uses "a new particle system per object", I think I can avoid this by using event procedures.
Event procedures seem to only work with events like "collide", I'm not sure if you can set your own rule to trigger the event... that's where the integer values that you're suggesting could come in.

Very interesting suggestion, I'm learning a lot :)

I guess I'll have to reconnect the surface to the cps node as well when trying to get the cps data. I'm going to check up on the commands, I think there was a cps command too.
I could also add a per-particle String attribute to store the name of the surface it's colliding with when in the collide state.
That String attribute could be filled during the event procedure with the appropriate surface.

There is something in my head saying this isn't going to work because I can't choose which event procedure to use...
I need to find a way to sample the name of the collision surface when a particle collides with it. I don't thinkt the built-in event procedure will be enough.

I don't know if those plugins are alive, but there's some really cool stuff in their galleries :). Makes me want to try to recreate some of the effects they pulled of.

06-07-2005, 07:25 AM
there's a particle attribute called "event." once you've created a dummy collision event, you can query this attribute to find if indeed an event has occurred. in order to find the closest colliding surface you can call on something like the "closestPointOnSurface" or "closestPointOnMesh" commands which are available through the devkit, and also included in the bonus tools package. i don't know if you need your system to recognize multiple surface per particle - what you could do otherwise is set a switch (like, as you suggested, a per-particle string) with the surface name, and query if this attribute is filled, so that you only call the command once per-particle.

the logic of per-particle attribute "switches" can be quite helpful in these scenarios. you want to change the behavior of your system based on changing conditions, while still maintaining per-particle differences.


CGTalk Moderation
06-07-2005, 07:25 AM
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.