Particle Systems Update

[Umrion]

Ok, I've got some work done on the particle systems. First thing I have to say, is that the map editor side needs more work, but I think I'll leave that to someone who knows the editor better than me

The client probably also still needs some fixes and maybe optimization, I haven't had time to do that much work on it (after getting it to work .)

The .part files might need more work, but as soon as I've written a graphical editor for them, this will be a lot easier to fix

 

Patch for client available here: https://developer.berlios.de/patch/index.ph...9&group_id=1256

Patch for map editor available here: https://developer.berlios.de/patch/index.ph...0&group_id=1256 (You'll also need the new particles.h and particles.c from the client)

Preliminary particle definitions and new button texture for map editor here: http://www.cs.umu.se/~dva97tha/particles.zip

 

Er.. I think I had something else to say, but I can't remember at the moment. I'll post again later if I think of anything.

[Cicero]

I've looked over the patch and patched my copy, and it seems to work. I'll look over it some more, and if nobody objects, I'll commit it.

[Entropy]

If they work, commit them

Great work, Umrion

[Cicero]

Well, I think it needs tweaking, but I don't really see any immediate reason not to commit it.

[Cicero]

I think I'll let sadez accept the map editor patch. He seems to have pretty much taken over the map editor

[Sadez]

Commited the map editor patch and added a windows file selector (there was only the gtk one).

[Entropy]

OMFG that's really leet

Now we can put smoke on house chimneys, fires in the swamps, and even the water fountains

Can you please post the format of the part files, so people can start experimenting?

[Umrion]

Thanks

 

Looking at it now, I can see that the update functions could need a few fixes. I see that I've not added TTL-support to all of them. Oh, well. It should work well enough for people to get the idea.

 

Here goes (this is the small_fire example):

2          // .part version. Should be 2 for now
4          // System type (i.e. which update function to use.) See below.
0x0302,0x1 // Blending factors (see below for values)
600        // #particles. Maximum is 2000
-1           // TTL (see below.)
0            // Particle texture. 0 means particle0.bmp etc.
1.0         // Particle size. 1.0 is as big as the largest particle in the old system. 0.0 is just silly
0            // Random function (see below.)
-0.1,-0.1,-0.2  // Starting position, minimum coordinates (for particles)
0.1,0.1,0.3    // Starting position, maximum coordinates.
-1.0    // Circular constrain (below.)
0.0,0.0,0.015   // Starting velocity, minimum values
0.0,0.0,0.03    // Starting velocity, maximum
0.725,0.075,-0.005,0.2  // Starting color (RGBA), minimum
0.775,0.325,0.105,0.7   // Starting color, maximum
-0.025,-0.025,-0.1  // Acceleration, minimum
0.025,0.025,0.1   // Acceleration, maximum
0.0025,0.0025,0.0025,-0.05   // Color-change, maximum
0.02,0.02,0.02,-0.05  // Color-change, minimum

 

System types:

0 Teleporter. "Acceleration" is used as a random modifier to speed each fram. Particles die when at z>2.0

1 Teleport in or out. Acceleration used as for teleporter. Particles die at z>2.0... Now that I think of it, this should probably not be used (the update function is almost identical to the teleporter one.)

2 Bag in or out. Acceleration used as for teleporter. Particles die at z>1.0

3 Spherical or circular burst. Set velocity to zero to make it be calculated by position. If particle has one coordinate set to zero, the burst will be circular, otherwise spherical. Particles die when at a distance of 3 times the constrain radius from the system center.

4 Fire (or smoke etc.) Acceleration used as for teleporter. Particles die when alpha<0.0

5 Fountain. Particles will bounce if they go under z=0 (the ground plane) and die when alpha<0.0

 

Blending factors

Source (first value):

GL_ZERO                           0x0
GL_ONE                            0x1
GL_DST_COLOR                      0x0306
GL_ONE_MINUS_DST_COLOR            0x0307
GL_SRC_ALPHA_SATURATE             0x0308
GL_SRC_ALPHA                      0x0302
GL_ONE_MINUS_SRC_ALPHA            0x0303
GL_DST_ALPHA                      0x0304
GL_ONE_MINUS_DST_ALPHA            0x0305

Destination (second value):

GL_ZERO                           0x0
GL_ONE                            0x1
GL_SRC_COLOR                      0x0300
GL_ONE_MINUS_SRC_COLOR            0x0301
GL_SRC_ALPHA                      0x0302
GL_ONE_MINUS_SRC_ALPHA            0x0303
GL_DST_ALPHA                      0x0304
GL_ONE_MINUS_DST_ALPHA            0x0305

These are used to combine the particle (source) with what's been rendered before (destination.) The final color for each pixel is sblend*scolor+dblend*dcolor (where sblend is the source blending factor and so on.) You can ignore GL_SRC_ALPHA_SATURATE and anything involving DST_ALPHA, since we don't (necessarily) have an alpha channel.

 

TTL

Not used when less than zero.

The system dies when all particles are free and ttl is zero (it's decremented when particles are updated.)

 

Random function

Random function used when creating particles. I'd prefer it if you used 0 here, but if you feel that 1 looks better, then go ahead and use it.

0 - Linear distribution between min and max

1 - Other kind of distribution (from the old system.) Most values should be between min and max...

 

Circular constraint

Not used when less than zero.

Created particles are constrained to be so that x*x+y*y<constraint, i.e. the constrain is the square of the radius.

 

Well, I think that's about it.

[Wytter]

Hmm, your TTL got me wondering a bit - the way I read your code, then the TTL will actually depend on the persons framerate. Shouldn't it rather use SDL_GetTicks() to ensure that the TTL is the same on every system in every situation? Or am I wrong?

[Umrion]

All animation - actors, water and particles - is controlled by a timer function (check my_timer in draw_scene.c) that is called a number of times per second that is (or should be) independent of frame rate. So update_particles is called the same number of times per second no matter what the frame rate is.

If this wasn't so, then we would need to use (for example) SDL_GetTicks to handle TTL, velocity, acceleration, color change...

[Wytter]

Ahh, thanks for clarifying :-)

[Sadez]

Fixed some copypaste errors that prevented from deleting particles systems in map editor. It now deletes particles systems when you have one selected and hit right click. Also fixed a small bug in all the windows file dialogs that didn't start in the correct directory.

[Entropy]

Can't wait to have all that in the new version

Are you working at the GUI particle editor?

[Umrion]

I've been a bit busy, so I'm still mostly in the planning stages

I'll get started properly tomorrow

[Entropy]

Excellent, keep up the great work

[duran]

i cant wait for spells that use this system

and maybe the new system for learning magic

hmm, is that what we are waiting on for the new public release maybe?

[Umrion]

Line 38 in interface.c:

particles_list[selected_particles_object]->ttl=-1; // we dont want the particle sys to disapear

Sadez, I guess you added this? It makes the program crash when trying to open a new particle system...

In the gtk version of the file dialog, open_particles_obj() returns right away, so selected_particles_object will still be -1 when this line is reached

[Keknehv]

Hmmm... just wondering, could we combine this patch with the friend vs. foe one that someone else had posted (can't find it now...). So we could have a few particles drifting up from defined players? (guild, Ent, etc.). Also, we need to make sure to have a way to turn off the particles for the lesser capable systems (really, some people run it at 4 FPS as it IS). Or maybe even a particle-scaled decrease, where the engine draws fewer particles (or more?) based on a setting.

 

Oh, and I've got the order now.

 

Entropy--GOD

Roja------Holy... something

Umrion---Jesus

Satan-----Satan

Jebus-----Imposter

 

TO BE REVISED

[crusadingknight]

Hmmm... just wondering, could we combine this patch with the friend vs. foe one that someone else had posted (can't find it now...). So we could have a few particles drifting up from defined players? (guild, Ent, etc.). Also, we need to make sure to have a way to turn off the particles for the lesser capable systems (really, some people run it at 4 FPS as it IS). Or maybe even a particle-scaled decrease, where the engine draws fewer particles (or more?) based on a setting.

 

Oh, and I've got the order now.

 

Entropy--GOD

Roja------Holy... something

Umrion---Jesus

Satan-----Satan

Jebus-----Imposter

 

TO BE REVISED

Just stick it under poor_man...

 

 

BTW-

Entropy--GOD

Roja------Holy... something

Umrion---Jesus

Satan-----Satan

Jebus-----Imposter

 

 

Then I am...thatn00bwhostuckaroundandcanprogramandissortofrecognizednowthathe'splayed12months?

[Sadez]

Line 38 in interface.c:

particles_list[selected_particles_object]->ttl=-1; // we dont want the particle sys to disapear

Sadez, I guess you added this? It makes the program crash when trying to open a new particle system...

In the gtk version of the file dialog, open_particles_obj() returns right away, so selected_particles_object will still be -1 when this line is reached

It should be fixed now

[crusadingknight]

Don't we need some support for non-point particles?

 

 

Also- Is it just me, or do they look better in the mapeditor?

[Umrion]

crusadingknight: #use_point_particles=0

 

Keknehv: I'm working on some optimizations, but yes, perhaps we should make (the amount of) particles an option

[Learner]

If your going to allow tuning the number of particles, maybe let them set a %

[Umrion]

Yes, maybe I'll add this to the ini-file:

#particles_percent

and use it to scale "total_particle_no" when loading a .part file. (And of course 0 would mean that

display_particles() and update_particles() are never called.)

[Umrion]

Updates, optimizations and stuff for particle systems:

https://developer.berlios.de/patch/index.ph...2&group_id=1256

#particles_percentage=50 in el.ini would make all particle systems use 50% of the number of particles defined in the .part files. I might later add so that particle sizes are scaled based on this, so that less particles would mean that each particle is larger. I'll have to test that a bit first, though.

 

The editor is also done (as a new window for the map editor)... But how do I make a diff when I want to add new files?

 

Don't we need some support for non-point particles?

Also, of course point sprites are disabled if not available.

 

 

Also- Is it just me, or do they look better in the mapeditor?

Shouldn't be much difference... However, remember that the particle systems use blending, so different backgrounds might give different effects.