Is it possible to make an image texture feedback loop with VUO, like would be done in QuartzComposer by using a Render In Image patch, and a couple billboards? As one would do by having the output splitter from the RII cycling back to one of the billboards, controlling the feedback quality via changing the color, blend, size, and position of the billboard?

Comments

Yep, it's already possible to

smokris's picture
Submitted by

Yep, it's already possible to render with feedback. Vuo's Render Scene to Image node is roughly equivalent to QC's Render in Image environment. Use Vuo's Hold Value to break the feedback loop (similar to how you'd use QC's Accumulator).

I've attached a simple example — a sphere spins, which is rendered to an image and fed back into the scene, slightly enlarged and shifted to the right, causing a trail.

Ok, I'm looking at this again

jersmi's picture
Submitted by

Ok! After about six months of brief moments and checking in on progress, looks like I may finally have a bit more time to play around with Vuo.

Attached is a test .vuo using a movie with the Render Scene to Image feedback method. Because of the blur in the feedback chain, I'm not getting very good performance, slow and unstable. (Here's an example where v002 blurs really help in QC). The whole point is to have the ability to insert a variety of effects into the feedback chain. Could I downres the image to the blur? Am I doing anything else dumb here? I thought using a Fire Periodically would be a good way to throttle fps with the Hold patch, but requestedFrame from the Render Image to Window node appears to be faster.

Hi, @jersmi.

smokris's picture
Submitted by

Hi, @jersmi. Glad to see you're starting to dig in to Vuo!

There a few different issues at play here:

  • The Blur Image node is slower than it could be, as you noted. Our current blur implementation uses an iterative method, which takes into account all the pixels in the image. Other blur implementations (such as v002) don't iterate, and instead skip increasing numbers of pixels as the radius increases — this is faster, but could produce moiré patterns depending on the source image. We're planning to implement some additional blur options, to allow you to choose the performance/quality tradeoff appropriate for your situation.
  • Vuo 0.7.0's new Event Throttling feature may be causing more events to be dropped than necessary. Try right-clicking on the Play Movie and Fire Periodically nodes' trigger ports and changing the Event Throttling Mode to enqueue. On my system (NVIDIA GeForce GT 650M, Mac OS 10.9.2) your composition runs smoothly after I change those 2 settings.
  • In your composition, the Hold Value node comes after all the time-consuming image filters, which defeats the purpose of using a Fire Periodically to slow it down — the image filters are still executing for every image that comes out of Render Scene to Image. It would be more efficient to place Hold Value before the image filters — to hold the image that comes out of Render Scene to Image, and only pass it to the time-consuming image filter chain when needed (from the Fire Periodically's event). (However, restructuring it like this revealed a bug which I just fixed in the Vuo 0.7.1 release, coming in a week or two.)

Could I downres the image to the blur?

Yes, that could also help (use the Resize Image node). After reducing the image size, you could also reduce the blur radius (which, in the current blur implementation, reduces the number of iterations and should improve speed).

Thanks, smokris. I'm getting

jersmi's picture
Submitted by

Thanks, smokris. Better results already, awesome. Btw: OSX 10.9.2, AMD Radeon HD 6770M, 1024 MB graphics, external monitor - Dell U2410 (which I guess is why my fans run loud and constantly with any graphics apps, FCPX, Logic Pro X, etc.)

Other blur implementations

jersmi's picture
Submitted by

Other blur implementations (such as v002) don't iterate, and instead skip increasing numbers of pixels as the radius increases — this is faster, but could produce moiré patterns depending on the source image. We're planning to implement some additional blur options, to allow you to choose the performance/quality tradeoff appropriate for your situation.

Another reason v002 blurs are awesome -- they keep the size of the image intact. Because of this and the speed factor, I use them constantly. A little moiré is a small tradeoff for most things real time. I'm facing this now with this feedback patch -- the black edges from the blur resampling make their way into the feedback image, bummer. Extra compositing required, etc.

I don't think there's a practical way to keep the size intact pixel to pixel (and eliminate the black border as radius increases) with the current blur, right?

Silly thought, wishful thinking.... what about porting over a few v002 items? i'd think vade would give his blessing.

Hi, @jersmi. Sorry I didn't

smokris's picture
Submitted by

Hi, @jersmi. Sorry I didn't get back to you sooner.

I don't think there's a practical way to keep the size intact pixel to pixel (and eliminate the black border as radius increases) with the current blur, right?

We'll try to add an option for that in the next release. In the meantime you could calculate the inset rectangle and use the Crop Image Pixels node.

To verify -- should this method work with layers, i.e., Render Layers to Image?

Yes, it works for layers, too. I just posted an example: Feedback Stripes.