@river - Start simple (if you do not have any rudimentary pipeline setup). In designing pipeline (and eventually tooling for it) you need to start light but solid with some fundamental principles incorporated.
*Core Tenets* Three things are of fundamental importance - Scalability, Reliability, and Security. Each of these aspects should be addressed. *Scalability* - The pipeline should be able to handle 10 shots as easily as it should 2000. Although, from the get go it is not easy to design for future proofing the data quantity but still you should pay some heed to it *Reliability *- The data should be reliably stored and backed-up. In the case of database outages, the pipeline should be able to recover itself as quickly as possible. If possible, there should be no central point of failure - go as distributed as possible(git is a wonderful example of such a distributed system). With Cloud Computing now becoming affordable and secure each day, you can take a look at it also. *Security* - Protecting the IP is important. User / Tool permissions to access the database should be implemented in the most secure way. This could start by harnessing the power of the os user permission (in the case of folders). Users should not be able to access the data only tools should. If you are using a database, most of them have this inbuilt, look at their relevant APIs. *Tools* Some basic tools need to be designed - *Publishers *- For exporting data from DCCs / Departments. Naming conventions and validity checks are the first part, then comes the part of exporting the data to a database. *Builders/ Importers *- For importing data into DCCs, basically looking up the data in a database (these can be as simple as folders or as complex as large database spread on huge servers)., retrieving it and then importing it in the scene. *Versioning* It also worth mentioning that versioning system is of uttermost importance here as well, do keep in mind what kind of versioning framework you are going to use. It should allow easy versioning operations like versioning up or down and should be intuitive to the artists. They should be able to easily access and use any old version and also able iterate over versions of their work/tasks in the simplest possible way. Again, look at the design principles used in git for versioning. If whole Linux Kernel can depend on it, so can a pipeline. *Inter Studio Data Flows* While talking of inputs and outputs, do mind that at times most modern pipelines have both 'inter-' and 'intra-' data flows. Meaning, you have intra-departments data flows in your studio, but also there is the case of inter-studio transfers. Collaboration is a growing trend in our industry. Even the biggest studios these days are outsourcing their work to smaller shops. This means you should be able to efficiently handle and transfer back the data coming from and to an outside studio. Most of such transfers employ industry-accepted cutting-edge formats like alembic. Thankfully our industry has encouraged and embraced open source projects more than any other. *Free Open Source Projects* There is a host of open source projects, big and small, helping you to facilitate such pipelines. Alembic is just one them. Also, USD from Pixar is gaining popularity since it has gone open source. In short, don't reinvent the wheel, use already available libraries to your advantage. This can save huge time and development costs. *Pipelines are living entities* Pipelines are a complex system and have a life of their own. They evolve over time responding to various production pressures. You cannot think of every possible requirement before it comes to haunt you, but you can surely design loosely coupled components (as generic as possible) so that it can evolve easily. You are never allowed to say no. *The Human Element* Pipelines have two brains (just like us human have left and right brain). One is the free flowing, creative, innovative side and the other is logical, calculating and rational. Both of these, fight with each other all the time. The resulting conflict causes the pipeline to evolve. The human side is the artist, they need fewer buttons on the UI, simplified workflows and be able to focus on their art rather than the technology. Tool design should take care of this. On the other hand, there is the database, the data, the metadata and all the stuff like versioning systems, naming conventions, data access, io operations that need to be designed in the most rational, pragmatic and logical way possible. A good pipeline constantly tries to broker peace between these satisfying the common denominator. And of course to wreck all of this are 'the clients'. They are paying and are the boss. They can and do demand most outrageous things and ask it to be delivered at exactly 2.37am the next morning. Do account for that also. Finally, *import this* It would be a disservice to write on the *python*-inside-maya group, without mentioning the awesomeness of python. Go to your REPL and type `import this`. Read carefully the stuff that your REPL spits out. Called 'Zen of Python', these are like the 'ten commandments' (only better, these are 20) of the religion called python. These apply to any design process. Each one is a gem and most of them pertain to pipeline design. Timeless in nature, these are relevant to any sort of engineering. Think about them and how they apply to your pipeline design. Use them in your pipeline and thank Tim Peters for writing 19 of them. These are my thought, quickly written and somewhat incohesive, but I hope they help. Good luck! - Alok. On Thu, Dec 15, 2016 at 8:09 PM, river bell <[email protected]> wrote: > hey Neil, > > First up thanks for the excellent input. > Barring a few doubts we have to surely consider this approach soon. > > We do reference the rig for animations > I have found that the name change also happens in the texture dep. > > From what i know yet alembic needs model uvs in place so the idea of > texturing and rigging and animation running in parallel was not possible > and therefore not considered as of yet. > I am in a position to research and introduce a better pipeline so will > delve this way for sure too > > Thanks > > -- > 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/3046793b-0896-45f3-9484- > efe8a54ea58a%40googlegroups.com > <https://groups.google.com/d/msgid/python_inside_maya/3046793b-0896-45f3-9484-efe8a54ea58a%40googlegroups.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/CAPaTLMQs5%3DJU8WkfYgpXHSXck78rQfT4AyMfFbTzFkNJcBXdHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
