Burning units

[titi]

These ideas are inspired by the black particles(smoke) idea

1. In original glest, moving units cannot burn. If you try this, you get fires which burns forever.... It would be nice if this whould be possible, for airships for example)

2.burning units / particle system in general: if you have for example a campfire it would be nice if it would be possible to have "real" fire in it.
Other nice things are energy towers which spray around with some particels while producing energy, smoking chimneys and so on.
For this we need a possibility to define particles/fire for every skill.

[Omega]

Yeah, I asked this a LONG time ago (though it was for regular glest). Black particles could be added without too much trouble, just add a few more colours! Or better yet, allow hex colors (ie: #000000 for black #ffffff for white, in the #RRGGBB format). That would allow most colours to be created!

Good idea?

[daniel.santos]

These ideas are inspired by the black particles(smoke) idea

1. In original glest, moving units cannot burn. If you try this, you get fires which burns forever.... It would be nice if this whould be possible, for airships for example)

2.burning units / particle system in general: if you have for example a campfire it would be nice if it would be possible to have "real" fire in it.
Other nice things are energy towers which spray around with some particels while producing energy, smoking chimneys and so on.
For this we need a possibility to define particles/fire for every skill.

titi,
0.3 already has the ability to associate a particle system with any skill, both projection and splash.  However, it isn't enough.  There isn't fire particle system support yet, but I don't anticipate that one being too difficult (including the request that you can move around with it).  The main problem is that the projection and splash particle systems were designed for attacks & explosions, and they look great for those.  However, they aren't doing well for other applications.  Thus, in addition to adding fire, we need more advanced particle system support.  At least we have part of the solution.  When I'm finished with 0.2.11, I'm going to merge changes in the 0.2 branch back into 0.3 and resume 0.3 development.

Yeah, I asked this a LONG time ago (though it was for regular glest). Black particles could be added without too much trouble, just add a few more colours! Or better yet, allow hex colors (ie: #000000 for black #ffffff for white, in the #RRGGBB format). That would allow most colours to be created!

Good idea?

Actually, it isn't that easy (the black particles). With the way the particle systems render, the closer a color is to white, the more transparent it is in that color (R, G & B).  I'm still new in graphics programming and it's less than trivial for me, but either way it involves changing the way particle systems are rendered, which can effect other things in the rendering process.  Feel free to figure it out and send me a patch!  (or talk Martiño into it, I'm sure he could do it much faster than I could)

As far as hex colors, I think that the current floating point, zero to one system is sufficient as you can always translate using a calculator (convert hex to decimal and then divide by 256).  Then again, a lot of people have hex codes for their favorite colors memorized, so maybe hex could be cleaner (less digits too, example 0D hex divided by 256 = 0.05078125 floating point decimal).  I dunno, but I'm sorry it's not too high on the priority list at the moment (maybe something to consider for later when there's more people modding GAE).

[Omega]

Yeah, but make the colors work more like hex. r=0 g=0 b=0 should be black.

[modman]

What about the variations of black?  Would that be controled by the alpha?

[daniel.santos]

I'm still learning here, but I was studying this yesterday (from an OpenGL book).  There are a few different blending modes.  Also, as a side note, there are mechanisms to support anti-aliasing in particles (well, points, lines & quads), but I'm against it.  You might say that I'm anti-anti-aliasing.  But really, the mechanisms I'm talking about are out dated and are more CPU and GPU costly than multi-sampling, which is performed on the entire buffer.

But you didn't ask about anti-aliasing.  So yea, the alpha and the blend mode I believe.  I'll know more when I learn more.

Omega, if you do hex RGB, there's only one way to go -- you copy the standard used in HTML, etc. 000000 is black, ffffff is white, 808080 is grey, etc.

Also, back to burning units, I've done more research on this (when I got tired of working on my screwed up multiplayer implementation) and learned more about how this should work to make it realistic.  Unfortunately, there are a tad more calculations that should go into a moving fire source, but not many.  As a fire burns, it's illustrated with little particles, actually textured, billboarded quads -- this is a square (in our case) polygon or pair of polygons, with a texture and "billboarded" so that it always faces the camera.  Fire particles rise due to heat (as does hot gas and plasma in a normal earth environment).  But when an object is moving, it creates a vacuum effect and turbulence behind it.  If this is left out, the fire particle system will look a little squirrelly IMO.  The turbulence will be the most difficult for me, but it's also the least important of the two, so I'll probably implement it without turbulence.  However, somebody is going to have to code turbulence at some point for a large number of particle systems and effects (this would make snow look more realistic around moving units, for instance).  Turbulence is what causes a fluid (in this case, air) to spin around.  Either way, the vacuum is what causes the fire particles to tend to follow the moving burning object rather than simply floating up completely detached from their source (although they are completely detached, bad analogy) -- Ok, I'm rambling, I stop here.