[Bf-committers] Blender online

Alexandr Kuznetsov kuzsasha at gmail.com
Sat Apr 27 06:41:49 CEST 2013


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.
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.

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. 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.


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

More information about the Bf-committers mailing list