be - distributed project configurations

General Forums Latest News
1

Hi,

I’m prototyping a command-line utility for setting up and sharing project configurations.

If you’re familiar with Docker, then you can think of this as “Docker for creatives”.

The idea is to encapsulate:

  • Directory structure
  • Application environment
  • Project starter-content

And expose them onto a central location that anyone can contribute to or learn more about.

Starter content would come in the form of basic rigs, models, sound, music, possible some 3-point lighting in a series of shots etc. Encapsulated in a uniquely identifiable project, hosted on GitHub, that anyone can grab and get going with.

Directory structure and application environment are typically very internal and ad-hoc in any company, many of which use similar string-formatting as be, the difference being that you can now compare one environment to the next and pick the one which suits you the best.

Here’s a database of currently available projects.

Any project can be downloaded by typing:

$ be new ad

or…

$ be new tutorial-project

etc.

You then “enter” a project, putting you in it’s curated environment with:

$ be in myproject myasset mytask

E.g.

$ be in hulk shot002 animation

Currently in Alpha and out looking for opinions along with designers interested in shaping up example projects. I wanted to post here on Blender Artists because of it’s potential in working on remote projects, along with the fact that it’s Open Source. Sharing a directory on something like Dropbox is a great option for a shared server, and now you can also have a shared pipeline.

Looking forward to hearing your thoughts.

Best,
Marcus

2

I’m still a tad unsure of whether I’m in the right place, but here’s some exciting recent developments.

https://cloud.githubusercontent.com/assets/2152766/8471653/8bfc0ab0-2092-11e5-935f-5da1f5209e4f.gif

https://cloud.githubusercontent.com/assets/2152766/8482842/2772e4d6-20e4-11e5-8294-c45f7e6bbc38.gif

Enjoy!

3

This looks really really cool !
Is there a feature roadmap somewhere ?

4

Thanks Hommes_doutant, glad you like it.

Have a look at the Issues section on GitHub for glances towards the future.

Currently, the primary agenda is trials - continuing to use it in production to find out what’s missing. Down the line, further work is intended to expand upon the kind of templates you can write, whilst maintaining the level of ease currently available. After that, implement the backend required to join a remotely running project (this is the part I’m particularly excited about and think the Blender community could benefit the most from, particularly with the amount of open collaborative film making happening here), and finally, as far as my own personal vision goes, a graphical user interface to expose it to users less keen on working with command-line interfaces all day. There’s more about these in the issues section.

Hope that answers your question, let me know if you have any more, and thanks for stopping by!

5

Yes, I see what you mean, I don’t think this tool will be used a lot by the blender community because there is rarely a big production pipelines involved, but remote collaboration on this kind of project could really be awesome.
I’d love to contribute on github when I have the time. I just took a quick look at the code and the issues and this looks promising (even though I have some question, which I think I will ask on the repo).

I’m really interested in open source pipeline management, and your tool comes at the right time for me. I also came across pyblish and a few months ago it could have saved me a lot of trouble !

6

I’m glad you think so, that is a primary goal.

Remote collaboration are one of the most stringent production environments, anything developed under such circumstances should hold up against some severe local production environment constraints. It puts even the most minute requirements under the spotlight very quickly, one example being how to keep everyone synchronised with versions of DCC applications.

Sure, I saw your questions and hopefully responded well enough to answer. I’ll mock up a style guide to clarify some of the code-style, but overall it’s PEP08 and pylint, along with Google Napoleon for docstring conventions.

Pyblish is a stable project and is running in a number of production environments today. I’m hoping to take be to a similar level and things are looking good so far!

I’d love to see you on the Pyblish forums, there’s always a few good pipeline discussions happening there, particularly in the Magenta thread.

7

Remote collaboration are one of the most stringent production environments, anything developed under such circumstances should hold up against some severe local production environment constraints.

Yes, something git-like for production would be pretty cool.

one example being how to keep everyone synchronised with versions of DCC applications.

This would be really difficult. On the top of my head, the two solution I see would be, either bundle everything in a system image (which could be a problem for licences), or have a dependency management system for projects.

I’d love to see you on the Pyblish forums, there’s always a few good pipeline discussions happening there, particularly in the Magenta thread.

I’d be happy to go there when I have the time. I read parts of the pyblish magenta forum and I don’t quite understand what it is. Was the foundation for “be” or is it something else ?

8

This would be really difficult. On the top of my head, the two solution I see would be, either bundle everything in a system image (which could be a problem for licences), or have a dependency management system for projects.

The way I’ve approched this with be is for be to reach out and ask for a pre-defined version based on the task.

For example, it may have been defined that Hulk is using Maya 2016 x64. For any artists working on Hulk, either local or remote, this version would be assumed and if it isn’t available - i.e. isn’t installed - then it wouldn’t be able to launch it. Simple as that. This way, anyone working on a project would be required to also work on the same versions. And the same goes for any of it’s dependencies, such as those handled by Rez or Ecosystem.

I’d be happy to go there when I have the time. I read parts of the pyblish magenta forum and I don’t quite understand what it is. Was the foundation for “be” or is it something else ?

Pyblish is a development framework for publishing pipelines. You write your own validations with it, and it then orchestrates and visualises these validations for you. Magenta is a curated publishing pipeline written with Pyblish and aims to fill a very specific set of production requirements.

See the heading “Narrow focus”.

The idea is for us and the community to write a number of these curated packages, covering various aspects of production, and distribute them for others to use.