johannes-eckart@gmx.at

I still haven't really solved my problem with drawing in Jitter. Maybe to explain it a little bit better what I want to do finally: With the help of a webcam I want to draw some forms in a jit.window. A coloured point in the movie gives me with the jit.getbounds operations coordinates. With these I would like to redraw the movement of the coloured point. My patch is working so far, but instead of a line, I only get individual points (because I am using a sphere to draw). It would be alright to draw with these points, but I don't really get a nice dash! There is just one point after another.

Would it be possible to draw in a jit.window like with a pen? I know, that I can draw with the mouse, but I wanted to draw with these given coordinates!

I also heard something about 'Subpixel-Rendering' but in the archives I didn't get some information about that.

I know, that my problem is a little bit weird, but maybe somebody would have just ANY help, a link or some patches which could help me!!

Hi community,
I still haven't really solved my problem with drawing in Jitter. Maybe to explain it a little bit better what I want to do finally: With the help of a webcam I want to draw some forms in a jit.window. A coloured point in the movie gives me with the jit.getbounds operations coordinates. With these I would like to redraw the movement of the coloured point. My patch is working so far, but instead of a line, I only get individual points (because I am using a sphere to draw). It would be alright to draw with these points, but I don't really get a nice dash! There is just one point after another.
Would it be possible to draw in a jit.window like with a pen? I know, that I can draw with the mouse, but I wanted to draw with these given coordinates!
I also heard something about 'Subpixel-Rendering' but in the archives I didn't get some information about that.
I know, that my problem is a little bit weird, but maybe somebody would have just ANY help, a link or some patches which could help me!!
Thanks a lot,
Johannes


drawing-like-with-a-pen-subpixel

If you posted a simple patch that would be helpful. You probably want

to use jit.lcd for drawing and overlay the result on the window. Hard

to say though without seeing exactly what you're doing.

> I still haven't really solved my problem with drawing in Jitter. Maybe to explain it a little bit better what I want to do finally: With the help of a webcam I want to draw some forms in a jit.window. A coloured point in the movie gives me with the jit.getbounds operations coordinates. With these I would like to redraw the movement of the coloured point. My patch is working so far, but instead of a line, I only get individual points (because I am using a sphere to draw). It would be alright to draw with these points, but I don't really get a nice dash! There is just one point after another.

> Would it be possible to draw in a jit.window like with a pen? I know, that I can draw with the mouse, but I wanted to draw with these given coordinates!

> I also heard something about 'Subpixel-Rendering' but in the archives I didn't get some information about that.

> I know, that my problem is a little bit weird, but maybe somebody would have just ANY help, a link or some patches which could help me!!

If you posted a simple patch that would be helpful.  You probably want
to use jit.lcd for drawing and overlay the result on the window.  Hard
to say though without seeing exactly what you're doing.

On 3/18/07, Johannes  wrote:
>
> Hi community,
> I still haven't really solved my problem with drawing in Jitter. Maybe to explain it a little bit better what I want to do finally: With the help of a webcam I want to draw some forms in a jit.window. A coloured point in the movie gives me with the jit.getbounds operations coordinates. With these I would like to redraw the movement of the coloured point. My patch is working so far, but instead of a line, I only get individual points (because I am using a sphere to draw). It would be alright to draw with these points, but I don't really get a nice dash! There is just one point after another.
> Would it be possible to draw in a jit.window like with a pen? I know, that I can draw with the mouse, but I wanted to draw with these given coordinates!
> I also heard something about 'Subpixel-Rendering' but in the archives I didn't get some information about that.
> I know, that my problem is a little bit weird, but maybe somebody would have just ANY help, a link or some patches which could help me!!
> Thanks a lot,
> Johannes
>


thanks for your answer! Of course with a patch it's maybe easier to understand. I rewrote my patch a bit more simple.

The camera (resolution 320*240, very poor, I know...) catches the movement of a red object (jit.findbounds). 

I change the volumes of brightness, contrast and saturation with jit.brcosa to find the color more easily.

I calculate the center of the red object and create a very small sphere at that point (jit.gl.gridshape).

When I move now the object, I create a sphere at every given point by findbounds. If it works well, I sometimes get nice dashes, but normally I just arrive to draw one dot after another! I could call it a dash, but I am looking for something more proper.

Maybe you, or anybody could understand, what I meen ;)

I am still at the beginning of working with Max/MSP/Jitter, so if I put my words in an uncomprehensible way, don't hesitate to do some critics!!

Hello Wes,
thanks for your answer! Of course with a patch it's maybe easier to understand. I rewrote my patch a bit more simple.
To explain:
The camera (resolution 320*240, very poor, I know...) catches the movement of a red object (jit.findbounds). 
I change the volumes of brightness, contrast and saturation with jit.brcosa to find the color more easily.
I calculate the center of the red object and create a very small sphere at that point (jit.gl.gridshape).
When I move now the object, I create a sphere at every given point by findbounds. If it works well, I sometimes get nice dashes, but normally I just arrive to draw one dot after another! I could call it a dash, but I am looking for something more proper.
Maybe you, or anybody could understand, what I meen ;)
I am still at the beginning of working with Max/MSP/Jitter, so if I put my words in an uncomprehensible way, don't hesitate to do some critics!!
Thanks,
Johannes


Thanks, Wes, maybe this could really help me! In fact, I don't want to draw with the mouse, but I will have a look at that command, and hope to find somethink useful...

Hi again,
just looked at jit.lcd!
Thanks, Wes, maybe this could really help me! In fact, I don't want to draw with the mouse, but I will have a look at that command, and hope to find somethink useful...
Greets,
Johannes


if you want to remain in opengl land, check the twineball recipe for curve

drawing in sketch or the etch-a-sketch example.

problem with this method is that if you dont manage your cmd-list or move it

to displaylist mode, this can get heavy on the card.

> I still haven't really solved my problem with drawing in Jitter. Maybe to

> explain it a little bit better what I want to do finally: With the help of a

> webcam I want to draw some forms in a jit.window. A coloured point in the

> movie gives me with the jit.getbounds operations coordinates. With these I

> would like to redraw the movement of the coloured point. My patch is working

> so far, but instead of a line, I only get individual points (because I am

> using a sphere to draw). It would be alright to draw with these points, but

> I don't really get a nice dash! There is just one point after another.

> Would it be possible to draw in a jit.window like with a pen? I know, that

> I can draw with the mouse, but I wanted to draw with these given

> I also heard something about 'Subpixel-Rendering' but in the archives I

> didn't get some information about that.

> I know, that my problem is a little bit weird, but maybe somebody would

> have just ANY help, a link or some patches which could help me!!

if you want to remain in opengl land, check the twineball recipe for curve
drawing in sketch or the etch-a-sketch example.
problem with this method is that if you dont manage your cmd-list or move it
to displaylist mode, this can get heavy on the card.

On 3/19/07, Johannes  wrote:
>
>
> Hi community,
> I still haven't really solved my problem with drawing in Jitter. Maybe to
> explain it a little bit better what I want to do finally: With the help of a
> webcam I want to draw some forms in a jit.window. A coloured point in the
> movie gives me with the jit.getbounds operations coordinates. With these I
> would like to redraw the movement of the coloured point. My patch is working
> so far, but instead of a line, I only get individual points (because I am
> using a sphere to draw). It would be alright to draw with these points, but
> I don't really get a nice dash! There is just one point after another.
> Would it be possible to draw in a jit.window like with a pen? I know, that
> I can draw with the mouse, but I wanted to draw with these given
> coordinates!
> I also heard something about 'Subpixel-Rendering' but in the archives I
> didn't get some information about that.
> I know, that my problem is a little bit weird, but maybe somebody would
> have just ANY help, a link or some patches which could help me!!
> Thanks a lot,
> Johannes
>

> if you want to remain in opengl land, check the twineball recipe for 

> curve drawing in sketch or the etch-a-sketch example.

> problem with this method is that if you dont manage your cmd-list or 

> move it to displaylist mode, this can get heavy on the card.

can you expand on this a bit? I've dealt with automatic thinning of the 

cmd-list before, and I really didn't care for it ;) Displaylist mode, 

however, is something I've never gotten into.

yair reshef skrev:
> if you want to remain in opengl land, check the twineball recipe for 
> curve drawing in sketch or the etch-a-sketch example.
> problem with this method is that if you dont manage your cmd-list or 
> move it to displaylist mode, this can get heavy on the card.
>
Hello Yair,
can you expand on this a bit? I've dealt with automatic thinning of the 
cmd-list before, and I really didn't care for it ;) Displaylist mode, 
however, is something I've never gotten into.

Weird, my emails to this list yesterday got completely lost. Anyway, 

Yair, could you elaborate a bit on the display list mode? I've not gone 

yair reshef skrev:
> if you want to remain in opengl land, check the twineball recipe for 
> curve drawing in sketch or the etch-a-sketch example.
> problem with this method is that if you dont manage your cmd-list or 
> move it to displaylist mode, this can get heavy on the card.
>
Weird, my emails to this list yesterday got completely lost. Anyway, 
Yair, could you elaborate a bit on the display list mode? I've not gone 
down that road before.

as far as my understanding goes, displaylist stores drawing commands

in effect freezing its state and so no new commands are sent. all is on the

i have seen several web references to manipulating stored lists. i dont know

> > if you want to remain in opengl land, check the twineball recipe for

> > curve drawing in sketch or the etch-a-sketch example.

> > problem with this method is that if you dont manage your cmd-list or

> > move it to displaylist mode, this can get heavy on the card.

> Weird, my emails to this list yesterday got completely lost. Anyway,

> Yair, could you elaborate a bit on the display list mode? I've not gone

as far as my understanding goes, displaylist stores drawing commands
(glcolor, glvertex etc.) on the card.
in effect freezing its state and so no new commands are sent. all is on the
card. makes the cpu happy.
i have seen several web references to manipulating stored lists. i dont know
if and who to do it in jitter.

On 3/20/07, Andreas Wetterberg  wrote:
>
> yair reshef skrev:
> > if you want to remain in opengl land, check the twineball recipe for
> > curve drawing in sketch or the etch-a-sketch example.
> > problem with this method is that if you dont manage your cmd-list or
> > move it to displaylist mode, this can get heavy on the card.
> >
> Weird, my emails to this list yesterday got completely lost. Anyway,
> Yair, could you elaborate a bit on the display list mode? I've not gone
> down that road before.
>
> cheers,
> Andreas.
>

I've looked a little bit on the attribute "displaylist" but couldn't find anything for managing it in the tutorials! Can anybody give me a hint on how to use this attribute? I have recognized, that my patch works really hard on my CPU, so this would be really useful.

Like Andreas, I am also not very well informed about managing my cmd-list! Just some patches or other informations could really save my CPU!!;)

Hi there,
I've looked a little bit on the attribute "displaylist" but couldn't find anything for managing it in the tutorials! Can anybody give me a hint on how to use this attribute? I have recognized, that my patch works really hard on my CPU, so this would be really useful.
Like Andreas, I am also not very well informed about managing my cmd-list! Just some patches or other informations could really save my CPU!!;)
Thanks a lot,
Johannes


as far as i can tell, displaylist is just and only a toggle. on and off.

managing cmd_list is a problem we all share.

all i saw from myself and from other maxers who use cmd_lists involve a lot

of jit.iter, plain iter colls and many many bangs..

we still use this method as its the most flixble way for dealing with opengl

i can post a subpatch with one but its nothing involving display_lists.

the main trick is to keep the number of lines in the cmd_list within your

erase some lines or reset completely and redraw the while batch.

my cards where not happy cmd_list with more then say... 215 quads with video

> I've looked a little bit on the attribute "displaylist" but couldn't find

> anything for managing it in the tutorials! Can anybody give me a hint on how

> to use this attribute? I have recognized, that my patch works really hard on

> my CPU, so this would be really useful.

> Like Andreas, I am also not very well informed about managing my cmd-list!

> Just some patches or other informations could really save my CPU!!;)

as far as i can tell, displaylist is just and only a toggle. on and off.
i'd love to hear differently.
managing cmd_list is a problem we all share.
all i saw from myself and from other maxers who use cmd_lists involve a lot
of jit.iter, plain iter colls and many many bangs..
we still use this method as its the most flixble way for dealing with opengl
commands i know of.
i can post a subpatch with one but its nothing involving display_lists.
the main trick is to keep the number of lines in the cmd_list  within your
graphic card capabilities.
erase some lines or reset completely and redraw the while batch.
my cards where not happy cmd_list with more then say... 215 quads with video
texture applied.

On 3/23/07, Johannes  wrote:
>
>
> Hi there,
> I've looked a little bit on the attribute "displaylist" but couldn't find
> anything for managing it in the tutorials! Can anybody give me a hint on how
> to use this attribute? I have recognized, that my patch works really hard on
> my CPU, so this would be really useful.
> Like Andreas, I am also not very well informed about managing my cmd-list!
> Just some patches or other informations could really save my CPU!!;)
> Thanks a lot,
> Johannes
>

If you go into the hundreds of quads realm with calls to glVertex,

it's safe to say your performance will start to suffer. The solution

is vertex buffers which are supported by jit.gl.mesh. Unfortunately,

not all scenarios lend themselves to being rendered by matrices. I

would think JS would be a good way to manage opengl commands because

it's something that lends itself to typical OO or procedural

techniques. There's also jit.gl.lua by the way. In Lua functions are

first class values meaning you can store them as variables and

generate new ones, meaning you can do stuff like this:

                        gl.Vertex(x1, y1, z1)

                        gl.Vertex(x2, y2, z2)

                        drawFunc()

                    end

Of course this code doesn't allow you to remove specific vertices or

save them later, but that could be remedied by saving the functions in

If you go into the hundreds of quads realm with calls to glVertex,
it's safe to say your performance will start to suffer.  The solution
is vertex buffers which are supported by jit.gl.mesh.  Unfortunately,
not all scenarios lend themselves to being rendered by matrices.  I
would think JS would be a good way to manage opengl commands because
it's something that lends itself to typical OO or procedural
techniques.  There's also jit.gl.lua by the way.  In Lua functions are
first class values meaning you can store them as variables and
generate new ones, meaning you can do stuff like this:

function draw()
	gl.Begin("LINES")
		drawVertices()
	gl.End()
end

function drawVertices()
	gl.Vertex(-1, 0, 0)
	gl.Vertex(1, 0, 0)
end

function addLine(x1, y1, z1, x2, y2, z2)
	local drawFunc = drawVertices
	drawVertices = function()
						gl.Vertex(x1, y1, z1)
						gl.Vertex(x2, y2, z2)
						drawFunc()
					end
end

Of course this code doesn't allow you to remove specific vertices or
save them later, but that could be remedied by saving the functions in
a table instead of in a function.

well I searched a little bit more about drawing lines with the help of your hints (THANKS A LOT!!)and so I created this posted patch.

I am not quite sure, if I understood everything well, about saving CPU and "displaylist": Just to disable could save my CPU?

Also my cmd-list worries me a bit! Maybe someone could have a look on the patch? Some hints to make it better would be great!!

Hi there,
well I searched a little bit more about drawing lines  with the help of your hints (THANKS A LOT!!)and so I created this posted  patch.
I am not quite sure, if I understood everything well, about saving CPU and "displaylist": Just to disable could save my CPU?
Also my cmd-list worries me a bit! Maybe someone could have a look on the patch? Some hints to make it better would be great!!
Thans a lot,
Johannes


any chance you could either zip it up or paste it as text in an email.

Patches attached directly always seem to get corrupted for me.

> well I searched a little bit more about drawing lines with the help of your hints (THANKS A LOT!!)and so I created this posted patch.

> I am not quite sure, if I understood everything well, about saving CPU and "displaylist": Just to disable could save my CPU?

> Also my cmd-list worries me a bit! Maybe someone could have a look on the patch? Some hints to make it better would be great!!

any chance you could either zip it up or paste it as text in an email.
 Patches attached directly always seem to get corrupted for me.

On 3/28/07, Johannes  wrote:
> Hi there,
> well I searched a little bit more about drawing lines  with the help of your hints (THANKS A LOT!!)and so I created this posted  patch.
> I am not quite sure, if I understood everything well, about saving CPU and "displaylist": Just to disable could save my CPU?
> Also my cmd-list worries me a bit! Maybe someone could have a look on the patch? Some hints to make it better would be great!!
> Thans a lot,
> Johannes
>
>
>
>


Here is the patch in text-form and also in Zip-version. I hope it will work like that! If not, just tell me and I will send an email directely to you with everything in it.

Hi Wesley!
Here is the patch in text-form and also in Zip-version. I hope it will work like that! If not, just tell me and I will send an email directely to you with everything in it.
Greetings,
Johannes

This is a tricky problem. The displaylist attribute will cause all

commands in a sketch to be built into a displaylist on draw. If you

add new commands, you will trigger a rebuild of the displaylist. This

could potentially cause large drops in framerate.

An alternate solution would be to accumulate the lines in a matrix and

draw them with jit.gl.mesh @draw_mode line_strip. You would keep

track of the last cell containing a point and use jit.submatrix to

send only those cells with data in them to the mesh object. The

drawback with this method is that you'll have a fixed sized buffer of

lines and have to handle the wrapping case when the counter goes back

Also, jit.pwindow eats up quite a bit of CPU. If you don't need it in

This is a tricky problem.  The displaylist attribute will cause all
commands in a sketch to be built into a displaylist on draw.  If you
add new commands, you will trigger a rebuild of the displaylist.  This
could potentially cause large drops in framerate.

An alternate solution would be to accumulate the lines in a matrix and
draw them with jit.gl.mesh @draw_mode line_strip.  You would keep
track of the last cell containing a point and use jit.submatrix to
send only those cells with data in them to the mesh object.  The
drawback with this method is that you'll have a fixed sized buffer of
lines and have to handle the wrapping case when the counter goes back
to 0.

Also, jit.pwindow eats up quite a bit of CPU.  If you don't need it in
your final patch, I wouldn't use it.

thank you very much for your correction! I will have a try with the new patch on my laptop. On my PC I don't have any problems, because the CPU is large enought.

I will go on now with my project, because finally I want to catch the mouvements of two colors and together they should create the lines.

Just what I don't understand is the counter. Because I would have to catch the colors for about one hour and also draw the lines at the same time. So I don't want to erase the lines. I set up the counter to 100000 so that gives me more time but I don't know if this is a good idea. What do you think?

Hey Wesley,
thank you very much for your correction! I will have a try with the new patch on my laptop. On my PC I don't have any problems, because the CPU is large enought.
I will go on now with my project, because finally I want to catch the mouvements of two colors and together they should create the lines.
Just what I don't understand is the counter. Because I would have to catch the colors for about one hour and also draw the lines at the same time. So I don't want to erase the lines. I set up the counter to 100000 so that gives me more time but I don't know if this is a good idea. What do you think?
Big THANKS,
Johannes


Drawing like with a pen (subpixel)