*I know lots of big studios have Shotgun or equivalent production management system, but i don't think my supervisor would be willing to pay that much*
TACTIC, the open source version is free: http://community.southpawtech.com/get-started fTrack, $39 per 3 seats https://www.ftrack.com/#pricing Shotgun, $49 per seat https://www.shotgunsoftware.com/pricing These are not high numbers compared to the savings you’ll get by removing the complications of getting to the data as half an hour spent on that per person, only requires 8 instances and you will have blown through a full workday’s worth of expenses on a relatively needless operation,i.e. digging around for where things are. I’m not sure how the others solve it but you can for example utilize Tank (*called shotgun pipeline toolkit today but Tank is a more fun name in relation to a Shotgun*) to handle the file system mount you describe so it’s a lot more manageable that way, only difference would be the users would need to “sign-in” to a task in order to get the project mounted. http://www.youtube.com/watch?v=BY4zZrBwCjk * most of our projects are part of the full production pipeline, which means project A maybe animation while project B might be only rendering* This is not as different from other standards as you might think. This workflow exists at larger studios as well but the difference is just in the definition of the word “project”. Sounds like all you need is a “master container” then all your “stages” i.e. animation,rendering,simulation become constituants of the master container. This means to adopt a full blown production pipeline your users potentially don’t need to change anything in the way they work but you or your supervisor tie it together by redefining project to stages. Give this about 6 months and the artists will rather want to work on projects than stages and the concept will catch on leaving your workflow migrated with ease. Ultimately you will need something like this, if not only just to account for the lost time digging for data otherwise. * most of our projects require us to map a network url as a drive* Excellent! There are too many benefits to doing that to go into really but make sure the drives are mounted accurately, a difference in a samba mount or an nfs mount can mean a difference of weeks in total accumulatedlost waiting time on annual basis. Just to make a case in general by mounting drives rather than accessing the server structure remotely you get full removal of directory structure complications. *track files on a pure file system(with...)? * With either embedded metadata inside your binary or ascii, then using grep or strings to extract it, or in a .info stub file either next to your data or stored on a separate metadata server. *not as good as we wish since "**s01c03_v03.ma <http://s01c03_v03.ma/>**" will not remind us of anything* This is actually a more directory structure issue than a naming convention issue. Keep in mind that file names are not the last readable stub you get displayed, a full filename would be: *C:\this\project\with\that\shot\s01c03_v03.ma* You can see the naming convention part is not the identifiable part, where the file is kept identifies the element being worked on. Keeping placement of files in order is not easy though, so you’ll need a publisher, something that ensures when an artist wants to pass on files to the next artist he/she does not have to worry about where to put the file, just click “publish” and let the distribution code put it where it should go. This means the fixed location will be a known location where anyone picks up any data, always in the same directory depending on what project is mounted on a drive P:\maya\renders for example would always include the Maya renders for the project in question. ///// With such a high number of stages and people I’m going to venture a guess that you are working on a gaming pipeline rather than a visual effects one, if that is the case then just make sure whatever system you adopt to transfer the “shots and sequences” terminology you find in the documentation into a “scene and element” terminology and the pipeline approach is then near identical (* with a notable missing feature in all the mainstream production managing software being a sandbox area in parallel with shot review turntable videos where you upload assets and can view them in an in-game environment, basically a video stream on your website coming from your engine, this would let your supervisors and directors do quick reviews even on their phones.* ) As for the non-english speaking part, Shotgun for example is a web based approach, as an example I'm using the target language as Spanish here below, in which case you get half away with just using things like auto-translate in Chrome. Translating the API itself is a hazardous sport, means you need to update your translation for every iteration and addition that comes from the developers so it may turn into a full time job. Again here Shotgun has the strength of you being able to work in english but you rename only your “entities”. Some people rename their “shot/sequence” category to “shots/sequences” so it can just as well be renamed to “disparo/secuencia”. That means a one-off translation which is performed as a definition at project startup anyway will ripple through to all projects. Hope this helps, it’s a fun subject, just make sure not to point that Shotgun at anyone since too much discipline/enforcement can definitely take away from the creative side the system is meant to support and enhance, try introducing the time saving benefits of doing this in a more organized fashion and surely your supervisor will love the free time he gets to work on the project data rather than search for the project data. -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/1f238a86-751c-4745-9122-76d6dd6fd582%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
