[Bf-committers] Blender online

Patrick Shirkey pshirkey at boosthardware.com
Sat Apr 27 09:24:23 CEST 2013

On Sat, April 27, 2013 2:41 pm, Alexandr Kuznetsov wrote:
> Hi.
> I had an idea for networking support for quite a while. I don't think
> that Blender will benefit from real time collaboration on the level of
> Google Wave. Humans don't function that way. It is impossible to edit an
> arm of a character while another artist is editing the leg of the same
> character. This leads to "real time" conflicts  which would had to be
> resolve often.

In some cases it would be useful to observe the progress of a specific
task in realtime. So that would be similar to share your screen type of
functionality without enabling multi editing. I don't see this as a
priority for networked collaboration but it is inevitable that others will
require it. As a producer it would be incredibly useful to be able to
remotely observe the progress each team member was making in realtime. It
would even be viable to build an observer mode which displays all team
members current state as thumbnails for a quick overview while allowing
the user to view in full screen too. I'm sure you don't need me to tell
you where that idea comes from ;-)

> Therefore, I think it best to implement support for existing distributed
> storage like git or svn. As they are open source, we can modify them for
> our needs.
> 1. Create generic file interface to support files on different storage
> systems like git, svn, and http as read only.
> 2. Resolve dependencies dynamically from network: oh, this.blend
> requires file depend.blend and ext.jpg  texture. Let me download them
> from the network.
> 3. Automatically check updated versions of file. Push edited versions
> back. If gsoc allows, add dynamic swiping  of library files (which user
> is not currently editing). For example, an artist working on a character
> animation can see that another artist changed lighting.
> 4. Add support for back up and forking through blender file explorer.
> 5. svn has horrible binary file support.  You can possibly investigate
> .blend format in order to make smaller diff files.
> 6. Resolve what to do when files are "opening" == downloading from the
> server. Interface hanging for 30 sec is unacceptable.

A lot of  thought has been expended on this front with the tube project,
they have settled on sparkle share in combination with git/svn.


A very recent development is distributed dropbox type functionality with


However the Blender team have been working on this for quite some time now
so it seems that this has been solved so some degree already inhouse?

> About web interface. I'm porting Blender to OpenGL ES. The standard is
> very similar to WebGL, so we can get blender running when it is done. We
> need to create a javascript library that calls remote GL commands on a
> client's computer. Also, we need to create simple web server front end
> which replaces standard gl.h. Instead of calling glClear, the blender
> would simply send this command to the client.

This is a good news. Do you have some more details?

>The problem with this is
> latency... I have up to 25ms latency with web servers. For real time
> feedback it gives 40fps. Now imagine you have to process and send back
> signals. We are now looking for  20fps. The only way this will work, if
> studio has a server or it is nearby with good internet.

Latency issues are dependant on the amount of data being pushed around.
With cube2 we can collaboratively edit and film a map (set) in realtime
with 56k modems because it is just data. All textures and models are
stored locally. They have already implemented push/pull for the textures
and map objects. Other projects have successfully used netjack to manage
professional recording sessions in locations 1000's of km's apart with
multiple full bandwidth 48k audio streams.

So the issue is not so much the amount of latency but if the collaborating
teams can manage the latency effectively. Of course big pipes help a lot.

> Best,
> Alex
> On 4/26/2013 12:09 PM, Patrick Shirkey wrote:
>> On Sat, April 27, 2013 1:35 am, Sergey Kurdakov wrote:
>>> Hi
>>>> Maybe it's a better idea to create a simple online modeller, so people
>>> could create a sketch and then export it to .blend format?
>>> then take a look at this approach
>>> https://github.com/kripken/emscripten  see some results
>>> http://www.youtube.com/watch?v=XsyogXtyU9o
>>> cannot say, how much of Blender would compile to run this way, but as 1
>>> mln
>>> lines of C/C++ code was converted to run in browser, I think, it is
>>> possible to convert blender ( not sure on dependencies and python
>>> though
>>> ),
>> I think it would be very useful to have the option of working with
>> Blender
>> in a browser but I don't think it is a requirement to achieve a
>> functional
>> networked collaborative platform with Blender as a core component.
>> For use on tablets and other mobile devices it might be necessary to
>> have
>> an html5 version of the interface. A lot of the functionality could be
>> handled by running Blender as a server side headless app and driving it
>> with an html5 frontend. Python allows for the separation of backend and
>> interface quite nicely. It may even be possible to run the current UI
>> toolkit in a browser.
>> To enable a fully modular production system I see JACK as the glue that
>> holds it all together. It would enable passing 3d data around a modular
>> environment in much the same way that audio/midi/video is now handled.
>> Textures would be an interesting challenge but it could be handled with
>> a
>> centralised archive on the master server or in the same way that
>> audio/video is handled now.
>> Working with a model in Blender while viewing it instantly rendered in
>> multiple external 3d engines anywhere in the world would be a very
>> powerful production and collaboration tool. It would certainly rival
>> anything that proprietary solutions are claiming to offer.
>> Companies like Intel and Samsung are interested in this because it sells
>> more hardware. Less money spent by studios on proprietary software
>> (upwards of $80k per seat in some cases) means more money is available
>> for
>> the hardware cluster and associated equipment. $80k worth of hardware
>> will
>> get a studio a lot of rendering and processing power. Adding additional
>> processing power can be as simple as plugging in a new machine to the
>> network. Over the course of a couple of years a studio using this
>> modular
>> system could build a very powerful rendering platform without retiring a
>> single machine due to hardware/software constraints or spending a cent
>> on
>> proprietary licenses. It would also free up budget for bespoke
>> development
>> which will inevitably be handled by the open source multimedia
>> community.
>> As new functionality is built out by the contributing studios it would
>> be
>> shared with the global community enabling everyone to move forward at a
>> quicker pace.
>> Eventually the singularity will be reached and we will all be able to
>> retire in comfort after having solved world hunger by discovering
>> unlimited supplies of energy thereby ensuring world peace too ;-)
>>> Regards
>>> Sergey
>>> On Fri, Apr 26, 2013 at 7:16 PM, Moisés Bonilla <neodivert at gmail.com>
>>> wrote:
>>>> Wow, this grows fast.
>>>> Some conclusions I reached until now:
>>>> * Better to take it as a concept project, instead of one for
>>>> production
>>>> use.
>>>> * Work "only" on a subset of operations. Indeed, from the beginning, I
>>>> was
>>>> thinking only about 3D modelling. I forgot to mention that, sorry.
>>>> * Patrick Shirkey could be a great ally or a fierce competitor ;-)
>> Just so you know I am not coming up with this on my own. I have some
>> pretty heavy weight brains behind me...
>>>> Maybe it's a better idea to create a simple online modeller, so people
>>>> could create a sketch and then export it to .blend format?
>>>> Patrick Shirkey, so you would like to extend Jack (which is for audio)
>>>> to
>>>> 3D animation, profitting its basic
>>>> session API and network functionality, ins't it? In that case, yeah,
>>>> there
>>>> is a common ground.
>> Nice to hear we might be onto something here. I propose using the iqm
>> format as the initial data format as it is well supported by multiple 3d
>> game engines including Valve's Source Engine and cube2.
>> http://source.valvesoftware.com
>> http://4-cube.com
>>>> Howard Trickey, indeed, when I first tried to describe the idea to a
>>>> friend, I said "It would be something like Google Docs, but with 3D
>>>> graphics" :P
>>>> Thanks for the help, and sorry if i didn't answer to all of you!.
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> --
>> Patrick Shirkey
>> Boost Hardware Ltd
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

Patrick Shirkey
Boost Hardware Ltd

More information about the Bf-committers mailing list