Glow Postprocessing
Hi,
my application renders several particle systems with a spark texture. Now, I want the particles to glow. It should be possible to specify the intensity of the glow, but I'm unsure where to write it when rendering.
There are probably several techniques for this:
* One method is presented at Gamasutra and in the Nvidia SDK. It involves writing the brightness of each object to the alpha channel of the backbuffer. However, I can't do this since the spark texture has transparency - therefore, alpha blending is necessary.
* Using multiple rendertargets, I could render the glow strength to a second surface. But MRTs don't allow antialiasing, and IIRC they have other limitations too.
* Would HDR with integer (as demonstrated in the HDRFormats SDK Sample) be a good solution for this particular situation?
I've read a lot of information about postprocessing, but I'm still unsure what to do and would be thankful for any advice.
Tubos
[Edited by - Tubos on July 17, 2007 2:38:08 PM]
Quote:Original post by TubosI can't read that as I'm not a subscriber. I had login details once, but I tend to lose such things.
* One method is presented at Gamasutra
Quote:Original post by TubosDo you specifically need destination alpha? If not then this may not be as big a limitation as you think.
However, I can't do this since the spark texture has transparency - therefore, alpha blending is necessary.
Quote:Original post by TubosSounds like overkill to me.
* Using multiple rendertargets, I could render the glow strength to a second surface. But MRTs don't allow antialiasing, and IIRC they have other limitations too.
Quote:Original post by TubosRGBE formats - integer exponent formats still make use of the destination alpha channel, so you've the same point at before - it may or may not matter.
* Would HDR with integer (as demonstrated in the HDRFormats SDK Sample) be a good solution for this particular situation?
Quote:Original post by TubosHave you played with the 'PostProcess' sample in the DirectX SDK? Might be a source of ideas.
I've read a lot of information about postprocessing, but I'm still unsure what to do and would be thankful for any advice.
The other option is always to do a multipass approach. If the alpha channel operations really stop you using that component then you could use a PS to render a single greyscale 'weighting texture' that contains the brightness (multiplied by source alpha) of each particle and then feed this back in to the actual post-processing stage...
Another option is just to fudge it - do a threshold blur for example. It's a cheap and nasty hack, but if it looks good then it is good [wink]
hth
Jack
Thank you for your helpful answers!
This is the desired result (the orange background is just for testing ;-) )
Destination alpha is necessary here - unless there is another way of achieving a similar result?
And when doing multipass, would the steps look like this?
1) Render particles to backbuffer (only Color)
2) Render particles to render target A (only Brightness value)
3) Multiply backbuffer and brightness into render target B
4) Vertical Blur on RT B
5) Horizontal Blur on RT B
6) Add RT B to backbuffer
Tubos
Quote:Original post by jollyjeffersI see. I'm doing it like this:Quote:Original post by TubosDo you specifically need destination alpha? If not then this may not be as big a limitation as you think.
However, I can't do this since the spark texture has transparency - therefore, alpha blending is necessary.
PS_OUTPUT RenderScenePS(VS_OUTPUT In, float2 texcoord: TEXCOORD0 ) { PS_OUTPUT Output; Output.Color=tex2D(MeshTextureSampler, texcoord)*In.Diffuse; return Output;}// States:AlphaBlendEnable=true;SrcBlend = One;DestBlend = InvSrcAlpha;
and this is my texture (photoshop screenshot so you can see the alpha channel):This is the desired result (the orange background is just for testing ;-) )
Destination alpha is necessary here - unless there is another way of achieving a similar result?
Quote:RGBE formats - integer exponent formats still make use of the destination alpha channel, so you've the same point at before - it may or may not matter.Using RGB16 would be possible, I guess?
And when doing multipass, would the steps look like this?
1) Render particles to backbuffer (only Color)
2) Render particles to render target A (only Brightness value)
3) Multiply backbuffer and brightness into render target B
4) Vertical Blur on RT B
5) Horizontal Blur on RT B
6) Add RT B to backbuffer
Tubos
Quote:Destination alpha is necessary here - unless there is another way of achieving a similar result?You've got the correct method as far as I can tell. Maybe you could hack something in using different states, but chances of getting it identical are slim.
Quote:Using RGB16 would be possible, I guess?Well thats still a traditional 4-component format, so not sure how you think it'd help - its just got some extra precision [smile]
Quote:And when doing multipass, would the steps look like this?Almost, but not quite!
1) Render particles to backbuffer (only Color)
2) Render particles to render target A (only Brightness value)
3) Multiply backbuffer and brightness into render target B
4) Vertical Blur on RT B
5) Horizontal Blur on RT B
6) Add RT B to backbuffer
1) Render particles (+colour+blending) to the backbuffer as usual
2) Render particle brightness to render target A with appropriate blending and depth testing against existing scene
3) Render contents of target A to target B with horizontal blurring
4) Render contents of target B to target A with vertical blurring
5) Add render target A to backbuffer.
You can get some pretty cool variations by altering (3) and (4) - more passes or different weightings for example.
Also, for (5) you might want to consider a tone-mapping operator to avoid getting excessive saturation.
hth
Jack
Quote:Well RGB16 is still a traditional 4-component format, so not sure how you think it'd help - its just got some extra precisionThere's this HDRFormats DirectX SDK sample, in which the 16bit of each RGB16 component are mapped to a float from 0-100. That means, HDR without real floating point texture and the alpha channel remains unused. The brightness could be stored in the colors.
But I think, I'll try the multipass approach first as it seems to be more flexible.
Quote:1) Render particles (+colour+blending) to the backbuffer as usualYou mean something like this?
2) Render particle brightness to render target A with appropriate blending and depth testing against existing scene
1) output.color = texture * input.color
2) output.color = texture * input.color * input.brightness
That would allow to draw particles which have the same color, but a different amount of glow. Exactly what I'd like to have.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement