Hey Alok, This kind of input provokes respect.Thank you so very much for your time and effort. This is kinda more than I expected.Awesome !
*It would be a disservice to write on the python-inside-maya group, without mentioning the awesomeness of python.*- Good line of thought. *quickly written and somewhat incohesive, but I hope they help. *Don't think they are in-cohesive though Rich intention* >*Much appreciated !!! Thank you On Thursday, December 15, 2016 at 6:46:13 PM UTC+5:30, Alok Gandhi wrote: > > @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. > > > -- > -- 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/86ad96bc-50e0-465a-bf78-04a7024773f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
