Can I make this smoother?

Oct 10, 2006 at 6:47pm

Can I make this smoother?

Hi,

This is a simple patch that moves a large image on a videoplane around in
space. For the most part it moves fairly smoothly, but every so often it
has a choppy movement. I’m obviously not managing the processing
correctly. I’ve tried it with overdrive on/off, qmetro, and loadram.

Could the problem be the way I am generating numbers? Is 1200 x 1200 too
big?

Any suggestions? I’m not sure what else to try.

Max 4.6.1 Jitter 1.6.1
Mac 10.4.7 1.67 Ghz Power PC G4 1 GB ram 128 Vram

Again, any suggestions much appreciated.

Bart

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 468 150 14 196617 1;
#P newex 468 112 48 196617 loadbang;
#P hidden newex 952 282 38 196617 sel 53;
#P hidden newex 937 261 40 196617 key;
#P button 903 101 15 0;
#P newex 903 121 30 196617 t b b;
#P message 484 150 14 196617 0;
#P message 952 202 39 196617 -2000;
#P message 925 202 26 196617 500;
#P message 898 202 26 196617 500;
#P toggle 484 169 15 0;
#P newex 18 63 52 196617 metro 20;
#P toggle 1024 305 15 0;
#P message 1024 322 44 196617 fsaa $1;
#P newex 724 270 113 196617 scale 0 1000 0.8 1.2;
#P message 724 232 55 196617 $1 28000;
#P newex 724 211 70 196617 random 1000;
#N vpatcher 95 230 695 630;
#P outlet 76 359 15 0;
#P inlet 76 49 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 163 144 39 196617 t b f;
#P message 163 117 20 196617 $1;
#P newex 76 244 29 196617 tanh;
#P newex 76 306 158 196617 scale -0.986614 0.986614 0. 1.;
#P message 76 117 67 196617 -2.5 , 2.5 $2;
#P newex 163 233 27 196617 f;
#P newex 76 214 53 196617 line 0. 20;
#P connect 7 0 2 0;
#P connect 2 0 0 0;
#P connect 0 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 8 0;
#P connect 7 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 1 0;
#P connect 1 0 3 3;
#P fasten 3 0 1 1 81 339 274 339 274 213 185 213;
#P connect 6 1 3 4;
#P pop;
#P newobj 724 250 66 196617 p tanh_ramp;
#P newex 484 188 70 196617 metro 28000;
#P newex 604 270 117 196617 scale 0 1000 -0.8 0.8;
#P message 604 232 55 196617 $1 28000;
#P newex 604 211 70 196617 random 1000;
#N vpatcher 95 230 695 630;
#P outlet 76 359 15 0;
#P inlet 76 49 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 163 144 39 196617 t b f;
#P message 163 117 20 196617 $1;
#P newex 76 244 29 196617 tanh;
#P newex 76 306 158 196617 scale -0.986614 0.986614 0. 1.;
#P message 76 117 67 196617 -2.5 , 2.5 $2;
#P newex 163 233 27 196617 f;
#P newex 76 214 53 196617 line 0. 20;
#P connect 7 0 2 0;
#P connect 2 0 0 0;
#P connect 0 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 8 0;
#P connect 7 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 1 0;
#P connect 1 0 3 3;
#P fasten 3 0 1 1 81 339 274 339 274 213 185 213;
#P connect 6 1 3 4;
#P pop;
#P newobj 604 250 66 196617 p tanh_ramp;
#P newex 484 270 117 196617 scale 0 1000 -0.8 0.8;
#P message 484 232 55 196617 $1 28000;
#P newex 484 211 70 196617 random 1000;
#N vpatcher 95 230 695 630;
#P outlet 76 359 15 0;
#P inlet 76 49 15 0;
#P window setfont “Sans Serif” 9.;
#P newex 163 144 39 196617 t b f;
#P message 163 117 20 196617 $1;
#P newex 76 244 29 196617 tanh;
#P newex 76 306 158 196617 scale -0.986614 0.986614 0. 1.;
#P message 76 117 67 196617 -2.5 , 2.5 $2;
#P newex 163 233 27 196617 f;
#P newex 76 214 53 196617 line 0. 20;
#P connect 7 0 2 0;
#P connect 2 0 0 0;
#P connect 0 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 8 0;
#P connect 7 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 1 0;
#P connect 1 0 3 3;
#P fasten 3 0 1 1 81 339 274 339 274 213 185 213;
#P connect 6 1 3 4;
#P pop;
#P newobj 484 250 66 196617 p tanh_ramp;
#P toggle 952 305 15 0;
#P message 952 322 70 196617 fullscreen $1;
#P newex 952 343 76 196617 jit.window red;
#P newex 72 125 196 196617 jit.gl.render red @erase_color 0. 0. 0. 1.;
#P newex 18 102 66 196617 t b b b erase;
#P toggle 18 30 28 0;
#P newex 455 297 99 196617 pak position 0. 0. 0.;
#P message 335 279 30 196617 read;
#P newex 335 297 117 196617 jit.qt.movie 1200 1200;
#P window linecount 2;
#P newex 335 319 245 196617 jit.gl.videoplane red @automatic 0 @interp 1
@scale 1.333 1.333 1. @depth_enable 1 @blend_enable 1;
#P window linecount 1;
#P comment 919 103 165 196617 < <

#P comment 501 170 221 196617 < <

#P comment 183 280 187 196617 load in a 1200×1200 tif file >>>;
#P connect 21 0 14 0;
#P fasten 21 0 18 0 489 208 609 208;
#P fasten 21 0 23 0 489 208 729 208;
#P connect 29 0 21 0;
#P connect 28 0 8 0;
#P fasten 39 0 29 0 473 167 489 167;
#P connect 38 0 39 0;
#P connect 27 0 26 0;
#P connect 11 0 10 0;
#P fasten 26 0 10 0 1029 340 957 340;
#P connect 12 0 11 0;
#P hidden connect 37 0 12 0;
#P hidden connect 36 1 37 0;
#P connect 34 0 30 0;
#P connect 34 0 31 0;
#P connect 34 0 32 0;
#P connect 35 0 34 0;
#P connect 22 0 25 0;
#P connect 24 0 22 0;
#P connect 23 0 24 0;
#P fasten 32 0 24 0 957 230 729 230;
#P connect 17 0 20 0;
#P connect 19 0 17 0;
#P connect 18 0 19 0;
#P fasten 31 0 19 0 930 230 609 230;
#P fasten 25 0 6 3 729 292 547 292;
#P fasten 20 0 6 2 609 292 518 292;
#P connect 16 0 6 1;
#P connect 13 0 16 0;
#P connect 15 0 13 0;
#P connect 14 0 15 0;
#P fasten 30 0 15 0 903 230 489 230;
#P connect 33 0 29 0;
#P fasten 34 1 33 0 928 145 489 145;
#P connect 4 0 3 0;
#P fasten 6 0 3 0 460 316 340 316;
#P fasten 8 2 3 0 59 316 340 316;
#P connect 5 0 4 0;
#P fasten 8 0 9 0 23 122 77 122;
#P fasten 8 3 9 0 77 124 77 124;
#P connect 7 0 28 0;
#P window clipboard copycount 40;

#28068
Oct 10, 2006 at 7:21pm

On Oct 10, 2006, at 1:47 PM, bart woodstrup wrote:

>
> Hi,
>
> This is a simple patch that moves a large image on a videoplane
> around in space. For the most part it moves fairly smoothly, but
> every so often it has a choppy movement. I’m obviously not
> managing the processing correctly. I’ve tried it with overdrive on/
> off, qmetro, and loadram.
>
> Could the problem be the way I am generating numbers? Is 1200 x
> 1200 too big?

Well, a little multiplication might suggest you’re um… moving
some memory around (1200 x 1200 x 4). Considering that my
pal Andrew sitting next to me can’t even get it to load on the
graphics card on his G5/G4 6800 machine, you might
consider… using uyvy and qmetro instead of metro, and setting
the dimensions of your videoplane to 2×2, and – finally – using
@transform_reset 2.

SInce you’re using a square texture, Andrew suggests scaling
your texture to a power of 2, and turning rect_tex to 0. He’s
brighter than I am, so I’ll take his word for it.

#85763
Oct 10, 2006 at 7:32pm

hes only banging the jit.qt.movie once (the read should be read, bang
btw otherwise the jit.qt.movie doesnt output anything), and the
texture is being uploaded only once. perhaps texture mode static
might help

you ought to be using qmetro rather than metro to draw to openGL.
using metro to trigger openGL isn’t ‘safe’.

uyvy will def reduce the size of the texture, and the videoplane is
defaulting to dim 20 20, I don’t think thats the issue.

You have a redudnant scale operation which which probably doesnt
matter (the scale in the p tanh and right after), though it helps
readability.

is this a part of a larger patch?

it seems to run fine on my powerbook G4 1.67. WHat kind of a machine
are you running on?

v a d e //

http://www.vade.info
abstrakt.vade.info

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I
LIVE! I LIVE! I LIVE! I LIVE!

You will not be saved by the Holy Ghost. You will not be saved by the
God Plutonium.

In fact, YOU WILL NOT BE SAVED!

On Oct 10, 2006, at 3:21 PM, Gregory Taylor wrote:

>
> On Oct 10, 2006, at 1:47 PM, bart woodstrup wrote:
>
>>
>> Hi,
>>
>> This is a simple patch that moves a large image on a videoplane
>> around in space. For the most part it moves fairly smoothly, but
>> every so often it has a choppy movement. I’m obviously not
>> managing the processing correctly. I’ve tried it with overdrive
>> on/off, qmetro, and loadram.
>>
>> Could the problem be the way I am generating numbers? Is 1200 x
>> 1200 too big?
>
> Well, a little multiplication might suggest you’re um… moving
> some memory around (1200 x 1200 x 4). Considering that my
> pal Andrew sitting next to me can’t even get it to load on the
> graphics card on his G5/G4 6800 machine, you might
> consider… using uyvy and qmetro instead of metro, and setting
> the dimensions of your videoplane to 2×2, and – finally – using
> @transform_reset 2.
>
> SInce you’re using a square texture, Andrew suggests scaling
> your texture to a power of 2, and turning rect_tex to 0. He’s
> brighter than I am, so I’ll take his word for it.
>
>
>

#85764
Oct 11, 2006 at 1:02am

Thanx, for the advice! The “metro instead of qmetro” and “read, bang” were
results of me sloppily editing the patch for the list. I tried uyvy and
didn’t notice much difference. This is a part of a larger patch, but this
effect happens without any of the other code.

However, I am interested in trying a few of these suggestions. I haven’t
seen some of these attributes before, could someone enlighten me a little
about them?

What is “transform_reset”? “rect_tex”?

Your suggestion of scaling the image to a power of 2 – you mean I should try
a 600 x 600 image scaled to a power of two? How does rect_tex affect that?

Here’s my machine: Mac 10.4.7 1.67 Ghz Power PC G4 1 GB ram 128 Vram

I suppose the stuttering I intermittently see could be from something that
is happening outside of Jitter, but I am not running anything… A friend
of mine who knows OpenGL (but not Jitter) looked at it in Shark but didn’t
see anything peculiar.

Maybe I have bad eyes? ha – actually it’s easily noticeable when
projected.

Thanks.

Bart

On 10/10/06, Gregory Taylor wrote:
>
>
> On Oct 10, 2006, at 1:47 PM, bart woodstrup wrote:
>
> >
> > Hi,
> >
> > This is a simple patch that moves a large image on a videoplane
> > around in space. For the most part it moves fairly smoothly, but
> > every so often it has a choppy movement. I’m obviously not
> > managing the processing correctly. I’ve tried it with overdrive on/
> > off, qmetro, and loadram.
> >
> > Could the problem be the way I am generating numbers? Is 1200 x
> > 1200 too big?
>
> Well, a little multiplication might suggest you’re um… moving
> some memory around (1200 x 1200 x 4). Considering that my
> pal Andrew sitting next to me can’t even get it to load on the
> graphics card on his G5/G4 6800 machine, you might
> consider… using uyvy and qmetro instead of metro, and setting
> the dimensions of your videoplane to 2×2, and – finally – using
> @transform_reset 2.
>
> SInce you’re using a square texture, Andrew suggests scaling
> your texture to a power of 2, and turning rect_tex to 0. He’s
> brighter than I am, so I’ll take his word for it.
>
>
>
>


bartwoodstrup.com
vodstrup.com

#85765
Oct 11, 2006 at 1:13am

perhaps thats the key. When you project you are probably running 2
monitors, whichs splits your vram in two, so you have 64 Mb for
monitor a and b, in other words, half your vram?

Ive got the exact same system, maybe ill try it later on the second
monitor.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Oct 10, 2006, at 9:02 PM, bart woodstrup wrote:

> Thanx, for the advice! The “metro instead of qmetro” and “read,
> bang” were results of me sloppily editing the patch for the list.
> I tried uyvy and didn’t notice much difference. This is a part of
> a larger patch, but this effect happens without any of the other code.
>
> However, I am interested in trying a few of these suggestions. I
> haven’t seen some of these attributes before, could someone
> enlighten me a little about them?
>
> What is “transform_reset”? “rect_tex”?
>
> Your suggestion of scaling the image to a power of 2 – you mean I
> should try a 600 x 600 image scaled to a power of two? How does
> rect_tex affect that?
>
> Here’s my machine: Mac 10.4.7 1.67 Ghz Power PC G4 1 GB ram 128 Vram
>
>
> I suppose the stuttering I intermittently see could be from
> something that is happening outside of Jitter, but I am not running
> anything… A friend of mine who knows OpenGL (but not Jitter)
> looked at it in Shark but didn’t see anything peculiar.
>
> Maybe I have bad eyes? ha – actually it’s easily noticeable when
> projected.
>
> Thanks.
>
> Bart
>
>
> On 10/10/06, Gregory Taylor < gtaylor@rtqe.net> wrote:
>
> On Oct 10, 2006, at 1:47 PM, bart woodstrup wrote:
>
> >
> > Hi,
> >
> > This is a simple patch that moves a large image on a videoplane
> > around in space. For the most part it moves fairly smoothly, but
> > every so often it has a choppy movement. I’m obviously not
> > managing the processing correctly. I’ve tried it with overdrive on/
> > off, qmetro, and loadram.
> >
> > Could the problem be the way I am generating numbers? Is 1200 x
> > 1200 too big?
>
> Well, a little multiplication might suggest you’re um… moving
> some memory around (1200 x 1200 x 4). Considering that my
> pal Andrew sitting next to me can’t even get it to load on the
> graphics card on his G5/G4 6800 machine, you might
> consider… using uyvy and qmetro instead of metro, and setting
> the dimensions of your videoplane to 2×2, and – finally – using
> @transform_reset 2.
>
> SInce you’re using a square texture, Andrew suggests scaling
> your texture to a power of 2, and turning rect_tex to 0. He’s
> brighter than I am, so I’ll take his word for it.
>
>
>
>
>
>
> —
> bartwoodstrup.com
> vodstrup.com

#85766

You must be logged in to reply to this topic.