smooth rendering/writing to disk?

lists@lowfrequency.or's icon

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 Patch
Copy patch and select New From Clipboard in Max.


Wesley Smith's icon

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:

Max Patch
Copy patch and select New From Clipboard in Max.

vade's icon

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

Wesley Smith's icon

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

lists@lowfrequency.or's icon

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

lists@lowfrequency.or's icon

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

vade's icon

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

randall jones's icon

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

david gottschalk's icon

this text seems to be incomplete.
can you please post this again.

best,
david