New Feature: "Glow" textures

[Mattn]

My personal preference is for the second option, at least initially (I may implement them both eventually), because it allows a much greater degree of artistic control, and I think it will fit well with the atmosphere of the game.  Having the "bright green" portions of UFOs glow, for example, seems like a natural extension of the current artistic style.  It would probably even be possible to have simple animations in which the glow-texture was varied over time, allowing things like pulsing or other fun visual effects.

ok, go for the second option then. also see about the shell effect in r_state.c - this is already something like that and could be extended a little bit to add a glow imo.

[MCR]

ok, go for the second option then. also see about the shell effect in r_state.c - this is already something like that and could be extended a little bit to add a glow imo.

Juhu !!!!!!!!!!!!!

Sorry, I meant YEAH !!! 

[H-Hour]

The standard textures do not make use of the alpha channel @ all 

Standard textures can use an alpha channel now. The rendering at distance is a bit odd (doesn't seem to blur properly), but I assume this will be fixed some day and having the alpha channel will be important for things like hanging wires, metal wire fencing, etc.

[MCR]

Standard textures can use an alpha channel now. The rendering at distance is a bit odd (doesn't seem to blur properly), but I assume this will be fixed some day and having the alpha channel will be important for things like hanging wires, metal wire fencing, etc.

But do our standard textures we have @ the moment use the alpha-channel ?! I know that the ufo*.* textures do not use it.
You are very right regarding the things you mentioned, but when we use the material system to define the textures which should glow, there should be no problem with having other textures, which have an alpha channel used for transparency for example or for other things on the same map without interfering ?!
But I am not an expert on this. Maybe arisian could answer this, so we can be sure...

[Mattn]

arisian, if you are implementing this, please try to add it for brushes at first, and incorporate it into the material system. so we can define it on a per-texture basis. skip it for meshes first, i have a pending patch for some kind of shader/material system for meshes, too. your interface should be generic enough to handle both cases. see the existing stuff in r_state.c those R_Enable* functions - please try to keep that pattern.

[arisian]

Okay, I've added some simple functions that allow (very limited at the moment) types of postprocessing for the battlescape.  The only visual change the patch I just committed makes is that all "shell" effects will now have a basic "glow" effect (if postprocessing is turned on).  There are several functions now that allow different ways of rendering "glow;" if you just want to render only to the "glow" buffer, you can do that with R_EnableDrawToGlow().  There's also the more general R_EnableGlow() which allows you to render to both the "standard" renderbuffer and the "glow" buffer at the same time.  This is mostly only useful if you're using shader programs, in which case you can specify separate colors for gl_FragData[0] ("normal" buffer) and gl_FragData[1] ("glow" buffer).  This is more efficient, because you can render to both buffers in a single pass, but is overkill for simple things like the shell effect example I've included.

Let me know what you think; Mattn, in particular, are the "R_Enable" functions I wrote the kind you had in mind?

[Mattn]

yes thanks, the R_Enable* stuff is what i had in mind, it should be quite easy now to get this into the material system, too

but please always test different resolutions - it's not working for 1024x768 - the render buffer is too small and the position of the glowing entities is wrong, too.

[Mattn]

noticed another small bug, glowing models are shining through other models - but not through brushes.

[BTAxis]

I realize we're still talking about general implementation technicalities and not about actual use, but I'd still like to point out that civilians should not glow red. Red is associated with enemies (a good example of this is Assassin's Creed's eagle vision). Aliens should glow red, civilians blue.

[MCR]

Good idea, BTAxis, I agree.
But I suppose this will be no technical problem @ all.
I just wanna also note here that it 'feels' a little unnatural if we have IR-googles, which should enable us to look through walls, but the shell effect does not shine through...
Maybe it should shine through the walls somehow ?!

[arisian]

I'll take a look at the "wrong size renderbuffer" issue, though I'm rather perplexed at first glance, since I'm using viddef.width/height as the size for creating the renderbuffer.  Is there some way that the viddef info could be wrong?  It seems to work fine for resolution switching in the geoscape; is viddef only applied to the geoscape or something?

As to the glow "through" other models, that's simple to fix if you're rendering the models using GLSL, but much more of a pain otherwise (you would effectively have to render all models twice, once to the render buffer and once to the glow buffer, and making them all black for the second of the two if they were supposed to block glow).  It wouldn't be difficult to implement, but it seems inefficient.  If you're using shaders, you can just render to both buffers simultaneously (using gl_FragData[0] and gl_FragData[1] after calling R_EnableGlow), so there isn't any performance hit.

[Mattn]

in general all screen width and height should be based on 1024x768 - and videf.rx, viddef.ry should be used to get the correct values. in the shaders we already have r_width and r_height as defines (see r_program.c line 276ff) - more could be added as needed.

about the rendering order or not used depth buffer (or whatever the cause is) - skip it maybe for now - the other bug is more important

@BTAxis about the color - this is work-in-progress.

[arisian]

Okay, I think I fixed the bug that was causing the "offset" issue; it seems to work at all resolutions here.  Let me know if anyone has issues with this after updating to the latest svn version.

[Sepelio]

I've not read the whole thread but glow maps are really really easy to make and I think they are a lot less performance killing than any sort of HDR.

[arisian]

That depends on what you mean by "glow maps."  If you just mean "emissive materials", that's easy, but they won't have bloom-effects around the edges.  You can also create one-off transparent textures that you slap on top of an object which create a type of bloom-effect (this is what has been done for the sun's "rays" on the geoscape), but that solution doesn't scale very well, as well as not being able to handle occlusion gracefully.

Doing bloom-effects as a post-processing step is, indeed, moderately expensive (just how expensive is dependent on how smooth a result you require), but there are several advantages.  First, you don't need an extra "halo" texture for everything-that's-supposed-to-glow-ever, which saves compute time (in calculating where in 2D space the textures should be placed, as well as in drawing them), memory, and artist's time.  Second, occlusions are handled naturally, and you wind up with bloom-edge-effects that look a lot more like camera images.  Finally, while the postprocessing step is costly, it only needs to be done once per frame; it's essentially a fixed cost regardless of how simple or complex the scene is.  Adding more models, textures, animations, etc. to the scene doesn't change the cost of the postprocessing step, so it's a very scalable solution.

"True" HDR relies on the same postprocessing as the glow/bloom features I've implemented; the only difference is that where I've got two separate render buffers (one for "normal" and one for "glow"), standard HDR uses a single buffer of half-floats, which allows values greater than 1.0 (or 255, depending on interpretation), which can then be used to determine what things are brighter than the screen can display, and draw bloom around those things.