Simple Glow Effect

if you are using direct3d, shaders will work on all hardware of that directx generation (ie. DX9 for the newest shaders). if you are using OpenGL, only use ARB_vertex_program and ARB_fragment_program, and the shaders will work on all hardware supporting OpenGL 1.5+

to simplyfy and bring to a higher level, you could use a shader language such as nVidia's Cg or Direct3D HLSL (C like language but for the graphics card!)

I've implemented the said "glow effect", the shader version gave me quite a bit of flexibility, because i could play with settings on a per-"pixel" level eg. the convolution blur factor etc. it was particularly easy because i used nVidia's Cg (and yes, i do have an ATi Radeon 9500 pro). one thing is that shaders are hell to debug (in OpenGL - what i use) but in the newest DX SDK i belive there is a new shader debugger of somesort.

anyway, worth checking out :)

Cheers,
Danu

PS. my glow effect screenie!

Which non-shader method did you use? It's impossible to say whether shaders would give you a speed increase without knowing how you're doing it at the moment [smile]

For the most part, shaders aren't a problem. If you write for the low version ones (like ps.1.1) then it'll run on pretty much any card that supports pixel shaders. The issue of rewriting shaders only arises if you want to take advantage of shortcuts available through later versions - even then you'd only be writing one shader per version (and you'd skip some - one 3.0 shader, one 2.0 shader, and a 1.1 shader is probably enough).

The technique I used was one based on the NEHE radial blur tutorial. I rendered the scene to the framebuffer, then I rerendered the scene to a 256 x 256 PBuffer using a glow texture. Then I sampled that PBuffer into another even smaller PBuffer (64 x 64) like 25 times, then I drew the small texture over the whole screen. on my Radeon 7500 it runs about 60 fps, and on my 9500 about 90 fps... that's in windowed mode though. The entire mech is about 1500 polys, which means it's not pulling the best framerates, but I need to try a shaders version for comparison. Still, in a situation where you don't have much geometry, and no shaders, it's respectable.

So, I'm trying out this shader stuff. I just downloaded a ton of stuff for CG. I picked that cuz it's high level and API inspecific. I've always been a little skeptical of CG though cuz I'm an ATI fan and I don't like the idea that NVIDIA might possibly not want to optimize for ATI as much as it could. Being the only crooss-platform/api high level shader language I know of, I guess it will have to do.

Cg is the same language as HLSL, which ATI has no problem supporting. AFAIK, the language is not keyed towards GeForces in particular.

Quote:

Original post by Sneftel Cg is the same language as HLSL, which ATI has no problem supporting. AFAIK, the language is not keyed towards GeForces in particular.

i was under the impression that Cg generats faster shader code when the target is nvidia hardware.

i also find it hard to beleive that the HLSL of OpenGL that was created by nVidia will not optimize favourably for nVidia's hardware. :)

The language is hardware-independent, but the tools may well not be [wink]

The technique you used sounds a bit like the non-shader approach in GPUGems... might be worth a look, if you've got it. (Is probably worth a look if you haven't got it, either). I reckon there's a trick with multitexturing that would allow you to condense your 25 passes into something more like 5-6...

Hi,

Cg and HLSL are not the same. Even when MS and nVidia colaborated, nVidia added some features. So some instructions of Cg may not compile directly on HLSL, but its easy to fix.

Cg is a good language but the lack of support for ATI cards (obviously) makes me uneasy with it. Anyway, nVidia has almost stopped Cg production and embraced the FX framework from DX9 (and in the way, dropping their FX framework CgFX).

Inversed, when you use the FX framework, the FX file may contain many versions (techniques) of the effect. The FX framework select which technique works with the hardware available in the computer. So the hard job is to provide enough versions in order to get better visual quality in as much HW as posible. You dont need to do that anyway, its optional. But I grant you the owner of a GeForce 6800 or Radeon X800 will be displeased seeing an effect that may not be what they expected.

Anyway, my glow, for VS and PS 1.1
http://www.spritekin.com/warscale/screen4.jpg

Luck!
Guimo

Is it just me or has graphics programming become one big pain in the ass since the introduction of shaders. I mean, it's always been a pain in the ass, but I remember when hardware TnL was a big thing and your choices where use it or don't use it. With shaders you have write like five verisions of an effect. I guess it's my fault for trying to do the sensible thing and not choosing sides in the graphics api debate. I just like flexibility. ... Maybe I should just be an audio programmer or something :)

Quote:

Original post by INVERSED Is it just me or has graphics programming become one big pain in the ass since the introduction of shaders. I mean, it's always been a pain in the ass, but I remember when hardware TnL was a big thing and your choices where use it or don't use it. With shaders you have write like five verisions of an effect. I guess it's my fault for trying to do the sensible thing and not choosing sides in the graphics api debate. I just like flexibility. ... Maybe I should just be an audio programmer or something :)

In a few years, technology should level out somewhat and you won't have to support widely varying shader capabilities. The current state of affairs is extremely transitional, as developers and manufacturers come to a consensus on what cards need to do and how they need to do it.

agreed, we are in a bit of a transistion period here. its the begining of the shader gen, and OpenGL 2.0 and DX10 are going to bring us some what closer to standardisation, GL2 by providing a vendor independant platform for openGL and DX10 by moving boldly into the "no-default-fixed-pipe" era.

I'm doing a similar glow effect in my game (see website in sig). Its basically the same method described in the gamasutra article on Tron 2.0's glow:

- Render scene with glow materials (anything that doesn't glow is black to get the proper obscuring of other surfaces).
- Copy to texture.
- Blur texture.

For the blur I use two methods:
- Mipmapped mode the auto build mipmaps extension on the glow texture, then renders all the mip levels blended over the scene. This is pretty fast but tends to look a bit blocky and you can't control the blur level too well.
- Multisample mode. Works pretty much like a regular multisampling blur filter. Repeatedly re-renders the glow texture blended over itself (first horizontally, then vertically). Uses two texture units if possible to do two samples at a time ('cos the blur filter is symetrical).

The second method could be extended to use as many texture units as possible, but thats *really* damn tricky to do on pre-shader hardware (I'm trying to stay compatable to GF1 and up). Multisample mode gives great quality though. [grin]