2011-12-11T23:58:04+00:00 http://flintparticles.org/forum/ Lussumo Vanilla & Feed Publisher http://flintparticles.org/forum/comments.php?DiscussionID=225&Focus=824#Comment_824 2009-06-21T00:34:00+01:00 2009-06-21T16:42:11+01:00 SanMajo http://flintparticles.org/forum/account.php?u=213

Hi Richard! Im already quite familiar with your particle system and after some time it begins to show that there are missing some concepts that make it possible to design long-living and changing ...

Im already quite familiar with your particle system and after some time it begins to show that there are missing some concepts that make it possible to design long-living and changing particle effects that are more complex than a sparkler, explosion or something like that. I have some suggestions for ideas that i know from sophisticaded particle systems in 3D-Programs like Maya, 3Ds Max, Cinema 4D etc. which would enhance the particle system and its usability:

1. Emitters
Should not be responsible for any particles / particle actions or what they are doing - the should just emit particles of a specific type / group.
Currently it is a great problem that all particles of an emitter belong to it for their lifetime and if you change the emitters initializers / actions, all particles will reflect that change. It is possible to create workarounds but it is really much more afford as it should be.

2. Particle Groups
The outer appearence of particles and the actions they perform should be defined in "particle groups" which are like the emitters now but only function as particle property / behaviour groups - An Emitter could then for example create particles of a specific group, which cares about everything else. The Emitter's properties could than be changed, it is not responsible for its casted particles anymore.

3. Particles
Should be able to change the particle group and therefore their behaviour / outer appearence
This would save huge amounts of particles for complex systems like a fireball, where fire particles are created first, which then should turn into smoke and slowly fade away. This could be realised with only a few particles, changing their appearence and behaviour completely over time.

4. Renderers
Should not take any properties like bluring or something like that. this should all be specified in the particle groups. Or at least it should be connected to particle groups, not emitters.
This would result in a better reuse of renderers: different particle groups (blurred / non blurred) could be rendererd by one renderer.

5. Zones
Should be placed anywhere and the groups could register themselves to be informed. So every zone would look at each particle of the specified groups and cast an event if the particles enter/leave the zone. With those events you could implement zone-specific functions like changing the group of particles (and their appearence) if they enter and change it back if they leave.

6. Special Force Fields
Gravity, drag, wind, whirl, rotation, reflector, attractor, annihilator should also be coupled to particle groups. so that you could create a simple animation like this:
- create particles of group 1: simply move +X, if particles of group 1 enter a specified zone (EVENT) change their group to group 2: This group has registered itself to a gravity field so all particles begin to fall down, they could also change their appearence (get blurred to emphasize the fall for example), if they hit the reflector (ground) which this group also was registered to: (EVENT) change their group to group 3: do what ever you want to do them now.

With this system it would be possible to create much more complex systems with greater ease as it is now.
This would of course need a huge change to the codebase, but i think if you dont take these ore similar steps towards a robuster framework, flint wont be able to evolve its full power!

Maybe i will take some time to change your existing code (only twoD for the time) to reflect these changes and give you feedback if it works.
What do you think about these considerations?

kind regards]]> http://flintparticles.org/forum/comments.php?DiscussionID=225&Focus=834#Comment_834 2009-06-24T08:01:48+01:00 2009-06-24T08:05:24+01:00 Richard http://flintparticles.org/forum/account.php?u=1

Hi You have some very interesting suggestions. 1/2/3/6: Splitting the emitter functionality into two classes - emitters and particle groups - would, as you say, add many options. It shouldn't ...

You have some very interesting suggestions.

1/2/3/6: Splitting the emitter functionality into two classes - emitters and particle groups - would, as you say, add many options. It shouldn't be too hard since it's already possible to move particles from one emitter to another. It's even possible to do much of what you suggest by using two emitters - one as the emitter in your scenario, and the other as the particle group.

While the architecture change would be fairly simple, the shift for users would be more dramatic since it would likely break all existing code. There may be a way around this with some sort of super-emitter that implements the same interface as the existing emitter, but behind the scenes combines an emitter and a particle group to do the work.

4: Applying blur to particle groups rather than renderers would produce a different effect - blur on renderers applies the blur to the bitmap image not to each specific particle. The ApplyFilter initializer can be used to apply blur to individual particles, but only when created. An action to apply varying filters would be interesting.

5: Zones are already flexible. Actions and initializers don't alter the zone they use in any way, so the same zone can be used in multiple behaviours on different emitters/particle groups. I don't see any benefits of shifting them to use events rather than the current set-up but I might if I think about it some more.

There's many features that I want to implement in Flint, and this becomes another possibility. All provide benefits (I'll write about them soon, and maybe even start a voting system). Your particle group proposal would indeed add more flexibility and hence power to the system. How soon to implement it will depend in part on whether it can be done without the turmoil of breaking all existing projects.

The other factor, of course, is time. So if you do make the changes yourself I'd love to see the code.

Thank you for your ideas.

Richard]]>