Jump to content
  • Advertisement
Sign in to follow this  
Tubos

Glow Postprocessing

This topic is 4100 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Tubos
* One method is presented at Gamasutra
I can't read that as I'm not a subscriber. I had login details once, but I tend to lose such things.

Quote:
Original post by Tubos
However, I can't do this since the spark texture has transparency - therefore, alpha blending is necessary.
Do you specifically need destination alpha? If not then this may not be as big a limitation as you think.

Quote:
Original post by Tubos
* 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.
Sounds like overkill to me.

Quote:
Original post by Tubos
* Would HDR with integer (as demonstrated in the HDRFormats SDK Sample) be a good solution for this particular situation?
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.

Quote:
Original post by Tubos
I've read a lot of information about postprocessing, but I'm still unsure what to do and would be thankful for any advice.
Have you played with the 'PostProcess' sample in the DirectX SDK? Might be a source of ideas.

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

Share this post


Link to post
Share on other sites
Thank you for your helpful answers!

Quote:
Original post by jollyjeffers
Quote:
Original post by Tubos
However, I can't do this since the spark texture has transparency - therefore, alpha blending is necessary.
Do you specifically need destination alpha? If not then this may not be as big a limitation as you think.
I see. I'm doing it like this:
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):
Image Hosted by ImageShack.us
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

Share this post


Link to post
Share on other sites
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?
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
Almost, but not quite!

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

Share this post


Link to post
Share on other sites
Quote:
Well RGB16 is still a traditional 4-component format, so not sure how you think it'd help - its just got some extra precision
There'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 usual
2) Render particle brightness to render target A with appropriate blending and depth testing against existing scene
You mean something like this?
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.

Share this post


Link to post
Share on other sites
I've implemented the multi-pass steps, which was not too difficult, and the result looks great.

Thank you very much for your help!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!