test 2017-09-16 22:13 GMT+02:00 Jason S <jasonsta...@gmail.com>:
> On 09/15/17 15:16, Anto Matkovic wrote: > > Whatever works for you. For example I never tried to key the global > transform in SI, always used constraint instead, because this clearly shows > what's going on. Also followed 'one object one transform' 'rule', that is, > never more than one constraint or expression per object - this makes it > easier to connect to another structure, reset, so on. But that's just me. > It's always possible to hide some null, after all. > > > Hum. I don't think it's just for what works for me.. --> * (see > footquote) > > In Maya (as I think I understand) , once you freeze your object, > -it- becomes the center of itself (for things to be relative to it), > and looses all references to Universe 0 does it not (?) > (also kind-of like many public companies actually ;) ) > > Then where are it's 'universal pose' values after it's frozen? > (where is the object in universal space?) > > In XSI there is "Neutral Pose" which allows to reset to that, > but there is always a (read/writable, and resettable) reference to 0 > universe. > > and as previously covered, where are it's 'local pose' values once it's > a child of something? > > it's doable but ... ... complicated (for simple things) > (more nulls forever) > > > And consequently, I really don't think any advantage of "dual > coordinates" has to do with '*keying global transforms*' > > but rather (as you probably know inside) :: > --> there is -always- 'local' ( parent relative values.. --and what > you normally animate in XSI-- ) > and 'global' (universal) coordinates, -- both coordinates for reference, > keying, driving or just setting (or -resetting-), > that are intricately part of absolutely everything, and there all the time. > > Without the need for redundant transient items that can accumulate quite > fast, and clutter up everything , > ( speaking by sometimes already finding too many control items in XSI and > always trying to simplify as much as possible ) > and without the need to calculate or deduce those (super useful) values > when wanting to reference (or drive) them. --> * > > and the previously mentionned "sea of relationships" can also very-much > include how relations are represented in the node editor, > with little to no abstraction to a way of doing things that (historically) > has been recognized as over-bloated or over-complicated. --> ** > > > > * from 2005 (about clutter and things) > http://forums.cgsociety.org/archive/index.php?t-173245.html > > > > > > > > > > > > > > > > > * ... in maya there are many things where i wonder what the hell is going > on. very often i parented an object into another and couldn't define the > coordinates correctly any more. and much more things. a further example: > after having mirrored and smoothed an object, maya has generated 4 > additional objects to the scene (2 transform groups, the low-poly mirror > and the smoothed mesh). working with blendshapes also generates some more > objects, so the whole scene gets very confusing after a little time. if you > don't give a name to EVERY little thing (even if it's a texture node), > efficient working gets nearly impossible. every object is connected to many > nodes - the complete program seems to be a big net, and it's your job to > navigate through it. (really annoying under time pressure) while working > with nurbs surfaces you should better clean up the history (delete modifier > stack) or maybe you get double transformations, can't move a parented > objects correctly or get other problems like that.* > > > ** from 2016 about Maya transforms > http://forums.fabricengine.com/discussion/585/maya-transforms > > > > > > > > *... as I was saying in the beginning, there is not reason to try to have > a Maya transform. It is an old thing that caries with it many problems. It > tries to give many features that in theory sound great, like the > possibility to set its pivots, but in practice it's simply way to > complicated, convoluted, over-designed, resulting in a huge object > (considering the context of its typical use) that it's slower than what it > should, not mentioning the headache it gives every time you have to deal > with it in the API. * > > > *My suggestion? You have Fabric now, that allows you to stay away from > the bloated Maya's transform as much as you can. * > > > *Learn instead how to handle Xfos, and do what you want with those. * > > *Care about the Maya's transform only when you set them from Fabric or > read them for Fabric.* > > * You said you come from Xsi. Don't make your life unnecessary sad and > ugly as I had to do* [image: :)] > > > > *_____________________________________ ... really thanks for the detailed > answer. Yes, I am trying to replicate Maya's transform for 1. understand > it better since now I have to work with it and 2.understand Fabric Engine. > * > > > *I was thinking that Mat44 and Xfo were pretty much the same as Scalar and > Float32, for instance. Different names for the same thing, which confuses > me a lot in Fabric. There are SO-many-nodes!* > > > *It was good to see your opinion on Maya's Transform, which seems to be > the general one. I never see people messing with the pivots, just grouping > lots and lots of transform groups.* > > > *I'll keep taking a look at Fabric. Cheers* > > So maybe in another life would there be simplicity again, > then also hopefully made by non-self-centered entities (not referring to > employees) > > Thanks, > J > > > > > > > > > > > > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > with "unsubscribe" in the subject, and reply to confirm. >
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
