[Bf-committers] Blender online

Moisés Bonilla neodivert at gmail.com
Fri Apr 26 17:16:58 CEST 2013


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 ;-)

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.

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



2013/4/26 Patrick Shirkey <pshirkey at boosthardware.com>

>
> 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
> collaboration tool.
>
> 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
> instead.
>
>
>
>
>
> > 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   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:
> >>
> >>> Hi,
> >>>
> >>> 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.
> >>>
> >>> Brecht.
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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
>



-- 
Moisés J. Bonilla Caraballo


More information about the Bf-committers mailing list