browse OpenProcessing

Wheel of Colors
Squeeze Past
the swinging grid
browse all>

browse the portfolio of Steven Kay

sun and moon
Spinning Globe
Edinburgh OpenStreetMap history
zebra trails
see more>
Squeeze Past

Squeeze Past

uploaded by
Steven Kay
A Voronoi map created from a set of moving points
Embed Code
Fave'd by 5 users
Sketch added to your favorites in your portfolio.
You must login/register to add this sketch to your favorites.

comments

source code

Comments

kirk "kirkjerk" israel
09 Dec 2009, 05:27
Wow! Voronoi maps are great-- though googling, it looks like it's your choice of subtle shading that makes this thing looks so bubbly and organic. (it's funny, I have trouble thinking of "what's happening per pixel" vs "what's happening per object")

If I could make a suggestion, bouncing the Attractors rather than wrapping them removes the kind of distracting/jarring "jumps"/"pops"...

public void move() {
// move with wall bounce
this.x+=this.dx;
if (this.x<0) this.dx *= -1;
if (this.x>200) this.dx *= -1;
this.y+=this.dy;
if (this.y<0) this.dy *= -1;
if (this.y>200) this.dy *= -1;
}


Steven Kay
09 Dec 2009, 13:59
thanks, that's an excellent suggestion - it looks a lot more calming without the pops!

kirk "kirkjerk" israel
09 Dec 2009, 15:01
Yeah, I was trying to think of a replacement for distanceTo() (incidentally, there's a very similar built in "mag()" - though half the time I forget and end up doing the pythagorean thing myself) that might treat the view area as -- umm, I guess technically the surface of a toroid, where North wraps around to South and East to West, and that a pixel near the center of the South border would "know" it's very near an attractor in the middle of the north border... I have a foggy idea of how to implement that (hmm, I guess checking if SCREENSIZE + the lesser coordinate is actually nearer to the larger coordinate than just the distance), but maybe my first scheme of bouncing the Attractors is almost and as pretty and much easier :-)
kirk "kirkjerk" israel
09 Dec 2009, 15:14
HAHA, I got it - if you want you can keep the wraparound move() code but replace distanceTo() with

public float distanceTo(int xx,int yy) {
// Euclidian Distance
int diffX = abs(xx-this.x);
if(diffX > (width / 2) ){
diffX -= width;
}
int diffY = abs(yy-this.y);
if(diffY > (height / 2)) {
diffY -= height;
}
return (float)Math.sqrt(Math.pow(diffX,2)+Math.pow(diffY,2));
}
}


the idea is, if the linear distance between, say, the x coordinates, is greater than half the screen width, then you can subtract the width from that linear distance, since it would be "cheaper" to wrap around the world to get to it.

So this algorithm also gets rid of the nasty "pops", and then it's a matter of taste if one prefers A. bouncing or B. wrapping attractors, and/or A. bubbles that wrap around to the other side or B. bubbles that happen to stick past the side of the screen, but you just can't see the outer edge.

Anyway, you found something really nifty with the shading of this --
kirk "kirkjerk" israel
09 Dec 2009, 15:34
Also, congratulations, in playing with this I see you really tweaked stuff to find good smooth performance - going to 200x200, and then only every other pixel...

it turns out
return mag(diffX,diffY);
is about twice as fast as
return (float)Math.sqrt(Math.pow(diffX,2)+Math.pow(diffY,2));

So on my machine, I could crank the size of it up to 300 and it still looked pretty smooth.

(and I'm not gonna pick on you for hardcoding "200" and "20" everywhere ;-)
Martin Schneider
10 Dec 2009, 08:16
that looks really nice.
I just made a tiny sketch version of it :-)
Steven Kay
11 Dec 2009, 14:36
thanks!

hadn't come across mag() before.

I suspect that it's feasible to do a pre-computed lookup table for the distances at this low resolution.. that should speed things up a bit, as sqrt() and pow() are fairly expensive operations.
You need to login/register to comment.