Matrix flips 
Mr_Stabby 
So i should totally know this but i failed linear algebra so i dont. I have 2 points A and B, the imaginative line going from A to B forms a vector, i normalize that vector and use its normal angles to get a matrix of local space. Niiice i think at first, this allows me to use simple trigonometry to place points along a plane between the 2 points for whatever i need but then there is a problem. As the 2 points move relative to world space the matrix produces correct values only for a short while before it flips a few dimensions. I tried putting in a bunch of if statements to prevent it from flipping and keep it going and it worked but it is a long list and very inefficient and i figured if i knew the reason why it flipped maybe i'd have a better solution for it. So does anybody know a better way to keep a matrix from flipping around? mind you i dont calculate the matrix by myself but use MatrixFromNormal function
read 514 times 1/8/2012 1:07:22 AM (last edit: 1/8/2012 1:07:22 AM)

Garp 
You mean like when you have an object with a lookat constraint and when you move it relative to its taget, it will flip around its lookat axis at some point? The lookat controller has an upnode setting for that. I'm not sure how to set up the equivalent through algebra though. Not simply anyway. I've had this problem in a few scripts that were using a matrix as local coordinate system. The way I solved it is by testing the sign of, say, the dot product of the matrix z axis with the world z axis. If positive, fine. If not, flip it. There's probably a smarter way though.
read 498 times 1/8/2012 2:04:06 AM (last edit: 1/8/2012 2:05:20 AM)

Mr_Stabby 
yea its like the lookat, in slightly related news: turns out i havent failed linear algebra yet afterall! i can take the exam again tomorrow at 10 :D maybe i should spend more time studying then fiddling with splines >_<
read 470 times 1/8/2012 4:00:16 PM (last edit: 1/8/2012 4:00:16 PM)

Mr_Stabby 
I decided to ditch matrixes since i dont get along with them very well and use some highschool math instead!
dependsOn $HSpineMidC $HSpineTop $HSpineBot
distTopPref = 34.3845 as float distBotPref = 24.7972 as float distBotTop = distance $HSpineTop.position $HSpineBot.position vectorBotTop = $HSpineTop.position  $HSpineBot.position ratioTop = distTopPref / ( distTopPref + distBotPref ) as float ratioBot = 1  ratioTop
posMedian = $HSpineTop.position * ratioBot + $HSpineBot.position * ratioTop distContOrig = distance $HSpineMidC.position posMedian vectorContOrig = $HSpineMidC.position  posMedian
prodA = (vectorContOrig.x ^ 2 + vectorContOrig.y ^ 2 + vectorContOrig.z ^ 2) ^ 0.5 as float prodB = (vectorBotTop.x ^ 2 + vectorBotTop.y ^ 2 + vectorBotTop.z ^ 2) ^ 0.5 as float angleOff = 90  (acos ((vectorBotTop.x * vectorContOrig.x + vectorBotTop.y * vectorContOrig.y + vectorBotTop.z * vectorContOrig.z) / (prodA * prodB))) if angleOff > 0 then vectorBotTop = vectorBotTop * 1 angleOff = abs angleOff distOff = ((2 * distContOrig ^ 2)  (2 * distContOrig ^ 2) * cos angleOff) ^ 0.5
($HSpineMidC.position + vectorBotTop * (distOff / distBotTop))
What this script should do is look at a helper named HSpineMidC and move along with it while keeping the distance ratios between hSpineTop and hSpineBot the same as they are in sample values. To do that it first calculates the angle between vector going from Bot to Top and vector going from imaginary center point to the controller. It then takes that angle and calculates the shortest distance from controller to the imaginary plane it then adds that distance equivalent of the vector going from bot to top to get the point on the plane. Worked in theory but in practice there are some problems with the result  the values it produces have a slight wobble to them when moving in a straight line and when nearing the control helper to either of the end nodes it does a wide curve around it. Anybody(oh who am i kidding, theres only 2 people here that answer these kinds of questions) have a clue as to why this might be?
read 455 times 1/10/2012 5:51:04 AM (last edit: 1/10/2012 5:51:20 AM)

Garp 
Well, there's a lot of redundancy in your code. It doesn't help to make it clear. Then your text lost me. You should try to explain what you want (not how) as if you were talking to someone who hasn't spent days thinking about it ;)
Let's see. You have two objects from which you define a coordinate system (a barycenter plus a z direction). Then you have a third object moving around and, in that coordinate system, you want a fourth object to have the same x and y than the third but twice its z. Right?
read 445 times 1/10/2012 11:34:13 AM (last edit: 1/10/2012 11:34:13 AM)

Mr_Stabby 
not quite i have object A and object B at a certain distance between these 2 objects there is an imaginary plane that defines its up as direction towards object A and down as direction towards object B next i have object C which is free to be where ever it wants and object D which has to be on the imaginary plane but as close to object C as possible (the end result of the script)
ill try cleaning up the code tomorrow, today im like yawnzzzzz
read 435 times 1/10/2012 11:55:57 AM (last edit: 1/10/2012 11:55:57 AM)

Garp 
Ok. Same as before except that D.z in the coordsys is 0.
read 431 times 1/10/2012 12:08:07 PM (last edit: 1/10/2012 12:08:07 PM)

Garp 
To test it, you can make a plane and assign a script controller to its transform with this:
read 428 times 1/10/2012 12:25:01 PM (last edit: 1/10/2012 12:40:36 PM)

Garp 
Also you should dish the dependsOn(). It's been deprecated for a reason. dependsOn obj will evaluate for every tick (4800 of them per second) each and every anim and subanim of obj: its transforms, wirecolor, modifiers, material, etc, and every value in them. Pretty inefficient. Instead create variables posA, posB and posC in the script controller and assign to them the corresponding tracks $A.pos, $B.pos and $C.pos.
read 395 times 1/10/2012 8:57:49 PM (last edit: 1/10/2012 9:03:24 PM)

Mr_Stabby 
well got around the testing this, i dont know what sort of witchcraft this is but works awesome, thanks :p
read 365 times 1/11/2012 3:28:28 PM (last edit: 1/11/2012 3:28:28 PM)

Garp 
You're welcome :)
No witchcraft though.  create a matrix (think 'user grid') with its Z axis properly align  set its origin  in its local coordsys, take C's coords, preserve its x and y and zero its z  convert the result from local to world space by multiplying it by the matrix
read 354 times 1/11/2012 7:33:39 PM (last edit: 1/11/2012 7:38:52 PM)

Mr_Stabby 
yea the coordsys function finally made max's coord system make sense :p of course now that the script is 3 lines long and i got a handle on what is where in relation to what im going for a larger degree of automation instead because if my head isnt hurting its no fun (making a sort of full body ik system)
read 340 times 1/11/2012 8:08:26 PM (last edit: 1/11/2012 8:08:26 PM)

Garp 
All meshes have their verts stored in their local coordinate system, as defined by their transform matrix. So matrix arithmetic is everywhere in max (and probably in all other 3D packages). It can simplify things a lot but it's soooooo easy to get wrong. CGAcademy has a good series of videos on maxscript, one of them being The Matrix Explained, by Bobo (Borislav Petrov, TD extraordinaire at Frantic), if you're interested.
read 335 times 1/11/2012 8:40:24 PM (last edit: 1/11/2012 8:40:24 PM)
