Well, a "SetRenderTarget component" is surely a godsent one ^^ but well, I'm just speaking about the blur here. We need a efficent and small sized blur, this is the fastest way we can get it! (and that's for sure! ^^)
So... uhm... let's just say that this would be a nice "under the hood" possible change. In no way wa are eliminating the blur component so try to get it working at his best!
And I think we can't recycle so much code once we get the SetRenderTarget component so we can go with this new blur right now ^^
Blur component "refresh"
Moderator: Moderators
Yes, that article is a nice find! I tried something similar to this a while a go but did not have good reference material so I never got it to work. We'll try this and see if it works ok. I can make an attempt later this week.
Kjell, it sounds like an interesting idea. We could have several low-level (as in close to the gpu) components such as SetRenderTarget and then they could be combined to userfriendly high-level components like Blur (perhaps using your blackbox idea). But as Kattle mentions this idea requires more thought before it can be realized. If you want to, please start a new thread outlining your idea a bit more and so we can discuss it further.
Kjell, it sounds like an interesting idea. We could have several low-level (as in close to the gpu) components such as SetRenderTarget and then they could be combined to userfriendly high-level components like Blur (perhaps using your blackbox idea). But as Kattle mentions this idea requires more thought before it can be realized. If you want to, please start a new thread outlining your idea a bit more and so we can discuss it further.
-
jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
That's exactly what Kjell was talking about. Infact... we "hardcode" the render to texture to obtain this effect, but make the rendering not available to the end user. We will surely find a way to get a decent "RenderTo" component in the "near" future, that's for sure ^^
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
I found some other REALLY interesting stuff...
http://www.opengl.org/sdk/docs/man/xhtm ... lter2D.xml
and
http://www.java-tips.org/other-api-tips ... -an-2.html
By using a convolution filter I am pretty sure we can do lots of stuff, and if using it does not require additional code (we must enable the imaging extension, I'm not sure about what this implies!), we can get the following components:
-blur
-sharpen
-(probably) normals
-(probably) light
with really little code size.
The convolution filter is not HW accelerated, but if it tiles good, well, it will probably be faster then any algorithm we can write ^^ or at least I hope so
http://www.opengl.org/sdk/docs/man/xhtm ... lter2D.xml
and
http://www.java-tips.org/other-api-tips ... -an-2.html
By using a convolution filter I am pretty sure we can do lots of stuff, and if using it does not require additional code (we must enable the imaging extension, I'm not sure about what this implies!), we can get the following components:
-blur
-sharpen
-(probably) normals
-(probably) light
with really little code size.
The convolution filter is not HW accelerated, but if it tiles good, well, it will probably be faster then any algorithm we can write ^^ or at least I hope so
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
I've updated the beta today with an experimental implementation of the GPU-filter based blur.
The new component is called BitmapBlurGPU_Test to signify that it is a temporary test. It has a Passes property, as well as a Radius.
The blur works by drawing the image on top of each other with slightly modified texture coordinates and alpha. This will cause a blur effect thanks to bilinear filtering. Then the image is copied back into texture memory for another pass. The radius-property is not really radius, instead it controls the displacement for the texture coordinates. Default is 0.5 that corresponds to half a pixel.
The benefits:
- it is ridiculously fast compared to the software based BitmapBlur-component
The cons:
- it is not as versatile and general as BitmapBlur. For instance we can't have the nice properties for Direction and Amplify (so the posterize effect won't work). Also Radius works differently.
- it does not work well with BitmapPixels because of the differences listed above
So unless we can find tricks to make this new component as good as the old one my suggestion is that we stick with the software based approach.
The convolution-approach might lead somewhere too so we need to investigate that further. I'm not sure what a convolution filter is actually, isn't it just a kind of multiply loop that we can implement ourselves? Because if it is in software anyway then we can keep it inside the engine to make sure we are compatible with low-end integrated GPUs.
Two other changes to the new beta:
- BitmapBlur now twice as fast (on my computer) at the cost of slightly larger code size
- BitmapPixels now set alpha values of the pixels it lights up. Previously the whole bitmap had alpha zero.
The new component is called BitmapBlurGPU_Test to signify that it is a temporary test. It has a Passes property, as well as a Radius.
The blur works by drawing the image on top of each other with slightly modified texture coordinates and alpha. This will cause a blur effect thanks to bilinear filtering. Then the image is copied back into texture memory for another pass. The radius-property is not really radius, instead it controls the displacement for the texture coordinates. Default is 0.5 that corresponds to half a pixel.
The benefits:
- it is ridiculously fast compared to the software based BitmapBlur-component
The cons:
- it is not as versatile and general as BitmapBlur. For instance we can't have the nice properties for Direction and Amplify (so the posterize effect won't work). Also Radius works differently.
- it does not work well with BitmapPixels because of the differences listed above
So unless we can find tricks to make this new component as good as the old one my suggestion is that we stick with the software based approach.
The convolution-approach might lead somewhere too so we need to investigate that further. I'm not sure what a convolution filter is actually, isn't it just a kind of multiply loop that we can implement ourselves? Because if it is in software anyway then we can keep it inside the engine to make sure we are compatible with low-end integrated GPUs.
Two other changes to the new beta:
- BitmapBlur now twice as fast (on my computer) at the cost of slightly larger code size
- BitmapPixels now set alpha values of the pixels it lights up. Previously the whole bitmap had alpha zero.
Yes the convolution is something we can code, too. But actually I think that since it's not HW accelerated it should be compatible "by default" with every video card ^^ Just wanting to try out this possibility to save a "convolute" function space. The point is that convolution like I would code it is also as slow as the current blur ^^. So maybe they got it optimized saving us a little work!
BTW: whoa... deleting the "InAdd" halfed the computational time???!!?!?!?!?
That's just great. I can remember I wrote in C a little program for analyzing some character sequences... I do remember that using the "inline" optimization halved the comp time there, too! ^^
BTW: whoa... deleting the "InAdd" halfed the computational time???!!?!?!?!?
That's just great. I can remember I wrote in C a little program for analyzing some character sequences... I do remember that using the "inline" optimization halved the comp time there, too! ^^
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
Some code about convolution. This is probably the last material one could need to undertand this really well.
This example is about a really simple convolution. It achieved a decent speed: "convolution with 256x256 image and 5x5 Gaussian filter: 3.2 ms" (code optimized & grayscale). It is almost equivalent to a 5-radius 3-pass blur made in our ZGE (that tooks 400 ms!).
http://www.songho.ca/dsp/convolution/convolution.html
Here's some other stuff for what concerns the OpenGL implementation... Actually, we might came up with some limitations. We will have to test some stuff on different machines (EG: we will probably find some limits for the max blur!)
http://www.opengl.org/resources/code/sa ... de151.html
and there's a follow up with some standard (and really common) convolution filters. Actually, the convolution might be nice if we are able to get it fast enough.
This example is about a really simple convolution. It achieved a decent speed: "convolution with 256x256 image and 5x5 Gaussian filter: 3.2 ms" (code optimized & grayscale). It is almost equivalent to a 5-radius 3-pass blur made in our ZGE (that tooks 400 ms!).
http://www.songho.ca/dsp/convolution/convolution.html
Here's some other stuff for what concerns the OpenGL implementation... Actually, we might came up with some limitations. We will have to test some stuff on different machines (EG: we will probably find some limits for the max blur!)
http://www.opengl.org/resources/code/sa ... de151.html
and there's a follow up with some standard (and really common) convolution filters. Actually, the convolution might be nice if we are able to get it fast enough.
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
I got OpenGL convolution working but found a problem, it seems it cannot be made to tile:
http://www.opengl.org/sdk/docs/man/xhtm ... ameter.xml
The GL_CONVOLUTION_BORDER_MODE-parameter controls how pixels outside the image are handled and there is no wrap-mode.
I guess that's dead end for built-in convolution then unless there is some trick I've missed.
Let's review our options for the blur-component:
- stick with the current software blur and try to optimize it further
- use our own software convolution
- use shader when available, otherwise use software fallback
- ?
http://www.opengl.org/sdk/docs/man/xhtm ... ameter.xml
The GL_CONVOLUTION_BORDER_MODE-parameter controls how pixels outside the image are handled and there is no wrap-mode.
I guess that's dead end for built-in convolution then unless there is some trick I've missed.
Let's review our options for the blur-component:
- stick with the current software blur and try to optimize it further
- use our own software convolution
- use shader when available, otherwise use software fallback
- ?
Ouch... didn't noticed that... Well, we got some options now:
-Trick the whole to get a new image produced with increased tileing borders by the use of some fancy stuff like RenderToTexture... Not sure about this one however, seems a really "dirt" approach.
-Build our own convolution. What I wanted to ask to you Ville is: how much faster is a loop through a fixed-size array in respect to a dynamic one? Because one trick (maybe we can even use this to speed up the blur a little) is making some calculus after having copied the image into a fixed-size array. I have thought about this but we might have some chanses. Now I'm going back to studying for my exam tomorrow!!! However, don't bother yourself more on the convolution. I'm the math guy so I'm gonna build something this weekend
Bye bye!!!
EDIT: one information I need... have you tried convoluting a (let's say) 512x512 image with a decent-sized convolution matrix? (EG: 5x5)
I'm really curious on the performance. This would easily tell us what's the best we can do using convolution.
-Trick the whole to get a new image produced with increased tileing borders by the use of some fancy stuff like RenderToTexture... Not sure about this one however, seems a really "dirt" approach.
-Build our own convolution. What I wanted to ask to you Ville is: how much faster is a loop through a fixed-size array in respect to a dynamic one? Because one trick (maybe we can even use this to speed up the blur a little) is making some calculus after having copied the image into a fixed-size array. I have thought about this but we might have some chanses. Now I'm going back to studying for my exam tomorrow!!! However, don't bother yourself more on the convolution. I'm the math guy so I'm gonna build something this weekend
Bye bye!!!
EDIT: one information I need... have you tried convoluting a (let's say) 512x512 image with a decent-sized convolution matrix? (EG: 5x5)
I'm really curious on the performance. This would easily tell us what's the best we can do using convolution.
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
Ok guys... This is serious ^^
I've managed to get convolution working at a decent speed (the code for the convolution is based on the latest software blur-code!).
pros:
-the simplest possible blur (1 radius, 1 passes) is now only a little slower. Every other combination is faster.
-now the time needed for a blur is independent on the "passes" variable: straight filtering ("1") now takes the same time of Gaussian ("3"). Actually, the results are a little bit different from the old "passes" settings since with the new implementation you need to set a higher radius.
-the computational time is linear and not quadratical with the radius setting. This means you can get pretty hight with the radius without sinking your CPU any more
This was possible even with optimization to the old blur code but I made this modification while adding the convolution code.
cons:
-I should remove the "4 passes" option unless I found any way to get something like that one. Can I?
-Code-size increased, dunno how much but hopefully nothing dramatic.
Open questions:
I can use this opportunity to get another meaning for the value "passes", EG a different way to blur the image, example attached. I see it being more usefull... You should decide
I've managed to get convolution working at a decent speed (the code for the convolution is based on the latest software blur-code!).
pros:
-the simplest possible blur (1 radius, 1 passes) is now only a little slower. Every other combination is faster.
-now the time needed for a blur is independent on the "passes" variable: straight filtering ("1") now takes the same time of Gaussian ("3"). Actually, the results are a little bit different from the old "passes" settings since with the new implementation you need to set a higher radius.
-the computational time is linear and not quadratical with the radius setting. This means you can get pretty hight with the radius without sinking your CPU any more
This was possible even with optimization to the old blur code but I made this modification while adding the convolution code.cons:
-I should remove the "4 passes" option unless I found any way to get something like that one. Can I?
-Code-size increased, dunno how much but hopefully nothing dramatic.
Open questions:
I can use this opportunity to get another meaning for the value "passes", EG a different way to blur the image, example attached. I see it being more usefull... You should decide
- Attachments
-
- StripBlur.png (15.02 KiB) Viewed 28222 times
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
-
jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
humm that looks interesting,. so this will replace the old blur? if it is faster and can achive the same results,. then I am all for it. can you get any more interesting effects using this? (degrade, edge, ect.) the strips blur is interesteing too but I am not just sure what it is doing,. would have to test it out to know i guess. I will see if it all works out and gets put in the beta,. .
random link; http://www.student.kuleuven.be/~m021692 ... onvolution
random link; http://www.student.kuleuven.be/~m021692 ... onvolution
iterationGAMES.com