1600x1200 horizontal continuous scrolling panorama


    Mar 23 2006 | 5:16 pm
    Hi all,
    I have made a patch with the purpose of showing a panorama which continuously scrolls left or right. The way I've done it now is cutting up a large photograph in 4 pieces. Each piece is placed on an 3d plane and when a plane goes out of view to the left, it is put after the last plane on the right (and the other way around). Your basic endless scrolling.
    I've put the patch here http://www.autofasurer.net/panoscroll/ since it is 2.9Mb
    I'm quite satisfied with the speed of this (running 60fps on an 1.9Ghz Imac G5 with 512ram) but I was wondering if my approach is maybe still "slow" and if so how this could be optimised.
    Any comments are appreciated. Feel free to use the patch, please note though that the pictures are copyrighted.
    B.

    • Mar 23 2006 | 9:25 pm
      Hi Brecht,
      Fundamentally from a rendering standpoint, there's not a lot of
      performance gains to be had by any other method, though you might
      gain slightly faster render times by using one instance of
      jit.gl.sketch and a shapeslice of 2 2, instead of the default 20x20
      grid which is being rendered with the plane command. You might also
      be able to simplify your math somewhat using the "jit.gl.render
      @ortho 2" orthographic projection rather than the fudge code to
      handle the default perspective transform.
      Where you will gain noticeable performance improvements is by
      eliminating the many number boxes and buttons which are consistently
      updating. While useful when creating and debugging these patches,
      they can easily become performance bottlenecks and lead to more
      staggered output. I was able to improve the performance significantly
      by replacing all buttons with "t b" (trigger bang), and replacing all
      flonum with the float object and all integer number boxes with the
      int object. This is easily done after the fact to many copies with
      the "paste replace" command. I've included the updated version of
      your patch below.
      Lastly, for smoothest animation which doesn't seem to change speeds
      as the framerate fluctuates, I would recommend driving your animation
      with the output of cpuclock. Updating by some scaled amount of the
      delta time between consecutive polls of the current time (See the
      cputimer subpatch of cpuclock.help for an example of obtaining the
      delta time). This is the most accurate way to perform animation for
      realtime processing (for non-realtime processing, your current
      approach is preferable).
      Hope this helps.
      -Joshua
      max v2;
    • Mar 23 2006 | 10:49 pm
      Thanks Joshua,
      Every little improvement helps! The reason I asked is that I need to
      add a HUD and some hardware interface interpretation stuff so I'll
      lose some performance when these are implemented.
      I see what you mean with the number boxes, I haven't checked on the
      Imac, but on a powerbook 12" with lesser graphics card mine got 44-
      ish fps, yours almost 60 ?!
      Does the elimination of the float and int still have any effect? I
      expect that if you have a lot of these the amount of unnecessary
      memory that is reserved can run up....
      Never used the cputimer, but it sounds like I'll want one of those
      more often.
      About the perspecive, there's one thing that struck me though and
      that's the fact that the textures seemed to be upside down (hence the
      @up 0 -1 0)... Am I missing something here?
      Thanks for the tips, it's always interesting to learn new tricks to
      improve performance...!
      grtz, Brecht.
    • Mar 23 2006 | 11:07 pm
      On Mar 23, 2006, at 2:49 PM, Brecht Debackere wrote:
      > Every little improvement helps! The reason I asked is that I need
      > to add a HUD and some hardware interface interpretation stuff so
      > I'll lose some performance when these are implemented.
      > I see what you mean with the number boxes, I haven't checked on the
      > Imac, but on a powerbook 12" with lesser graphics card mine got 44-
      > ish fps, yours almost 60 ?!
      Btw, I get 80-90fps with jit.window @sync 0. (60fps is the limit of
      synchronized monitor refreshing), so it's essentially 2x faster.
      > Does the elimination of the float and int still have any effect? I
      > expect that if you have a lot of these the amount of unnecessary
      > memory that is reserved can run up....
      Probably not anything measurable. The biggest problem is lots of UI
      objects updating.
      > About the perspecive, there's one thing that struck me though and
      > that's the fact that the textures seemed to be upside down (hence
      > the @up 0 -1 0)... Am I missing something here?
      No the default texture coordinates for plane have always been as
      such. You can easily "roll your own" with whatever orientation you
      see fit with an explicit vertex list using glbegin, glvertex,
      gltexcoord, glend instead of the plane command.
      -Joshua
    • Mar 23 2006 | 11:09 pm
      FWIW, 110-120 fps with a faster qmetro with sync off.
      -Joshua
    • Mar 24 2006 | 12:00 am
      sweet!
    • Mar 30 2006 | 4:30 am
      For fun I was playing with Brecht's patch and I was curious if there was a way to overlay/alphablend video onto the scrolling panorama. I cut/paste a jit.gl.videoplane that I use for most of my blending - it works at first but not after a save/reopen. I assume there's a hierachy to the planes? I've attached a screenshot of what it looks like - the flower image is in the jit.gl.videoplane and the mountain image is being drawn to jit.sketch. code is below... If anyone can set me on the right path for doing something of this sort it would be appreciated.
      Also, JKC mentioned the use of a "cpuclock" to drive animations for realtime. Is this anymore efficient or is it just to keep a steady framerate?
      www.bartwoodstrup.com
    • Mar 30 2006 | 5:02 am
      added 'automatic 0' to strictly control render order, added
      blend_enable 1 to the jit.gl.sketch's and used alpha of the video
      plane to control blending.
      enjoy.
      max v2;
      v a d e //
      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!
    • Mar 30 2006 | 9:05 am
      Like Joshua said, it provides a steadier way to animate realtime. Ultimately I believe it gives you more control over animating multiple objects over a certain nr. of frames, say 2 bouncing balls with a different speed. This way they will always move the same over time and in relation to eachother.
    • Mar 30 2006 | 9:29 am
      thanks vade/Brecht works fine and I can add multiple vidplanes w/o problems. Is
      there an organized list of the gl attributes and their associations in the c74 manual
      or tutorial? I've never seen a "list." Does the naming convention of
      the attributes match the "Red Book" terminology in a self-explanatory
      way? Sorry - I probably could answer these questions on my own with a little bit
      of research, except in the case the answers were "no's."
      thx again
      bart
      -----Original Message-----
      >From: Brecht
      >Sent: Mar 30, 2006 4:05 AM
      >Subject: [jitter] Re: 1600x1200 horizontal continuous scrolling panorama
      >
      >
      >Like Joshua said, it provides a steadier way to animate realtime. Ultimately I believe it gives you more control over animating multiple objects over a certain nr. of frames, say 2 bouncing balls with a different speed. This way they will always move the same over time and in relation to eachother.
      www.bartwoodstrup.com
    • Mar 30 2006 | 9:54 am
      On mac ctrl-alt-clicking an object will present a menu with all the attributes and arguments of any object. on PC I think it's just ctrl-click.
      The naming convention of the attributes (like in the html reference where it says "see red book") is the same as the OpenGL commands, though
      these mostly don't "just" work, they have to be used in the right way... (I'm not exactly clear on the exact use of all, but messing around with openGL gives some good insights in how things work, especially when trying some stuff in c or c++ using Xcode and the GLUT library a nice tutorial can be found here : http://onesadcookie.com/Tutorials)... the openGL manuals can be found here : blue book (reference) http://www.opengl.org/documentation/blue_book/ and redbook (programming guide) : http://www.opengl.org/documentation/red_book/
    • Mar 30 2006 | 2:24 pm
      Also check out the GL Group html help page in [your Max/MSP
      folder]/patches/JitterReference/group-GL.html for attributes and
      messages common to all gl objects.
      --
      ***
      http://danwinckler.com
      http://share.dj
    • Mar 30 2006 | 5:13 pm
      Yes, this is exactly what I was looking for. Thanks!
      I'm not too lazy to do the tutorials or read the html pages (I spend plenty of time doing both), but one of the things I struggle with is the graphic layout of the information - especially those html pages. What I've always felt was so ingenious about Max was that it was a programming language that catered to the "visual learners" amongst us. Especially the max book (pdf) written by Chris Dobrian (way back when) was/is brilliant.
      I apologize if this is seen as critical, but the html and even the help files for Jitter are extremely flat with too uniform distribution of information. I think every visual learner is going to have a handicap when trying to find their answers in that info. I can't help but assume that most people drawn to the Jitter software will be in this category.
      I probably couldn't find my way through Jitter/OpenGL without the forum and the help I get from this list! - thanks for that, and sorry for going off topic.
      Bart
      www.bartwoodstrup.com
    • Mar 30 2006 | 5:25 pm
      Well,... I guess that's what this forum is for... to provide users
      with help tailored to their specific needs :)
      I know I learned my share of tips here, but I understand what you
      mean... somethings are a bit harder to get a grasp on when just
      looking at the tutorials, especially if your not
      that good with math, matrices or other difficult topics... (I'm one
      of those...)
      But luckily there's a great deal of people out there willing to help.
      Problem is, judging by a recent barrage of posts of people asking
      questions about even the most basic things, is that
      a lot of people drawn to jitter think is a sort of plug and play 'VJ'
      app. Some things are just as hard as when programming them in more
      conventional languages, but you don't have to bother with all the
      difficult things like windowing, memory management, usb
      interfacing,... And that's where it's strength lies, for me at
      least,... the possibility to 'sketch' cocncepts and ideas in a
      relatively easy way.
      I think the tutorials and help files give a nice overview of what is
      possible and how to do certain things. Once you want to move on, it's
      a bit more blurry and you'll have to have a basic idea of the openGL
      state-machine, javascript or basic programming principles... but
      that's a good thing I guess.... understanding the 'medium'
    • Mar 30 2006 | 8:34 pm
      On Mar 29, 2006, at 8:30 PM, vodstrup wrote:
      > Also, JKC mentioned the use of a "cpuclock" to drive animations for
      > realtime. Is this anymore efficient or is it just to keep a steady
      > framerate?
      Neither. It is actually the best way to keep apparently consistent
      motion under realtime usage despite inherently *fluctuating*
      framerates/CPU usage.
      -Joshua
    • Apr 20 2006 | 3:19 pm
      In case someone is still looking for "how", recipe 31 makes use of the cpuclock to time an animation.
    • Oct 13 2010 | 10:25 pm
      I am trying to use/modify/extend the patch discussed here and - as a beginner - would greatly appreciate if someone could comment its functionality. I am particularly confused about the way its components use resolutions/dimensions and control the movement. And my intermediate goal is to make it work with an arbitrary number of images rather than just with four.
      A separate thread on this is here: http://cycling74.com/forums/topic.php?id=28904
      Thank you.
    • Feb 07 2012 | 5:27 pm
      Sorry to revive an old thread but I've been playing this patch and am trying to work out why images look much darker in the panorama than the actual jpgs themselves on any other program.
      Anyone have any ideas?
      Thanks,
    • Feb 07 2012 | 5:30 pm
      generally this is the result of opengl objects default color attribute being grey. set it to white, and the images should return to full brightness.
    • Feb 08 2012 | 4:50 pm
      This was a long thread and I didnt follow all of it, but it seems it got stuck in GL land. As I understood the original question it was about being able to continiously scrolling an image right or left? Sounds lika a VR panorama to me... which to my knowledge is handeled just fine by jit.qt.movie (also lets u tilt up/down if the image resolution is bigger than the projectiin area, upnto 90 degrees). Maybe I missed something here but sometimes "old" technologies are good technologies and are worthwhile looking into...
    • Feb 08 2012 | 6:10 pm
      Thanks for that Robert! Very helpful!
      Parmerud - VR panorama looks pretty ideal actually. Any chance anyone's got any initial patches I can mess around with that use these? Always good to have new channels to explore!
      Thanks
    • Feb 09 2012 | 11:25 am
    • Feb 10 2012 | 5:18 pm
      Got to find yourself some VR panorama stitching software though. Basically the scrolling image could be as wide as you want but there might be issues if the VR movie becomes too big... not really sure.
    • Aug 21 2012 | 2:51 pm
      hi, i have a huge image (f.e. 6000 x 6000), from which i only show a small zoomed part, scrolling horizontally and vertically through the big image. i use videoplanes with jit.anim.drive and gl.node @capture 1, and i would just like to wrap the image in each direction endlessly like you can do with jit.rota @boundmode wrap...
      thanks for any tips
      (and i would prefer to stay with videoplanes and jit.anim.drive, not matrix source and dest dims)
      So what i want is pretty much what you can do with the offset messages and jit.rota, but jit.rota and a 6000x6000 image is absolutely not working...
    • Aug 21 2012 | 5:08 pm
      hi. you can do this using the td.rota.jxs slab-shader.
      on your gl.slab, you probably want to set @adapt 0 and explicitly set your @dim attribute to the final jit.window output size. otherwise the gl.slab will take the dimensions of the incoming texture and adjusting the parameters will cause a drop in framerate.
      you can also use your jit.anim.drive to control the anchor parameter of the td.rota.jxs slab, by setting it's @drawto attribute to the name of your rendering context.
    • Aug 21 2012 | 10:53 pm
      thanks robert, that's exactly what i wanted and it works wonderful....
    • Aug 22 2012 | 12:06 am
      Hm, sorry, one more time: i am somehow missing something basic to understand how i can control the anchor parameter of the slab with jit.anim.drive... i tried different things, but something very simple i am missing...
      I can find a solution with line objects or counter objects to start scrolling around, but not with jit.anim.drive if i just want to start scrolling endlessly to right f.e. (aka move...)
    • Aug 22 2012 | 5:07 am
      this one works stable...
    • Aug 22 2012 | 3:42 pm
      you need to look at what the anim.drive is outputting for each animation message.
      the move message outputs the message "anim_move" followed by a move amount for x,y, and z, and a scale value.
      simply route these values, unpack the X and Y vals and multiply with the Scale val, and send to an accum object.
    • Aug 22 2012 | 4:05 pm
      great, thanks!