While i can see that some people might want to use a installer its not neccesreily a good idea.
First Security, if i get a exe file i must overweigh what the overall usefullness of it versus the potential security problems (now your kindof forcin any sane TD/sysadmin to sandbox this first and then get the files). While any maya script itself is a security problem i do look over every single file that has a call to eval, system, refernce scriptjob and file.
Second, exes aren't croiss platform so any mac and linux user out there is automaticaly disqualified from participating. Which contadicts your goals.
Third some people want to see what they install, this is part of the apprisal of the usefullnes of any script to glance the sources at first conception.
So please ship just flat files aswell as installer
Deployment issue 2.
Maya allready has a built in module functionality, why arent you using it instead ove developping your own?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact there are. A few of them in fact, maya even ships one very rudimentary one (that works very well, it has pictures and all). Especially on the scope your doing it in.
The base problem is that your targeting too low, assets aren't the most important part of the pipe, but rather a fraction of what the pipe should be. For example your in a way trying to go into the area of a cvs repository (for example www.perforce.com), indexing service, request and maybe a approval system. Now all those are important but just the tip of the iceberg missing the bulk entirely.
Theres much more stuff that needs to be accounted for and unfortunately a pipeline is not and should not be limited by the application in use because it spans the entire workflow form script to finished project, this is why maya defines project folders.
However in order to get a true pipeline you need a way to communicate all data much more effectively and store all data much more safely (again exampleperforce does enable 2 artist to work on the same asset file simultaneously, in limited degree if its a ma file). But thats not the end of it the pipeline is also must do all requests keep track of staff meetings, push renders into queues, compress outputs for approvalm Back-up stuff, Monitoring synchronous projects, etc..
However this alone cant be done in maya there must be tools that are outside the maya scope since maya cant facilitate all things needed. because mayas just on facet of the entire pipe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The exe is long gone so that's not an issue anymore.
joojaa you are totally right that assets are only one small part of the pipeline puzzle - we are in the process of planning a standalone version written in python that will cover all aspects of the pipeline and cross in and out of worker applications.
underearth, joojaa: care to pitch in? Thanks for the thoughts and sorry for the months of delayed response!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree with you about the idea that asset is just a facet of the pipeline, but I also want to mention a thing that asset is the base facet of the pipeline,
Just imagine a wrong version of Rig pushed into Episodic Animation production , where control names are different than approved Rig Template,
When TDs will realize animator would have made tons of animation files,
and in one project we already faced too many problems in Animation because we don't have any version control or communication method between artists of different department.
My point is, Let this asset management be tip of the iceberg but once we conquer it then we can provide other modules for """keep track of staff meetings, push renders into queues, compress outputs for approvalm Back-up stuff, Monitoring synchronous projects, etc..""" on top of it,
correct me if I am wrong,
We are in process of developing an openSource system which will provide features like Alienbrain studio,
Please support us at each level,
I Hope to see more thoughts on these topics,
:)
Vishang Shah
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes off course, however i suggest you roll in some tool set to use a cvs system instead of trying to make one in mel (a cvs makes it possible to have one file which has many versions so you also don't clutter up stuff, and the user will KNOW when he has a older version). Plenty of free ones around they are perfectly suited for use in maya.
however i think you mean a TASK is a the primary facet of a pipeline, not a asset (just like the product in factory inst the most fundamental part of the factory but rather the flow of it whilst ist becomes a product). The asset is just what the task produces or processes.
So pick one CVS or make a pi for the cvs and build the gui to use that.
Then gear the open pipeline to actually do pipeline stuff cvs is cvs thats what should take care of assets keeping teh assets current. However the pipeline should take care of sending notification to users / automated systems in timely fashion at right time so that they start processing so the next notification can be made. So pipeline in m mnid is more like the conveyor belt in a factory than actually managing the storage area any sotrage are can should be able to be used.
This is what i see the ultimate pipeline doing:
So when user XXX sits in on his computer hes greeted by a list of things to be done (maybe in a form of a production schedule list with deadlines but in simple form jsut in priority), he then only double cliks on said job and the conveyor belt should ideally FETCH the right thing to do (its not its job to facilitate the storage) the user does NOT knwo what file he is accessing nor should he care. Along which all he needs, such as soundtracks, special instructions and so on. The cvs tracks the storage area and sets the file marked as in use. The pipeline manager tracks JOBS, next one to log in get their own list which now no longer has this task to be done since its under works. When the current task is finished, be it a texture paint a rigging operation. When the user is finished this job dissapear form his list, the job knows whats going on next the user needn't know nor care what it is. If its going to a animator or or approval does not amtter at this stage its a next job.
Now let us suppose a simple animation sequence might look form pipelines point fo view like this all of theese are jobs tat pop up on various persosn desktops at various times
Stage 1:
synopsis
script
stage 2 (turns into):
storyboard
soundtrack
revised script
stage 3
simple sotoryboard animatic with preliminary sountrack
stage 4
approval or return to stage 2
stage 5.
each character and object is assigned a individual job that are defined here
....
these are then submitted partially concurrently on need to the pipe. Sometimes the next stage is a script sometimes its a person sometimes it s group of persons etc. At some point the object might be submitted in and the next user get sthe object only to se ethet it has occlusion baked in between the last submission for example.
Well im just feeling your half on the right track but too focused on making it into a cvs which isnt what a pipeline is about, its wats pipelines need to manage. Lateley yove gone to better direction tough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You bring up some critical issues. But I would argue that you can't build any of the concepts you've mentioned without building what we have currently. Right now we are very focused on issues of plumbing that will provide the working base for the management skins that will overlay this. For some users, what we've built is enough. For example, most small studios and independent animators don't have the know-how or interest in setting up CVS (or subversion) so this provides a built-in solution. They can start using it right away. They also get a bird's-eye view of the assets in their project, collaborative (XML) notes, project definitions in an XML format, a simple form of scene population, and a code base to start building off of. In the future the revision control schema in place will be the "openPipeline Classic" option of saving and integration with subversion will be another (it's better at dealing with binary files) option. The revised project manager is the first step towards the larger pipeline tool that I think you're hoping for.
The notion of "Tasks" is a whole layer above what we have built thus far. That falls under the banner of project management and we are looking for a good open source project management application to build on top of this that will interact with the current Maya version and the future stand-alone python version as needed. We are in talks now with possibly just the right fit for this.
The upcoming stand-alone python version and the collaboration with an animation project management system will take all this plumbing to the next stage of building an open-source animation pipeline. Care to join?
Thanks for the feedback!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> For example, most small studios and independent animators don't have the know-how or
>> interest in setting up CVS.
That is then their problem, thing is the independent animator and small studio has most to gain of setting up the cvs on the very short term. Why because a independent operator has least resources available to spare. However by setting up a cvs they can not only save disk space, but also in a very sane way force to think about backups and collaboration.
Why cvs for the single user? It helps to de clutter your drives, it also promotes you to backup your work, especially if you set up the cvs on a external system (which for a indie user makes most sense). But mostly it keeps disk usage at minimum and enables you to go back when you screw up rather nicely with minimal overhead. But more than that you can now share cvs access with others, so if you suddenly need to get a musician to work with you its by far much much easier because you can share everything you need seamlessly as if it was on your disk. Not to mention clients.
>> But I would argue that you can't build any of the concepts you've mentioned without
>> building what we have currently.
I do understand you need to do some kind of file management yourselves off course you do. However your goal is to promote a better way for thees people to operate, if that includes him setting up or at least you suggesting for him to set up a cvs system then all the better. Its not as if setting up the cvs is THAT hard (if it is then setting up open pipeline is equally impossible). But it can also be the pivotal reason the users cant reach next stage.
As for maya i also suggest you force users to use may ascii files, theres several EXTREMELY compelling reasons to do this
>> For some users, what we've built is enough.
Well yes but thats hardly a good reason to do stuff badly, i mean most people are content with IE too...
>> The upcoming stand-alone python version and the collaboration with an animation project
why python? Nothing againt it but just out of curiosity really. Because installing certain python's stuff with maya8.5 on the drive is a living pain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that setting up a *real* revision control system is efficient and ideal and it will come with time. And with that will be instructions on how to setup the backend aspects of it. I've had lots of people (even in IT) shudder at the thought of setting up a CVS or SVN server even at well known smaller studios. The point of openPipeline is tools and education. These things will come and your note is more encouragement for us to make that next step happen.
I agree about ASCII files but the point is to suggest things but provide options so as to not to be prescriptive and require that they not use binaries (for say the mastered/published file) ever. What people have asked for most is options. The idea is to build a community around this.
>> For some users, what we've built is enough.
> Well yes but thats hardly a good reason to do stuff badly
That's a bit strong for a free open-source tool that hasn't even reached version 1.0 yet (not to mention insulting for the developers). Jump in. Make it better.
Care to write a tutorial on how to setup a CVS or SVN repository and how to make it work with openPipeline? We'll add the code and functionality to make it work. Help us get the word out on how to do things right.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well i might but im a bit short on time at the moment. Thing is all this thread boils down to is this:
you built the code down up, whereas if you had built code up down you would have been much faster there.
For example you can build the entire higher level system with minimal interfacing to maya and it would by design be compatible with any app really.
Suppose your python gui was the first thing you did, then you'd have done a simple task format, and the popup gui, you could have done the maya integration with 4-6 lines of code since all the user needed was to know what file to open at stage 1. But you would have gotten ANY file integration. Be it photoshop, XSI or cakewalk.
the realization is that there needs not be any special tools in maya if you have a rudimentary task pusher that works. You can then build the integration deeper.
Now the problem is that your pipe fixed parts of its clienside api, because you were solving a fixed problem set. However what you should have done is a open framework for integrating anything.
So is there a framework design team somewhere (there should be a framework draft alölready or yo might end trashing a lot of existing code)? Or if not is there going to be?
>> For some users, what we've built is enough.
>>> Well yes but thats hardly a good reason to do stuff badly
:D I wasn't implying your necessarily doing things badly, but rather the comment is a catch it all kind of one that you can use to justify anything you want. So just because 70% of the computer the world are content with their computers does not man they are perfect.
>> What people have asked for most is options. The idea is to build a community around this.
Yes i understand that, but thing is the 1.0 road map must be fixed at some point. Just adding stuff because users request them isn't a terribly good idea. Thing is there needs to be some ideological direction at hand.
So for instance there needs to be somebody saying, we wont include that because we think its not a critical part of work flow, or better yet because your working on a even better way t solve same issue.
PS: is there a decision on what gui toolkit you will be bounding the python tool set on. Or will it be strictly cmd?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
There had been a very good amount of discussion going on here , i guess,
I want to add some examples here,
Since few days I have been going through the overview of tools developed by major studios around,
Lets have a look,
---------------------------------------------------------------------------
ILM - Zeno http://vfxworld.com/?sa=adv&code=1e242f07&atype=articles&id=2608
---------------------------------------------------------------------------
Blue Sky Studios - CGIStudio http://www.blueskystudios.com/content/process-tools.php
---------------------------------------------------------------------------
Pixar - Marionette and Renderman
---------------------------------------------------------------------------
Kaydara - FBX Format
---------------------------------------------------------------------------
The examples listed above shows the fact that when any studio crosses over some level of productions, The need of FULL CONTROL arises.
When I started making my own animExportImport in Maya through MEL, I found lots of trouble accessing and setting animCurve values,
So I found its answer in API Programming,
My point is , by developing your own format or tool you have full control over your production pipeline.
You build a tool for most important aspect of your production, Animation, VFX or Lighting and then build support utilities for all other departments around that tool.
Just like FBX format,
First Kaydara built FilmBox file format, in those days it was being used just for transfer of data between packages,
And then on top of it came Motionbuilder, which instantly became standard for MoCap Projects.
A very good example for our discussion is Zeno, developed by ILM,
After successfully implementing Zeno, ILM built its Asset Management software around it, so that both ILM and LucasFilm can share their assets seamlessly to avoide rework.
So what I suggest is lets build something which can give us full control over Maya, Photshop, Shake or Fusion, or any other software being used in our production pipeline,
The UI and versioning can be built around it in next step.
I hope I have not gone too far off the topic.
:)
Vishang Shah
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, i don't think thats a viable option on the short term. The only truly good with this tactic so far is the EXR format
If you are a big studio it is kind of but if not then not. A big studio has TDs that dictate what and how they want to deal with stuff. Thus they can subset anything and add on later. However developing a open source tool like this requires more people on board than not. And thus everything has to be there day one the format is in place. if you read about Zenos is sounds like its heaven to use, but its not heaven to mainatain.
> So what I suggest is lets build something which can give us full control over Maya, Photshop, Shake or Fusion,
> or any other software being used in our production pipeline,
I think its being built all the time, your just missing the framework. I think of all these software the most problematic one is Adobes software, rest pretty much plays any ball you throw at them. Adobe needs a full jolt to its core to work a bit better here.
But do define full control. I mean until you have the code at your disposal your allways going to have less than full control.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Deployment issue 1.
While i can see that some people might want to use a installer its not neccesreily a good idea.
First Security, if i get a exe file i must overweigh what the overall usefullness of it versus the potential security problems (now your kindof forcin any sane TD/sysadmin to sandbox this first and then get the files). While any maya script itself is a security problem i do look over every single file that has a call to eval, system, refernce scriptjob and file.
Second, exes aren't croiss platform so any mac and linux user out there is automaticaly disqualified from participating. Which contadicts your goals.
Third some people want to see what they install, this is part of the apprisal of the usefullnes of any script to glance the sources at first conception.
So please ship just flat files aswell as installer
Deployment issue 2.
Maya allready has a built in module functionality, why arent you using it instead ove developping your own?
hey joojaa...
i agree with you about installer issue..
i am trying open pipeline.. as i speak..
animation community does need such works..
i wonder why there is no such tools available previously..
hope to actively participate in community...for further development of open pipeline..
let me have my hands on this baby...
thanks..
In fact there are. A few of them in fact, maya even ships one very rudimentary one (that works very well, it has pictures and all). Especially on the scope your doing it in.
The base problem is that your targeting too low, assets aren't the most important part of the pipe, but rather a fraction of what the pipe should be. For example your in a way trying to go into the area of a cvs repository (for example www.perforce.com), indexing service, request and maybe a approval system. Now all those are important but just the tip of the iceberg missing the bulk entirely.
Theres much more stuff that needs to be accounted for and unfortunately a pipeline is not and should not be limited by the application in use because it spans the entire workflow form script to finished project, this is why maya defines project folders.
However in order to get a true pipeline you need a way to communicate all data much more effectively and store all data much more safely (again exampleperforce does enable 2 artist to work on the same asset file simultaneously, in limited degree if its a ma file). But thats not the end of it the pipeline is also must do all requests keep track of staff meetings, push renders into queues, compress outputs for approvalm Back-up stuff, Monitoring synchronous projects, etc..
However this alone cant be done in maya there must be tools that are outside the maya scope since maya cant facilitate all things needed. because mayas just on facet of the entire pipe
Just realized people were posting to the forum...
The exe is long gone so that's not an issue anymore.
joojaa you are totally right that assets are only one small part of the pipeline puzzle - we are in the process of planning a standalone version written in python that will cover all aspects of the pipeline and cross in and out of worker applications.
underearth, joojaa: care to pitch in? Thanks for the thoughts and sorry for the months of delayed response!
Hey Joojaa,
Thanks for the thoughts you posted,
I totally agree with you about the idea that asset is just a facet of the pipeline, but I also want to mention a thing that asset is the base facet of the pipeline,
Just imagine a wrong version of Rig pushed into Episodic Animation production , where control names are different than approved Rig Template,
When TDs will realize animator would have made tons of animation files,
and in one project we already faced too many problems in Animation because we don't have any version control or communication method between artists of different department.
My point is, Let this asset management be tip of the iceberg but once we conquer it then we can provide other modules for """keep track of staff meetings, push renders into queues, compress outputs for approvalm Back-up stuff, Monitoring synchronous projects, etc..""" on top of it,
correct me if I am wrong,
We are in process of developing an openSource system which will provide features like Alienbrain studio,
Please support us at each level,
I Hope to see more thoughts on these topics,
:)
Vishang Shah
Yes off course, however i suggest you roll in some tool set to use a cvs system instead of trying to make one in mel (a cvs makes it possible to have one file which has many versions so you also don't clutter up stuff, and the user will KNOW when he has a older version). Plenty of free ones around they are perfectly suited for use in maya.
however i think you mean a TASK is a the primary facet of a pipeline, not a asset (just like the product in factory inst the most fundamental part of the factory but rather the flow of it whilst ist becomes a product). The asset is just what the task produces or processes.
So pick one CVS or make a pi for the cvs and build the gui to use that.
Then gear the open pipeline to actually do pipeline stuff cvs is cvs thats what should take care of assets keeping teh assets current. However the pipeline should take care of sending notification to users / automated systems in timely fashion at right time so that they start processing so the next notification can be made. So pipeline in m mnid is more like the conveyor belt in a factory than actually managing the storage area any sotrage are can should be able to be used.
This is what i see the ultimate pipeline doing:
So when user XXX sits in on his computer hes greeted by a list of things to be done (maybe in a form of a production schedule list with deadlines but in simple form jsut in priority), he then only double cliks on said job and the conveyor belt should ideally FETCH the right thing to do (its not its job to facilitate the storage) the user does NOT knwo what file he is accessing nor should he care. Along which all he needs, such as soundtracks, special instructions and so on. The cvs tracks the storage area and sets the file marked as in use. The pipeline manager tracks JOBS, next one to log in get their own list which now no longer has this task to be done since its under works. When the current task is finished, be it a texture paint a rigging operation. When the user is finished this job dissapear form his list, the job knows whats going on next the user needn't know nor care what it is. If its going to a animator or or approval does not amtter at this stage its a next job.
Now let us suppose a simple animation sequence might look form pipelines point fo view like this all of theese are jobs tat pop up on various persosn desktops at various times
Stage 1:
synopsis
script
stage 2 (turns into):
storyboard
soundtrack
revised script
stage 3
simple sotoryboard animatic with preliminary sountrack
stage 4
approval or return to stage 2
stage 5.
each character and object is assigned a individual job that are defined here
....
these are then submitted partially concurrently on need to the pipe. Sometimes the next stage is a script sometimes its a person sometimes it s group of persons etc. At some point the object might be submitted in and the next user get sthe object only to se ethet it has occlusion baked in between the last submission for example.
Well im just feeling your half on the right track but too focused on making it into a cvs which isnt what a pipeline is about, its wats pipelines need to manage. Lateley yove gone to better direction tough.
Hi joojaa,
You bring up some critical issues. But I would argue that you can't build any of the concepts you've mentioned without building what we have currently. Right now we are very focused on issues of plumbing that will provide the working base for the management skins that will overlay this. For some users, what we've built is enough. For example, most small studios and independent animators don't have the know-how or interest in setting up CVS (or subversion) so this provides a built-in solution. They can start using it right away. They also get a bird's-eye view of the assets in their project, collaborative (XML) notes, project definitions in an XML format, a simple form of scene population, and a code base to start building off of. In the future the revision control schema in place will be the "openPipeline Classic" option of saving and integration with subversion will be another (it's better at dealing with binary files) option. The revised project manager is the first step towards the larger pipeline tool that I think you're hoping for.
The notion of "Tasks" is a whole layer above what we have built thus far. That falls under the banner of project management and we are looking for a good open source project management application to build on top of this that will interact with the current Maya version and the future stand-alone python version as needed. We are in talks now with possibly just the right fit for this.
The upcoming stand-alone python version and the collaboration with an animation project management system will take all this plumbing to the next stage of building an open-source animation pipeline. Care to join?
Thanks for the feedback!
>> For example, most small studios and independent animators don't have the know-how or
>> interest in setting up CVS.
That is then their problem, thing is the independent animator and small studio has most to gain of setting up the cvs on the very short term. Why because a independent operator has least resources available to spare. However by setting up a cvs they can not only save disk space, but also in a very sane way force to think about backups and collaboration.
Why cvs for the single user? It helps to de clutter your drives, it also promotes you to backup your work, especially if you set up the cvs on a external system (which for a indie user makes most sense). But mostly it keeps disk usage at minimum and enables you to go back when you screw up rather nicely with minimal overhead. But more than that you can now share cvs access with others, so if you suddenly need to get a musician to work with you its by far much much easier because you can share everything you need seamlessly as if it was on your disk. Not to mention clients.
>> But I would argue that you can't build any of the concepts you've mentioned without
>> building what we have currently.
I do understand you need to do some kind of file management yourselves off course you do. However your goal is to promote a better way for thees people to operate, if that includes him setting up or at least you suggesting for him to set up a cvs system then all the better. Its not as if setting up the cvs is THAT hard (if it is then setting up open pipeline is equally impossible). But it can also be the pivotal reason the users cant reach next stage.
As for maya i also suggest you force users to use may ascii files, theres several EXTREMELY compelling reasons to do this
>> For some users, what we've built is enough.
Well yes but thats hardly a good reason to do stuff badly, i mean most people are content with IE too...
>> The upcoming stand-alone python version and the collaboration with an animation project
why python? Nothing againt it but just out of curiosity really. Because installing certain python's stuff with maya8.5 on the drive is a living pain.
I agree that setting up a *real* revision control system is efficient and ideal and it will come with time. And with that will be instructions on how to setup the backend aspects of it. I've had lots of people (even in IT) shudder at the thought of setting up a CVS or SVN server even at well known smaller studios. The point of openPipeline is tools and education. These things will come and your note is more encouragement for us to make that next step happen.
I agree about ASCII files but the point is to suggest things but provide options so as to not to be prescriptive and require that they not use binaries (for say the mastered/published file) ever. What people have asked for most is options. The idea is to build a community around this.
>> For some users, what we've built is enough.
> Well yes but thats hardly a good reason to do stuff badly
That's a bit strong for a free open-source tool that hasn't even reached version 1.0 yet (not to mention insulting for the developers). Jump in. Make it better.
Care to write a tutorial on how to setup a CVS or SVN repository and how to make it work with openPipeline? We'll add the code and functionality to make it work. Help us get the word out on how to do things right.
Since your actually building a front for the disk system why would it matter for the user if he has a repository set up or not.
Well i might but im a bit short on time at the moment. Thing is all this thread boils down to is this:
you built the code down up, whereas if you had built code up down you would have been much faster there.
For example you can build the entire higher level system with minimal interfacing to maya and it would by design be compatible with any app really.
Suppose your python gui was the first thing you did, then you'd have done a simple task format, and the popup gui, you could have done the maya integration with 4-6 lines of code since all the user needed was to know what file to open at stage 1. But you would have gotten ANY file integration. Be it photoshop, XSI or cakewalk.
the realization is that there needs not be any special tools in maya if you have a rudimentary task pusher that works. You can then build the integration deeper.
Now the problem is that your pipe fixed parts of its clienside api, because you were solving a fixed problem set. However what you should have done is a open framework for integrating anything.
So is there a framework design team somewhere (there should be a framework draft alölready or yo might end trashing a lot of existing code)? Or if not is there going to be?
>> For some users, what we've built is enough.
>>> Well yes but thats hardly a good reason to do stuff badly
:D I wasn't implying your necessarily doing things badly, but rather the comment is a catch it all kind of one that you can use to justify anything you want. So just because 70% of the computer the world are content with their computers does not man they are perfect.
>> What people have asked for most is options. The idea is to build a community around this.
Yes i understand that, but thing is the 1.0 road map must be fixed at some point. Just adding stuff because users request them isn't a terribly good idea. Thing is there needs to be some ideological direction at hand.
So for instance there needs to be somebody saying, we wont include that because we think its not a critical part of work flow, or better yet because your working on a even better way t solve same issue.
PS: is there a decision on what gui toolkit you will be bounding the python tool set on. Or will it be strictly cmd?
Hi All,
There had been a very good amount of discussion going on here , i guess,
I want to add some examples here,
Since few days I have been going through the overview of tools developed by major studios around,
Lets have a look,
---------------------------------------------------------------------------
ILM - Zeno
http://vfxworld.com/?sa=adv&code=1e242f07&atype=articles&id=2608
---------------------------------------------------------------------------
Blue Sky Studios - CGIStudio
http://www.blueskystudios.com/content/process-tools.php
---------------------------------------------------------------------------
Pixar - Marionette and Renderman
---------------------------------------------------------------------------
Kaydara - FBX Format
---------------------------------------------------------------------------
The examples listed above shows the fact that when any studio crosses over some level of productions, The need of FULL CONTROL arises.
When I started making my own animExportImport in Maya through MEL, I found lots of trouble accessing and setting animCurve values,
So I found its answer in API Programming,
My point is , by developing your own format or tool you have full control over your production pipeline.
You build a tool for most important aspect of your production, Animation, VFX or Lighting and then build support utilities for all other departments around that tool.
Just like FBX format,
First Kaydara built FilmBox file format, in those days it was being used just for transfer of data between packages,
And then on top of it came Motionbuilder, which instantly became standard for MoCap Projects.
A very good example for our discussion is Zeno, developed by ILM,
After successfully implementing Zeno, ILM built its Asset Management software around it, so that both ILM and LucasFilm can share their assets seamlessly to avoide rework.
So what I suggest is lets build something which can give us full control over Maya, Photshop, Shake or Fusion, or any other software being used in our production pipeline,
The UI and versioning can be built around it in next step.
I hope I have not gone too far off the topic.
:)
Vishang Shah
Well, i don't think thats a viable option on the short term. The only truly good with this tactic so far is the EXR format
If you are a big studio it is kind of but if not then not. A big studio has TDs that dictate what and how they want to deal with stuff. Thus they can subset anything and add on later. However developing a open source tool like this requires more people on board than not. And thus everything has to be there day one the format is in place. if you read about Zenos is sounds like its heaven to use, but its not heaven to mainatain.
> So what I suggest is lets build something which can give us full control over Maya, Photshop, Shake or Fusion,
> or any other software being used in our production pipeline,
I think its being built all the time, your just missing the framework. I think of all these software the most problematic one is Adobes software, rest pretty much plays any ball you throw at them. Adobe needs a full jolt to its core to work a bit better here.
But do define full control. I mean until you have the code at your disposal your allways going to have less than full control.