Development > Artwork
New Feature: "Glow" textures
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version