Interesting question, would be happy to add my 2 cents. Currently and in the past I found that a combination of publishing framework together with a database can work great. Each publish is store in the database with at lest those basic field: context ( Shot/Asset ) type/group ( rig, geo, maya-scene-file ) status ( approved, rejected... pending review ) user ( who publish ) location ( of files/folder ) date ( publish date )
With that you could do useful queries like this: findPublishes( assetID=1, type='rig', status='approved' ) The publishing framework would handle the file-system transactions and permission: it should do something like this: - receive data/files/folder to publish - pre-register the transaction ( create and lock version 01 ) - creates place for the data in a user-read-only location - copy the published files/folder into - lock permissions for read only - post-register the transaction ( finish publishing version 01 ) * in case the publish failed for any reason, the manager will revert back the operation and delete the transaction records. The database ( could be Shotgun using publishFile entity or some custom entity or a local mysql ) will handle the following: - keep track of published versions per asset/shot - keep track if an asset/shot got checked out - keep track of the version status ( approve, latest... ) this approach can support multi users&shows and even multi OS working together. hopes that helps a little, Asi On Tuesday, February 18, 2014 6:47:47 AM UTC-8, Eduardo Grana wrote: > > Hello Everyone! > I just love this topic, i would be great to come up with a 'python inside > maya' workflow and pipeline guidelines. Or even Pipeline Standards! > Maybe we can make the industry a better place to work! > Thanks everyone for sharing > . > Cheers! > Eduardo > > > On Tue, Feb 18, 2014 at 5:41 AM, Ævar Guðmundsson > <[email protected]<javascript:> > > wrote: > >> *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 >> accumulated lost 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 <http://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] <javascript:>. >> 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. >> > > > > -- > Eduardo Graña > www.eduardograna.com.ar > -- 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/1cf0c905-95dd-41c7-9aff-b54eee04d186%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
