[Bf-taskforce25] Radians vs Degrees

[Campbell Barton]

On Thu, Jan 22, 2009 at 3:30 AM, Joshua Leung <aligorith at gmail.com> wrote:
> 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.
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25

+1 (BE CONSISTENT IN RNA)

My preference is to use degrees for RNA and internally use whatever
makes more sense, converting from/to radians where needed.

As long as RNA has the ability to convert from one to another, it
should be possible for PyRNA to use radians only (if the Py team
disagrees and wants to go with radians).

At some point it was agreed to use radians for the 2.4x api IIRC but I
think the new py api is a lot higher level and matches the user
interactions much closer, so Id rather go with degrees.

-- 
- Campbell