smooth animation test

Jan 18, 2006 at 9:59pm

smooth animation test

I really like to clear some things up about the patch below. My problem is:

- 40fps doesn’t look smooth, even though there is almost nothing going on
and my cpu is at 7%
- raising it to 60fps makes it smooth but kills the max interface.

I don’t want to believe that jitter can’t generate this simple animation
fluently on my computer. I can’t raise the framerate to 60 because it’ll
kill my cpu if I want to do more interesting stuff than this. I really hope
there is something wrong about the way I’m experiencing this patch, please
have a look.

t_

winmax 4.5.6, jitter 1.5.2, nvidia go6800, pentium m1.86, 1gig ram.

#P window setfont Tahoma 10.;
#P window linecount 2;
#P comment 782 149 100 12779530 menubar is almost non-responsive;
#P user hslider 452 74 18 128 128 1 0 0;
#P window linecount 3;
#P comment 678 230 100 12779530 not smooth , eventhough running at 40fps;
#P window linecount 1;
#P message 612 235 55 12779530 25;
#P message 612 148 55 12779530 10;
#P hidden newex 546 311 50 12779530 loadbang;
#P message 524 360 72 12779530 lookat 0. 0. -10;
#P message 599 360 46 12779530 fsaa 1;
#P window setfont “Sans Serif” 9.;
#P user jit.fpsgui 294 169 60 9109513 0;
#P window setfont Tahoma 10.;
#P message 440 285 88 12779530 camera $1 0. 2;
#P message 440 221 55 12779530 -1 , 1 4000;
#P message 401 222 35 12779530 stop;
#P newex 440 254 50 12779530 line 0.;
#P window setfont “Fixedwidth Serif” 10.;
#P message 401 360 113 9240586 read mushrooms.obj;
#P user jit.pwindow 8 203 347 233 0 1 0 0 1 1;
#X name ml;
#P message 9 180 140 9240586 name ml , depthbuffer 1;
#P newex 19 88 73 9240586 t b b erase;
#P newex 384 412 128 9240586 jit.gl.model ml;
#B color 5;
#P window setfont “Proportional Serif” 10.;
#P comment 34 44 70 9175050 Start Rendering;
#P window setfont “Fixedwidth Serif” 10.;
#P newex 19 64 62 9240586 qmetro 10;
#P toggle 19 43 15 0;
#P newex 19 133 272 9240586 jit.gl.render ml @erase_color 0.5 0.3 0.2 1.;
#B color 5;
#P user panel 9 35 346 129;
#X brgb 247 99 169;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P window setfont Tahoma 10.;
#P window linecount 5;
#P comment 678 129 100 12779530 60fps looks smooth but reduced max ui
response;
#P window linecount 2;
#P comment 453 43 100 12779530 check interface response;
#P connect 9 0 10 0;
#P hidden connect 17 0 10 0;
#P connect 4 0 5 0;
#P connect 5 0 8 0;
#P connect 8 0 3 0;
#P fasten 8 2 3 0 86 116 24 116;
#P connect 15 0 3 0;
#P hidden connect 18 0 3 0;
#P hidden connect 20 0 5 1;
#P hidden connect 21 0 5 1;
#P connect 8 1 16 0;
#P fasten 11 0 7 0 406 393 389 393;
#P hidden connect 19 0 11 0;
#P hidden connect 19 0 14 0;
#P connect 12 1 14 0;
#P connect 13 0 12 0;
#P connect 14 0 12 0;
#P connect 12 0 15 0;
#P hidden connect 19 0 18 0;
#P hidden connect 19 0 17 0;
#P window clipboard copycount 25;

#23988
Jan 18, 2006 at 11:12pm

Try connecting a number box to the right inlet of [line] and sending it
some low values – around 1 or 2. The default time grain for [line] is
20ms, which could be the problem. Feeding it a time grain of 1ms
smooths things right out on my machine (Max 4.5.6, Jitter 1.5.2 ,1.5Ghz
AluBook OSX.3.9). – David

#68680
Jan 18, 2006 at 11:58pm

I forgot to set the interval for the test patch. In my own patch I had it at
5ms, and it helps, but doesn’t completely smooth out the animation. Still 60
fps runs a lot smoother. I this also true on your powerbook? I don’t
understand why this can’t run perfectly smooth at 30 or even 40 fps.

t_

#68681
Jan 19, 2006 at 12:20am

Well, on my machine the jerkiness was very minimal to begin with – no
large hesitations or jumps – just some chunky movement at the rate of
the [line] time grain. 60 fps looks pretty much the same for me,
although the responsiveness of the UI does take a hit, of course. Is
the rough rendering really dramatic on your system?

#68682
Jan 19, 2006 at 9:27am

No it’s not dramatic at all, but noticeable. I just don’t understand why it
has to be this way. A framerate of 30 fps with just one moving object is not
a lot to process. You can do far more complex jitter and max processing
without this getting worse, so I guess it’s just always there. If Jitter can
do all this fancy stuff, I don’t understand why a simple smooth animation at
a normal framerate is impossible. Maybe it has to do with the low priority
jitter processing? O well, so be it.

t_

#68683
Jan 19, 2006 at 7:55pm

You can definitely get “smooth” animations if you work at it. It’s
complex because there are many ways to approach timing in your Jitter
patch, some of which won’t be so smooth. My current approach is to
run everything as closely to the DSP as possible. A single train~
object generates bangs which are sent to a dsptime~ object that
clocks my patch, including spatial things. Scheduler in audio
interrupt and overdrive are on. This works well for me– and like
yourself, I am cursed with an eye for detail.

-Randy

#68684
Jan 19, 2006 at 8:43pm

That’s good news! I’ll give it a try tomorrow. Hopefully I can integrate
something like that into my patches without too many adaptions. It’s also
good to know that I’m not the only one who cares about stuff like this.

Best, Thijs

#68685
Jan 23, 2006 at 2:23pm

Or forget using [line] and use [bline] – looks very smooth on my
computer, without having to write your own audio-rate clocking system.
If that’s a little jumpy, you can always throw in a [jit.qball]
somewhere to smooth out the rate of incoming bangs.

here’s what I mean:

> #P window setfont Tahoma 10.;
> #P window linecount 2;
> #P comment 782 149 100 431423498 menubar is almost non-responsive;
> #P user hslider 452 74 18 128 128 1 0 0;
> #P window linecount 3;
> #P comment 678 230 100 431423498 not smooth , eventhough running at
> 40fps;
> #P window linecount 1;
> #P message 612 235 55 431423498 25;
> #P message 612 148 55 431423498 10;
> #P hidden newex 546 311 50 431423498 loadbang;
> #P message 524 360 72 431423498 lookat 0. 0. -10;
> #P message 599 360 46 431423498 fsaa 1;
> #P window setfont “Sans Serif” 9.;
> #P user jit.fpsgui 294 169 60 196617 0;
> #P window setfont Tahoma 10.;
> #P message 440 285 88 431423498 camera $1 0. 2;
> #P message 440 221 55 431423498 -1 , 1 400;
> #P message 401 222 35 431423498 stop;
> #P newex 440 254 50 431423498 bline 0.;
> #P window setfont “Fixedwidth Serif” 10.;
> #P message 401 360 113 1441802 read mushrooms.obj;
> #P user jit.pwindow 8 203 347 233 0 1 0 0 1 1;
> #X name ml;
> #P message 9 180 140 1441802 name ml , depthbuffer 1;
> #P newex 19 88 73 1441802 t b b erase;
> #P newex 384 412 128 1441802 jit.gl.model ml;
> #B color 5;
> #P window setfont “Proportional Serif” 10.;
> #P comment 34 44 70 131727370 Start Rendering;
> #P window setfont “Fixedwidth Serif” 10.;
> #P newex 19 64 62 1441802 qmetro 10;
> #P toggle 19 43 15 0;
> #P newex 19 133 272 1441802 jit.gl.render ml @erase_color 0.5 0.3 0.2
> 1.;
> #B color 5;
> #P user panel 9 35 346 129;
> #X brgb 247 99 169;
> #X frgb 0 0 0;
> #X border 0;
> #X rounded 0;
> #X shadow 0;
> #X done;
> #P window setfont Tahoma 10.;
> #P window linecount 5;
> #P comment 678 129 59 431423498 60fps looks smooth but reduced max ui
> response;
> #P window linecount 2;
> #P comment 453 43 100 431423498 check interface response;
> #P connect 8 1 16 0;
> #P connect 8 1 12 0;
> #P connect 12 1 14 0;
> #P connect 13 0 12 0;
> #P connect 14 0 12 0;
> #P connect 12 0 15 0;
> #P hidden connect 19 0 11 0;
> #P hidden connect 19 0 14 0;
> #P hidden connect 19 0 18 0;
> #P hidden connect 19 0 17 0;
> #P fasten 11 0 7 0 406 393 389 393;
> #P hidden connect 21 0 5 1;
> #P hidden connect 20 0 5 1;
> #P hidden connect 18 0 3 0;
> #P connect 15 0 3 0;
> #P fasten 8 2 3 0 86 116 24 116;
> #P connect 8 0 3 0;
> #P connect 5 0 8 0;
> #P connect 4 0 5 0;
> #P hidden connect 17 0 10 0;
> #P connect 9 0 10 0;
> #P window clipboard copycount 25;

#68686
Jan 23, 2006 at 8:18pm

That is a really nice and easy solution if you’re doing animation that isn’t
time sync. I need it to be as time sync as possible. On my system the two
different framerates automatically create different speeds in movement. The
inconsistency in position is solved but by sacrificing overall timing
accuracy. I think the actual problem still remains, which would be the
timing of rendering bangs/events. Or am I missing something?

Thijs

#68687
Jan 23, 2006 at 8:35pm

changing the millisecond sampling rate for line didnt solve this?

v a d e //

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

#68688
Jan 23, 2006 at 9:52pm

On 1/23/06, vade wrote:

> changing the millisecond sampling rate for line didnt solve this?

No not really. On my system 60fps looks smoother than 40fps, even with 1ms
line interval. I think Randy’s solution is the only way to go, but I
haven’t found the time to try it yet.

Thijs

#68689

You must be logged in to reply to this topic.