Andy

moving-planes-efficiently-in-opengl

I get 60 fps under all conditions with your patch. You may want to

consider using Javascript or something similar to manage all of this

because if you change on of those subpatches, you're going to end up

doing 16 times the work. In a script, it's one change and you're

done. Either that or try to move as much into the poly~ as possible.

As far as efficiency goes, from what I can tell, each

jit.gl.videoplane instance has the same properties for drawing. You

can greatly improve drawing speed by setting up OpenGL once and

drawing 16 times with the drawraw method as opposed to always

resetting the OpenGL state machine on each draw as is done with the

standard jit.gl.* way of drawing. you can make this happen by using

jit.gl.sketch in combination with the videoplane objects.

> #P flonum 469 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 432 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 395 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 358 452 122 196617 pak scale 0. 0. 0.;

> #P flonum 768 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 732 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 696 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 660 452 118 196617 pak position 0. 0. 0.;

> #P newex 320 491 144 196617 jit.gl.videoplane ken @layer 1;

I get 60 fps under all conditions with your patch.  You may want to
consider using Javascript or something similar to manage all of this
because if you change on of those subpatches, you're going to end up
doing 16 times the work.  In a script, it's one change and you're
done.  Either that or try to move as much into the poly~ as possible.
As far as efficiency goes, from what I can tell, each
jit.gl.videoplane instance has the same properties for drawing.  You
can greatly improve drawing speed by setting up OpenGL once and
drawing 16 times with the drawraw method as opposed to always
resetting the OpenGL state machine on each draw as is done with the
standard jit.gl.* way of drawing.  you can make this happen by using
jit.gl.sketch in combination with the videoplane objects.

On 6/25/07, Andy Brennan  wrote:
>
> You will also need the following.
>
> Many thanks
>
> Andy
>
> max v2;
> #N vpatcher 1149 109 2425 1089;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #N in 5;
> #P newobj 696 329 25 196617 in 5;
> #P newex 696 356 82 196617 t b b b;
> #P newex 768 380 27 196617 0;
> #P newex 732 380 27 196617 -2.;
> #P newex 696 380 27 196617 -2.;
> #N in 4;
> #P newobj 639 329 25 196617 in 4;
> #N in 3;
> #P newobj 603 329 25 196617 in 3;
> #N in 2;
> #P newobj 395 329 25 196617 in 2;
> #P newex 395 356 84 196617 t b b b;
> #P newex 469 380 27 196617 0;
> #P newex 432 380 27 196617 0.2;
> #P newex 395 380 36 196617 -0.16;
> #P flonum 469 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 432 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 395 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 358 452 122 196617 pak scale 0. 0. 0.;
> #P flonum 768 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 732 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 696 428 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 660 452 118 196617 pak position 0. 0. 0.;
> #P newex 320 491 144 196617 jit.gl.videoplane ken @layer 1;
> #N in 7;
> #P newobj 858 329 25 196617 in 7;
> #N in 6;
> #P newobj 822 329 25 196617 in 6;
> #N in 1;
> #P newobj 320 329 25 196617 in 1;
> #P connect 0 0 3 0;
> #P fasten 4 0 3 0 665 480 325 480;
> #P fasten 8 0 3 0 363 480 325 480;
> #P connect 16 0 15 0;
> #P connect 15 0 12 0;
> #P connect 12 0 9 0;
> #P fasten 17 0 9 0 608 411 400 411;
> #P connect 9 0 8 1;
> #P fasten 15 1 13 0 437 376 437 376;
> #P connect 13 0 10 0;
> #P fasten 18 0 10 0 644 411 437 411;
> #P fasten 10 0 8 2 437 446 437 446;
> #P fasten 15 2 14 0 474 376 474 376;
> #P connect 14 0 11 0;
> #P fasten 11 0 8 3 474 446 474 446;
> #P connect 23 0 22 0;
> #P connect 22 0 19 0;
> #P fasten 1 0 5 0 827 407 701 407;
> #P connect 19 0 5 0;
> #P connect 5 0 4 1;
> #P connect 22 1 20 0;
> #P fasten 2 0 6 0 863 407 737 407;
> #P connect 20 0 6 0;
> #P fasten 6 0 4 2 737 447 737 447;
> #P connect 22 2 21 0;
> #P connect 21 0 7 0;
> #P connect 7 0 4 3;
> #P pop;
>
>


I'm not sure in which way to use sketch and videoplane in combination, nor how to use drawraw. Are there any examples/tutorials/documentation that outline this use? I've had a look but can't see anything specific.

Here's a simple example. As you can see things get complicated fast.,

but this is what you have to do if you want to maximize efficiency. I

would recommend using one of the scriping languages for managing this

Here's a simple example.  As you can see things get complicated fast.,
but this is what you have to do if you want to maximize efficiency.  I
would recommend using one of the scriping languages for managing this
kind of thing.

Thanks for that you have been a great help.

I think my main problem in this area is that I do not have a particularly in depth red book knowledge - as I do not understand what aspects of the example patch make it more efficient. I have looked through it before but being a novice at this sort of thing means I don't absorb most of it.

Thanks for that you have been a great help. 

Essentially, when a jitter object draws itself, it resets the entire

opengl state. When it does drawraw, it doesn't do any of this.

Resetting opengl state frequently especially when there is no reason

to (i.e. when drawing lots of the same thing) can be a real

performance bottleneck. Have a look at jit.gl.multiple and try

messing with the targetmode attribute in the help patch. I have a

good graphics card so the difference is only 5fps, but on a lesser

machine or with more objects, the difference would be quite a bit

> Thanks for that you have been a great help.

> I think my main problem in this area is that I do not have a particularly in depth red book knowledge - as I do not understand what aspects of the example patch make it more efficient. I have looked through it before but being a novice at this sort of thing means I don't absorb most of it.

Essentially, when a jitter object draws itself, it resets the entire
opengl state.  When it does drawraw, it doesn't do any of this.
Resetting opengl state frequently especially when there is no reason
to (i.e. when drawing lots of the same thing) can be a real
performance bottleneck.  Have a look at jit.gl.multiple and try
messing with the targetmode attribute in the help patch.  I have a
good graphics card so the difference is only 5fps, but on a lesser
machine or with more objects, the difference would be quite a bit
larger.

On 6/25/07, Andy Brennan  wrote:
>
> Thanks for that you have been a great help.
>
> I think my main problem in this area is that I do not have a particularly in depth red book knowledge - as I do not understand what aspects of the example patch make it more efficient. I have looked through it before but being a novice at this sort of thing means I don't absorb most of it.
>
> Andy
>
>


Interestingly changing the target mode makes absolutely no difference on my machine. The fps fluctuates between 43 and 44 in both states - with default performance settings. The difference between the two does not seem to alter if I change performance settings - the fps changes but again has a 1-2 fps fluctuation in both states. Could this suggest that my graphics card can't handle the task?

> Interestingly changing the target mode makes absolutely no difference on my machine. The fps fluctuates between 43 and 44 in both states - with default performance settings. The difference between the two does not seem to alter if I change performance settings - the fps changes but again has a 1-2 fps fluctuation in both states. Could this suggest that my graphics card can't handle the task?

> My graphics card is an ATI Radeon 9600.

On 6/25/07, Andy Brennan  wrote:
>
> Interestingly changing the target mode makes absolutely no difference on my machine. The fps fluctuates between 43 and 44 in both states - with default performance settings. The difference between the two does not seem to alter if I change performance settings - the fps changes but again has a 1-2 fps fluctuation in both states. Could this suggest that my graphics card can't handle the task?
>
> My graphics card is an ATI Radeon 9600.
>
> Andy
>
>


Quote: wesley.hoke@gmail.com wrote on Mon, 25 June 2007 14:18

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

Unchecked the objects seem to be varying shades of grey.

Checked the objects are all the same colour.

Quote: wesley.hoke@gmail.com wrote on Mon, 25 June 2007 14:18
----------------------------------------------------
> Does the render image change at all?
> wes

Unchecked the objects seem to be varying shades of grey. 

Sorry, I was mistaken in how jit.gl.multiple works internally. Here's

a patch using sketch that actually shows what I was trying to explain.

With uzi set to 100, I see a 15fps difference between draw and

Ah,
Sorry, I was mistaken in how jit.gl.multiple works internally.  Here's
a patch using sketch that actually shows what I was trying to explain.
 With uzi set to 100, I see a 15fps difference between draw and
drawraw.

Yes that does make an improvement of around 6 fps on my system. Can I ask what resources you used to learn his stuff as I think I really should look into it myself and get my head around it. My main problem is that my experience lies more with interactive audio systems design rather than actual in-depth graphics programming, so a lot of the principles that lend to a more successful and efficient application are alien to me.

> Yes that does make an improvement of around 6 fps on my system. Can I ask what resources you used to learn his stuff as I think I really should look into it myself and get my head around it.

- Reading the specs of OpenGL docs like the Redbook and the OpenGL 2.1

http://www.opengl.org/registry/doc/glspec21.20061201.pdf

the man pages for the different functions

- Looking at other people's code like NeHe ( 

- Lot's of practice and trying things out

- Subscribing to various mailing lists like the Apple OpenGL list to

- Reading the specs of OpenGL docs like the Redbook and the OpenGL 2.1
PDF ( http://www.opengl.org/registry/doc/glspec21.20061201.pdf )  Also
the man pages for the different functions
- Looking at other people's code like NeHe ( http://nehe.gamedev.net/ )
- Lot's of practice and trying things out
- Subscribing to various mailing lists like the Apple OpenGL list to
catch tips here and there

Thats great. Thanks a lot for your help. Its been really appreciated.

and may i suggest a few things that didn't come up in this discussion.

1. all your [line] objects will tick away at 20ms (50fps) and that independent of the framerate you're running. better to use your main metro to manually ramp and set scale+positions only once for each frame.

2. remove all those number boxes. with 16 poly voices you've got 100+ updating at 20ms. again those line objects. all gui objects eat framerate.

3. avoid to [pak] scale and positions if possible. you'll get x3 messages for each change. pack is better for collecting and then bang right before you output a frame.

and may i suggest a few things that didn't come up in this discussion.
1. all your [line] objects will tick away at 20ms (50fps) and that independent of the framerate you're running.  better to use your main metro to manually ramp and set scale+positions only once for each frame.
2. remove all those number boxes.  with 16 poly voices you've got 100+ updating at 20ms.  again those line objects.  all gui objects eat framerate.
3. avoid to [pak] scale and positions if possible.  you'll get x3 messages for each change.  pack is better for collecting and then bang right before you output a frame.

Quote: f wrote on Mon, 02 July 2007 11:51

> and may i suggest a few things that didn't come up in this discussion.

> 1. all your [line] objects will tick away at 20ms (50fps) and that independent of the framerate you're running. better to use your main metro to manually ramp and set scale+positions only once for each frame.

> 2. remove all those number boxes. with 16 poly voices you've got 100+ updating at 20ms. again those line objects. all gui objects eat framerate.

> 3. avoid to [pak] scale and positions if possible. you'll get x3 messages for each change. pack is better for collecting and then bang right before you output a frame.

They all seem like good suggestions. I had often wondered if the inclusion of number boxes had any efect. I always kept them in as a way to monitor the system. I'll give them a go.

Quote: f wrote on Mon, 02 July 2007 11:51
----------------------------------------------------
> and may i suggest a few things that didn't come up in this discussion.
> 1. all your [line] objects will tick away at 20ms (50fps) and that independent of the framerate you're running.  better to use your main metro to manually ramp and set scale+positions only once for each frame.
> 2. remove all those number boxes.  with 16 poly voices you've got 100+ updating at 20ms.  again those line objects.  all gui objects eat framerate.
> 3. avoid to [pak] scale and positions if possible.  you'll get x3 messages for each change.  pack is better for collecting and then bang right before you output a frame.
>
> _f
----------------------------------------------------

Sorry to keep this post going but I'm not having much luck in sorting out my problem.

Maybe there is better way of doing what I require that I don't know? - i.e. not moving planes in OpenGL.

(I have tried all suggestions and can't seem to get any significant improvements)

Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential - i.e the amount of time taken from object start to object end position.

I'm going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.

Sorry to keep this post going but I'm not having much luck in sorting out my problem. 

Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential - i.e the amount of time taken from object start to object end position. 

Well, with 16 identical things, graphics programming is probably not

the easiest way to go. I would suggest at the very least using

javascript or if you don't mind diving into something a bit more

involved using jit.gl.lua. The idea would be to model the behavior

you want once and use it 16 times with timing patterns affecting the

> Sorry to keep this post going but I'm not having much luck in sorting out my problem.

> Maybe there is better way of doing what I require that I don't know? - i.e. not moving planes in OpenGL.

> (I have tried all suggestions and can't seem to get any significant improvements)

> Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential - i.e the amount of time taken from object start to object end position.

> I'm going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.

Well, with 16 identical things, graphics programming is probably not
the easiest way to go.  I would suggest at the very least using
javascript or if you don't mind diving into something a bit more
involved using jit.gl.lua.  The idea would be to model the behavior
you want once and use it 16 times with timing patterns affecting the
parameters of the individual objects.

On 7/5/07, Andy Brennan  wrote:
>
> Sorry to keep this post going but I'm not having much luck in sorting out my problem.
>
> Maybe there is better way of doing what I require that I don't know? - i.e. not moving planes in OpenGL.
>
> (I have tried all suggestions and can't seem to get any significant improvements)
>
> Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential - i.e the amount of time taken from object start to object end position.
>
> I'm going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.
>
> Does anybody have any thoughts?
>
> Cheers
>
> Andy
>
>
>


Sorry that should say "graphical programming" not "graphics programing"

> Well, with 16 identical things, graphics programming is probably not

> the easiest way to go. I would suggest at the very least using

> javascript or if you don't mind diving into something a bit more

> involved using jit.gl.lua. The idea would be to model the behavior

> you want once and use it 16 times with timing patterns affecting the

> > Sorry to keep this post going but I'm not having much luck in sorting out my problem.

> > Maybe there is better way of doing what I require that I don't know? - i.e. not moving planes in OpenGL.

> > (I have tried all suggestions and can't seem to get any significant improvements)

> > Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential - i.e the amount of time taken from object start to object end position.

> > I'm going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.

On 7/5/07, Wesley Smith  wrote:
> Well, with 16 identical things, graphics programming is probably not
> the easiest way to go.  I would suggest at the very least using
> javascript or if you don't mind diving into something a bit more
> involved using jit.gl.lua.  The idea would be to model the behavior
> you want once and use it 16 times with timing patterns affecting the
> parameters of the individual objects.
>
> wes
>
> On 7/5/07, Andy Brennan  wrote:
> >
> > Sorry to keep this post going but I'm not having much luck in sorting out my problem.
> >
> > Maybe there is better way of doing what I require that I don't know? - i.e. not moving planes in OpenGL.
> >
> > (I have tried all suggestions and can't seem to get any significant improvements)
> >
> > Essentially all I require is an image, duplicated 16 times, each of which can be scaled and moved independently. The purpose of this is to provide visual information for a rhythm action type game, so timing is essential - i.e the amount of time taken from object start to object end position.
> >
> > I'm going to start experimenting with matrices now instead of OpenGL planes. The downside of this is that I wanted to move as much visual processing onto the GPU as is possible.
> >
> > Does anybody have any thoughts?
> >
> > Cheers
> >
> > Andy
> >
> >
> >
>


There are three methods that jump to mind here which don't involve using any of the scripting languages.

first, as Wesley suggests use sketch. Then use the cmd_replace message to alter your glscale and gltranslate commands;

second, videoplane can run multiple planes using just the one videoplane object - set up the values for each plane and bang them in turn;

and third, you could use poly~. There are a number of ways you could set this up, depending on your circumstances, but you could consider putting an interface to common values inside the poly~ which would affect each of your 16 planes, with the main gl object outside (so you're using only one instance of it).

and third, you could use poly~.  There are a number of ways you could set this up, depending on your circumstances, but you could consider putting an interface to common values inside the poly~ which would affect each of your 16 planes, with the main gl object outside (so you're using only one instance of it).

I am currently using poly~ to create and control 16 copies of the plane. This keeps things tidier but I don't see any increase in efficiency.

Using 1 x videoplane with 16 controls - would this be any more efficient than having 16 individual planes? I imagine so to a degree. I'll give it a go.

Sketch I have little experience with so that could be a possible area of investigation.

I can certainly see the merits of using javascript, the only downfall is my knowledge of the language. I'm hopefully going on a javascript workshop soon which will be enlightening.

My main thoughts around this subject are ones of bewilderment. I can't believe how awkward it is to efficiently move what are effectively 16 sprites around a screen (or is it that I just don't know what I'm doing - I guess not). I have a little experience with "sketch" languages such as "Processing" where doing the sort of thing I am trying to do would be easy - the only downfall is that it doesn't offer a lot of the other things I require my app to do.

Fortunately I have managed to use all your advise (cheers guys) to tweak my patch so it works to an acceptable level.

Using 1 x videoplane with 16 controls - would this be any more efficient than having 16 individual planes? I imagine so to a degree. I'll give it a go. 

I can certainly see the merits of using javascript, the only downfall is my knowledge of the language. I'm hopefully going on a javascript workshop soon which will be enlightening.  

Fortunately I have managed to use all your advise (cheers guys) to tweak my patch so it works to an acceptable level.    

It's more efficient if you use the drawraw method of videoplane

instead of the draw method. Otherwise it will only be marginally more

efficient instead of significantly. You'll probably want to use

jit.gl.sketch in conjunction with jit.gl.videoplane for this.

> I am currently using poly~ to create and control 16 copies of the plane. This keeps things tidier but I don't see any increase in efficiency.

> Using 1 x videoplane with 16 controls - would this be any more efficient than having 16 individual planes? I imagine so to a degree. I'll give it a go.

> Sketch I have little experience with so that could be a possible area of investigation.

> I can certainly see the merits of using javascript, the only downfall is my knowledge of the language. I'm hopefully going on a javascript workshop soon which will be enlightening.

> My main thoughts around this subject are ones of bewilderment. I can't believe how awkward it is to efficiently move what are effectively 16 sprites around a screen (or is it that I just don't know what I'm doing - I guess not). I have a little experience with "sketch" languages such as "Processing" where doing the sort of thing I am trying to do would be easy - the only downfall is that it doesn't offer a lot of the other things I require my app to do.

> Fortunately I have managed to use all your advise (cheers guys) to tweak my patch so it works to an acceptable level.

It's more efficient if you use the drawraw method of videoplane
instead of the draw method.  Otherwise it will only be marginally more
efficient instead of significantly.  You'll probably want to use
jit.gl.sketch in conjunction with jit.gl.videoplane for this.

On 7/6/07, Andy Brennan  wrote:
>
> I am currently using poly~ to create and control 16 copies of the plane. This keeps things tidier but I don't see any increase in efficiency.
>
> Using 1 x videoplane with 16 controls - would this be any more efficient than having 16 individual planes? I imagine so to a degree. I'll give it a go.
>
> Sketch I have little experience with so that could be a possible area of investigation.
>
> I can certainly see the merits of using javascript, the only downfall is my knowledge of the language. I'm hopefully going on a javascript workshop soon which will be enlightening.
>
> My main thoughts around this subject are ones of bewilderment. I can't believe how awkward it is to efficiently move what are effectively 16 sprites around a screen (or is it that I just don't know what I'm doing - I guess not). I have a little experience with "sketch" languages such as "Processing" where doing the sort of thing I am trying to do would be easy - the only downfall is that it doesn't offer a lot of the other things I require my app to do.
>
> Fortunately I have managed to use all your advise (cheers guys) to tweak my patch so it works to an acceptable level.
>
> Thanks a lot
>
> Andy
>


plus, you could lower the dimensions of jit.gl.videoplane, it 

defaults to 20x20 vertices, but 2x2 should be enough:

plus, you could lower the dimensions of jit.gl.videoplane, it  
defaults to 20x20 vertices, but 2x2 should be enough:

Moving planes efficiently in OpenGL