I'd like to make a pixel shader for post processing that draws a glow around white pixels.
I've looked on google for both how to use the shader language or how to make a glow effect but I didn't find any explanation.
If you know, could you please post the steps used (and possibly the code to do that since I don't have any idea) to achieve the effect?
The effect I'm looking for is this:
(photoshopped)
[img]http://dl.dropbox.com/u/2951174/GameOfLife/glow.jpg[/img]
Since you're making everything glow, you should render to a texture, copy that texture, blur it, then render them both with the glow texture using blending. A more compilcated approach is listed in [url=http://www.gamasutra.com/view/feature/2107/realtime_glow.php?page=1]this[/url] article, though it's for DirectX.
As far as the SFML & GLSL implementation goes, I've found a few bits of documentation regarding this. The Renderer has a SetShader function which takes one [url=http://www.sfml-dev.org/documentation/2.0/classsf_1_1Shader.htm]Shader[/url] as an argument. The Shader has both LoadFromFile and LoadFromMemory functions, as well as all the required parameter functions.
According to that page, the best method is to "draw everything directly to the main target, then use sf::Image::CopyScreen to copy its contents to an image and draw it to the main target using the shader."
If you do manage to do this please make a guide for dummies
[QUOTE=Metroid48;26488344]Since you're making everything glow, you should render to a texture, copy that texture, blur it, then render them both with the glow texture using blending. A more compilcated approach is listed in [url=http://www.gamasutra.com/view/feature/2107/realtime_glow.php?page=1]this[/url] article, though it's for DirectX.
As far as the SFML & GLSL implementation goes, I've found a few bits of documentation regarding this. The Renderer has a SetShader function which takes one [url=http://www.sfml-dev.org/documentation/2.0/classsf_1_1Shader.htm]Shader[/url] as an argument. The Shader has both LoadFromFile and LoadFromMemory functions, as well as all the required parameter functions.
According to that page, the best method is to "draw everything directly to the main target, then use sf::Image::CopyScreen to copy its contents to an image and draw it to the main target using the shader."[/QUOTE]
God that sounds so hard I don't even know if it's worth it anymore.
[QUOTE=TerabyteS;26493144]God that sounds so hard I don't even know if it's worth it anymore.[/QUOTE]
On further research, I don't think you can do this while using version 1.6 of SFML. Apparently there's no functionality to render to textures. Sorry!
The actual steps aren't that hard and, once version 2.0 comes out, they'd look something like this:
[list=][*]Disable depth testing
[*]Render the cells to the first texture
[*]Render to the second texture a full-screen quad, textured with the first texture, using a horizontal blur shader
[*]Render to the screen a full-screen quad, textured with the first texture. The shader used should blur the second texture vertically and blend the result with the first texture
[/list]
[QUOTE=TerabyteS;26493144]God that sounds so hard I don't even know if it's worth it anymore.[/QUOTE]
:what:
[QUOTE=TerabyteS;26493144]God that sounds so hard I don't even know if it's worth it anymore.[/QUOTE]
Programming
Takes
Time
[QUOTE=Metroid48;26493614]On further research, I don't think you can do this while using version 1.6 of SFML. Apparently there's no functionality to render to textures. Sorry!
The actual steps aren't that hard and, once version 2.0 comes out, they'd look something like this:
[list=][*]Disable depth testing
[*]Render the cells to the first texture
[*]Render to the second texture a full-screen quad, textured with the first texture, using a horizontal blur shader
[*]Render to the screen a full-screen quad, textured with the first texture. The shader used should blur the second texture vertically and blend the result with the first texture
[/list][/QUOTE]
Yea the theory is extremely simple I think, its doing it thats going to be hard.
Also do you know if this is available with the current build of SFML 2.0?
[QUOTE=Richy19;26494323]Yea the theory is extremely simple I think, its doing it thats going to be hard.
Also do you know if this is available with the current build of SFML 2.0?[/QUOTE]
I've never used SFML, but there is documentation available for [url=http://www.sfml-dev.org/documentation/2.0/classsf_1_1RenderImage.htm]RenderImage[/url].
Also, I was just thinking about it and there is a way that this could be approximated with 1.6. You could draw a fullscreen quad and pass it a texture containing every cell status. Then the shader could determine which cell the current pixel fits in and (if empty) do an addition of the linear blur from each adjacent cell. It would only work if the cells were all squares and the blur never exceeded one cell's width, but with those assumptions it wouldn't be [i]too[/i] hard to get working.
Shaders are 2.0 only. 1.6 uses this horrible ScreenEffects or some shit. You can find a SVN dump of the new revision of 2 on the website, gonna have to compile it yourself though.
Shaders work well on SFML 2.0, as does RenderImage.
Just to confirm :)
If you're just doing a blur, it's easily possible in 1.6. Just apply two PostFX sequentially. SFML 1.6 PostFx are in GLSL, just formatted slightly differently.
[url]http://www.sfml-dev.org/tutorials/1.6/graphics-postfx.php[/url]
[QUOTE=BMCHa;26509026]If you're just doing a blur, it's easily possible in 1.6. Just apply two PostFX sequentially. SFML 1.6 PostFx are in GLSL, just formatted slightly differently.
[url]http://www.sfml-dev.org/tutorials/1.6/graphics-postfx.php[/url][/QUOTE]
From the glsl script, how do I access the position of current pixel, or color of nearby pixels?
[QUOTE=BMCHa;26509026]If you're just doing a blur, it's easily possible in 1.6. Just apply two PostFX sequentially. SFML 1.6 PostFx are in GLSL, just formatted slightly differently.
[url]http://www.sfml-dev.org/tutorials/1.6/graphics-postfx.php[/url][/QUOTE]
Oh hey, I didn't know they had shader functionality specific to the whole screen! That would definitely work.
[QUOTE=TerabyteS;26514662]From the glsl script, how do I access the position of current pixel, or color of nearby pixels?[/QUOTE]
The current pixel is given as the variable _in, a vec2. You should be able to add vectors to it when retrieving pixels from the framebuffer (see their example) to get adjacent pixels. To determine how much to add, you should probably pass the shader a parameter with screen dimensions, since texture coordinates are in the [0,1] range.
So, just run it through two PostFXs, one that blurs horizontally, one vertically. See s0ul0r's link for code you can adapt for that.
[QUOTE=Metroid48;26515470]Oh hey, I didn't know they had shader functionality specific to the whole screen! That would definitely work.
The current pixel is given as the variable _in, a vec2. You should be able to add vectors to it when retrieving pixels from the framebuffer (see their example) to get adjacent pixels. To determine how much to add, you should probably pass the shader a parameter with screen dimensions, since texture coordinates are in the [0,1] range.
So, just run it through two PostFXs, one that blurs horizontally, one vertically. See s0ul0r's link for code you can adapt for that.[/QUOTE]
Doesnt _in contain the color of the pixel? I'd like to be able to access another pixel's position and set its color. Anyway since the shader code is run for every pixel, that could be problematic and I could end up with glow on the whole screen
Which is why you'd only apply the glow based on the luminosity of the pixel you're currently on. Therefore dark colours will have very little or no glow
[QUOTE=TerabyteS;26525604]Doesnt _in contain the color of the pixel? I'd like to be able to access another pixel's position and set its color. Anyway since the shader code is run for every pixel, that could be problematic and I could end up with glow on the whole screen[/QUOTE]
Well, as it was said, you first have to render the scene without this shader to a texture, then do a second render-pass with this shader in which you can access said texture to read neighbor pixels.
[QUOTE=TerabyteS;26525604]Doesnt _in contain the color of the pixel? I'd like to be able to access another pixel's position and set its color. Anyway since the shader code is run for every pixel, that could be problematic and I could end up with glow on the whole screen[/QUOTE]
No, _in is the coordinate. framebuffer(_in) is the colour of the current pixel. To get adjacent pixels, define a vec2 that contains the cell dimensions in screenspace (divide by the screen dimensions) then do something like framebuffer(_in + cellSize * vec2(1,0)) for the pixel to the right.
You can't set the colour of another pixel - fragment shaders only let you output the current pixel's colour. Also, there's no issue about glow on the whole screen since the only things that can glow are the cells. If your game got more visually complicated then you could use an alpha value to mask the image during the first glow pass.
[QUOTE=Metroid48;26530839]No, _in is the coordinate. framebuffer(_in) is the colour of the current pixel. To get adjacent pixels, define a vec2 that contains the cell dimensions in screenspace (divide by the screen dimensions) then do something like framebuffer(_in + cellSize * vec2(1,0)) for the pixel to the right.
You can't set the colour of another pixel - fragment shaders only let you output the current pixel's colour. Also, there's no issue about glow on the whole screen since the only things that can glow are the cells. If your game got more visually complicated then you could use an alpha value to mask the image during the first glow pass.[/QUOTE]
I think I got it, I'll try soon. Thanks.
Sorry, you need to Log In to post a reply to this thread.
