texture conundrum

There could be a number of things here. try turning off depth testing. Maybe blend_mode 6 1 (additive blending) will work. Also, if you have a recent beta version of jitter, you could use jit.gl.sketch with the glalphafunc OpenGL command to have transparent pixels discarded. Alternatively, you could make a simple shader that discards fragments below a certain alpha threshold.

wes

On 4/10/07, Andreas Wetterberg wrote: > Hi, > > I am having some weird problems using jit.gl.texture on > jit.gl.gridshape. Basically the transparency is really wonky. I'd > appreciate it if some of you genii could have a look at my little > screenshot plus explanation here and let me know what I am doing wrong! > http://www.flickr.com/photos/18877453@N00/454570427/?#comment72157600062628167 > > Thanks! > Andreas. >

Wesley Smith skrev: > There could be a number of things here. try turning off depth > testing. I'm sorry, I have been unable to do that - it doesn't appear as an arg for any of the objects in the hit.gl.texture helpfile...? I already tried @depth_enable 0, which doesn't work either. > Maybe blend_mode 6 1 (additive blending) will work. Unfortunately that was the first thing I tried. > Also, > if you have a recent beta version of jitter, you could use > jit.gl.sketch with the glalphafunc OpenGL command to have transparent > pixels discarded. As much as I like jit.gl.sketch I really needed matrixoutput for this patch, so jit.gl.sketch is a no-go for me, right? > Alternatively, you could make a simple shader that > discards fragments below a certain alpha threshold. I've been meaning to getting into shaders for a while, but aren't custom shaders slightly overkill in order to get the jit.gl.texture helpfile to work for me? What I am also really wondering is why the problem worsens when you turn up the dim count for gridshape?

Thanks for your feedback here! Andreas.

>From your images, it's difficult to tell what's happening. Clearly you should be able to get the effect you want, but as you have found out OpenGL has many pitfalls so without a patch I can't say any more. Post one and I'll gladly take a look.

best, wes

Wesley Smith skrev: >> From your images, it's difficult to tell what's happening. Clearly > you should be able to get the effect you want, but as you have found > out OpenGL has many pitfalls so without a patch I can't say any more. > Post one and I'll gladly take a look. Please refer to my response to Hubert on this (for some reason it went off-list?!?:

Hi Hubert, the patch is pretty straightforward: Load any picture with transparency into the jit.gl.texture helpfile, set it to something like "opencylinder" and rotate it around to see the buggy (?) behaviour. The dim was left untouched - I just checked the default dim of gridshape and it's [20 20] - and if you try tweaking the dim while a texture is loaded you'll notice that the problem worsens with each additional dim: for the middle example you get an extra horizontal line per dim?!? xp, latest maxMSP, Jitter 1.6.3b2

Cheers. Andreas.

The behavior is not buggy. That's just how OpenGL works. Transparent pixels still contribute to the depth buffer and will thus block geometry behind them if things aren't rendered in back to front order. This is what you're seeing. As I suggested earlier, if you turn off depth testing (depth_enable 0) the back face is no longer blocked.

wes

On 4/11/07, Andreas Wetterberg wrote: > Wesley Smith skrev: > >> From your images, it's difficult to tell what's happening. Clearly > > you should be able to get the effect you want, but as you have found > > out OpenGL has many pitfalls so without a patch I can't say any more. > > Post one and I'll gladly take a look. > Please refer to my response to Hubert on this (for some reason it went > off-list?!?: > > Hi Hubert, > the patch is pretty straightforward: Load any picture with transparency > into the jit.gl.texture helpfile, set it to something like > "opencylinder" and rotate it around to see the buggy (?) behaviour. > The dim was left untouched - I just checked the default dim of gridshape > and it's [20 20] - and if you try tweaking the dim while a texture is > loaded you'll notice that the problem worsens with each additional dim: > for the middle example you get an extra horizontal line per dim?!? > xp, latest maxMSP, Jitter 1.6.3b2 > > Cheers. > Andreas. > >

Wesley Smith skrev: > The behavior is not buggy. That's just how OpenGL works. Transparent > pixels still contribute to the depth buffer and will thus block > geometry behind them if things aren't rendered in back to front order. > This is what you're seeing. As I suggested earlier, if you turn off > depth testing (depth_enable 0) the back face is no longer blocked. >

thanks for the explanation. I definitely needed that :-) I must say I am kind of bummed, though. So the only way to both get depth_enable 1 AND not have those streaks will be to actually map the texture onto a 2d surface that follows the opaque content of the texture? Got it. Thanks!

Andreas.

> thanks for the explanation. I definitely needed that :-) > I must say I am kind of bummed, though. So the only way to both get > depth_enable 1 AND not have those streaks will be to actually map the > texture onto a 2d surface that follows the opaque content of the > texture?

Not quite, but you have to do more work! You can use glalphafunc or a custom shader to get the effect you want with depth testing enabled. It's easier than you might think.

wes

Wesley Smith skrev: >> thanks for the explanation. I definitely needed that :-) >> I must say I am kind of bummed, though. So the only way to both get >> depth_enable 1 AND not have those streaks will be to actually map the >> texture onto a 2d surface that follows the opaque content of the >> texture? > Not quite, but you have to do more work! ;) > You can use glalphafunc or a > custom shader to get the effect you want with depth testing enabled. > It's easier than you might think. You've convinced me, Wes - eloquent as usual! I'll give it my best shot once the rest of the patch comes together.

Cheers, Andreas.

Here's a demo patch with some shaders that allow depth testing to be on but don't block what's behind. Take a look at them and you'll see how straightforward this kind of thing is.

Here's the link: http://www.mat.ucsb.edu/~whsmith/DepthTransparent.zip

wes

On 4/11/07, Andreas Wetterberg wrote: > Wesley Smith skrev: > >> thanks for the explanation. I definitely needed that :-) > >> I must say I am kind of bummed, though. So the only way to both get > >> depth_enable 1 AND not have those streaks will be to actually map the > >> texture onto a 2d surface that follows the opaque content of the > >> texture? > > Not quite, but you have to do more work! > ;) > > You can use glalphafunc or a > > custom shader to get the effect you want with depth testing enabled. > > It's easier than you might think. > You've convinced me, Wes - eloquent as usual! > I'll give it my best shot once the rest of the patch comes together. > > Cheers, > Andreas. >

Brilliant, Wes! You're the man. And you weren't kidding about the simplicity, were you! :)

Andreas

Wesley Smith skrev: > Here's a demo patch with some shaders that allow depth testing to be > on but don't block what's behind. Take a look at them and you'll see > how straightforward this kind of thing is. > > Here's the link: > http://www.mat.ucsb.edu/~whsmith/DepthTransparent.zip > > wes > > On 4/11/07, Andreas Wetterberg wrote: >> Wesley Smith skrev: >> >> thanks for the explanation. I definitely needed that :-) >> >> I must say I am kind of bummed, though. So the only way to both get >> >> depth_enable 1 AND not have those streaks will be to actually map the >> >> texture onto a 2d surface that follows the opaque content of the >> >> texture? >> > Not quite, but you have to do more work! >> ;) >> > You can use glalphafunc or a >> > custom shader to get the effect you want with depth testing enabled. >> > It's easier than you might think. >> You've convinced me, Wes - eloquent as usual! >> I'll give it my best shot once the rest of the patch comes together. >> >> Cheers, >> Andreas. >> > > . >