Hey Fredrik, Is your logic from the Project Manager separated out into a library that can be reused easily by other tools? If so, then I think that is a good path, since if you are going to move towards an almost pure filesystem abstraction, it will be pretty good to have a way to support tooling needs outside of the main UI that you all use.
I've seen and heard different levels of filesystem abstractions, all the way up to where everything is flat with UUIDs and you 100% rely on your abstraction to make any sense of it. But the more abstract it is, obviously the better and more versatile the tool support should be. So I don't think it is all that crazy of an idea, provided you prepare for those circumstances. And it also does depend on how big your company is and how different your project structures are, how much you expect them to conform, and how much tooling you have around concepts that expect consistency. But I assume the amount of flattening that someone would go with might also be a balance of still wanting to be able to have enough flexibility to have different mount points to control which data lands on which storage backends, and being able to transparently migrate data between available storage. That is probably the reason I have seen at least the project/scene/shot granularity, but your mileage may vary. Also there is probably the consideration of how many files will end up in a given directory, which could make listings slower. All in all, the file system abstraction can totally make it easier to do renaming of items without breaking anyone, as long as everyone is going through the abstraction layer (back to having good tools). So ya I support your ideas here. But it might be good for me to play devils advocate and not think in terms of "we really only use Nuke or Maya" but rather "what if we didn't use Nuke or Maya one day?". You said you have that partially covered by having the standalone manager. It just means if someone were in, say, Photoshop, they would need to have a workflow that supports opening and saving files without too much fuss, or without you scrambling to make another application integration. That can be the reason for at least having a minimal amount of hierarchy. Anyways, sounds like a cool goal! On Thu, May 8, 2014 at 8:32 PM, Fredrik Averpil <[email protected]>wrote: > 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<https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWPVFHJ-B1gGjv9-t2x0pc7OidZnESJKiMiTwn%2BZip%3Dimw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAPGFgA3wNMi8jdDE6rD5C7jpHsHsDBr3wbe%3DtG36DwDDjEFV6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
