QUOTE(aen @ 10/07/08, 08:10 PM) [snapback]292974[/snapback]
Since when did this thread change to aim constraint limited to 2 axis?
I seem to have missed something!
Well what was what it initial second post said underlined and firt post says (probably because you answer was adeqate for him), it has changed since. Anyway Yes your sis basically expression of it all.
IMO, good Mel coding is totally subjective but this could be a cultural thing?
No, mel is not acting on maya in way that makes it entirely code. Thus you can not attack mel in way that. The problem i see is that people brute force mel and expressions in ways that they assume programmed direct systems do (yes its the complete maya programming book thats the cause). Cultural whatever works right. Works not so fine for maya, where everything is indirect. read below.
Much of mayas perfomance comes out of using maya right, not in how the code is done. But doing code that does not do maya right is trivially simple. You can see this all around the entire web wich is why many gravitate here for the last answer on the subject. Please note this has NOTHING to do with how you have written mel, but how you used it. Idf you used it for worng reasons you wrote it for worng reasons.
But let us take a look at how you for example make a expression node up maya to do things you continuously call -ae 1. Well you dont need to. You are wasting the entire dgtime on updating the expression EVEN when its not needed. Since the dg gets it straight in both examples call -ae 0 youll save a heap of time for this habit (knowing whne to call -ae 1 is a good start). And no RIG time performance. So doing it right would probably save you a 100 milliseconds every frame easily. On even a slightly busy scene.
Fixing Mel errors is required but making the code = Pretty = is a total waste of time.
And thats EXACTLY true. Its more on what mel is used for. Mel is used for making indirect changes for for the dg to do the computation. But your example while indeed intermediate misses on fundamental rule of maya design. Your forcing the dg to evaluate.
Yes this s true. But you still treat mayas dg as if its a coding ground its not. Use api seriously it works better for your point of view here.
2. In such cases nodal based optimization is required, experimenting with the timerX really helps.
Well i would never put mel inside shader code. Since it wouldnt work out in mental ray or prman etc etc. And making a native render node out in code is actually simpler than trying to use expressions to fix it.
I dont optimize mel bacuse mel is not doing my job. The dg is and that i DO optimize.
3. The above facts are simply known to all intermediate level Mel programmers and preaching to newbies is truly the Blind leading the Blind..
and i am sorry for that since its a wee bit worng not much but a bit. In fact my philosophical point is that 75% of all mel out there INCLUDING autodesk and aliases code is the wrong mel use. Many problems stem form this. Yes i know no good literature about it, i wnet to ocnsiderable lengths to disect maya once because i dindt belive what i was taught.
BUT THE POINT OF THIS ALL
IF maya has a node that does the job USE that node, its simpler faster and its the right way to do it. See the aim constraint also includes certain fixes for allowing rotation to go the right way when baked etc. Thst how mel is used best simple as that.
In this case they both represent half retarded ways since Aim constraint accomplishes the net effect OF BOTH methods, all you need to do is choose the right up vector. And for the individual rotation. One can just put a extra transform in place and take it form there. So all the examples on this post are moot. Since you can also do the gimbals right ith the aim constraint nowhere does maya say it can not push the data out to nodes in other than driect indeed constraints dont need to constrain!
Now your second expression is better and i grant you expressions are easier to manage, bot one shoudl avoid using MEL inside expressions since the expression engine takes a hit on doing so. And you can end up in significant problems. Still i would just use aim costraint since it can do BOTH alternates faster! MUCH faster.
Euler based conversions are the worst, it seems Maya has a very special way of dealing with Gimbal lock -
Maya has 3 ways of dealing with gimbal lock! what it uses is up to you. But user is never locked unless they use the gimbal gizmo maya treats the data as a matrix not actually as a interpolant, nodes do. this back once its keyed tough and recostructed. But tell maya to interpolate like it changes values and you are fine.
But no never had prblems with mayas gimbal lock-. But i am aware thet theres a somebody who has thought theres a gimbal lock problem where there is no euler arithmetics about and i can see where its it coming from. Anyway this truly was blind leading blind.
so a lot of Net based coding will never work in Maya - Euler-Matrix conversion do not work
bang you went into a trap here.
thats simply because mel should not be regarded as code! Its a bit like the recepies of making a cake dont include the data to do so. So dont go googling and copyng examples over the net. its not allways very right.
Anyway as to Euler-Matrix conversion maya has this. It is re purposed as a node called transfrom and it allready has this matrix computed So theres no POINT in making a mel code that does this. I was here once too. But you can actually just ask the value. Going back is equally simple but you need to load a goodies first called decompose matrix that ships with maya but is not loaded thus the entire first example can done with 3 nodes as well as just 1 aim contraint. As can the gimbal plasma cannon with one node but by diverting the connections.
Variations on theme using aim on plasma cannon:
file -f -new;
polyCylinder -r 0.7 -h 4 -sx 20 -sy 1 -sz 1 -ax 0 1 0 -rcp 0 -cuv 3 -ch 1;
torus -p 0 0 0 -ax 0 1 0 -ssw 180 -esw 360 -msw 360 -r 1.2 -hr 0.2 -d 3
-ut 0 -tol 0.01 -s 8 -nsp 4 -ch 1; objectMoveCommand;
rotate -r -os -90 0 0 pCylinder1 nurbsTorus1;
makeIdentity -apply true -t 1 -r 1 -s 1 -n 0 pCylinder1 nurbsTorus1;
spaceLocator -n "aim";
move 3 1 -12;
parent pCylinder1 nurbsTorus1;
aimConstraint -offset 0 0 0 -weight 1 -aimVector 0 0 -1 -upVector 0 -1 0
-worldUpType "vector" -worldUpVector 0 -1 0 aim nurbsTorus1;
disconnectAttr |nurbsTorus1|nurbsTorus1_aimConstraint1.constraintRotate.constraintRotateX |nurbsTorus1.rotate.rotateX;
connectAttr -f nurbsTorus1_aimConstraint1.constraintRotateX pCylinder1.rotateX;
setAttr "nurbsTorus1.rotateX" 0;
//ok its allmost there just fix the flip:
connectAttr -f nurbsTorus1_aimConstraint1.constraintVectorZ nurbsTorus1_aimConstraint1.upVectorY;
//this is a bit of a design stupidity.
one node. Right computation order etc etc. yes i didnt kill the singularity at Z=0 but that easily done. just a small nudge in a attribute.
Dg time them! to see the difference in speed. Form this you can also see thet any aim is possible using aim constraint. Plus it respects the dag hierarchy.
he rigging runs in about 200 msecs while the frames now requires above 10 minutes per frame
So now are we on the same page. Yes true for rendering but even animators nee to live and working 24 fps versus 5 fps is a huge deal. So yes a 200 ms rig is bad since i can have 300 of them at comfy 25 fps even on a seriously old machine. With proxying a whopping 10,000 of them was no problem. So rendreing with maya hw at one frame per 2 sec was alternative suddenly. wich meant more passes could be done and ultimetely a better job. With less work, thets the right way of doing things.
So no its not just free form style issue its smart versus not so smart. Use nodes they are there for you. If you write a expression to do the job of one node then you loose allmost every time. Note its not true that expressions are necceserily slower than nodes, it depeds on how you do them. But the way most do them they are.
PS: dont take it the hard way after all the problem is mine i was jut being lazy answering the first and second time. Anyway update your workflow here please it will make you so more better.