[Bf-committers] Blender online
ton at blender.org
Fri Apr 26 10:27:44 CEST 2013
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 Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 26 Apr, 2013, at 1:22, Brecht Van Lommel wrote:
> On Thu, Apr 25, 2013 at 11:38 PM, Moisés Bonilla <neodivert at 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.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers