Blender 2.8: development plan

Ton posted this yesterday:

Blender 2.8 – the Workflow releaseby ton on Jul 20, 2015 • 15:4144 Comments
This is a proposal for work focus on blender.org for the coming year.
I’ve written this because we keep missing bigger development targets – we don’t have enough time for larger projects. Instead too much time goes to releases, bug fixing, reviews, maintenance and support topics. The bug and patch tracker duties are keeping the best of our developers away from their own targets. As a result we then don’t have time for design docs, for planning, logs and in-depth sessions with the module teams, and have no time for the artists who are involved to make sure we’re well aligned and know what to do. I think everyone has noticed that we’re floating too much, things are not clear. Where are we heading? Who does what, and how do we decide on things?
So – it’s time to act and gather the troops to refocus and get back energy, to maximize involvement from everyone who’s active in blender.org and make sure Blender can survive for many more years.
—– Blender 2.8 – Workflow release —–Just like for 2.5, the proposal would be to take a bigger leap to a bigger release by not releasing for a year. The 2.76 release then would be the last ‘real’ version we do until 2.80 somewhere in 2016.
Obviously, for the crucial fixes and smaller (stable) features we can do update releases 2.77, 2.78 and 2.79.
Topics to finish for 2.8 could be:

  • UI work: wrap up Python configurability project, make Workflow based configuring possible
    Proof of concept: the stripped “Blender 101″ for high school kids.
  • Viewport project, including a PBR quality engine/editor that could replace BI and GE render.
  • A better designed integration of physics simulation in Blender
  • Invite the GE team to rethink game logic editing, to use viewport and new physics
  • Don’t add the half finished Gooseberry targets but take the time needed to code it well:
    Particle nodes, hair nodes, simulation nodes, modifier nodes…
  • Asset managing and browsing, linking, references, external files in general.
  • Integration in non Blender pipelines.

Practical considerations:

  • Move development to special 2.8 branch(es)
  • Module teams are empowered to cleanup quite radically and get rid of legacy code.
  • The 2.8 series is allowed to be not 100% compatible with 2.7x. (Physics, particles, games).
  • Spend time on organizing ourselves better, agreed designs should lead to more empowerment.

And some core principles to agree on:

  • We reconfirm and where needed update the 2.5 spec docs.
  • Stick to existing Blender data structures and code design for as much as possible.
  • Make Blender ready to survive until 2020, but…
    … start collecting the list of bigger redesign issues we need to for a 3.0 project
  • Bring back the fun in Blender coding! http://code.blender.org/wp-includes/images/smilies/simple-smile.png

The code.blender.org article for the roadmap of 2014-2015 is still valid in my opinion. We just need to take a break of 9-12 months now, to make it work for real.
Blender 2.8 Workflow SprintIn the coming months we can discuss and review the plans and make sure we’re 100% aligned on the 2.8 targets and for other work during the coming years. We should also meet and have good feedback sessions on it. So I propose to use the Blender Conference in October as a deadline, and organize a workshop in the week before.

  • Four days of workshops and design sessions, in the week before Blender Conference.
  • Travel and hotel covered for by BF (and Dev Fund, or a new fund raiser?)
  • We should try to get someone from every (active, involved) module team on board. Also key user/contributors have to be on board. But it’s also more efficient to keep it compact.
  • Proposal: we do this invitation-only: First we invite the 5 most active contributors of past years. Together they then invite persons more, until we have 12 (?) people.
  • Sprint sessions can be in parallel too – UI, Viewport, Physics, etc. Let’s make it public as good as possible.
  • The Sprint results get presented and reviewed during further on sessions during the Blender Conference.

Seven years ago, back in 2008, we also took a break for more than a year, to get the 2.5 project started up. It was a very exciting period where a lot of new things were possible and could happen, even though we didn’t finish everything… it gave us quite a solid foundation to build on, attracting a lot of new developers and great features.
I realize we have to be realistic now, not everything will be possible. But we also shouldn’t stop dreaming up a good future for Blender. Let’s take a break from our demanding release cycle, rethink it all, but not for too long. Let’s cherish what we agree on and enjoy the freedom of a configurable workflow that will enable you to do what you think is best… for making 3d art, games, film and animation!

-Ton-

This could be good for blender! What do you guys think?

Allowing developers to spend upwards of several months to replace legacy code and functionality with modern solutions (preferably node-based) sounds like a good plan to me.

An alternative though (if they don’t want to go through a release drought that long), would be to double the length of the release cycle to 4 months instead of 2 (devs. should be able to have at least 2 months to implement release targets until Bcon 3 rolls around). In this case, 2.77 would not be released until the end of December or early January.

We’ll likely do some modest update releases on 2.7x series, even if its just fixes and some improvements / optimizations - backported from 2.8x branch.

Of course for workflow-blocking bugs or regressions we can make some exceptions - and do a,b,c,d releases too.

The point is that we’re not spending significant time devoted to 2.7x maintenance.

I personally think that it is a step in the right direction. Especially given the limited number and time of developers.

Will we still have access to bleeding edge/unstable branch features via buildbot? :slight_smile:
Part of the fun for me at least is in keeping an eye on what you guys are working on.

this made me very excited for the future of blender! eventhough it’s going to take a very long time :c
I’m not worried at all about the modeling, animation, or rendering portions of blender, seeing how they’ve been improved so much in such a short time. However, I’m both excited and scared for the BGE. I really like the idea of mixing the 2 engines into one, but I hope they keep the ability to export runtime games. I would also prefer the logic editor to be converted to a normal node editor. That way we could have a lot more control with less nodes. It would theoretically look like a visual representation of logic gates! not the shape of the node, of course, but the setup.

I agree, if we can get standalone support, and modern shaders,
the bge will bebin great shape, the only issue I see with nodes, is how
is the data exposed to a script api?

also a “empty” sensor block (to make gaps in logic messes)
empty controller and empty actuator = allows you to spread stuff out,

I love the current logic system though I know it needs some upgrades,
(color grouping, hide by color, and leave last noodle highlighted, and colored noodles)

this would expand the current logic to the point where no matter how thick the logic is, no untrackable spaghetti.

if electricians could only use black wire they would quickly go insane

Plain & simple… do it!
:yes:

As much as I like how frequently Blender gets updated, this seems like an excellent idea.

I’m also very glad it looks like OpenSubDiv is making the cut off for 2.76.

the thing I don’t like about the current logic is the inablility to either move the nodes around, or connect sensors and actuators together. I know it sounds silly, but hear me out. here’s kind of what I’m thinking:


Everything is swell and nice but

“UI work: wrap up Python configurability project, make Workflow based configuring possibleProof of concept: the stripped “Blender 101″ for high school kids.”

erm…

yeah… What’s the point of this? Creating a dumbed down version of blender? Honestly I don’t see a benefit of doing this.

@fdfxd, Yep, personally Im rather un-interested in a stripped down Blender,
but there is some demand for it I’m told :slight_smile:

The benefit is Blender will have to be made more configurable.

Of course if we just take existing Blender code and strip out half the buttons and keymaps

  • thats a waste of time.
    If we make sure Blender can be configured, for simple use case as well as advanced users… this is a nice target, since it means everything in between will be supported too.

A lot of work will be on ensuring UI and keymaps can be better customized, so generally useful stuff.

got git, pulled her down
now I attempting to decode the matrix.

I now begin my ascension to devGod status, or my decent into madness.

Yeah, high school kids are not so dumb that they need a special version. In fact they’d probably consider that uncool.

Other than that, the plan sounds good to me :slight_smile:

really though, The UI needs to be Wrectified,

Soft coding saves lives.

Ui panel = a container for code

widgets = manipulate properties used by code

and this can do everything,

widget types = slider, list, 2d slider with background, static image, generated image, and list. (more?)

Great question! Personally, I’m interested in this as part of a larger studio pipeline… We could create versions of blender that are specifically optimized for one task that you do over and over and over for 10 hours a day.

for example, if I only animate… And that’s all I ever do, we could strip out all the non-essential tools and configure all hotkey settings so things are super efficient for animation. When I’m ready to animate, I just launch that blender from my shot and bam, it’s only what I need and nothing else.

same for modeling, rigging, texturing, compositing… You get the idea.

To me it’s all about efficiency when working on a particular task.

certainly not for everyone… But for a team of 10 modelers who only build objects 35 hours per week and tweak uvs the other 5… Super efficient and awesome! :slight_smile:

-Jason

@jasonschleifer, right, thats exactly why the project is useful,

In theory you can configure Blender already, but anyone who tries to make larger customizations runs into limits (hard coded keymaps, difficulty syncing keymaps after updates, mixing own panels with existing ones… etc).

I hope blender stays open source. It would become the first most powerful open source 3d software.

Closing the source and attaching a pricetag won’t happen because the GPL won’t allow it, it will always remain the most affordable solution out there :slight_smile:

Are there any plans to support grouping in Blender? It is IMHO currently the most important missing feature. By grouping I mean the ability to group objects to make them act as a single one (viewport select). The current workflow with group linking has some flaws - it is difficult to keep different versions of the linked groups, sometimes you need to edit the group directly inside the scene (if you need to match colors in your scene and you need to see it side by side; if you need to match dimensions of a furniture according to walls etc.) It is usually not possible to join the object into one because every object has different set of modifiers.

[citation needed]

It won’t happen because the GPL makes it highly impractical, at this point. If there had been enough will (or foresight) to change the license in the future, the BF would’ve only accepted contributions from authors that waive their exclusive copyright.

That way, the BF (with approval of copyright owners) could dual-license Blender in a proprietary version and free version, or move to a more compatible license such as LGPL (or even move back to proprietary-only, though that won’t affect older versions). In fact, the possibility such dual licensing has existed in the form of the Blender license, it just hasn’t ever been applied and it’s discontinued.