It depends how granular you want to get. To give a few examples, our asset management is hooked in as a maya module, this handles all our save and load functionality. Our skin weight editing toolset is another module etc.
All our generalised python code is completely abstracted so it can be called from any application and the whole lot is wrapped up in a deployment system that ensures all the users are on the right versions of tools etc. We did it that way so we could share modules without having lots of dependent code (a core python library is usually the only dependency of a module... There are a few exceptions of course!) Not sure if that helps much, but it's the closest approach to a workgroup as both have a defined structure to load specific data types from. Mike Sent from my iPhone > On 9 Mar 2014, at 21:15, "Tim Crowson" <[email protected]> wrote: > > Thanks for the feedback guys. This really helps. So for our custom pipeline > tools, like loaders and publishers, would those be considered 'modules'? > -Tim > >> On 3/9/2014 4:09 PM, michael malinowski wrote: >> Maya Modules are probably the closest thing, at least in terms of code >> encapsulation. You can also just add one module path into the environment >> variable and point to a lot of different modules. >> >> It's nowhere near as nice as workgroups but it is the nicest way I have >> found to handle lots of code/plugins in a distributable way. >> >> Shelves are the only caveat in that a maya module doesn't have a shelf path, >> thus you either have to handle it separately or dynamically load the shelves >> via a plugin. >> >> Mike >> >> >> >> On 9 Mar 2014, at 19:42, "Siew Yi Liang" <[email protected]> wrote: >> >>> Hello, for myself I actually use symbolic links in Windows; my Maya scripts >>> directories and plugins folder are synced to my OneDrive, and then a >>> symlink links directly to that folder for my Maya installations. Works >>> pretty nicely! You can use something like: >>> >>> https://bitbucket.org/jsumners/winln/wiki/Home >>> >>> If you don't want to play with the cmd prompt, too! >>> >>> I should do the same thing for my XSI setup but right now I'm too lazy. :P >>> Yours sincerely, >>> Siew Yi Liang >>>> On 3/9/2014 10:19 AM, Tim Crowson wrote: >>>> That's correct, Stephen. Thanks. >>>> -Tim >>>> >>>>> On 3/9/2014 12:16 PM, Stephen Blair wrote: >>>>> Yes, you can append paths. I assume you mean MAYA_PLUGIN_PATH and >>>>> MAYA_MODULE_PATH? >>>>> >>>>> about distributing modules: >>>>> http://around-the-corner.typepad.com/adn/2012/07/distributing-files-on-maya-maya-modules.html >>>>> >>>>> >>>>>> On Sun, Mar 9, 2014 at 1:05 PM, Tim Crowson >>>>>> <[email protected]> wrote: >>>>>> And my follow up question would be.... can we append multiple paths to >>>>>> those envars, so we can point to multiple locations at once? >>>>>> >>>>>> >>>>>>> On 3/9/2014 12:02 PM, Tim Crowson wrote: >>>>>>> That's more like the equivalent to rray.de/xsi... >>>>>>> ;-) >>>>>>> >>>>>>> Looking at the Maya docs, I'm guessing I need to implement environment >>>>>>> variables to point to a different path for plugins and scripts at >>>>>>> launch... >>>>>>> -Tim >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 3/9/2014 11:52 AM, Emilio Hernandez wrote: >>>>>>>> creativecrash.com >>>>>>>> >>>>>>>> El mar 9, 2014 10:50 AM, "Tim Crowson" >>>>>>>> <[email protected]> escribió: >>>>>>>>> Is there anything like XSI's Workgroups in Maya for sharing plugins >>>>>>>>> across a network? >>>>>>>>> >>>>>>>>> -Tim >>>>>>>>> -- >>>>>> >>>>>> -- > > -- > > > Tim Crowson > Lead CG Artist > > Magnetic Dreams, Inc. > 2525 Lebanon Pike, Bldg C, Suite 101, Nashville, TN 37214 > Ph 615.885.6801 | Fax 615.889.4768 | www.magneticdreams.com > [email protected] > > Confidentiality Notice: This email, including attachments, is confidential > and should not be used by anyone who is not the original intended > recipient(s). If you have received this e-mail in error please inform the > sender and delete it from your mailbox or any other storage mechanism. > Magnetic Dreams, Inc cannot accept liability for any statements made which > are clearly the sender's own and not expressly made on behalf of Magnetic > Dreams, Inc or one of its agents. > >
