Hugh etc.,
Not wanting to comment on what is fast becoming purely a matter of opinion I
would just like to add that java.Math has the two following methods:
toDegrees( double radian )
toRadians( double degree )
These are what I use as I feel that it makes for more readable code than
every developer hard coding a conversion factor.
The trig. functions in java.Math are defined to accept radians. Changing
Java 3D would make it inconsistent with java.Math.
If anyone was wondering about my prolonged absence from the list I have been
making forays into EJB... It's nice to be back! ;-)
I will be posting an update to our Java 3D benchmark results in the next
couple of days. Sorry for the delay to everyone who sent me results.
Sincerely,
Daniel Selman
[EMAIL PROTECTED]
Tornado Labs Ltd.
http://www.tornadolabs.com
-----Original Message-----
From: Discussion list for Java 3D API
[mailto:[EMAIL PROTECTED]]On Behalf Of Hugh Fisher
Sent: Sunday, March 26, 2000 7:40 PM
To: [EMAIL PROTECTED]
Subject: [JAVA3D] Lose the radians
I sent this off to the java3d-comments email. I'd like
to know if other people are as willing as I am to rewrite
existing code if it means never having to convert between
degrees and radians again.
BUG: Java3D rotations are expressed in the internal
format of radians rather than degrees.
WORKAROUND: Programmers must use math routines to convert
angles into the internal format before passing as arguments,
and again on return values to generate meaningful output for
the user interface or testing/debugging.
FIX: All rototation-related classes such as transformations
and quaternions should accept arguments, or return values,
in degrees and keep the implementation format hidden.
Radians may have nice mathematical properties, but these are
only of interest to ... mathematicians. New programmers,
experienced programmers, 3D artists, architects, geographers,
etc all think in degrees. Exposing radians makes coding,
testing, and debugging tedious. It makes it harder for
lecturers to translate most textbook examples into computer
code. (Quick: can gimbal lock occur after a rotation of 1.6707
about an axis?)
It will be easier to convert code from OpenGL, and easier for
OGL programmers to switch to Java3D.
A counter argument is that radians are already used in VRML.
That was a mistake and should not be imitated. I have never
read any VRML tutorial/introduction that did not apologise
for the use of radians, with some comment along the lines of
"You'll get used to it." We don't. No student in my 3D graphics
course has ever expressed satisfaction that VRML uses radians
instead of degrees, and all have been delighted to move on to
coding in OpenGL where it no longer applies.
Is this code incompatible with existing code? Yes, and I for
one would gladly change my existing code if it meant that
*every* future program would be simplified.
Hugh Fisher
ACSYS/CSIRO VE Lab
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
