I look at how using something like Google Docs has made a huge difference both in how I do work at work, and also how students in schools do group projects. I think it was hard to predict how much easier this make things versus the days when people mailed Word documents around to each other.
Yes, it is true that it is rare for two people two people to be working on the same paragraph (or even different paragraphs of the same doc) simultaneously, but it is still a great step forward for two reasons: 1) the data is "in the cloud": so you and your colleagues don't have to think about where it is, what machine they are currently using, or anything else. 2) people can be looking at the same exact data simultaneously: maybe only one person is changing it, but others can see the changes live immediately. It would be great to get these kind of things to work as well for Blender scenes. But I agree with those that say this would require deep deep changes and is a very challenging project. On Fri, Apr 26, 2013 at 8:44 AM, CoDEmanX <codem...@gmx.de> wrote: > Multiple people working on a single image sounds ridiculous indeed, but > with 3D, it's a different story. Especially if you use Blender to create > game environments, multiple working working on the map is really a use > case. Since Blender isn't designed to stream 3d content, a sharing > feature should be kept simple. So how about a button to update linked > library objects? That way, one could sort of work on the same scene. > > Am 26.04.2013 10:27, schrieb Ton Roosendaal: > > Hi, > > > > Oh - yeah I was interpreting it as similar to how we setup pipelines in > a studio. Where you keep the .blends individually owned, and link in data. > > > > Work on the same .blend scene together is a specification that would > right go deep into the core of Blender's design. I wouldn't recommend to > try this, nor do I think it would become a succesful project with the > current state of Blender. > > > > The issue of efficient data sharing for projects is really something you > can handle on a meta level, and not try to do it on vertex/objects level or > on tools. > > > > Take GIMP for example. It sounds fun to have 2 people do operations on 1 > image, but if this is useful? In practice, ownership of such data is really > not a limitation. > > > > That goes for character rigs, models, environments, props, etc. Easy to > design a data structure based on .blends being managed by individuals. > > > > -Ton- > > > > ------------------------------------------------------------------------ > > Ton Roosendaal Blender Foundation t...@blender.org www.blender.org > > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > > > On 26 Apr, 2013, at 1:22, Brecht Van Lommel wrote: > > > >> Hi, > >> > >> On Thu, Apr 25, 2013 at 11:38 PM, Moisés Bonilla <neodiv...@gmail.com> > wrote: > >>> First of all, thanks for the quick response. > >>> > >>> Ton Roosendaal: That idea about the "normalized" file IO sounds good. > Do > >>> you think that maybe I could start thinking about the case when two > people > >>> starts with a empty scene and each one sends to the other simple > commands > >>> (Create cube at ..., Rotate object ..., etc)? > >> > >> I think Ton misunderstood what you were proposing? Handling network > >> paths is quite different from realtime sharing. > >> > >>> And no, although summer of code sounds interesting, I would prefer to > "take > >>> it easy" for now :). Anyway, I should start by proposing the project > in the > >>> wiki, isn't it? > >> > >> Yes, you can add make a wiki page about the project. > >> > >> But note that there's a reason Verse was never finished and > >> integrated. If it's a research project where you create a proof of > >> concept then it can work, but to make this ready for production use is > >> problematic. That's because there are many different data structures > >> and editing operations in Blender, and they weren't designed with this > >> kind of thing in mind. It's quite possible to make it work for a small > >> subset of those, but supporting this across Blender in a way that's > >> reliable and maintainable probably requires a major redesign of > >> Blender internals. > >> > >> Brecht. > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers