Vec2d about pymunk

[viblo]

From vb%[email protected] on November 10, 2009 05:23:12

I remember that we had a reason to use degrees instead of radians, but I don't
remember it right now.. I think at least pygame use degrees so that might have been
part of the reason.

Anyway, do you have what can be done about it now? I guess there are a couple of options:

1. Add corresponding radian-functions to vec2d (something like angle_r?)? This will
   confuse some as vec2d will contain more functions for no real reason.
2. Change it to use radians. In this case a good time to do it is when pymunk is
   upgraded to the new chipmunk code. All current code who uses it will have to be
   rewritten, and anyone who have degrees in their code will have to convert before
   passing on to pymunk.
3. Do nothing. Meaning everyone who uses radians will have to convert it before
   chipmunk.

Anyway, I don't expect wrapping the cpVect functions to be of any real advantage, a
call down into chipmunk is probably about as expensive as doing the calculation
directly in python. For these simple calculations its probably the function call
overhead thats important and my guess is that its about as expensive (or maybe even
cheaper in pure python). Also, my first intuition is that for almost all use cases
the conversion is cheap compared to other things pymunk does (but I haven't done any
tests :)).

Would be really good if you (and anyone else with an opinion on the subject) could
comment on what's the best way to handle it?

[viblo]

From vb%[email protected] on November 10, 2009 05:23:22

Owner: [email protected]

[viblo]

From vb%[email protected] on December 04, 2009 11:39:24

Ive researched this a bit more. I think the only reason for degrees instead of
radians was that the vector lib I included in the first release was using degrees,
and that I didn't think much about it as the small projects I used it in didn't use
the angle functions.

And apparently I was wrong in my previous post, pygame does use radians and not degrees..

So, right now Im leaning towards option 2, make the change and break all degree-using
code. If the change is to be made, why not do it asap? ;)

[viblo]

From [email protected] on December 09, 2009 11:54:57

radians, definitely.
do it! nao! :)
thank you for your efforts

[viblo]

From vb%[email protected] on December 10, 2009 08:27:16

Thanks for the input!
As noone has said they like to keep degrees but several indicated they like radians I
think Ill go forward with the radians switch. I have done some testing locally and I
think Ill rename the current methods (angle_degree and so on) if anyone want to use
the old methods.

Expect it to be included in the next version, to be released as soon as I've upgraded
pymunk to work with the newly released chipmunk 5.0.0 version.

[viblo]

From vb%[email protected] on December 10, 2009 08:27:34

Status: Started

[viblo]

From red.hamsterx on January 03, 2010 16:56:15

What about something like the ability to set a 'use degrees' flag at the module level?

import pymunk
pymunk.init_pymunk(use_degrees=True)

Then, for each function, at the C level, convert if necessary.

[viblo]

From red.hamsterx on January 03, 2010 16:58:32

Follow-up, since I don't see an 'edit' option: that should probably be
'use_radians=True' in my example call, since use_radians=False should be the default
for backwards-compatibility, assuming that's even a consideration, pre-1.0.

(I'm new to pymunk myself, so I'm fine either way)

[viblo]

From vb%[email protected] on January 04, 2010 04:26:51

Thank you for your input red.hamsterx!
Yes, that would also be an option. However, that would create other complications,
for example in the documentation and when you share code with others.

I don't think backwards-compatibility is that important in this case. I didn't know
what changes was required for the upcoming pymunk release (using chipmunk 5) when I
started to look into this in November, but now its almost complete and its clear that
many other things have changed meaning most people will have to do code changes with
or without the degrees/radians switch. Therefor I think the solution in Comment 5 is
still the best one. But Im still open for input.

[viblo]

From vb%[email protected] on January 06, 2010 14:16:08

The changes necessary has been added to trunk.

Status: Fixed

[viblo]

From [email protected] on January 07, 2010 11:37:49

You could define a constant 'Degrees' with the value pi/180.
People who want to use degrees could then use the following syntax:

a = 90 * Degrees # 45 deg == 45 * pi/180 == pi/4
z = Sin(a) # z = 1

or alternatively use functions like

def R2D(x):
return x * pi/180

def D2R(x):
return x * 180/pi

radians are more comfortable when one is working with arc lengths.

Length of an arc of 90 deg of radius 5:

d = 90
r = pi/2

arclen_d = 5 * d / 180 * pi
arclen_r = 5 * r

[viblo]

From vb%[email protected] on January 07, 2010 14:00:01

I agree that a Degrees constant would look nice :) However, I think Ill leave it up
to the user to define it if they want it.

Also, the math module already contain math.radians() & math.degrees() for easy
conversion and I imagine that most people import it anyway for other uses such as sin
and cos.

[viblo]

From [email protected] on January 30, 2010 10:15:21

When doing this, it may be possible to overhault API information on rotaion, I'm currently at the GameJam in
Bremen and break my fingers of trying to figure out, in wich directions the different rotation calls rotate.

[viblo]

From vb%[email protected] on January 30, 2010 11:30:02

Im not sure I understand your question?
But anyway, a Vec2d pointing up ((Vec2d(1,0)) will have 0 rotation, and then the
rotation increase clockwise, math.pi/2 for Vec2d(0,1), math.pi for Vec2d(-1,0) and so
on.

For a Body, it will start with 0 angle, and then rotate in the same way when some
force affect it.