liubo

i am trying to use jit.multiple with a set of planes textured with png files with transparency. i am having what seems to be a depth sorting problem as sometimes the transparency works and sometimes not. since there are many 'particles' moving around a lot, doing depth sorting myself does not look promising.

i am attaching a patch which needs a png texture that can be found in the attached archive. there is also a screengrab illustrating the problem. any ideas of how to go about rendering this properly would be greatly appreciated.

moreover, it seems that the depth sorting behavior of jitter is inconsistent, e.g. turning fsaa on and off leads to different results regarding which transparency planes are rendered properly.

my system is mbp core 2 duo, maxmsp 4.6.3 / jitter 1.6.3

p.s. if there are problems with the attachment, it can be downloaded at 

---------------------------------------------------------

i am trying to use jit.multiple with a set of planes textured with png files with transparency. i am having what seems to be a depth sorting problem as sometimes the transparency works and sometimes not. since there are many 'particles' moving around a lot, doing depth sorting myself does not look promising. 

i am attaching a patch which needs a png texture that can be found in the attached archive. there is also a screengrab illustrating the problem. any ideas of how to go about rendering this properly would be greatly appreciated. 

p.s. if there are problems with the attachment, it can be downloaded at http://2rem.net/depthproblem.zip
---------------------------------------------------------

depth-sorting-transparency-jit-multiple-issue

There is no depth sorting in Jitter, so that's not the issue. What is

gong on here is that your fully transparent pixels are stil writing to

the depth buffer. You can avoid this in one of 2 ways:

1) write a shader that calls the discard command if alpha == 0

2) use the glAlphaFunc settings to tell OpenGL that alpha values of a

particular range shouldn't write to the depth buffer.

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/glAlphaFunc.3.html

You can manipulate the alphaFunc settings through jit.gl.sketch.

> i am trying to use jit.multiple with a set of planes textured with png files with transparency. i am having what seems to be a depth sorting problem as sometimes the transparency works and sometimes not. since there are many 'particles' moving around a lot, doing depth sorting myself does not look promising.

> i am attaching a patch which needs a png texture that can be found in the attached archive. there is also a screengrab illustrating the problem. any ideas of how to go about rendering this properly would be greatly appreciated.

> moreover, it seems that the depth sorting behavior of jitter is inconsistent, e.g. turning fsaa on and off leads to different results regarding which transparency planes are rendered properly.

> my system is mbp core 2 duo, maxmsp 4.6.3 / jitter 1.6.3

> p.s. if there are problems with the attachment, it can be downloaded at 

> ---------------------------------------------------------

> #P newex 272 129 158 196617 jit.gl.texture display @name fish;

> #P message 272 112 80 196617 read coral1.png;

> #P newex 72 437 98 196617 jit.gl.handle display;

> #P newex 165 316 356 196617 jit.gl.gridshape display @shape cube @poly_mode 1 1 @scale 5 5 5 @position 5 5 5 @dim 40 10 @automatic 0 @depth_enable 0 @rotatexyz 90 90 0;

> #P newex 291 206 71 196617 r shapeobject;

> #P user jit.pwindow 164 63 82 62 0 1 0 0 1 0;

> #P flonum 242 188 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 459 76 70 196617 r _dimchange;

There is no depth sorting in Jitter, so that's not the issue.  What is
gong on here is that your fully transparent pixels are stil writing to
the depth buffer.  You can avoid this in one of 2 ways:

1) write a shader that calls the discard command if alpha == 0
2) use the glAlphaFunc settings to tell OpenGL that alpha values of a
particular range shouldn't write to the depth buffer.

On 6/15/07, liubo  wrote:
> hi,
>
> i am trying to use jit.multiple with a set of planes textured with png files with transparency. i am having what seems to be a depth sorting problem as sometimes the transparency works and sometimes not. since there are many 'particles' moving around a lot, doing depth sorting myself does not look promising.
>
> i am attaching a patch which needs a png texture that can be found in the attached archive. there is also a screengrab illustrating the problem. any ideas of how to go about rendering this properly would be greatly appreciated.
>
> moreover, it seems that the depth sorting behavior of jitter is inconsistent, e.g. turning fsaa on and off leads to different results regarding which transparency planes are rendered properly.
>
> my system is mbp core 2 duo, maxmsp 4.6.3 / jitter 1.6.3
>
> thanks
>
> p.s. if there are problems with the attachment, it can be downloaded at http://2rem.net/depthproblem.zip
> ---------------------------------------------------------
>
> max v2;
> #N vpatcher 489 132 1262 716;
> #P origin 35 -31;
> #P window setfont "Sans Serif" 9.;
> #P message 72 418 34 196617 reset;
> #P toggle 179 423 15 0;
> #P message 179 440 44 196617 fsaa $1;
> #P newex 272 93 48 196617 loadbang;
> #P newex 272 129 158 196617 jit.gl.texture display @name fish;
> #B color 5;
> #P message 272 112 80 196617 read coral1.png;
> #P newex 72 437 98 196617 jit.gl.handle display;
> #P newex 166 296 39 196617 r first;
> #P newex 60 121 39 196617 s first;
> #P window linecount 2;
> #P newex 165 316 356 196617 jit.gl.gridshape display @shape cube @poly_mode 1 1 @scale 5 5 5 @position 5 5 5 @dim 40 10 @automatic 0 @depth_enable 0 @rotatexyz 90 90 0;
> #P window linecount 1;
> #P newex 291 206 71 196617 r shapeobject;
> #P newex 1 25 48 196617 loadbang;
> #P user jit.pwindow 164 63 82 62 0 1 0 0 1 0;
> #P newex 4 492 65 196617 s nextframe;
> #P flonum 242 188 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 242 206 48 196617 scale $1;
> #P newex 105 122 35 196617 s tick;
> #N vpatcher 716 252 1890 846;
> #P origin 0 -6;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 70 55 47 196617 s _mtex;
> #P window linecount 0;
> #P message 539 73 44 196617 setall 0;
> #P window linecount 1;
> #P newex 459 76 70 196617 r _dimchange;
> #P newex 409 77 47 196617 r _mtex;
> #P outlet 409 121 15 0;
> #P newex 409 99 143 196617 jit.matrix mtex 1 char 100 1;
> #P user jit.pwindow 511 246 82 62 0 1 0 0 1 0;
> #P window linecount 0;
> #P newex 476 222 87 196617 jit.matrix noise3;
> #P button 476 167 15 0;
> #P newex 493 167 70 196617 r _dimchange;
> #P newex 476 194 122 196617 jit.noise 3 float32 100 1;
> #P newex 271 100 49 196617 pipe 100;
> #P newex 271 69 66 196617 loadmess 50;
> #P newex 135 310 70 196617 r _dimchange;
> #P newex 184 352 130 196617 jit.matrix 3 float32 100 1;
> #P newex 183 431 47 196617 s _mpos;
> #P newex 18 54 47 196617 s _mpos;
> #P newex 18 32 35 196617 r tick;
> #P newex 185 392 239 196617 jit.expr 3 float32 100 1 @expr "10*(noise3.p[0]-0.0)" "10*noise3.p[1]" "10*noise3.p[2]";
> #P newex 66 212 70 196617 r _dimchange;
> #P number 271 136 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 271 158 46 196617 s _dim1;
> #P newex 100 183 70 196617 s _dimchange;
> #P newex 100 161 30 196617 t b s;
> #P number 103 112 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 100 139 74 196617 pak dim 100 1;
> #P newex 103 90 46 196617 r _dim1;
> #P newex 16 212 47 196617 r _mpos;
> #P inlet 244 35 15 0;
> #P newex 16 234 156 196617 jit.matrix mpos 3 float32 100 1;
> #P outlet 16 256 15 0;
> #P connect 11 0 1 0;
> #P connect 3 0 1 0;
> #P connect 1 0 0 0;
> #P fasten 13 0 14 0 23 51 23 51;
> #P fasten 2 0 14 0 249 52 23 52;
> #P connect 13 0 30 0;
> #P connect 5 0 7 0;
> #P connect 7 1 8 0;
> #P connect 7 0 8 0;
> #P connect 4 0 6 0;
> #P connect 6 0 5 1;
> #P connect 12 0 15 0;
> #P connect 17 0 16 0;
> #P connect 16 0 12 0;
> #P connect 17 0 12 0;
> #P connect 18 0 19 0;
> #P connect 19 0 10 0;
> #P connect 10 0 9 0;
> #P connect 29 0 25 0;
> #P connect 27 0 25 0;
> #P connect 28 0 25 0;
> #P connect 25 0 26 0;
> #P connect 18 0 22 0;
> #P connect 21 0 20 0;
> #P connect 22 0 20 0;
> #P connect 20 0 23 0;
> #P connect 23 0 24 0;
> #P pop;
> #P newobj 246 41 292 196617 p GenGLParams;
> #P newex 246 65 386 196617 jit.gl.multiple display @targetname multi @glparams position texture @texture fish;
> #B color 5;
> #P newex 183 206 56 196617 s loadbang;
> #P newex 165 177 48 196617 loadbang;
> #P button 165 205 15 0;
> #P window linecount 2;
> #P newex 165 229 407 196617 jit.gl.gridshape display @shape plane @blend_enable 1 @automatic 0 @smooth_shading 1 @depth_enable 1 @dim 2 2 @name multi @color 1 1 1 1 @lighting_enable 0 @tex_map 2;
> #P window linecount 1;
> #P newex 419 459 38 196617 sel 27;
> #P newex 419 441 40 196617 key;
> #P toggle 419 477 15 0;
> #P message 419 493 70 196617 fullscreen $1;
> #P newex 419 509 308 196617 jit.window display @depthbuffer 1 @fsmenubar 0 @doublebuffer 1;
> #P newex 4 437 58 196617 r renderer;
> #P newex 2 121 58 196617 s renderer;
> #P newex 2 83 74 196617 t b b b erase b;
> #P toggle 1 46 15 0;
> #P newex 1 64 57 196617 qmetro 33;
> #P newex 4 460 399 196617 jit.gl.render display @erase_color 0 0 0 1 @far_clip 40000 @camera 8 8 10 @axes 1;
> #P connect 22 0 2 0;
> #P connect 2 0 1 0;
> #P connect 1 0 3 0;
> #P connect 3 0 4 0;
> #P connect 3 3 4 0;
> #P connect 5 0 0 0;
> #P connect 27 0 0 0;
> #P connect 31 0 0 0;
> #P connect 0 0 20 0;
> #P connect 3 2 25 0;
> #P connect 33 0 27 0;
> #P connect 3 4 17 0;
> #P fasten 16 0 21 0 251 61 170 61;
> #P connect 13 0 12 0;
> #P connect 12 0 11 0;
> #P fasten 18 0 11 0 247 225 170 225;
> #P fasten 23 0 11 0 296 225 170 225;
> #P connect 26 0 24 0;
> #P connect 32 0 31 0;
> #P fasten 13 0 14 0 170 200 188 200;
> #P connect 19 0 18 0;
> #P connect 16 0 15 0;
> #P connect 30 0 28 0;
> #P connect 28 0 29 0;
> #P hidden connect 9 0 10 0;
> #P hidden connect 10 0 8 0;
> #P connect 8 0 7 0;
> #P connect 7 0 6 0;
> #P connect 16 1 15 1;
> #P pop;
>
>
>
>
>


thanks for the quick response. i'd prefer if i can do it with sketch. looking at the apple ref you sent, seems like i need to make a call like glAlphaFunc(GL_GREATER,0.1) to jit.gl.sketch. how would that translate to jitter?

(which is documented in the help file for sketch)

i tried sending these messages with no luck:

(which is documented in the help file for sketch)
i tried sending these messages with no luck:

glalphafunc greater 0.2
glalphafunc gl_greater 0.2
glalphafunc 4 0.2

I have the same problem. Did you find the solution?

You probably didn't enable alpha testing. It's a pain, but with

OpenGL docs, you really have to read carefully. For alpha testing to

occur, you have to call glEnable(GL_ALPHA_TEST)

You probably didn't enable alpha testing.  It's a pain, but with
OpenGL docs, you really have to read carefully.  For alpha testing to
occur, you have to call glEnable(GL_ALPHA_TEST)

thanks wes, this really helps. i guess my problem was that to be able to use glalphafunc i need to pass my objects through jit.gl.sketch (but wouldn't that slow me down if i am using multiple or many particles)?

is there a way to set glalphafunc globally (i.e. send the message to jit.gl.render)?

...or would you recommend lua (which rocks btw)?

secco, to solve my problem i ended up not using glalphafunc (though i think it's a better solution). i ended up messing around with blend modes and in one case turning on fsaa did what i wanted. 

the patch is big and ugly but if interested, it's here

secco, to solve my problem i ended up not using glalphafunc (though i think it's a better solution). i ended up  messing around with blend modes and in one case turning on fsaa did what i wanted. 
the patch is big and ugly but if interested, it's here

Indeed, if you don't mind going that diretion, jit.gl.lua will make

things easier and cleaner because you need some low-level OpenGL

> thanks wes, this really helps. i guess my problem was that to be able to use glalphafunc i need to pass my objects through jit.gl.sketch (but wouldn't that slow me down if i am using multiple or many particles)?

> is there a way to set glalphafunc globally (i.e. send the message to jit.gl.render)?

> ...or would you recommend lua (which rocks btw)?

> secco, to solve my problem i ended up not using glalphafunc (though i think it's a better solution). i ended up messing around with blend modes and in one case turning on fsaa did what i wanted.

> the patch is big and ugly but if interested, it's here

Indeed, if you don't mind going that diretion, jit.gl.lua will make
things easier and cleaner because you need some low-level OpenGL
control to do what you want.

On 6/18/07, liubo  wrote:
>
> thanks wes, this really helps. i guess my problem was that to be able to use glalphafunc i need to pass my objects through jit.gl.sketch (but wouldn't that slow me down if i am using multiple or many particles)?
>
> is there a way to set glalphafunc globally (i.e. send the message to jit.gl.render)?
>
> ...or would you recommend lua (which rocks btw)?
>
> secco, to solve my problem i ended up not using glalphafunc (though i think it's a better solution). i ended up  messing around with blend modes and in one case turning on fsaa did what i wanted.
> the patch is big and ugly but if interested, it's here
>
> http://2rem.net/code/fishes.zip
>


thanks again, while i got you on the line, hope i'm not abusing your time and kindness... any chance you could repost the lua example that has mass matrix assignment - it's referenced in this forum but i can't see/find the lua code

What do you mean mass matrix? do you mean luaODE? I neglected to add

the dBodyGetMass function to the library. I can add that pretty soon.

What do you mean mass matrix?  do you mean luaODE?  I neglected to add
the dBodyGetMass function to the library.  I can add that pretty soon.

https://cycling74.com/forums/index.php?t=msg&goto=105648

you refer to a pendulum patch, which i assumed had dBodySetMass.. yes, mass would be nice, any news on the luaODE front are always exciting... looking forward

you refer to a pendulum patch, which i assumed had dBodySetMass.. yes, mass would be nice,  any news on the luaODE front are always exciting... looking forward


somehow I don't understand what's going on there in my patch.

Is there any good resource I could read for better understanding how jitter manages depth and/or alpha.

I have just three videoplanes one upon the other with some small distance between them.

All of them have images loaded which contain alpha. One has a combination of live video and some images combined by a shader with jit.gl.slab.

Now this patch sometimes works correctly and sometimes not. And it's not reproducible.

Such as when I toggle border on or off for the jit.window or when I toggle around with depth enable/disable of the videoplanes or sometimes when I just reedit any argument of a videoplane without even changing the value.

I tried with jit.gl.sketch but it doesen't work. mainly because I don't know what it does because I can't find infos about attributes like @layer in the online documentation at 

https://cycling74.com/documentation/group-GL

https://cycling74.com/documentation/jit.gl.sketch

Is there a more current documentation somewhere?

What exactly do these jit.gl.sketch messages do for instance?:

reset, glbindtexture mov 0, glenable alpha_test, glalphafunc greater 0, glcolor 1 1 1 1, drawobject vplane 1, glunbindtexture mov 0

somehow I don't understand what's going on there in my patch.
Is there any good resource I could read for better understanding how jitter manages depth and/or alpha.
I have just three videoplanes one upon the other with some small distance between them.
All of them have images loaded which contain alpha. One has a combination of live video and some images combined by a shader with  jit.gl.slab.
Now this patch sometimes works correctly and sometimes not. And it's not reproducible.
Such as when I toggle border on or off for the jit.window or when I toggle around with depth enable/disable of the videoplanes or sometimes when I just reedit any argument of a videoplane without even changing the value.
I tried with jit.gl.sketch but it doesen't work. mainly because I don't know what it does because I can't find infos about attributes like @layer in the online documentation at https://cycling74.com/documentation/group-GL or
https://cycling74.com/documentation/jit.gl.sketch
Is there a more current documentation somewhere?

What exactly do these jit.gl.sketch messages do for instance?:
reset, glbindtexture mov 0, glenable alpha_test, glalphafunc greater 0, glcolor 1 1 1 1, drawobject vplane 1, glunbindtexture mov 0

Sound like you need to use @layer. Whenever you modifuy jit.window or

jit.gl.render in certain ways, the context gets rebuilt causing the

jit.gl. objects to re-register, potentially reordering themselves. If

you use @layer, you are guaranteed order. Layers work by drawing from

lowest to highest, so if you had each videoplane in layers 1, 2, 3

then you would get them drawn i that order.

> somehow I don't understand what's going on there in my patch.

> Is there any good resource I could read for better understanding how jitter manages depth and/or alpha.

> I have just three videoplanes one upon the other with some small distance between them.

> All of them have images loaded which contain alpha. One has a combination of live video and some images combined by a shader with jit.gl.slab.

> Now this patch sometimes works correctly and sometimes not. And it's not reproducible.

> Such as when I toggle border on or off for the jit.window or when I toggle around with depth enable/disable of the videoplanes or sometimes when I just reedit any argument of a videoplane without even changing the value.

> I tried with jit.gl.sketch but it doesen't work. mainly because I don't know what it does because I can't find infos about attributes like @layer in the online documentation at 

> Is there a more current documentation somewhere?

> What exactly do these jit.gl.sketch messages do for instance?:

> reset, glbindtexture mov 0, glenable alpha_test, glalphafunc greater 0, glcolor 1 1 1 1, drawobject vplane 1, glunbindtexture mov 0

Sound like you need to use @layer.  Whenever you modifuy jit.window or
jit.gl.render in certain ways, the context gets rebuilt causing the
jit.gl. objects to re-register, potentially reordering themselves.  If
you use @layer, you are guaranteed order.  Layers work by drawing from
lowest to highest, so if you had each videoplane in layers 1, 2, 3
then you would get them drawn i that order.

On 6/19/07, secco  wrote:
>
> hi folks,
>
> somehow I don't understand what's going on there in my patch.
> Is there any good resource I could read for better understanding how jitter manages depth and/or alpha.
> I have just three videoplanes one upon the other with some small distance between them.
> All of them have images loaded which contain alpha. One has a combination of live video and some images combined by a shader with  jit.gl.slab.
> Now this patch sometimes works correctly and sometimes not. And it's not reproducible.
> Such as when I toggle border on or off for the jit.window or when I toggle around with depth enable/disable of the videoplanes or sometimes when I just reedit any argument of a videoplane without even changing the value.
> I tried with jit.gl.sketch but it doesen't work. mainly because I don't know what it does because I can't find infos about attributes like @layer in the online documentation at https://cycling74.com/documentation/group-GL or
> https://cycling74.com/documentation/jit.gl.sketch
> Is there a more current documentation somewhere?
>
> What exactly do these jit.gl.sketch messages do for instance?:
> reset, glbindtexture mov 0, glenable alpha_test, glalphafunc greater 0, glcolor 1 1 1 1, drawobject vplane 1, glunbindtexture mov 0
>
> And how could I use it in my case?
>
> thanks
> secco
>
>
>


thanks wes, @layer helped. Where is that documented? And is there a good resource for understanding the correct jitter syntax of jit.gl.sketch commands?

layer is documented in the Group-GL section of the jitter documentation.

gl-sketch commands are basically opengl commands.

the opengl redbook or the nehe opengl tutorials are good places to start. other than that, the gl-sketch help file is packed full of instructional goodness. much experimentation is required.

gl-sketch commands are basically opengl commands.
the opengl redbook or the nehe opengl tutorials are good places to start. other than that, the gl-sketch help file is packed full of instructional goodness.  much experimentation is required.


wheck out the group-GL.html Jitter reference. It has common OpenGL attrs.

> thanks wes, @layer helped. Where is that documented? And is there a good resource for understanding the correct jitter syntax of jit.gl.sketch commands?

wheck out the group-GL.html Jitter reference.  It has common OpenGL attrs.

On 6/23/07, secco  wrote:
>
> thanks wes, @layer helped. Where is that documented? And is there a good resource for understanding the correct jitter syntax of jit.gl.sketch commands?
>
> secco
>


depth sorting / transparency / jit.multiple issue