Hi all,<br><br>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. <br>
<br>This raises an interesting point: what should we use? Radians or Degrees? <br>Clearly, the old / 10 hack is not acceptable, and should definately be replaced, but by what?<br><br>--<br><br>If we used degrees, we'd have the following considerations:<br>
* "User-friendly" - most users will be more familiar with degrees than radians<br>* 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'<br>
* 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<br><br>The opposites situation applies when using radians:<br>* 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)<br>
* One benefit though, is that rotation curves can natively fit on same set of axes as loc/scale curves<br>* Slight performance improvements for animation playback (though probably counteracted by other more significant factors) due to reduced conversions needed...<br>
<br><br>Discuss.<br>