smooth rendering/writing to disk?


    Feb 01 2006 | 11:16 pm
    Howdy list,
    I'm very curious about getting smooth animations (using OpenGL),
    especially for non-realtime (frame-by-frame, using bline to drive
    presets) recording. I created this patch as part of a system for doing
    that - starting a save, stopping a save, all without losing frames, and
    recording frame-by-frame without skipping any. Can someone look this
    over and tell me if this is an efficient method for doing this? My
    biggest issue was working out a way of banging the jit.gl.render
    object, reading that video to a matrix, saving it via jit.qt.record,
    and then banging again when done, without causing a stack overflow.
    There are comments in the attached patch that explain the process.
    Basically, I use onebang as a gate after the main qmetro (which drives
    the patch) to prevent the state of the jit.gl.* objects from changing
    before the frame finishes rendering. But it's possible that I'm
    missing something, using a qmetro on one end and jit.qball on the
    other. It does seem to work very well, though.
    Any thoughts appreciated.
    Best,
    Evan
    max v2;

    • Feb 02 2006 | 12:50 am
      Here's how I've been doing it. Generally speaking, I give all of my
      gl objects the @automatic 0 attribute. Going into the jit.gl.render
      object, I have a t b b erase. The middle bang is for rendering.
      After the scene is drawn, I send a bang to the jit.gl.sketch object
      and send it the command "glreadpixels mat_name 0 0 width height". I'm
      a bit lazy, so I send it on every bang, but this is redundant. Just
      afterward, I send a bang to the matrix which holds the rendered pixels
      and pipe that into a jit.qt.record. The outlet of the record has a
      delay on it to avoid feedback problems and a gate. THe gate
      allows/disallows a new frame to be rendered.
      If possible, I'd like to remove the delay and replace it with
      something else that will immediately send a bang but still avoid
      scheduler overflow.
      wes
      HEre's the patch:
    • Feb 02 2006 | 1:10 am
      Any strategies for dealing with jit.gl.handle when recording 'non'
      realtime?
      ie: in your patch, running it in realtime and manipulating
      jit.gl.handle results in a camera rotation. turning off the qmetro
      and banging manually results in unsteady rotations (jit.handle is
      still rotating behind the scenes, the render context isnt being
      updated).
      any ideas on how to deal with this, as I use a jit.gl.handle
      abstraction in my patches to control many gl objects, and non rt
      rendering would be fun to play with.
      thanks,
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 02 2006 | 1:34 am
      Good question. I'm not entirely sure it's possible if @auto_rotate is
      enabled. I tend to calculate my own rotations, so I've not had to
      deal with this.
      wes
    • Feb 02 2006 | 2:30 am
      I usually use a javascript to deal with this, that rotates objects a
      certain amount each frame.
      Although, it would be cool if jit.gl.handle had an @automatic attribute
      also!
      -ev
    • Feb 02 2006 | 2:33 am
      That's what I was doing before, but the stack overflows and jerkiness
      were a real problem. Thus, using the onebang object to gate the main
      qmetro, so you can both use the patch for realtime feedback, and then
      set the qmetro speed to something very low and render to disk as fast
      as possible.
      -ev
    • Feb 02 2006 | 2:34 am
      you sir, know how to read a girls mind. exactly what I was hinting at.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Feb 02 2006 | 7:51 pm
      Some good ideas in this thread. I spent a lot of time this winter
      working on a recording patch. The interest here is prompting me to
      clean it up for sharing earlier than I was planning to, like in a
      couple of days, so please stay tuned.
      -Randy
    • Feb 08 2006 | 11:37 am
      this text seems to be incomplete.
      can you please post this again.
      best,
      david