Processing 1.0 - Processing Discourse - polar coordinate system

jandot

polar coordinate system
Mar 10^th, 2009, 10:23am

Hi all,

Is it possible to use a polar coordinate system for all drawing instead of using the cartesian and having to calculate x and y with sin and cos? I'm trying to create pictures like on http://tinyurl.com/756752. The tool has to be interactive and it's very compute-intensive to calculate polar coordinates within the cartesian coordinate system. However, this is actually nothing more than a linear representation that is circularized.

So is there any way where I can let e.g. x denote the angle ("width" would be 360 (degrees)) and y denote the distance from the center? Added bonus for including mouseX and mouseY into this.

Many thanks,
jan. (http://saaientist.blogspot.com)

PhiLho YaBB Moderator Offline Posts: 4190 Near Paris (France)	Re: polar coordinate system Reply #1 - Mar 10^th, 2009, 1:30pm Not sure what you want exactly. You want to avoid converting between Cartesian and polar coordinates? Not only that's not useful (Java is quite fast), but you cannot avoid Cartesian coordinates, because that's just how the computer sees the screen (rows of pixels).

jandot

Re: polar coordinate system
Reply #2 - Mar 10^th, 2009, 2:14pm

What I need basically is a mouseA and mouseR (for angle and radius) rather than mouseX and mouseY. Similarly, rect(PI/2, 50, 5,5) would draw a rectangle straight above the center of the screen or buffer at a distance of 50 pixels from that center.

There's (tens of) thousands of datapoints to be plotted, so any less code/calculation is a good thing.

I was just hoping that Processing would allow using a polar coordinate system or would have functions somewhere hidden within to make this transition very fast. It would probably have to be coded very lowlevel (because as you say everything is drawn in rows of pixels) or at least be quite optimized. I'm not a java-expert, so if such functionality would be already available, that would be great. If not: I'll have to do it myself.

jandot YaBB Newbies Offline Posts: 7	Re: polar coordinate system Reply #3 - Mar 10^th, 2009, 4:00pm Is there a way to let me draw everything on a line and afterwards fold the line onto itself so that it becomes a circle? For example: http://www.flickr.com/photos/82932180@N00/3343645675/ : drawing everything in A and then transforming that to create B. jan.

eskimoblood Senior Member Offline Posts: 341	Re: polar coordinate system Reply #4 - Mar 10^th, 2009, 4:06pm What's about lookup tables(http://processing.org/hacks/hacks:sincoslookup). Creating your sin/cos value ones and store it. Now you only need to multiply them with the radius of your needs.
	Andreas Köberle {eskimoblood}

cloister

Re: polar coordinate system
Reply #5 - Mar 10^th, 2009, 6:22pm

Lookup tables can (and do) speed up trig calculations, but at a cost: reduced accuracy. Basically, you have to decide ahead of time how big to make your tables, and later if you end up needing a value that's between the one in table slot N and table slot N+1, you're stuck. You have to just pick one. Essentially, it means that you have to round all your angles up or down to the nearest value that's actually represented in the lookup table.

This may or may not actually be a problem, depending on the nature of the functions being plotted and the region of interest. For areas close to the polar coordinate origin, it's not a big deal. The perceptual difference between the point r=3, theta = 95 degrees and the point r=3, theta = 100 degrees is very small. For small values of radius, all the angles are packed close together, so you'll never see the small errors induced by the rounding-off that a lookup table creates. But for r=300, say, you'll definitely see the difference.

But these days, honestly, the overhead of a sin() and cos() per point plotted is probably small enough as to be not worth worrying about. What I would suggest is that JanDot implement his/her own polar coordinate transforms as a set of utility functions within the sketch, and then route all drawing operations through those.

So instead of calling, for example, "point(100, 300)" to plot a point at pixel x=100, y=300, you would call "polarPoint(57, 223.4)" (or whatever the corresponding polar coordinates were). polarPoint would simply do something like this:

void polarPoint(float r, float theta)
{
point(r*cos(theta), r*sin(theta));
}

Basically, just encapsulate all the cartesian-to-polar and polar-to-cartesian transformations inside a small set of easy-to-use functions that, except for their names, look like the underlying processing drawing functions.

You'd also want, of course a pair of polarMouseR() and polarMouseTheta() functions that do the atan2() and distance calculation to convert from mouseX and mouseY.

If it were me, I'd wrap all this functionality up in a class so that the constructor could handle all the business of setting things up: translating the cartesian coordinate system to wherever you wanted the origin to be (e.g. the center of the screen), and establishing an appropriate scale factor so that the desired amount of radius fits onto the screen. That way, if you needed to, you could have several independent polar coordinate systems operating simultaneously without getting lost in the details of which is which. I'm not sure what a useful application of that would be, but I'm sure there are some...

jandot

Re: polar coordinate system
Reply #6 - Mar 10^th, 2009, 6:45pm

Thanks Cloister. That's exactly what I was thinking. I'm going to try and create such a class, but will take some effort because I'm not at home in java (perl and ruby, sorry).

I wonder if it's possible to _not_ change the method names from e.g. point to polarPoint, but to have the arguments be transformed instead.

Something like:
point(polar(r, theta))

Your explanation is a real big help, cloister.

jan.

cloister

Re: polar coordinate system
Reply #7 - Mar 10^th, 2009, 9:12pm

Unfortunately, Java syntax doesn't really permit the solution you've suggested. That would be syntactically nice, but what you'd really need for Java to be happy is:

point(XFromPolar(r,theta), YFromPolar(r,theta))

because point() expects two coordinates. And obviously, that's ugly as sin (no pun intended).

If there were a point() overload that took an array of 2 floats as its argument, then you could do what you suggest because the argument types would match. But in Java there's no way to get the return value of one function or method call to magically turn into a comma-separated list of arguments to another function or method.

Either way, hang tight: You got me thinking "that shouldn't be so hard" so I'm working on a PolarCoordinate class right now. It'll be pretty basic at first (supporting points and lines only) but should get you going.

jandot YaBB Newbies Offline Posts: 7	Re: polar coordinate system Reply #8 - Mar 10^th, 2009, 9:17pm Thanks! This'd be a great thing to plug into Processing.

PhiLho

Re: polar coordinate system
Reply #9 - Mar 10^th, 2009, 9:58pm

cloister wrote on Mar 10^th, 2009, 6:22pm:

if you end up needing a value that's between the one in table slot N and table slot N+1, you're stuck. You have to just pick one.

You can still interpolate, it might be faster than computing a trigo function. Or not: as you point out, these operations are quite fast today, even more with floating point CPUs.

cloister

Re: polar coordinate system
Reply #10 - Mar 11^th, 2009, 6:52pm

Ok, I have some code that's worth sharing, at least to willing early-adopters. It isn't packaged into a nice clean library yet, but that seems premature before getting some people to bang on it. It's too long to post here (grr; I really hate that this forum software has such a harsh limit on post length), so anybody who wants it can send me a message through my profile with their e-mail address, and I'll send it to you that way.

Here's what's in it:

a PolarCoordinateSystem class (catchy name, eh?), with the following methods:

* Default and with-parameters constructors,
* get/set methods to modify the coordinate system if needed,
* polarPoint() and polarLine() methods that draw points and lines for you,
* A drawGrid() helper method that draws a "spiderweb" style coordinate grid for you.
* toCartesian() and toPolar() methods that convert between screen coordiantes and polar coordinates

Note, polarPoint(), polarLine() and drawGrid() all use the current drawing style, whatever it happens to be. So in that regard you can treat those methods just like you would any of processing's built-in drawing methods.

That's it so far. There is not, as you might think, a polarMouse() function to give you the polar coordinates of the mouse, but that's because mouseX and MouseY are always measured in unmodified _screen_ coordinates, rather than in the translated/rotated/scaled coordinate system used by point(), line(), and the other drawing functions. And, as Processing offers no way for my code to discover the current transformation matrix so as to figure out the screen coordinates from the raw mouseX and mouseY, there's no practical way for my class to implement polarMouse(). Instead, the user of the class must handle converting raw mouseX and mouseY values to screen coordinates (i.e. account for the current translation/scale/rotate matrix), and pass those to the toPolar() method. The example code I've got shows how to do this.

jandot YaBB Newbies Offline Posts: 7	Re: polar coordinate system Reply #11 - Mar 11^th, 2009, 7:10pm Great work! I'll send you my email address. Wouldn't something like that be good to be included in Processing itself?

cloister Full Member Offline Posts: 138	Re: polar coordinate system Reply #12 - Mar 11^th, 2009, 8:57pm Well, _I_ think so: coordinateMode(POLAR); But I guess it's up to Fry. Why don't you post a suggestion in the "Software, Documentation, Website Suggestions" forum?