pixel blog

RadialGradient_mod_by_spxl
based on RadialGradient.pde by Ira Greenberg

Source code: RadialGradient_mod_by_spxl.pde

Here’s another Processing sketch I’ve been fiddling about with for more time than is probably reasonable… this one is just 2D, and, once again, based on one of the basic examples provided with the Processing Development Environment. The original program painted some nice circles with gradient fills. Just once. No animation or anything tricky. Looking under the hood I was curious about a comment that didn’t seem to reflect the behaviour of the code:

// hack to ensure there are no holes in gradient
// needs to be increased, as radius increases
float gapFiller = 8.0;

The gapFiller wasn’t changed anywhere, and the implication of this value is that 8 points are plotted per degree rotation around the circumference of each circle, regardless of the radius (note that one solid disc in the final image is generated by plotting successive rings of increasing radius). Anyhow, since the circumference is linearly proportional to the radius, I figured that replacing this constant with some other constant divided by the radius (of the current ring) would be a good idea. I ran the program a bunch of times trying to find the smallest such constant that seemed to produce “gapless” discs up to a reasonable size. I also played with the idea of interpolating the radius step (eg step by 0.5 pixels instead of 1 pixel per ring) with a reduced angle interpolation – by this method the number of plots can be reduced, but finding an optimum pair of values seemed like a pretty hit-and-miss affair and was never going to be as sensible as a properly optimised circle drawing algorithm anyway. Having int-based parameters to specify exact pixel locations seems “close enough” for this sketch, and reduces a fair amount of confusion!

I quickly became tired of having to wait for the entire scene to be rendered before getting to see any of it, so decided to replace the array-filling loops with a draw() method that produced only a single disc on each invocation, and effectively moved the loop outside that by using some global variables to keep track of where we’re up to. I also switched over to using radians directly instead of needlessly converting between degrees and radians all the time, and of course did away with the duplication of the angle calculation (in the original program, j and angle are almost the same, differing only in when they are incremented, and should effectively cover the same circle’s-worth of angles) and moved the colour calculation out of the angle loop, since the colour is the same for a given radius. I’ve also replaced the manual colour calculations with the colorLerp() function provided by Processing. Yay for easy. It does make me wonder, though, on what basis the examples provided are included. This example has quite a few problems!

I also decided it would be nice to space the discs out a bit, and then started becoming heavily involved with working out how to space the discs evenly, especially so that the gap between the discs was the same as the gap between the discs and the edge(s). From there I moved on to asking, what if I want the gap to be proportional to the size of the disc? What size should the discs be, and where should they be centred? Than further still, what should that proportion be if I want the area covered by the circles to be some proportion of the total area? (For this case I’m talking about the average coverage of a single square “unit”, where one unit can be formed as a square whose corners are the centres of four adjacent circles. That is, I decided the visual average over the majority of the space was important, not at the edges where I simply want uniform spacing, especially since, if the rectangle to be filled is not square, the spacing to the edges in the shorter dimension will mostly not be uniform with the rest of the spacing – instead the arrangement is simply centred, keeping the circle-to-circle spacing uniform). Eyes glazed over yet? ;o)

I’ve kept on with the theme of making the sketches interactive to some degree as well, so have inclded keyboard controls for various parameters. After much playing around, eventually getting away from annoying calculations for those obscure ratios and moving towards “what makes this fun and interesting to look at?” the sketch is now in it’s present almost VJ-able form… well, in a winamp visualisation kind of way, only I haven’t sussed out audio reactivity yet – guess what my next plans are? :o)

-spxl

Posted in: Colour, Graphics, Interactive, Processing Sketch, Subpixel's Creations by subpixel /