Feedback frequency/ QC Performance

blackburst's picture

Is the "frequency" of feedback images through an accumulator equal to the display refresh rate? Because it doesn't change when I change the display refresh rate.. I found this: https://developer.apple.com/library/mac/#technotes/tn2145/_index.html Pretty much says it does it's best to keep up with display refreshes. I am finding that I constantly come to dead ends with "iterative drawing" with feedback in QC because it just isn't quick enough. (before you wonder, my mac is more than capable.) It's just that I constantly end up with patchy painting if the movements are done with any speed. I came across this thread: http://kineme.net/forum/Discussion/DevelopingCompositions/LightPainting I noticed that the vimeo example given is one that is in-fact, as Dust said, an in-camera method as admitted by them on their site here:http://www.lichtfaktor.com/design/clips/ I've done it myself with a dsr-450. The goal is to draw quickly, and smoothly with things like a kinect, mouse etc. But it has opened up old wounds for me..

I'm still unhappy with how quartz seems to "strobe" it's content with fast motion as if it has a refresh rate slower than that of the display and the graphics card for that matter. I've been through a few macs, a few monitors, graphics cards, it's always the same. I tried to explain it to George in this post http://kineme.net/forum/Discussion/General/Particlerefreshrate but I think he gave up on me. (pleeeeaase read and watch attached vid in the post).

Any help on this would be great, because it's starting to seem like I'm spending all my time on a platform that can only go so fast.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

gtoledo3's picture
Re: Feedback frequency/ QC Performance

I don't think it's that quartz has a slower refresh rate than the "display and the graphics card for that matter", I think it's that x/y is moving quicker than the refresh rate.

I think one way of coming to a solution may be to find an app or code example that "doesn't" do that.

Every system that I can think of that captures x/y position and then "draws stuff", whether or not it's by using feedback or drawing quadstrips or whatever, does that; that same thing happens in Processing and OFX among others. One solution might be to try to render textured quad strips or something instead, but that will still have the same side effect - if you move x/y quickly, the length between verts will be longer, and the strips will look less smooth. You can try to take that data and turn it into a curved path or something, maybe.

gtoledo3's picture
Re: Feedback frequency/ QC Performance

I think another way of looking at it, is that the system is receiving the info at a given rate... you're moving x/y at inconsistent speeds. There is no way that the distance between points is going to be consistent if the sample rate is reasonably consistent and your rate of change (eg., speed you move x/y) is inconsistent.

I was thinking about ways of handling this... I can't think of any great way to handle it that won't introduce latency. Maybe one thing you could try, if the idea is to do something like light writing and you're using the RII's feedback setting, or an accumulator or something, would be to multiply the x/y data by something less than 1 so that the data covers less territory and then enlarge the resulting texture and maybe blur it. Maybe making resolution lower off the top and doing nothing with the x/y data might smooth things out.

You also might try something like smoothing the data a little bit, and then using a gaussian for the "tip". Then, run the result through a threshold, like the one found in "combed trail.qtz" and some other apple examples. The result will be smooth on the edges because of the gaussian texture, and thresholding the result will even out the "dips" that area little darker.

blackburst's picture
Re: Feedback frequency/ QC Performance

Thanks George they're all good suggestions that I'll have to work through in time. The last one certainly sounds like what I'm after.

I think the thing that gets me is that I can't see ANY difference when i change the display refresh. I would expect that my trails would become closer together with a faster refresh but they don't. But...

I did some tests and it seems to all pretty much work out. I hooked a sphere up to an LFO and took some photos. I think pretty much the only thing that is wrong is that my graphics card doesn't like 75 Hz, it renders tearing, choppy refreshes as seen in the 75Hz photo. But yes, the system is indeed running (at least trying) at my monitor refresh rate.

But does this have to be the case? In the corner of the viewer where it states the fps, it quite often goes over the display refresh when rendering is set to unlimited speed. From this you'd assume that frames are being calculated in-between refreshes, but just not displayed, right? If so, for things like particle emitters, where the birthrates are tied to display refreshes.. Couldn't the new frame just display the particles that were emitted in-between frame intervals? Ie. An emitter is moving from points A through to G faster than the display refresh, where every second point (A,C,E,G) is an actual display refresh and a burst of particles comes out. Assuming the machine is capable of calculating the content faster than the refresh the refresh rate (eg. 120Hz), couldn't the frames rendered at A,C,E & G draw the particles that would have been emitted on points B, D and F? Because this doesn't seem to be the case. The display refresh actually seems to bottleneck the calculation of the content and spit out particles at 60Hz intervals rather than displaying a seemingly steady stream of particles 60 times a second. I would have thought that's what the "unlimited" rendering speed would be for.

PreviewAttachmentSize
IMG_7329.JPG
IMG_7329.JPG4.87 MB
IMG_7334.JPG
IMG_7334.JPG4.45 MB

blackburst's picture
Re: Feedback frequency/ QC Performance

I can only upload two files at a time for some reason, but check out the "eat my own words" photos

PreviewAttachmentSize
IMG_7332.JPG
IMG_7332.JPG5.07 MB
IMG_7313.JPG
IMG_7313.JPG4.99 MB

blackburst's picture
Re: Feedback frequency/ QC Performance

I think the "should have 0 ghosts ones are ghosting perhaps from grey to grey lcd respons time. Note that in different photos I change the camera exposure, rate of lfo controlling sphere, and refresh rates.

PreviewAttachmentSize
IMG_7338.JPG
IMG_7338.JPG4.83 MB
IMG_7339.JPG
IMG_7339.JPG4.42 MB

gtoledo3's picture
Re: Feedback frequency/ QC Performance

I'm going to answer this in greater detail tomorrow, but there are a number of assumptions about what's going on here, that, I think, are incorrect.

Look at it this way... everything starts at the consumer patch. It's asking for upstream info. It does it at a fairly even rate (even taking fps fluctuation into account).

So, it's "banging" up the pipeline. Except sometimes, you've moved x/y WAY faster than other times.

So, the next cycle that the consumer patch is "asking" for the info, you've already moved further. There's no "in between" available, because it was not ever captured. FPS may be unlimited, but still, the graph had to traverse from the consumer patch, through all of the processor patches, up to whatever the provider is (the mouse or whatever). A "push" system (like max) wouldn't really make any difference... the difference between push/pull is largely in the way it's presented to the user (and maybe being able to shave a little evaluation time when being driven by an external input, but not anything that is impacting the visual). In my experience, the same damn thing happens in ALL scenarios like this (as I alluded to above). Checkout graffiti paint (ofx) and see if you think it does it. I think it does, and I've gotten smoother results in QC with careful programming (and I think I could improve graffiti paint to get the same result in ofx.) Checkout some of the processing sketches that let you draw stuff and move your cursor around quickly... distance between points is greater the quicker you move it, at least on the two macs I usually work on.

That said, there's some convolution between the evaluation of the graph/nodes with refresh rate of the Viewer in the way you're thinking about this that isn't quite right. I'm kinda at the end of my night here, and I'll try to remember to flesh this out tomorrow some more :-) For instance, the thing about birthrate being tied to display refresh doesn't sound right, it's tied to patch time, afaik...maybe that winds up being the same thing effectively, but I don't believe so.

Another thought - interactive stuff sometimes requires some kind of training of the user. Hopefully, the user can kind of instantly train themselves by observing the visual feedback of what they're doing. If I scrawl on a paper fast with a pencil, it's not going to look as clean as carefully measured strokes. Similarly, someone doing this kind of interactive thing will have to be aware that they should write in a careful and measured way with consistent speed. If someone can just write at a consistent speed, and it looks good... why kill it with a ton of "fix it in the mix". Don't get me wrong... backup plans are good, but reality is...real!