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

    • 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