Wow, glad to see all the interest here!
I'll try to answer the questions I've spotted:
1.) None of the real-time glow stuff will ever work without GLSL. There's just no way to implement those features without using shader programs (in particular, for the postprocessing step itself). The only thing you can do without shaders is make sprite-style "glow," by slapping a transparent texture with pre-rendered glow effects on top of an object (this is the way the halos around lights are done now, as I recall).
2.) Having a parameter that lets you control intensity in the material shouldn't be too difficult; "pulse" animations already adjust intensity on the fly, and it shouldn't be too hard to add a parameter to control the "base" intensity to the .mat file. By the way, the "pulse" effect should already allow glow to fluctuate over time. The stretch, rotate, and scroll effects should work with glow-maps, too.
3.) There's no reason glow couldn't be applied to the particles. Essentially, if you want something to glow, you just need to make sure the "glow" part gets rendered to the glow buffer, and everything else is taken care of by the existing post-processing code. I know nothing about the particle system, so we'd have to figure out how glow should be specified there.
3.) The glow "radius" is something which can be adjusted in the code, but not on the fly (at least, not at the moment). Reducing the intensity will reduce the effective distance that it spreads, though. In terms of what the glow radius is, there's a tradeoff between performance, quality, and size. You can adjust any one of those three parameters, but doing so will affect the other two. For example, right now there's a sort of "sparkle" effect to the glow when you move the camera, particularly if you have small, bright spots of glow. This is essentially an aliasing artifact; it's easy to reduce, but doing so would either decrease the glow radius, or increase the computational cost of doing the postprocessing. If you want to play around, look at the DOWNSAMPLE_PASSES and DOWNSAMPLE_SCALE macros in r_state.h, as well as the FILTER_SIZE macro in r_program.c
4.) I'm disinclined to decouple glow-maps from normal textures too much, so I don't want to have one-to-many mappings (ie. one "normal" texture with several "glow" textures for animation frames). However, I think it should be possible to add a material parameter that would cause the "standard" textures to be rendered to the glow-buffer. This would let you have only the textures you needed for your animation frames, if I understand what you're asking for.
5.) Mattn, I've got no idea what's going on for you; let me know if you figure anything out, or want help.
If I've missed any other questions, I appolagize; there were a lot of them
Show Posts
otherwise, I'm inclined to wait until I'm more confident that the code has stabilized before doing lots of documentation.