[Bf-taskforce25] Radians vs Degrees

Joshua Leung aligorith at gmail.com
Thu Jan 22 12:30:06 CET 2009


Hi all,

I ran across the Radians vs Degrees issue today while porting IPO-curves for
Object rotation over to Animato. The old system used a special 'degrees
hack' - rotations were specified in psuedo-'degrees', which were displayed
as degrees but were actually stored as values / 10, so that loc/scale curves
could be viewed alongside rotation curves. Now, AFAICT, the RNA wrapping for
Object rotations currently uses radians, as that's the unit that rotations
are stored in internally.

This raises an interesting point: what should we use? Radians or Degrees?
Clearly, the old / 10 hack is not acceptable, and should definately be
replaced, but by what?

--

If we used degrees, we'd have the following considerations:
* "User-friendly" - most users will be more familiar with degrees than
radians
* Conversion overhead - IMO it would be nice to do this on RNA-level, so
that we don't need to introduce special hacks all over Animation/Buttons
code for example to convert to/from the two forms + drivers would become
difficult to manage. However, one major problem with this is that some tools
(i.e. Python scripts) might want data in radians as they are mathematically
'nicer'
* Downside is that rotation curves can't natively (i.e. without some mapping
occurring during drawing) fit on same set of axes as loc/scale curves

The opposites situation applies when using radians:
* Most users will be even more confused than they are about quats now, and
it is forseeable that there would be widespread moaning about this unless a
VERY ROBUST mapping/translation scheme is put in place (i.e. display and
input must never reveal that we're using radians for everything)
* One benefit though, is that rotation curves can natively fit on same set
of axes as loc/scale curves
* Slight performance improvements for animation playback (though probably
counteracted by other more significant factors) due to reduced conversions
needed...


Discuss.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090123/efe9269f/attachment.htm 


More information about the Bf-taskforce25 mailing list