/sighs The point appears to be that I completely blanked on the e-17 bit! >.<
You see, this is the kind of crap you have to deal with when you start cutting down on caffeine! On 21 February 2013 15:20, Martin Chatterjee < [email protected]> wrote: > Hi Peter, > > > as far as I see it your result is correct? The resulting vector should be > * [0.0, 0.0, -1.0]* - which is effectively the result of your print > statement. > > in your example *vec.Y* has a value of *6.12323399574e-17* which > essentially is *0.0* (due to floating point math precision). > > So all is fine - or did I not get your point? > > > Cheers, Martin > -- > Martin Chatterjee > > [ Freelance Technical Director ] > [ http://www.chatterjee.de ] > [ https://vimeo.com/chatterjee ] > nbsp;] > > > On Thu, Feb 21, 2013 at 3:21 PM, Peter Agg <[email protected]>wrote: > >> (and yes, rotating [0, 1, 0] by [-90, 0, 0] should actually make make [0, >> 0, -1]) :) >> >> >> On 21 February 2013 14:15, Peter Agg <[email protected]> wrote: >> >>> Hey all, >>> >>> I'm trying to rotate a vector in a Python Script and seem to be running >>> into an odd block. For example: I want to rotate the vector [0, 1, 0] by >>> [-90, 0, 0], which should make [-1, 0, 0] (and does so if I test in ICE >>> using a Rotate Vector node) but I can't seem to work out how to do this via >>> scripting. >>> >>> What I tried: >>> >>> vec = XSIMath.CreateVector3(0, 1, 0) >>> rot = XSIMath.CreateRotation(XSIMath.DegreesToRadians( -90 ), >>> XSIMath.DegreesToRadians( 0 ), >>> XSIMath.DegreesToRadians( 0 )) >>> vec.MulByRotationInPlace( rot) >>> print vec.X, vec.Y, vec.Z >>> # 0.0 6.12323399574e-17 -1.0 >>> >>> ...which makes me think that I've misunderstood what MulByRotation does! >>> >>> Any ideas? >>> >> >> >
