I’ve added a sphere field qcFX to the tb Fields 2.0.1 pack, available from the Box.net widget.
Archive for the 'OpenCL' Category
Updated versions of some of my very early QC experiments, but this time using OpenCL instead of the Image Pixel patch, which speeds things up quite a lot. It should fall back to using Image Pixel if OpenCL isn’t available, but I’ve not been able to test that, as I no longer have a non-OpenCL-capable machine.
‘tb Field qcFX 2.0.1.zip’ in the Widget.
It’s been so long, I barely remember how this thing works…
Some screenshots from a little project I’ve been working on for Weirdcore. It’s essentially a simplified version of vade’s Rutt-Etra effect (keep coming back to that one, don’t I), but in some ways truer to the original hardware device, in that the displacement of the lines takes place on the Y-axis only, so it’s essentially a 2D effect, rather than an extrusion of an image plane into 3D space. The other difference is that the lines can vary in width, so with the right input material, you can get these really graceful curves and almost calligraphic lines. It’s a kind of hybrid visually of the early work of Bridget Riley and Victor Vasarely- hence the title.
OK, this one needs some explanation. I know it looks almost exactly like vade’s Rutt-Etra plugin, but this one takes a slightly different approach. It’s essentially a slightly reworked version of the Apple OpenCL Text Extrusion example QTZ. I thought I’d try messing around with putting the resulting mesh inside a Kineme Polygon Mode patch (from GL Tools). I initially tried setting it to render only the raw vertices as points. You can see what that looked like in the video in the previous post.
Then, I thought I’d try rendering the mesh in Wireframe mode. Initially, there was a problem with long lines connecting the end of each row to the beginning of the next. I fixed this by stealing vade’s trick of reversing the direction of the vertices of each line. I then had to compensate for this by reversing every other line of the original input image. I actually did this with a CIFilter (thanks to cwright for showing me the error of my ways with the GLSL mod() function), though I’m sure it could be done also in the OpenCL kernel.
This later version has Point and Line modes, colour and monochrome, and some other bits and options.
One of the exciting things about OpenCL is that you can take one kind of data, and treat it as if it’s another kind. For example, you can take image data, and take the colour information from each pixel of that image, and output it as an array of values (in reality, of course, an image IS in fact simply a multi-dimensional array. QC traditionally hasn’t treated it this way, however- until now).
It occurred to me earlier that I could use this fact to quickly generate a load of random 0 > 1 values in an array, by simply feeding a 1D texture made by passing the output of a CIRandomGenerator through a Crop, and outputting the values for the RGB and A channels of each pixel as a float4 (OpenCL’s equivalent of a GLSL vec4) in an array. Changing the crop position of the Crop patch would give you a new set of random values. I made a little self-contained CIFilter to generate the base 1D texture, and coded an OpenCL kernel to do the rest, adding Scale and Offset parameters for the generated numbers, and it seems to work.
I don’t know if this is in any way useful, but it occurred to me it might be a more efficient alternative to generating four random numbers inside an Iterator using the Random patch- you’d simply pass the whole array into the Iterator, and choose an item from the array/structure based on iteration index.
‘tb_OpenCL_Random_vec4_Array_141009.qtz’ in the Box.net widget.
Done before using GLSL Shaders, but here’s the same thing with OpenCL patches inside an Iterator.
This time there’s no need to calculate normals, though, as there’s an OpenCL virtual patch to do that for me.
I’ve made a much more efficient version of this now. Seems marginally more crash-prone though.