Roman Thilenius

would anyone have a simple example ("best practice") for me how to draw a (2D) triangle shape using the most basic jit.gl objects and send it as matrix to a pwindow?


would anyone have a simple example ("best practice") for me how to draw a (2D) triangle shape using the most basic jit.gl objects and send 

jit-gl-2d-gui-elements

jit.gl.sketch let's you send drawing commands directly. The triangle syntax should be:

tri <x1> <y1> <z1> <x2> <y2> <z2> <x3> <y3> <z3>

Hi, Roman. 
jit.gl.sketch let's you send drawing commands directly. The triangle syntax should be:
tri <x1> <y1> <z1> <x2> <y2> <z2> <x3> <y3> <z3>


...and if i want to have a jit.matrix in between?

What version of Max, Roman? Your reputation precedes you... ;-)

I think this might work from Max 6 onwards, certainly 7...

But if you want the end result in matrix format, it might not be useful to draw the triangle in a GL context (drawn by the GPU) , because you need to bring it back to the CPU/RAM.

What version of Max, Roman? Your reputation precedes you... ;-)
I think this might work from Max 6 onwards, certainly 7...
But if you want the end result in matrix format, it might not be useful to draw the triangle in a GL context (drawn by the GPU) , because you need to bring it back to the CPU/RAM.


there is only one thing which doesnt work in max 4 so far, and that is the color, which is 0.5 instead of 1.0.

i guess i need to turn light on and change the direction somehow? right now when i turn lightning on it gets black.^^ 

i have to script-create the pwindow anyway in my context, but eventually it is better to mix some matrixes for the background (like i am used to with lcd.jit)

i have no idea yet what happens to CPU usage when i only need to update a little part of the GUI element (which is 500 or 1000 pixels big)


there is only one thing which doesnt work in max 4 so far, and that is the color, which is 0.5 instead of 1.0.

i guess i need to turn light on and change the direction somehow? right now when i turn lightning on it gets black.^^ 

i have to script-create the pwindow anyway in my context, but eventually it is better to mix some matrixes for the background (like i am used to with lcd.jit)

i have no idea yet what happens to CPU usage when i only need to update a little part of the GUI element (which is 500 or 1000 pixels big)


"it might not be useful to draw the triangle in a GL context"

i have reasons to avoid both jit.lcd and mgraphics here and i am sometimes in the mood to learn something new. :)

"it might not be useful to draw the triangle in a GL context"

i have reasons to avoid both jit.lcd and mgraphics here and i am sometimes in the mood to learn something new. :)


use a jit.gl.videoplane to mix matrix input with other gl elements in a gl context

"and that is the color, which is 0.5 instead of 1.0. "

"and that is the color, which is 0.5 instead of 1.0. "

ah, user error.



excuse me, but what is the rule how to control layers by message order?

if i draw two shapes with both z = 0, sometimes the first one and sometimes the second one is on top.

i know i could use z = 0.001, but that will only be the makeshift solution.


excuse me, but what is the rule how to control layers by message order?

if i draw two shapes with both z = 0, sometimes the first one and sometimes the second one is on top.
:(

i know i could use z = 0.001, but that will only be the makeshift solution.


if you control via layer than set @depth_enable 0.

https://docs.cycling74.com/max8/vignettes/jitter_layering

if you control via layer than set @depth_enable 0.
https://docs.cycling74.com/max8/vignettes/jitter_layering 

hm, that changes the current order in my patch, but still doesnt let me control which of the shapes i want on top. 

max v2;
#N vpatcher 233 85 1676 1131;
#P newex 221 306 134 196617 jit.gl.sketch foox;
#P button 853 58 50 0;
#P message 1232 271 96 196617 depth_enable 0;
#P flonum 1167 472 85 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 1167 397 85 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 1167 433 184 196617 expr cos(6.28318530718*$f1);
#P newex 744 116 78 196617 t 0.8 0.1;
#P button 744 40 50 0;
#P newex 853 134 78 196617 t 0.1 0.8;
#P newex 958 209 50 196617 t f b b;
#P newex 722 257 245 196617 pak tri 0. 0.5 0. 0. -0.5 0. -0.5 -0.5 0.;
#P newex 978 257 113 196617 list glcolor 0. 0.5 1.;
#P newex 1107 257 97 196617 t reset;
#P flonum 958 186 65 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 722 306 134 196617 jit.gl.sketch foox;
#P newex 457 209 50 196617 t f b b;
#P newex 221 257 245 196617 pak tri 0. 0.5 0. 0.5 -0.5 0. -0.5 -0.5 0.;
#P newex 477 257 113 196617 list glcolor 1. 0. 1.;
#P newex 606 257 97 196617 t reset;
#P flonum 457 186 65 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user jit.pwindow 29 391 602 602 0 1 0 0 1 0;
#X name foox;
#P newex 53 149 78 196617 t b erase;
#P toggle 53 67 15 0;
#P newex 53 111 78 196617 qmetro 25;
#P newex 53 204 97 196617 jit.gl.render foox;
#P connect 2 0 1 0;
#P connect 1 0 3 0;
#P connect 3 0 0 0;
#P connect 3 1 0 0;
#P connect 22 0 24 0;
#P connect 8 0 24 0;
#P connect 7 0 24 0;
#P connect 6 0 24 0;
#P connect 9 0 8 1;
#P connect 18 1 5 0;
#P connect 16 0 5 0;
#P connect 5 0 9 0;
#P connect 9 1 7 0;
#P connect 9 2 6 0;
#P connect 22 0 10 0;
#P connect 14 0 10 0;
#P connect 12 0 10 0;
#P connect 13 0 10 0;
#P connect 17 0 18 0;
#P connect 15 0 14 1;
#P connect 23 0 16 0;
#P connect 18 0 11 0;
#P connect 16 1 11 0;
#P connect 11 0 15 0;
#P connect 15 1 13 0;
#P connect 15 2 12 0;
#P connect 20 0 19 0;
#P connect 19 0 21 0;
#P pop;



hm,  that changes the current order in my patch, but still doesnt let me control which of the shapes i want on top. 

 

To make sure you draw things in a chosen order, you can make your gl objects @automatic 0 and bang them yourself in the order you like. See this:

[t b b b b b b b b erase] leftmost bang is to jit.gl.render, all the bangs in the middle go to your gl objects in the order you want (in you case, you have just 2 of these middle bangs).

oh, so automatic 0 is my new friend. didnt figure before that this didnt not work because i was continously metro´ing [t b erase]. (note the "erase")

this is very good that i can get rid of the metro, because i need to metro the the gl objects anyway already.


oh, so automatic 0 is my new friend. didnt figure before that this didnt not work because i was continously metro´ing [t b erase]. (note the "erase")

this is very good that i can get rid of the metro, because i need to metro the the gl objects anyway already.


in lcd world, i do clever things like shown in the image.

the messages are executed in order of serial connection. automatic back to front is all quickdraw can do anyway. it could not be easier.

would be great if i come there using some simple gl, too.

qd-clever.jpg


in lcd world, i do clever things like shown in the image.

the messages are executed in order of serial connection. automatic back to front is all quickdraw can do anyway. it could not be easier.

would be great if i come there using some simple gl, too.


Maybe the old Jitter Tutorial 40, using jit.gl.sketch.

You could use it with @automatic 0, of course.

Maybe the old Jitter Tutorial 40, using jit.gl.sketch.
You could use it with @automatic 0, of course.

it requires a "main" t b b in the center (and eventually a bunch of gates for when you need to redraw only parts?), but otherwise it works well to force some linearity to it.

i have not yet understood the exact meaning of the sketch and render objects (because i dont read manuals), so changes may become neccessary later, but i think we´re are at "90% proof of concept" now... after 20 minutes of patching.

it remains a bit annoying that you cant just add a new thing to an existing gl.render / pwindow without redrawing everything, but maybe you just need to know how?

gl-proof.jpg


it requires a "main" t b b in the center (and eventually a bunch of gates for when you need to redraw only parts?), but otherwise it works well to force some linearity to it.

i have not yet understood the exact meaning of the sketch and render objects (because i dont read manuals), so changes may become neccessary later, but i think we´re are at "90% proof of concept" now... after 20 minutes of patching.

it remains a bit annoying that you cant just add a new thing to an existing gl.render / pwindow without redrawing everything, but maybe you just need to know how?


Yes, that's the way gl.render works. You redraw everything everytime you change something, but it happens on the GPU, it's really cheap.

no chance to not recreate a single object (such as sketch)? 

i was hoping that it is kind of a register like [i] or [zl reg]. 

the message creation itself can quickly become a problem when the source is not the mouse, but 10 zerox~ or 100 meter~

you _have to bang to trigger output (when auto is off), but you can only one time. that feels strange.


no chance to not recreate a single object (such as sketch)? 

i was hoping that it is kind of a register like [i] or [zl reg]. 

the message creation itself can quickly become a problem when the source is not the mouse, but 10 zerox~ or 100 meter~

you _have to bang to trigger output (when auto is off), but you can only one time. that feels strange.

I - think - that you just need to give the drawing commands to sketch once.

What you need to do everytime is [t b b... erase] with the middle bangs banging every object you want to draw (videoplane, mesh, etc, or, in your case, sketch). Giving the drawing commands to sketch might be a little expensive. Just banging it to include in render should be very light.

A trick to lighten the processing, for instance with a mesh (or a still image on a videoplane), is to feed it with a geometry (or image), then just give offset/scale instructions to these gl.mesh or gl.videoplane for each redraw - these happen only on GPU. I'm not sure how that would figure with sketch.

I - think - that you just need to give the drawing commands to sketch once.
What you need to do everytime is [t b b... erase] with the middle bangs banging every object you want to draw (videoplane, mesh, etc, or, in your case, sketch). Giving the drawing commands to sketch might be a little expensive. Just banging it to include in render should be very light.
A trick to lighten the processing, for instance with a mesh (or a still image on a videoplane), is to feed it with a geometry (or image), then just give offset/scale instructions to these gl.mesh or gl.videoplane for each redraw - these happen only on GPU. I'm not sure how that would figure with sketch.

thanks for the headup ... once more i thought it wouldnt work because of a careless patching mistake.

yesterday i got everything working as it should, found the most general approach to making abstractions, and now everything is linear while it still would work to have parallel branches, alternative subsets, too.

the last open question is about copymodes/opcolor/masking. does such thing exist for GL 2d planes as it does for QD?

gl-final.jpg


 thanks for the headup ... once more i thought it wouldnt work because of a careless patching mistake.

yesterday i got everything working as it should, found the most general approach to making abstractions, and now everything is linear while it still would work to have parallel branches, alternative subsets, too.

the last open question is about copymodes/opcolor/masking. does such thing exist for GL 2d planes as it does for QD?


1.) when unlocking the patcher which contains the pwindow, 

- the pwindow gets black and you have to redraw, or in other words, using "onscreen 0" has no effect (it has for matrix content), it does the same thing than drawing onscreen.

- every redraw of the GL content (bang to gl.render) is repositioned randomly for up to 3 pixels in different directions (i would understand ~0.5 pixels, but 3?)

- the next redraw will delete the content (to black), only another redraw will actually redraw. putting the pwindow in a bpatcher fixes that one.


first test - max4 issues

1.) when unlocking the patcher which contains the pwindow, 
 - the pwindow gets black and you have to redraw, or in other words, using "onscreen 0" has no effect (it has for matrix content), it does the same thing than drawing onscreen.

2.) when moving the window,
 - every redraw of the GL content (bang to gl.render) is repositioned randomly for up to 3 pixels in different directions (i would understand ~0.5 pixels, but 3?)
 - the next redraw will delete the content (to black), only another redraw will actually redraw. putting the pwindow in a bpatcher fixes that one.

alltogether not very funny.




jit.gl 2d gui elements