[Bf-python] Good old euler problem

[Joseph Gilbert]

I agree that all radians would be fine.

The methods for each class make the assumption that the object is using  
degrees. So if you fill it with radians you will end up with a problem.  
The same can be true when we fill a euler with degrees after this fix and  
then call a method of the euler.

I have thought about this alot and I think that it would be nice to  
implement 2 types of eulers. One that uses radians and one that uses  
degrees. The conversion between the 2 would be a method of the class.
Euler.toRadians()
Euler.toDegrees()
In the class there would be a flag set to tell which type it's using for  
it's internal methods. This might also mean separating the constructors as  
REuler() and DEuler() or something.

I don't know where else this occurs, however, Euler seems particularly  
problematic.

On Tue, 20 Feb 2007 13:53:31 -0500, Ken Hughes <khughes at pacific.edu> wrote:

> In the post-2.43 release glow, I wanted to float the issue of our  
> radian/degree issue in the Mathutils module and elsewhere:
>
> https://projects.blender.org/tracker/index.php?func=detail&aid=3362&group_id=9&atid=264
>
> I really think we should fix this for the next release, and I think the  
> best thing to do is implement a fix early in the cycle so that we can be  
> sure scripts are converted as necessary.
>
> I think the prevailing decision was to go with radians in the API, not  
> just in the Mathutils module.  So should this also be applied to the Ipo  
> module (should rotation Ipocurves return real radians instead of the  
> degree/10 stuff)?  That's bitten me a few times lately.
>
> Ken
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/