Standard QC Glitchin'

Actually, here is more useful virtual patch version of the same idea, that can go in Graphics/Quartz Composer Patches, "RII Glitch Generator Patch GT".

... and also, a flattened version going to billboard, as an example, and one with the video going to the input, so that it is totally clear it doesn't just have to be a "generator".

Thanks, a good preset to apply for some instant distortion.

I like the fact that it may not have been intended to work like that, but one can nonetheless get it do that anyway :-)

Of course one's got to watch out, 'cause all one has to do is inadvertently slip a clear into that RII and all that beautiful distortion is gone forever •~

Post Script

Of course one could just toggle the depth & / or color buffer on the clear and get some of that distortion action back on track - sweet.

Great to attach some audio or mouse input to the RII.

So I went with mouse [& audio input], obviously can't protocolise the Image Filter to accept a clear patch within itself, so started nesting and looping out to obtain a similar result I was seeking.

Amending the underlying the default Image Filter seems like a good first step, to me, experimentation wise :-)

I guess you'll have seen the v002 glitch set for vdmx.

Only just started experimenting with their use.

It is very amusing to exploit the unintended possibilities of QC.s inbuilt patches, though, as I found with some previously sweet results I got in the Tiger days, they just don't change their stripes for spots at all, perhaps these RII effects will not outlive the leap to higher QC Snow Leopard hunting grounds .

You can do similar things with the GLSL patch and get slightly different results by omitting the clear. Its fun :)

Really? You get glitches when you don't have a clear and use glsl? That doesn't happen for me. Are you talking about a particular kind of scenario/setup?

I think it's interesting how it looks like the "plasma" was setup as an image unit like this, but how it pulls out like a regular patch.

I use RII + the GLSL patch, with a very simple GLSL shader that just textures with the input image.

You have to play with it a bit, but you can get artifacts on the output image. Here is a video with the artifacts I get on my x1600. Forgive the lewdness, I cant help it, Im from NYC.

http://abstrakt.vade.info/ILOVETHEQCLIST/RII%20%2B%20GLSL%20Glitch-deskt...

hmm, i seem to be out of the loop here. Exactly how is this glitch being generated?

I can see that the the clear fixes it, so to me it seems like it is using old data from the texture space. Would that be true? If that didn't make sense, well... it made sense in my head :)

Otherwise it looks like a cool effect to have, would be difficult to use in larger compositions though if you can't have a clear

Lango wrote:
I can see that the the clear fixes it, so to me it seems like it is using old data from the texture space. Would that be true?

I think that's exactly what's happening. It's using old data from the GPUs texture memory.

Quote:
Otherwise it looks like a cool effect to have, would be difficult to use in larger compositions though if you can't have a clear

Don't know if this composition is doing this, as I haven't downloaded it, but you can use a billboard inside a Render In Image, without a Clear patch inside, and it will glitch. You can still use Clear patches outside the RII, and the output of the RII will still be 'glitched', I think.

a|x

Here's an Image Filter derived version exploiting vade's Zoom Blur instead of the Apple only Zoom Blur.

The GlitchingFilter :-)

Uses Mouse input to vary the x , y variables.

Could just as well be an automated iteration, timelined interpolation, or audio input affected.

Indeed the possibilities are endless for affecting video glitching.

This is an interesting concept, but really defeats the point of the virtual patch I made..

I made this because Vade's plugs were giving problems on restore, and I wanted to show how the glitch can basically be done anyway.

In general, imo, it is best to stay away from plugins at every possible opportunity. If you CAN do it without, do it without.

As far as the comment on the clear, up above yours (forgot who made it)... again, the point is not to go into the virtual patch. It's a generator/filter... it might be interesting to publish controls on the randoms, or the image sizes on the render in image or something to get some additional control...

Best regards....

Talking of Glitch effects, I just made a really simple, but quite effective one using the CIBarsSwipeTransition effect in a CIFilter patch.

a|x http://machinesdontcare.wordpress.com

Hi Cybero

I see you have used a clear outside the render in image and that still successfully produced the Glitch, which answers my early question and toneburst's thoughts.

I haven't used the Render in Image before. I see that normally there is one output for the it called 'image', but if i go inside and create a simple filter patch and publish the output. The Render In Image now has two outputs, is this normal behaviour for patches?

Shouldn't it just keep the one output if inside it i publish an output with the same name and type?

Regards

You don't need to publish any outputs. Whatever is on the Billboard inside the RII will be output from the Image output of the patch. To get the basic effect, all you need to do is stick a Billboard inside the RII, and publish it's Image input to the patch's top level. Pipe some video into that input, and connect the Image output of the Render In Image to another billboard, and add a Clear on layer 1.

That should do it nicely.

EDIT Ignore this. It won't work. Sorry... :(

a|x

Lango wrote:
Shouldn't it just keep the one output if inside it i publish an output with the same name and type?

No -- you can have multiple identically named/typed ports as inputs/outputs to any macro.

The initial Image output on an RII patch is for what gets rendered (pink/red patches) inside the RII patch. Any other published outputs from the patches inside get published out of the RII patch. So, using an image filter inside an RII patch (where you publish the input and output image ports) serves no purpose because you're not rendering inside the RII.

Neat

:-)

Whats this 'restore' issue? Ive never heard of this from anyone :(

The old fbo glitch vs. the new one.

The old fbo glitch was called fbo glitch, and took an image input. In the new version, this patch is still there, but it's called fbo texure glitch (or something really similar), and what happens is that when someone opens up an old file with the new plugin, it loads a new patch that has the old name...

... the new patch that has the same key as the old one doesn't have an image input, it's just a generator. So, if you were piping an image to it, and someone opens it up, it makes it quite amusing (a week or so later... I was up a whole night trying to figure out what was wrong)... there will obviously no longer be an image source, and whatever was connected to it breaks.

After a couple of days, the pieces fell together on what the problem was, but it did kind of take the wind out of my sails on what was one of my cooler qtz's to date. Afterwards, I was just thinking "why did I even use this", because I could have gotten an extremely similar effect without a plugin. It's more of a murphy's law thing for me... it seems like everytime I use a plugin, in general, when I could have gotten away with doing it standard, I regret it later.

On a different note, the optical flow seems to be fairly inconsistent from system to system, but I do note that Andrew Benson did the orig thing, and it is GPU based, so I figure it's kind of par for the course.

I thought I had sent you a note about the fbo... Your plugins are very visually appealing, I don't want this to come off wrong. I also understand that things can change between beta and release, or even subsequent beta's, so I feel it's not on you, it's on me. I think you are awesome for putting the stuff out there. It was the first time I have ever had a scenario where an old key was used for a different patch, so it definitely had me chasing my tail a bit.

Ah, I see, yea, I did indeed change the 'class name' of the plugin because, well, I developed a new FBO glitch source one and felt the names should be switched/made more obvious, so yea, that was on me. I thought you meant a "I can open it and it works once, but then close and re-open and it does not" kind of in-consistency.

As far as similar effect, the thing about the built in method of 'gitching' is that you have no control over the target buffer type (its always the same afaik), so you cant change the type of glitching at all. The FBO Glitch gives very different results across vendor and chipset/driver versions, which is part of the fun, its meant to be glitchy in an actual legitimate "real" glitchy sort of way.

And yeah, the optical flow is using some GLSL stuff that may indeed be GPU version dependent, thus making some systems incompatible. But when it works, it should always STAY working ;)