I might add I have a working prototype project management tool which runs in Maya, Nuke and standalone. It supports all of the above and Maya and Nuke scene versioning as well as assets. It reads all user-defined names for files and folders from a mySQL database currently.
So it works. It's just whether the whole approach is flawed in a major way that I haven't thought of. Fredrik On Thu, May 8, 2014 at 10:27 AM, Fredrik Averpil <[email protected]>wrote: > Hi all, > > We are revising our file structure on disk, and I figured I'd just ask for > some advice/ideas here for anyone interested. > > Currently, we use the server/project/sequence/shot/ approach with assets > being stored per sequence, but as we tend to rarely utilize "sequences" or > "shots" as we do a lot of archviz and shorter commercials, this file > structure is more often cumbersome than helpful. We are also a generalist > group of people, meaning one or two people may run a project and complete > it. Sometimes a project needs to get divided up on a much larger group of > people, but this is pretty rare. > > Therefore I'm contemplating whether to flatten the file structure into > just /server/project/ or to keep the current one. My goal is to provide the > power of structuring up a project but also be able to work in a much more > flattened manner for smaller, one or two man projects. This flattened > approach would mean that you would find a default Maya project directly > underneath server/projectX/ and in here all scene files for anything is > stored. > > The reasoning behind flattening the file structure would mean I would > accompany the file structure on disk with a project management tool which > is available inside of Maya and Nuke. This tool would read a database or > JSON file, which would dictate virtual folders. So a user would still be > able to create sequences and shots, but no folders would get created on > disk. Instead, only one Maya project directory exists within a project and > each scene file gets tagged with which virtual folder it belongs to (along > with other attributes such as whether the scene is in fact an asset or e.g. > a render scene). In the project management tool, you navigate through this > virtual folder structure and find your scene files. Whenever you want to > save a new scene, a dialog pops up asking you where you wish to save it in > this virtual structure and which type of file it is. > > The project management tool allows you to select files and > reference/import and do other things such as export proxies and such. When > generating new data on disk, for the most used features, a custom dialog > would pop up to ask the artist whether he or she would generate e.g. > particle cache "globally" on tied to the scene. Depending on user choice, > the data will get stored in subfolders or in the default location. > > So everything seems to happen in a folder structure but this really does > not exist on disk. There would be a few scenarios where users must deal > with the real file structure on disk though, and for this reason there will > always be a right click menu in the project management tool's navigation > pane, where you can "Browse folder on disk" to immediately get to the > physical location on disk without having to figure your way there. > > There are of course scenarios where this approach (virtual folders) > doesn't work at all, for example in any software where the project > management tool won't run (perhaps because the lack of PySide support). But > here in our studio, 90% of what we do, we do it in either Maya or Nuke, > which both would support this. And since the project management tool is > designed to run as standalone, artists can use it to get to application > folders without having to navigate manually. > > Now, I just need to make sure I'm not doing something stupid, such as > making it impossible for us to run certain software in the future which > would require us to completely overhaul this system. And I was thinking I'd > just post this over here to see if anyone 1) has read this enormous email > at all 2) has any ideas or comments to this type of approach, or even > experience in something similar which they would like to share. Any > comments are greatly appreciated. > > > Fredrik > > > > > > -- 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/CAD%3DwhWPVFHJ-B1gGjv9-t2x0pc7OidZnESJKiMiTwn%2BZip%3Dimw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
