blurring individual jit.gl.gridshape
am working on a project which requires blurring of shapes whilst remaining in opengl. the current patch i'm working on uses multiple instances of jit.gl.gridshape to draw planes. Some of them will be drawn with hard edges, others need to have soft edges - like a kind of blurring effect.
the difficult part is making the soft edged planes - i'm thinking of using a texture (128x128 / 256x256 pixels) with a circular black and white gradient - white circle in the middle, fading out to black on the edges. ok it might not look that smooth at that resolution, but it should be good enough.
using the alpha colour attribute, with blend_enable, and blend_modes (probably needs to be additive) i think i should be able to get close to a soft edged square...
does anyone have any experience of this kind of effect in opengl?
is my current thinking along the right lines, or would i be better off using a shader function...
any suggestions welcome!
will post a patch shortly to illustrate the idea...
thanks, justin
This sounds like a typical job for a pixelshader.
pixel shader, i presume u mean a shader program for jit.gl.shader?
i'm a noob in the shader department, do you know of any existing patch i could take a look at...
i have looked at the blur "cf.blur.jxs-help" patch which seems like a good starting point, altho it uses jit.gl.slab which is probably not necessary for me (swap it for jit.gl.shader). have to admit, i feel a bit overwhelmed by the shader / slab part of jitter!
great potential and scope, but the learning curve seems quite steep... sigh.
that will work.
512x512 works better, but you will get a decent effect with your method.
cheers
evan
On Jan 10, 2007, at 3:06 PM, justin wrote:
>
> am working on a project which requires blurring of shapes whilst
> remaining in opengl. the current patch i'm working on uses multiple
> instances of jit.gl.gridshape to draw planes. Some of them will be
> drawn with hard edges, others need to have soft edges - like a kind
> of blurring effect.
>
> the difficult part is making the soft edged planes - i'm thinking
> of using a texture (128x128 / 256x256 pixels) with a circular black
> and white gradient - white circle in the middle, fading out to
> black on the edges. ok it might not look that smooth at that
> resolution, but it should be good enough.
>
> using the alpha colour attribute, with blend_enable, and
> blend_modes (probably needs to be additive) i think i should be
> able to get close to a soft edged square...
>
> does anyone have any experience of this kind of effect in opengl?
> is my current thinking along the right lines, or would i be better
> off using a shader function...
>
> any suggestions welcome!
>
> will post a patch shortly to illustrate the idea...
>
> thanks, justin
To blur something you need access to a neighborhood of pixels that you
smear together. Running a shader on a gridshape won't give you access
to neightboring pixels. Instead, you need a texture that you can
operate on as you realized the slab objects do. So, to blur a
girdshape, you first need to render it to texture using @capture
tex_name and then send this texture through a videoplane or other
planar geometry and run a shader on that or alternatively run the
texture through a slab.
wes
On 1/10/07, justin wrote:
>
> pixel shader, i presume u mean a shader program for jit.gl.shader?
>
> i'm a noob in the shader department, do you know of any existing patch i could take a look at...
>
> i have looked at the blur "cf.blur.jxs-help" patch which seems like a good starting point, altho it uses jit.gl.slab which is probably not necessary for me (swap it for jit.gl.shader). have to admit, i feel a bit overwhelmed by the shader / slab part of jitter!
>
> great potential and scope, but the learning curve seems quite steep... sigh.
>
thanks for replies everyone, help much appreciated.
wes, i understand what u mean about the neighbouring pixels for the blur fx.
my current idea is similar but without having to capture the gridshape as a texture. instead i was thinking of using something like jit.lcd to draw a square (plane) or circle which is smaller than a 128x128 > 512x512 char matrix, leaving pixel border for the blur to bleed.
then send this char matrix to jit.gl.shader with a blur shader > then onto jit.gl.gridshape as a shader.
the reason for this is that i will most likely have several instances of jit.gl.gridshape on screen at once, and each instance needs to have its own blurring fx parameters...
am i right in thinking that capturing jit.gl.render as texture would make all gridshapes go thru the same blur fx?
thanks,
justin
An alternative to using fragment shaders is you use additive blending.
You could draw several instances of one of your gridshapes on top of
each other with slight offsets and different alpha values. This can
create a blur effect, but will require some experimentation. If you
do go this route, there are some performance considerations. Don't
use the gridshape's draw() method, which is how drawing is done by
default. Instead, use jit.gl.sketch or jit.gl.multiple to setup
things like blend_enable, depth_enable, lighting, etc. and then draw
the geometry with the drawraw() method. This will be quite a bit
faster.
wes
On 1/10/07, justin wrote:
>
> thanks for replies everyone, help much appreciated.
>
> wes, i understand what u mean about the neighbouring pixels for the blur fx.
>
> my current idea is similar but without having to capture the gridshape as a texture. instead i was thinking of using something like jit.lcd to draw a square (plane) or circle which is smaller than a 128x128 > 512x512 char matrix, leaving pixel border for the blur to bleed.
>
> then send this char matrix to jit.gl.shader with a blur shader > then onto jit.gl.gridshape as a shader.
>
> the reason for this is that i will most likely have several instances of jit.gl.gridshape on screen at once, and each instance needs to have its own blurring fx parameters...
>
> am i right in thinking that capturing jit.gl.render as texture would make all gridshapes go thru the same blur fx?
>
> thanks,
>
> justin
>
This is more than a decade later, but it may help others.
From Rob mostly.