What you described, Joey, is nothing more than point of reference. What is local in one perspective and global in another, can be modeled as parent/child relationships in many cases. It can be done, it's just a matter of studying the ripple effect of changing a core fundamental feature. It may not be a practical investment of time, but it can be done.
I am sure any one of us could make a very long laundry list of what we'd like to see carried over from Softimage. I think it would be better to describe them from a function point of view rather than specific named feature. For example, ability to use global transforms to manipulate an object instead of just local as Maya currently supports. The ability to define your keyboard commands so the stuff you use 80% of the time doesn't get stepped on by esoteric stuff. For example, if "A" frames all objects in a viewport, then that key should not be used for something less important (or completely unimportant) such as changing your layout to be in animation mode. Softimage put all the important stuff in the center of the keyboard where your hand naturally rests, and put the lesser important stuff at the perimeter. the less important it was, the more hoops you had to jump through to access it. That's how it should be. Maya has no system. Example: must use ALT-MMB to pan the camera. WTF? Not only is that out of the way, but requires uncommon use of key and mouse to perform. It's certainly hard on my arthritic wrists. Probably the most important change I would like to see is rewriting of the documentation. Whoever wrote the current docs has poor organizational skills and doesn't have a mastery of the English language. Topics frequently point to other pages only for those pages to point back to where you started without answering your question. Many pages have so little information it's not worth having pages for them. The SDK documents aren't much better as they fail to mention some very important pieces too as everything is written from the point of view of hindsight (i.e. written as if you already know the SDK. Not designed for newcomers). Heck, the C++ SDK docs don't even alphabetize the methods available in a class. Seriously? Ever look at a larger class like MFnMesh and try to find the one method you need to get UV space info? It's a chore. As a direct comparison, take a look at the Maya Python API docs which describe many of the same methods. notice they are alphabetized, and while that doesn't solve the problem, it certainly makes it less of a chore. comparison - C++ vs. Python documentation of MFnMesh class: C++: http://help.autodesk.com/view/MAYAUL/2017/ENU/?guid=__cpp_ref_class_m_fn_mesh_html Python: http://help.autodesk.com/view/MAYAUL/2017/ENU/?guid=__py_ref_class_open_maya_1_1_m_fn_mesh_html Ideally, I'd like to see the SDK docs written like the Softimage scripting object model documentation where the methods were listed above, and the properties listed below in grid fashion. That was a powerful arrangement of information to make learning easy. Matt Date: Thu, 31 Aug 2017 16:11:08 +0000 From: "Ponthieux, Joseph G. (LARC-E1A)[LITES II]" <j.ponthi...@nasa.gov> Subject: RE: What were they thinking.... I know this is not going to be popular, but I'm going to suggest that no one should get their hopes up about ever seeing that changed. Folks need to understand that transforms, matrices, centers (pivots) and their breakout and order are deeply embedded in Maya's internal structure. Further, when they were established PA and TAV were used as precedence for their design. For example some of it is considered from the vantage point of a model centric zero world position, because prior to Maya, everything in TAV's modeler (Model) was modeled from a world zero relationship to the model in Model. The model was then imported into its animation editor (PreView), or other tools like Dynamation, and what was world zero for the model in Model became the Transform center for the object in Preview. If you are old enough to be familiar with TAV's behavior, and to have used it, you would understand why Maya was designed the way it was. You can't take XSI or SI3D's way of doing these things and compare them 1:1 to Maya. They are inherently different and for specific reasons. XSI and SI3D gave us an abstraction layer for centre/pivot control which, in my own opinion, was not only unique but radically out of step with the rest of the CGI world. If one wants to argue that it was forward thinking I suspect argument could be made, but it sure made it easy, maybe even too easy, to alter pivots mid-stream in SI. Once you get used to pivots and understand how to edit pivots (or rather when not to edit pivots) in Maya, they are really not that difficult to deal with. But you literally have to ignore the way you were doing it in Softimage and take it from the Maya way. If you try to assume a Softimage centric way of pivots in Maya, or even try to visualize it that way, you are going to be miserable. It doesn't work that way, and more than likely, probably never will. -- Joey __________________________________________________ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -----Original Message----- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Morten Bartholdy Sent: Thursday, August 31, 2017 10:36 AM To: r...@casema.nl; Official Softimage Users Mailing List. https://groups.google.com/forum/#!forum/xsi_list <softimage@listproc.autodesk.com> Subject: Re: What were they thinking.... - and there is the idiosyncrasy of the concept of centers and pivots and how the position is displayed... MB > Den 31. august 2017 klokken 15:39 skrev Rob Wuijster <r...@casema.nl>: > > > same here ;) > > Rob > > \/-------------\/----------------\/ > > On 31-8-2017 15:32, Morten Bartholdy wrote: > > Well a lot of XSI functionality has popped up in the modeling section of > > Maya 2018. Still looking for UI logic and straightforward useability. > > > > MB > > > > > > > >> Den 31. august 2017 klokken 14:16 skrev Rob Wuijster <r...@casema.nl>: > >> > >> > >> Yet I'm foolishly waiting for Maya to pick up some of the SI > >> workflow and menu setups.. > >> e.g. forest of mesh options en menu's..... > >> > >> > >> Rob > >> > >> \/-------------\/----------------\/ > >> > >> On 31-8-2017 13:55, Morten Bartholdy wrote: > >>> It is good to know that there is at least one sensible person in > >>> close proximity of Maya development :) > >>> > >>> Morten > >>> > >>> > >>> > >>>> Den 30. august 2017 klokken 17:28 skrev Luc-Eric Rousseau > >>>> <luceri...@gmail.com>: > >>>> > >>>> > >>>> ok, I'll have someone take a look. thanks > >>>> > >>>> On 30 August 2017 at 10:18, Ponthieux, Joseph G. (LARC-E1A)[LITES > >>>> II] <j.ponthi...@nasa.gov> wrote: > >>>>> No, unfortunately I'm not confused about this. > >>>>> > >>>>> If you build a scene, save that scene, there is no lingering copy > >>>>> clipboard file still resident in the temp directory, and you never > >>>>> hit CTRL-C, hitting CTRL-V while in the Outliner rereads the same > >>>>> exact scene you are currently in, and had just saved, back into > >>>>> itself. > >>>>> > >>>>> It then begins telling me with via the progress bar, that the scene > >>>>> I had just saved, in my particular case with all 40,000+ objects, is > >>>>> now being read into the working scene. > >>>>> > >>>>> Which means my scene now has two iterations of itself present in the > >>>>> scene after it is finished. > >>>>> > >>>>> The repro steps for this are here: > >>>>> > >>>>> https://forums.autodesk.com/t5/maya-forum/ctrl-v-reads-a-copy-of > >>>>> -the-scene-into-itself/m-p/7329534#M46237 > >>>>> > >>>>> The point of this "feature" was apparently to facilitate the copying > >>>>> of objects across independent Maya sessions. But the > >>>>> cutCopyPaste.mel appears to be caching the current scene name and > >>>>> decides to use that instead if copy has never been executed prior to > >>>>> the paste or if no clipboard file is available and found. It just > >>>>> summarily, and without warning, proceeds to "paste" the saved scene > >>>>> back into itself. > >>>>> > >>>>> The upshot is that CTRL-V assumes an input that was never given it > >>>>> by the user. > >>>>> > >>>>> I'm not sure why in the world I would ever want it to do that when I > >>>>> can use "import" to explicitly re-read the scene, or explicitly > >>>>> perform a copy&paste on the active scene hierarchy, to accomplish > >>>>> the same result. > >>>>> > >>>>> Instead it is an uncalled for action that has the potential to cause > >>>>> severe loss of data. Which is what happened in my case, because when > >>>>> I went to delete the 40,000+ extra copies that I did not need, it > >>>>> was still trying to delete them a day later. > >>>>> > >>>>> Joey > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: softimage-boun...@listproc.autodesk.com > >>>>> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of > >>>>> Luc-Eric Rousseau > >>>>> Sent: Wednesday, August 30, 2017 9:51 AM > >>>>> To: Official Softimage Users Mailing List. > >>>>> https://groups.google.com/forum/#!forum/xsi_list > >>>>> <softimage@listproc.autodesk.com> > >>>>> Subject: Re: What were they thinking.... > >>>>> > >>>>>> Ctrl-V executes a scene read, of the currently saved scene > >>>>>> into the existing scene This happens if you are in the outliner > >>>>>> Its basically the equivalent of import scene > >>>>> I think you're confused about this one. Ctrl+V is just the "paste" > >>>>> command and the clipboard is implemented by saving objects when you > >>>>> press ctrl+C, and later importing objects on paste from a temp > >>>>> scene. > >>>>> Exactly the same as it is XSI. The only thing new here is that a > >>>>> progress bar was added to the outliner to show progress when there > >>>>> is a massive number of nodes added, and the log window will say > >>>>> something "scene read in 1s" or something, which may be confusing > >>>>> you. > >>>>> ------ > >>>>> 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. > >>>> ------ > >>>> 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. > >>> > >> ------ > >> 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. ------ 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 Softimage@listproc.autodesk.com http://listproc.autodesk.com/mailman/listinfo/softimage End of Softimage Digest, Vol 105, Issue 54 ****************************************** ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
