Graal Forums  

Go Back   Graal Forums > Graal V6 forums > Feature request
FAQ Members List Calendar Today's Posts

Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
  #1  
Old 04-29-2011, 12:14 AM
calani calani is offline
Scriptess
calani's Avatar
Join Date: Aug 2003
Location: asmgarden.gmap
Posts: 606
calani is on a distinguished road
Send a message via AIM to calani
Post Emitter Improvements

While working with emitters, I kept finding myself frustrated at the emitters' inability to do certain things, having to cheat to get them to look right, etc; and, I thought of a few things that would be exceedingly handy to have. After awhile, I started writing these down, and ended up compiling this list about two years ago. Even adding support for just a few of these would allow us to make *amazing* things with emitters.

Here's the list:



Particle Emitter Improvements

Summary (no specific order) :
* particle layers independent of parent TShowImg
* flag that specifies whether dropemitter/dropwateremitter particles inherit values
* nested emitters
* dropairemitter - triggers when z>=0 (or waterheight)
* changing values in set amounts, ex: multiples of pi/8
or possibly: selecting a random value out of an array. ex: {0, 1, 2, 4, 8, 16}
* modifier that affects only a percentage of particles
* easy removal of specific modifiers (possibly give each modifier a name/groupname (does not have to be unique) as an identifier)
* ability to reference current particle values (ex: modifying stretchx based on speed)
* toggle for Z altering particles' screen display position
* changing a particle's image after emit
* attaching particles to groups
* ability to read particle's height over (or under) terrain
* ability to read the height of the terrain at the particle's xy
* flag to force a particle's z to always be equal or greater than the terrainheight
* flag to force a particle's z to always be equal or greater than the waterheight
* flag to force a particle's z to always be less than or equal to zero (or waterheight)






Specifics:


Drop emitters' particles need to be able to be on different layers than the container TShowImg
* particle layers independent of parent TShowImg
Ex: Raindrops falling: layer 3. -> Splash effect in dropemitter: layer 0.


Drop emitters should inherit the values from the dropped particle
* flag that specifies whether dropemitter/dropwateremitter particles inherit values
This one is a must. Without it, there is no way to make a particle actually bounce, as it does not know which direction the particle was going, nor the speed, etc. Also, for snowflakes: if a flake hits the ground, you want the drop emitter to show the same snowflake fading out as it melts. problem, though, is that the drop emitter does not know what image the particle was using.

Ex: particle with a random snowflake graphic hits the ground, dropemitter shows the same snowflake fading out
Ex: shrapnel particle hits the ground with random angle/rotation/image, dropemitter causes an identical particle to bounce up and fall with gravity, second drop emitter causes an identical particle to bounce lower and fall with gravity, third drop emitter shows an identical particle resting on the ground then fading out.


Attaching emitters to particles
* Nested emitters
Attaching an emitter to each particle in another emitter.
Ex: Missile particle with a smoke emitter forming the trail behind it, that explodes into a firework via dropemitter (who's particles do not have the smoke attached)

NPC Code:
missile emitter {
particle {
settings;
smoke emitter {
modifiers;
}
}
modifiers;

drop emitter {
particle {
settings;
}
modifiers;
}
}


in the above example, you could also attach another emitter to the dropemitter's particles if needed.



Ability to change particles' attributes in set amounts, ex: change a particle's X by .5, 1, 1.5, ..., angle by increments of pi/4, etc.
* changing values in set amounts, ex: multiples of pi/8
* or possibly: selecting a random value out of an array. ex: {0, 1, 2, 4, 8, 16}

I want to be able to emit particles with angles along set increments, such as every 15 degrees, or (to make a matrix-like effect) spawn text spaced every .5 tiles.
Ex: Anime-style surprise emote: short lines around someone, every 20° or so
Ex: pulsating lines around Super Mario Sunshine's pulsating logo
Ex: matrix-style effect: spawn letters spaced every .5 tiles, add an impulse at .2 seconds to move the letter down .5 tiles. the only way to do this currently is have one emitter per column... which is not very efficient.


Ability to have a modifier affect random particles:
* modifier that affects only a percentage of particles
I only want 20% of my particles to spin, there's no real way of doing this.
The only method of having a few particles spin is by adding an impulse with a timeframe between 0 and 200 seconds or such. You cannot guarantee a percentage, but it -will- make only some of your particles spin. Not a very good solution.


Easier way to remove specific modifiers (rather than clearing all modifiers and readding the ones you want to keep)
* easy removal of specific modifiers (possibly give each modifier a name/groupname (does not have to be unique) as an identifier)
Impulse modifiers are always active and never expire. Need a way to remove (or just enable/disable) these.
Ex: Initial alpha of (.1 to .5) -> lower alpha by .05 every (.01 to .05) sec. Later, remove impulse modifier and fade particle back in to alpha=1.


Way to reference particles' current values in modifiers.
* ability to reference current particle values
Ex: Range modifier replacing alpha from (alpha) to (alpha)+.5 over 3 seconds.
Ex: Range modifier replacing alpha from (alpha) to zero over 3 seconds.
Ex: changing a particle's zoom based on it's speed. 0.05 sec impulse: replace zoom with speed/10
Ex: picking a random number, and fading the alpha of a particle from zero to that number, then back to zero again.


Flag to enable or disable a particle's Z from changing its display position
* toggle for Z altering particles' screen display position
This would be useful for angled falling particles on 3d gmaps. I want rain to fall down from the sky at an angle, and hit the terrain. Setting an angle and speed works great, but if I modify the Z so it can hit the terrain, that will change where the client draws raindrop on the screen, and make the drop's movements jittery as it falls. I want to use Z so i can detect if it hits water or land, and change the ring or splash dropemitter accordingly.
Ex: after setting the flag, a particle at (10,15,22) will be drawn at the same place on the screen as (10,15,0).
Ex: Angled rain falling on a gmap; Uses angle+speed to move the particle, and lowering Z until the particle hits to add a splash.


Ability to change a particle's image after emit
* changing a particle's image after emit
Either setting the particle's image to a specific image, or to one of an array of images {"crystalflash.gif", "g4_particle_x.png", "g4_particle_bluelight.png"}
(or just one of a set of numbered images, ie Snowflake[0..25].png).
The uses for this are staggering.


Particle groups - Changing variables of the group changes all of the particles' vars.
* attaching particles to groups
Attach all particles in a group to a group 'object' so their positions, angles, etc are relative to that object. Like spinning a clock turns the hands, the numbers, the face, etc; and the clock hands cab still move on their own and keep their relative angles and speeds.
Altering the group object, then, would alter every particle therein. if you have a cloud of particles and change the group object's rotation, it would rotate all the particles in the cloud around the center of the group object.

Ex: creating a galaxy emitter and spinning the entire thing without distorting its shape
Ex: flock of birds, school of fish, glow around a flying cannonball, clouds around GK magic bullets/wounds, wind blowing certain smoke particles, etc.
Ex: normal modifiers for each individual particle, along with adding a modifier to alter the speed and heading of the group
Ex: spinning particle spawn points around a central point (see my housing portal emitter on Classic iPhone)


(continued below)
__________________
Reply With Quote
  #2  
Old 04-29-2011, 12:15 AM
calani calani is offline
Scriptess
calani's Avatar
Join Date: Aug 2003
Location: asmgarden.gmap
Posts: 606
calani is on a distinguished road
Send a message via AIM to calani
Post Emitter Improvements (continued)

Ability to read terrainheight on 3d gmaps
* ability to read particle's height over (or under) terrain
* ability to read the height of the terrain at the particle's xy
Would be nice to be able to read a particle's height above the terrain, too, as well as just the height of the terrain the particle is over. Height above (or below) terrain would actually be much more useful. Ex: changing the opacity of cloudcover based on how high it is off the ground - would cover mountainpeaks in denser clouds, or allow for rolling fog near the shore.
Ex: allows particles to interact with the environment, such as golfballs rolling down hills. With particle grouping, could display shadows under particles, and with reading current vars, could change the size of the shadow based on z, and change the shadow alpha, stretching, and angle based on speed.


Flag to tell the particle to never go below the terrain height
* flag to force a particle's z to always be equal or greater than the terrainheight
* flag would disable checkbelowterrain and dropemitter if present (and optionally dropwateremitter)
Particle always at z>=terrainheight.
With this, you could give a particle a zangle of -pi/2 and speed>0, and it will always be on the terrain while moving around.

Ex: Golfballs: can fly in the air and roll around, but never go below the green.
Ex: Rabbits running (hopping) across the grass. Set their angle, speed, and impulses to make them jump, land with gravity, and change angle, but never go below the terrain or trigger a dropemitter. Attached an example below. Wildlife as emitters, interacting with the terrain!


Flag to tell the particle to never go below the terrain height
* flag to force a particle's z to always be less than or equal to zero (or waterheight)
* flag to force a particle's z to always be equal or greater than the waterheight
* flag would disable checkbelowterrain and all drop emitters present (except when particle lifetime expires)
Particle always at z<=0.
With this, you could give a particle a zangle of pi/2 and speed>0, and it will always be at or under the water on a 3d gmap

Ex: Fish
Ex: Rabbits running (hopping) across the grass. Set their angle, speed, and impulses to make them jump, land with gravity, and change angle, but never go below the terrain or trigger a dropemitter. Attached an example below. Wildlife as emitters, interacting with the terrain!
Ex: Ducks (or toy boats)

Dropairemitter
* Dropairemitter - triggers when z>=0 (or waterheight)
* same as a dropemitter or dropwateremitter, but in reverse.

Ex: Bubbles rising from the seafloor to pop at the surface
Ex: Fish jumping
Ex: Waves



Events based on emitters' vars
While I don't expect this to happen, it would be extremely useful.
Ex: If the particle's alpha<=zero, apply these modifiers.
Ex: with(AddLocalEvent("speed >= 30")) { /* Attach cloud-ring emitter for sonic boom*/ }
Ex: Use as a fix for dropemitters not inheriting particle values: shrapnel hitting the ground (saving rotation, image); event removes speed, spin, etc. and fades particle out, or bounce the particle


Particles applying modifiers to nearby particles
I don't expect this either, as particles would have to add modifiers to other emitter's particles. The distance checking, cross-script access, etc. would not be easy to implement.
Implementing this for only particles belonging to the same emitter would still be useful for collisions, though!

perhaps addAreaModifier() with a condition such as Z<2, or dist<3, etc
Ex: collisions
Ex: speed reduction for marbles rolling into and through slime
Ex: adding angular momentum to cloud particles when more 'solid' particles fly through them, such as a cannonball















Examples

Rainfall: (uses: ignore-z-when-drawing, dropemitter changes drawlayers, read current particle vars)

Base Emitter:
- layer 3
- check below terrain
- autorotation
- ignore z when drawing
- image g4_particle_spark
- initial angle = -pi/2 + random(-pi/10,pi/10);
- add -64..64 to x
- add -64..32 to y
- set z to 32
- set mode to 1
- set alpha to between 0.25 .. 1 (picks a random target alpha)
- range: replace alpha from 0 to (alpha) over 0.5 seconds (fade in from zero to current (target) alpha)
- 0.05 sec impulse: add -.1 to z

Scheduleevent outside of emitter, every 0.05:
- modify emit angle by +/- pi/32, but keep within bounds of {-pi/2 +/- pi/10} (for changing wind)

Drop emitter:
- image: g4_particle_ring.png
- set stretchy to 0.5 (keeps perspective)
- set mode to 1
- emissionoffset of {0,1,0}
- range: replace zoom from 0 to 0.5 over 0.75 seconds
- range: replace alpha from 1 to 0 over 0.75 seconds

Drop water emitter:
- image: g4_particle_ring.png
- set stretchy to 0.5 (keeps perspective)
- set mode to 1
- emissionoffset of {0,1,0}
- range: replace zoom from 0 to 0.8 over 1 seconds
- range: replace alpha from 1 to 0 over 1 seconds



Bouncing ball: (uses: dropemitter particle inheriting)

Base Emitter:
- layer 3
- ball graphic
- children_particles_inherit_values
- add -15..15 to x/y
- set z to 10..15
- set zangle to -pi/2
- set angle to 0..2*pi
- set speed to 0.1;
- .05 sec impulse: add 0.1 to speed (apply fixed gravity)

Drop Emitter 1: (inherits particle data)
- multiply speed by -.6 (ball changes direction, loses momentum)
- 0.05 sec impulse: add 0.1 to speed (pull particle back to the ground with fixed gravity)

Drop Emitter 2:
- multiply speed by -.6
- 0.05 sec impulse: add 0.1 to speed

Drop Emitter 3:
- multiply speed by -.6
- 0.05 sec impulse: add 0.1 to speed

Drop Emitter 4:
- multiply speed by -.6
- 0.05 sec impulse: add 0.1 to speed

Drop Emitter 5:
- set speed to 0
- range: replace alpha from 1 to 0 over 3 seconds



Running Rabbit: (Uses: always above terrain flag, change image after emit)
Problems: will run over water (perhaps along the seafloor depending on 'AlwaysAboveTerrain' flag behavior)

Base Emitter:
- layer 1
- image of a rabbit running
- AlwaysAboveTerrain=true (disables drop emitter, lets rabbit run up hills)
- set angle to 0..2*pi
- 1 sec impulse: add pi/3 to zangle (hopping)
- 0.05 sec impulse: add -0.1 to Z and multiply zangle by .85 (gravity, coupled with hopping by using zangle, should make for realistic-looking hopping)
- (0.1 to 3) sec impulse: add +/- pi/8 to angle (running around randomly)
- (10 to 60) sec impulse: set speed to (10 to 12) and change image to running // running
- (5 to 40) sec impulse: set speed to (5 to 8) and change image to running // hopping
- (0 to 30) sec impulse: set speed to 0 and change image to an idle and scratching animation // stop and scratch, look around



Running Rabbit: (Uses: events)

Base Emitter:
- layer 1
- image of a rabbit running
- set angle to 0..2*pi
- 1 sec impulse: add pi/4 to zangle
- 0.1 sec impulse: add +/- pi/32 to angle

Events:
- if Z>=TerrainHeight: 0.05 sec impulse: lower zangle by pi/48 (for running down terrain)
- if Z<=TerrainHeight: add pi/8 to zangle (for hopping and climbing terrain)
- if Z<=0.5: add pi/3 to angle (so it doesn't hit the water)
- if Z<=0: stop moving, fade alpha 1 to 0; respawn




Semi-intelligent school of fish: (uses: events, grouping, terrainheight)

layer 0, so always below player

Emitter for individual fish:
- spawns several particles with random graphic (animated graphic of the fish swimming slowly)
- adds a few tiles to their x/y/z so they're in a school
- set their angle to between 0..2*pi

Group fish particles:
- apply an impulse to slowly change the group's angle and speed

Events based on Z:
- if group terrainheight>=-3: enable an impulse to change the group's angle by pi/16 every half a second
- if group terrainheight<-3: disable above impulse
- if group terrainheight<=-1: add pi/3 to angle.
__________________
Reply With Quote
  #3  
Old 04-29-2011, 01:01 AM
WhiteDragon WhiteDragon is offline
Banned
Join Date: Feb 2007
Posts: 1,002
WhiteDragon is a splendid one to beholdWhiteDragon is a splendid one to beholdWhiteDragon is a splendid one to beholdWhiteDragon is a splendid one to beholdWhiteDragon is a splendid one to behold
Long post is long.


I like most of these ideas, but my main worry is some of the ideas is moving from "emitters specifying global particle behavior", to "directly specifying individual particle behavior".

I.e., after being able to: control random subsets of particles, control specific subsets of particles, and access specific particle data, we are very close to directly manipulating particles. The main reason the particle system 'works' is because it avoids doing that and can perform reasonably well as a result.


The rest looks good imo (though I don't use terrain stuff so I can't really comment there).
Reply With Quote
  #4  
Old 04-29-2011, 01:18 AM
calani calani is offline
Scriptess
calani's Avatar
Join Date: Aug 2003
Location: asmgarden.gmap
Posts: 606
calani is on a distinguished road
Send a message via AIM to calani
Quote:
Originally Posted by WhiteDragon View Post
... but my main worry is some of the ideas is moving from "emitters specifying global particle behavior", to "directly specifying individual particle behavior".
Agreed, and that's why I tried to steer clear of those sorts of things. Features dealing with specific particles tend to add a lot of processing, especially one particle (or emitter) modifying another. That's why I totally don't expect those to happen... it would be a ton of work ><. If implemented, though, just think of what we could create! (:


Still, the rest of them shouldn't add much strain to the engine, and would make everything ever so much more useful.
__________________
Reply With Quote
  #5  
Old 05-21-2011, 11:59 PM
Admins Admins is offline
Graal Administration
Join Date: Jan 2000
Location: Admins
Posts: 11,693
Admins has much to be proud ofAdmins has much to be proud ofAdmins has much to be proud ofAdmins has much to be proud ofAdmins has much to be proud ofAdmins has much to be proud of
The "z doesn't influence display position" sounds problematic for 3d terrain, it would be out of screen if the z is not used as offset
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:50 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.