Collaboration Tools

Ideas, enhancements, feature requests and development related discussion.

Collaboration Tools

Postby dcuny » Thu Jan 05, 2006 1:24 am

From the A:M forums, I noticed a comment that they are (or are planning) on adding collaborative features for the TWO (Tin Woodsman of Oz) project. This reminded me that being able to collaborate on projects was one of Sascha's reasons for writing JPatch in the first place, so I thought perhaps it might be useful to start up a thread of possible features.

I suspect that I'd never use most of these features. Still, I could imagine some of them - especially the version control ones - being useful. Of the few models that I've created with JPatch, I've managed to destroy most of them with "improvements". ;)
  • User List. You should be able to assign (and unassign) people to a project, and lock down their rights, so (for example) an animator wouldn't be able to modify a model's geometry.
  • Web Aware. You could post the project somewhere, and from within JPatch, download it, and then upload changed. Of course, it would have to be secure, because I don't want a bunch of hackers getting a hold of my FTP site.
  • Version Control. If you didn't like a change, you should be able to roll something back to a prior version. For something like an animation, this would mean that all objects in an animation could (as a group) be rolled back to a prior state.
  • Project Merging. As an alternative to uploading files directly from the Internet, an option for updating files would be to import or merge elements from a modified version of the project.
  • Difference Files. To facilitate Merging projects, a project could generate a file that contained only the changes made prior to the last syncronization. This file could then be sent to the maintainer of the main file for merging.
  • Base64 Binary Storage. Storing binary information (such as sound files) in Base64 format ensures that JPatch project and difference files can be safely be sent via email.
  • Binary Assets as Seperate Files. Since binary files (such as bitmaps and sound files) are potentially the largest components of a project, having these available as seperate files could make synchronizing with a master file much faster.
  • Partial Checkout. You should be able to compare your project to the master project file, see what changes have been applied, and only check out changes that are of interest to you. For example, you might want to get only the most current version of a model.
  • Comments. There should be a "notes" section, where comments about something - reminders to oneself, notes about decisions make - can be jotted.
Although I've pushed for (and continue to push for) a single, unified project file, it seems most sensible for collaboration to have a project as a set of files, and have a unifying "assets" table of some sort which keeps track of versions and such. Perhaps a "project" file would simply be a zipped version of this, which could be optionally unzipped to a directory JPatch's working directory?

Although I like the idea of being able to drop files around on my machine willy-nilly, this seems the most sensible approach. JPatch already has the idea of a "home" directory, so this would be a minor extention.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Jan 05, 2006 8:28 pm

I suspect that I'd never use most of these features.

Oh, don't say that. Once the JPatch Movie Project was launched and we compete with the major studios we'll need you - I'm counting on you! :D

But seriously. I think that after one ore two more IRTC animations the next logical step would be to produce a real short (say about 5 to 10 minutes long) - Collaboration would be nice, so I plan to add some tools to JPatch (and the homepage). The Internet Movie Project showed that there is interest and that in theory such a project could work. Well, we'll see how this will work out...

About your concrete feautre requests: I think pretty much of this is covered by CVS. So adding a CVS client to JPatch might be a good solution. I am really impressed by Eclipse and the way it handles CVS projects - so I think I'm gonna use something similar for JPatch.
I was thinking about zip files as project files, but came to the conclusion that a project directory with the individual projects as subdirectories would be the best solution. Each project would be a fixed directory structure, this way JPatch would know where to look for resources (and where to store them). Normally the user would not have to interact with project folders via the file system, but of course he could if he wishes to (that's also possible with zip archives, but I think direct access via the file system is much more convenient).

Like in Eclipse, a project could be im/exported as ZIP-files (which simply contains the project directory structure).

A project directory would contain subfolders for models, animations, images, textures or shadres and optionally for rendered frames.

Base64 Binary Storage

We've got 2006 - I think mail clients should by now be able to handle binary files correctly :wink:
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Jan 05, 2006 8:57 pm

The only concern I had with CVS is that non-technical people (or lazy people, like me) would find it easier if JPatch provided an "all in one" sort of solution. But there's no joy in recreating an existing tool without a really, really compelling reason.

With Blender's Orange project and A:M's Tin Woodsman of Oz moving forward, I think we'll be hearing a lot more buzz about collaboration in the future. How well collaborative animation will work out remains to be seen - there are a lot of projects that start out with dreams way beyond their grasp. Starting with animations limited to a minute or two seems like a good goal for now.

Besides, did you notice how hard those Pixar animators have to work? It's always a huge push with lots of overtime as the final deadline approaches. And that's almost nothing compared to the horror experienced towards the middle of the project, when you realize the story just doesn't hang together, and you've got the rewrite the story and start from scratch... ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Fri May 25, 2007 6:47 pm

I was browsing the shelves of my local bookstore, and noticed 3D World magazine had an article on making independent animated films. (In in the US, so we're probably a month behind the UK). They listed a number of projects, including Plumiferos and The Tin Woodman of Oz.

Both of these projects mentioned using Subversion to maintain large databases of assets for the films. The Plumiferos group mentioned that, because of the the way Blender's binary data files are set up, it was difficult to merge changes, and they had to use custom Python scripts. For example, it was difficult to merge a UV mapped texture with existing animation.

Just something to keep in mind...
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat May 26, 2007 10:26 am

There is a lightweight Java Subversion client, and IIRC Subversion supports binaries (a lot better that CVS, because it's using a binary-diff algorithm). Any, JPatch files are XML, so a standard text diff should be quite efficient, so the only binary files that need version controls are image textures, matte paintings and the like.

I plan to include project management like in eclipse (with a workspace folder that contains one folder for each project, and a project folder having a special structure (i.e. separate directories for models, animations, resources, rendered images, etc.) - with a local history feature that keeps e.g. the last 10 versions of each file, and (later) with subversion support. This should be a nice start for collaboration, but I'm also thinking about more sophisticated features for future versions, e.g. a mode where two or more people can work on a model or an animation at the same time (like in those collaboration tools that are somtimes found in netmeetig like applications), with a chat window and perhaps even a voice-over-IP connection.
This should be quite easy to implement - one user is the "master" who can modify objects, the changes are sent to the other connected JPatch applications and displayed in realtime, so these users can watch what's being done and comment on it using a chat or VoIP. At any time another user can request to become the master and apply changes too. But that's not on the todo list right now.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: undo/redo behavior

Postby John VanSickle » Sun Feb 24, 2008 5:24 am

:!: These next four posts were merged from the Undo/Redo thread - dcuny

One issue that should be taken into consideration is the potential for collaborative effort. In a larger project, one person will be working on a model and another will animate it, and each will own their part of the project, with only advisory control over the other parts.

Therefore I think it would be best if the modeling and scene-building projects were entirely separate, and the scene-building application should only monitor the files from which models come for changes during scene building so that the animator can be suitably warned.

This greatly simplifies many of the issues involved here, including undo/redo behavior.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: undo/redo behavior

Postby sascha » Sun Feb 24, 2008 9:21 am

Collaborative work on a project can be realized using a CVS or Subversion repository. I think the characters should be completely modeled and rigged before the animators can start animating - later changes should be minimized. I think to do that you'll need to do some test animations to check the models and rigs before starting the real thing. There should also be someone who's responsible for the models and rigs (I don't know how to call this person: modeling supervisor, rigging supervisor, technical director,...) - she should check that the characters have all the capabilities the animators need, and that the rigs are somewhat consistent.
Ultimately I'd love to have a project team working on a short film using JPatch, but that's too far away to make actual plans at this time.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: undo/redo behavior

Postby dcuny » Sun Feb 24, 2008 5:53 pm

sascha wrote:Collaborative work on a project can be realized using a CVS or Subversion repository.

I don't think it's too early to start planning this sort of thing. The ultimate goal of JPatch is the creation of animated movies. But even single person projects benefit from having an asset tool in place.

The collaborative movie projects Plumiferos and Tin Woodman of Oz use Subversion to maintain their assets, so I think that's a good choice.

However, I think it would be a good thing if JPatch could provide the general structure and front end to Subversion when working with assets. For example, it might be helpful to be able to assign assets (puppets, props, audio) to scenes. Once a scene is declared (usually at the animatic stage), you know what sorts of assets - audio, puppets, props - you'll need. As these are done, scenes can be marked as ready for animating, and assigned to animators. The animation process generally flows through several steps (blocking, rough, final) before moving on to lighting and compositing.

I think OpenPipeline is also worth looking at. If nothing else, it provides a general outline of an asset management tool that's been tested in the real world.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: undo/redo behavior

Postby sascha » Sun Feb 24, 2008 7:18 pm

I don't think it's too early to start planning this sort of thing.

Subversion is nice, and if, in a first step, JPatch can maintain projects in a Subversion repository (just like Eclipse does) it would be a good starting point.
More important than technical details is, IMHO, "management": I think it would be important to define several key roles - who is responsible for what.
In a project run by volunteers, it's critical that a role can be taken by someone else in case the previous owner has to leave the project. For a small project, say 5 to 10 people working on it, a single person would occupy several roles (one could be, for example, director, modeler and animator at the same time), but I think it would still be helpful to define these roles and their respective responsibilities. I'm not a film geek, but ad hoc I could think of several roles:
* Director
* Editor
* Writers (script, screenplay)
* Storyboard artists
* Director of photography (camera and lighting)
* Technical director (responsible for all kinds of technical things)
* Modelers
* Animators
* Shader writers
* 2D artists (matte and texture painters, texture photography, etc.)
* Modeling and rigging supervisor (ensure that the animators can work with the rigs)
* Voice actors
* Someone responsible for recording the voices, casting the voice actors, etc.
* Songwriters, composers, musicians.
* "Render farmers" for running a distributed renderfarm.

Jeez, this list goes on forever.

Thoughts?

Btw, this is a bit off topic, if we continue this discussion we should probably move it to its own thread.

:!: Done - dcuny
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria


Return to Development

Who is online

Users browsing this forum: No registered users and 5 guests

cron