[Bf-taskforce25] Radians vs Degrees

[Ton Roosendaal]

Hi,

Store radians internally, RNA (also via Py) and the UI should allow to 
map this to any value for input or display. Same will go for meters, 
inches or parsecs anyway! I think it's much worth finding a solution 
for this.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 22 Jan, 2009, at 12:30, Joshua Leung 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