[Bf-python] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [11267] branches/pyapi_devel/source/ blender/python/api2_2x: * Object, made softbodies a seperate type rather then having its variables mised up with object .

[jmsoler at free.fr]

Selon Campbell Barton <cbarton at metavr.com>:

> jmsoler at free.fr wrote:
> > Selon Matt Ebb <matt at mke3.net>:
> >
> >> Having this in radians just seems like it would be quite awkward,
> especially
> >> when the number you set is completely different to what you see before and
> >> after in the UI, and it sounds like something that would get quite
> >> annoying and confusing  to use.
> >
> > Your are right : in the UI, radians are not user friendly.
>
> If people realy want they can ask it be brought up at the meeting?
>
> Though there is so much to discuss and I realy dont want to thrash. If
> you really wanted not to use radians you should have said something when
> it was decided on this list.
>
> However I got the impression that it was agree'd that al things
> considered radians were the way to go.
>
> One thing is sure - We do NOT want to mix both.
>
> At most, I would accept All radians with a few exceptions (lamp and
> camera angles).
>
> I dont think we can draw a line between stuff that is trig based and
> user setting based.
>
> An object rotation is something users are familiar dealing with in
> degrees - but you might want to do trig with.
>
> The math.radians argument can work the other way, people can use
> math.degrees for functions that return radians... so we could go either way
>
> - whatever happens, if topics keep re-opening after (we?) have discussed
> them like this it waists time.
>


Of course if the blender's UI displays degres and python api returns radians,
there is no problem.