[Bf-committers] Blender online
pshirkey at boosthardware.com
Fri Apr 26 15:24:17 CEST 2013
On Fri, April 26, 2013 10:44 pm, CoDEmanX 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.
Sharing data with other 3d/game engines which already have multiple user
functionality is also a way to achieve realtime production without
requiring significant changes to Blender. The additions could be made to
the jack plugin which is now part of Blender and has widespread adoption
with Open Source Multimedia tools.
For realtime production it is possible to have people modelling objects in
Blender (or other tools such as MH) while they are being realtime updated
in an external engine (ex. cube2, source, etc...) with other people (crew)
building maps (sets) and capturing live footage (filming) in realtime
using multiple spectators (cameras).
This is the direction that large studios such as Pixar are heading too.
With high performance clusters rendering is now becoming a realtime
procedure. For example, at our studio in Sydney we have a cluster for this
purpose and we can collaborate on production from multiple global
locations with connections as low as 56 kb/s.
With Intel becoming interested in this for Tizen and Android and the
recent release of jack for iOS it will be possible to collaborate with
mobile devices too. Imagine sitting on the beach in Thailand and working
on your latest production ia your Tizen tablet, chromebook or other mobile
device. Cube2 has recently been ported to webgl by the Firefox developers
so we can expect that any firefox OS device will also be a useful
At the moment the biggest barrier to faster production is modelling,
rigging and animation. We do not have an small army of highly skilled
professionals working for us so we are automating as much as possible
> Am 26.04.2013 10:27, schrieb Ton Roosendaal:
>> 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
>> 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>
>>>> First of all, thanks for the quick response.
>>>> Ton Roosendaal: That idea about the "normalized" file IO sounds good.
>>>> you think that maybe I could start thinking about the case when two
>>>> starts with a empty scene and each one sends to the other simple
>>>> (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
>>>> 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
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
Boost Hardware Ltd
More information about the Bf-committers