Blender's increasing development pace and the lurking danger of overcomplication

#1

Experiencing Blender’s increasing development speed I was thinking about the following, and I’m curious what others think of this.

To be honest I can imagine a ‘feature fatigue’ if Blender’s development pace keeps accelerating with more and more active developers who are relatively free to add tools, features and UI changes.

New features, tools and UI changes are added to the Blender alpha master builds almost every day at the moment. A stark contrast with the yearly updates of Houdini, ZBrush, 3ds Max, etcetera, introducing a maximum of about ten major new features.

It’s becoming harder to keep up with Blender’s frequent changes and additions, while it’s disputable whether they all really improve Blender’s user experience. Even default keyboard shortcuts are frequently changed.

I’d personally like to see more structure in the additions and changes, for example with a multi-person judgement panel and/or a public poll system evaluating whether a change or addition is really worth it before having it added to the master builds, so there would be some kind of filter, to avoid Blender users becoming oversaturated with a constant flood of new features and changes by an ever-growing army of independent developers.

This is just my personal $0.02. I’m interested to read your thoughts on this.

Why Blender Isn't Industry Standard
ZBrush 2020 announced
#2

Well, I’m not sure if Blender actually gets more development, or it just seems that way because the commit logs are public.

But anyway, I’d say I’m pretty happy with the current structure. In the past it was common for things to get caught in limbo, or die on the vine. Almost all areas seem to be actively maintained at the moment.

6 Likes
#3

That’s basically a good thing, but I think there’s a limit to what users can digest in terms of changes and additions in a relatively short amount of time. And there’s the danger of quantity over quality. A number of new features feel incomplete, and stay that way for too long. This would not be the case if there would be a stronger selectivity before final implementation.

An often-heard piece of criticism regarding the 2.8 release is that it feels like a prematurely released beta version. I can imagine why users think of it that way.

#4

Adesk haven’t used that yearly release model for quite some years. It’s been quarterly for some time now, but I get your point.

You’re right though, I make sure to watch Pablo Vasquez’s weekly streams to stay abreast of these changes. :laughing: The only other software that moves at this lightning pace is UE4. It’s almost a full-time job keeping up with Epic’s updates.

One of the recent changes that makes absolutely ZERO sense to me is moving the new ‘edit origin’ feature from the pivot menu to the options rollout - which in itself seems like a waste of space.

Other than that I’m not really experienced enough with Blender to comment too much on it. One of my main gripes with the UI is the duplicate entries. I know every DCC suffers from this, but in Blender’s case it seems more prevalent, especially the N panel conflicts with the active tool and workspaces panel. For instance, in Sculpt Mode with the top toolbar on and the N panel open we have the brush settings on screen in 3 different places at once.

My other main gripe is with the tab system for addons. I would prefer a shelf type system like Max/Maya.

Sorry if this wasn’t the intention of the thread.

3 Likes
#5

Good points, Dan. I agree.

1 Like
#6

From my experience on the Max beta this is a hard one. Although this same beta principle could be applied in public with Blender. For major UI changes or features maybe some sort of poll on a thread on this site rather than one of the other dev based sites. There seems to be much more traffic here and a lot of users probably don’t ever go past here to the dev based sites. Or so I would imagine.

1 Like
#7

Yes! As Blender is meant for everyone, and everyone is welcome to contribute, why not make development decisions and evaluations more public as well, to further democratize the open process.

Right now some areas of Blender are predominantly developed by one person, often with only one other developer serving as a reviewer before the commit is approved.

1 Like
#8

This has been a weird and also wonderful experience for me with Blender. I love the nightly builds, but it also has a perpetual-beta feel to it. There was a huge burst of excitement when 2.80 officially released, but I was already using 2.81… :laughing:

For good or bad, it will probably always feel like a beta.

2 Likes
#9

:grin: Yeah, I know the addictiveness of downloading the daily master builds. :slightly_smiling_face: But lately I’m becoming a bit overwhelmed by the continuous flood of changes and additions.

1 Like
#10

This is something that commercial devs have over Blender. It is highly structured and compartmentalised in specialist teams. Those teams post up new feature tasks(I’m talking Max here) and post a related thread on the forums. We test the features from the start, give our feedback on design/implementation/possible features/bug reports… rinse and repeat. The feature doesn’t ship until it’s finished. Devs have a quarterly deadline. If they don’t finish it, it doesn’t make the release and rolls on. You were on Max beta once upon a time so you know how it goes.

2 Likes
#11

Fully agreed, that kind of structured development definitely has its advantages.

#12

Exactly. Letting bugs rot for years, writing them off on design, requiring long and tedious disucssions on rclickselect with no clear outcome, while at the same time frivolously mangling the UI “because Campbell talked to an artist” is… questionable.
I’m all for trying new ideas, but there has to be some process to it, preferably without double standards.

1 Like
#13

Just my 2 cents here… However awesome 2.8 is, it’s obvious that many aspects of it aren’t finished yet. It’s a strong foundation to build on but everything we have now is pretty much work in progress. I expect many aspects of the UI and functionality to change radically with the upcoming couple of patches. After that I also expect the development pace will still be strong but less visible as we won’t be as flooded with new features and changing functionality as we are now.

3 Likes
#14

I certainly hope you’re right, but I’m a bit afraid Blender’s increasing popularity and corporate fund contributors will mobilize an army of bedroom developers, pushing Blender to have 200 new changes and features every three months, increasing the need for a strong filter at the top level of development, but also at the base level, putting users in charge as well.

#15

It’s funny, but we can go to any random 3D program forums at any given time over the last 10 years and the very same things are being said. It’s just part and parcel, I suppose. There are things in Max or Zbrush that have been there for 10 years and drive people crazy, yet remain against all logic. I don’t think it matters how big a team is or how much resources they have, this is the same old story in all the DCCs. One thing I have to say though is that even though people complain about Max’s new features year after year, that team crush an insane amount of bugs.

5 Likes
#16

Be careful what you wish for… :smiley:
I don’t know if this will be the case, although it’s certainly possible. Even the jump in the amount of devs this year would create administration havoc with whatever system they already had in place for 20-odd years. It’s a whole different level of logistics and management. This is where the BF could benefit from the structured approach that Max/Maya devs use.

1 Like
#17

I don’t think feature fatigue is the right formulation of the problem. The issue which usually arises from the fast ramp up of development resources is better formulated as “overcomplication”. The problem occurs when too many features are added but not many are removed or replaced by the newly added ones. At every point in time of development, the main focus should be on simplification.

By that I mean constantly striving to remove old, legacy junk, constantly striving to unify tools to have smaller set of more universally usable tools, and constantly striving to introduce new tools, which do same amount of things or more things with less UI knobs.

Blender suffers from that on many places, a few examples being:

  1. Overcomplicated, extremely fragmented keymap and theme customization.
  2. Shit ton of user preferences instead of superior defaults which would remove necessity for half of them
  3. Nonsense like movie editor having it’s own unique graph editor with own unique theme and keymap settings instead of sharing global graph editor.
  4. Generally offering multiple workflows of different benefit/drawback proportions to do one thing, instead of one right way.

I’ve seen an interview with Elon Musk recently where he confirmed the mindset I am using for years already. He said his favorite part of the engineering meeting is when someone “un-designed something” instead of “designing something”. When someone simplified something, made something that works the same way with less parts and less complexity.

6 Likes
#18

Fully agreed, @rawalanche. In fact, I’ve changed the topic title to include ‘overcomplication’. :slightly_smiling_face:

I’m also a minimalist, living and acting by the ‘less is more’ rule, also known as ‘KISS’ (Keep It Simple, Stupid!).

It was just that ‘feature fatigue’ alliterated so nicely. :wink:

1 Like
#19

I’m not sure this is true - Blender’s development is tightly orchestrated by team leads at the Blender Foundation. It’s not a ‘free for all’, not all patches/contributions will be accepted into the main release.

2 Likes
#20

As somebody who cares about usability, UX and DX (developer experience) I see the significance of your concern; although I’m not really concerned. Reason being that I see lots of activity to ensure quality does not get lost behind quantity.

There are currently big efforts to make the development scale better. E.g.:

  • There are now two hired development coordinators (we often call them “Managers”): Dalai Felinto and Nathan Letwory.
  • BF/BI Devs do lots and lots of meetings with people from within and outside of projects they work on. These are rather informal and just informative for devs/stackholders, so most of them don’t get public coverage.
  • Last week, we had a couple of long post-conference developer meetings in the Blender headquarters, to tackle issues in bug triaging, reviewing, quality ensurance, personal matter, etc. Results of this are getting formalized and published currently. E.g. yesterday Dalai published The Life of A Bug, reevaluating the bug triaging to fixing process.
  • There’s development for developer.blender.org, trying to make it more accessible and manageable.
  • Two people are hired to work just on the bug tracker, possibly another one will be added.
  • Technical dept is a big issue. A good part of the Epic Mega Grant will be spend on tackling that.
  • For the longer term, Ton seeks to get directors and a supervisory board for the Blender Foundation.
  • …

On the UI side I think we’re also on a good track:

  • There’s a hired UI designer (William Reynish) and a full time UI dev (myself) now. Pablo Vazquez is also hoping to help more on this topic. AFAIK Ton wants to get another UI dev which I’d appreciate a lot.
  • Because of this there’s lots of activity from the core UI team. Check developer.blender.org to follow individual processes.
  • Recently we decided to work on Human Interface Guidelines for Blender. To have a place that contributors, including Add-on authors can refer to. Aim is mostly to have a consistent baseline design all over Blender, i.e. less randomness. E.g. check Apple’s or KDE’s. IMHO this is a really important step.
  • We try to make things more based on real life needs. E.g. we start design work based on concrete use-cases and try to get more artist involvement. One thing I’m preparing is having informal feedback sessions and proper usability testing with the artists from the Blender Animation Studio.
  • Further, we try to make sure the UI project, as well as other projects have a clear vision to work towards to. E.g. some people are keen on improving the VSE - but what is the vision for the VSE? Should it become a fully fledged video editor? Or should it limit its focus on supporting the 3D animation workflows?
    I also always try to remember people of thinking about the actual target audience we try to cater.
    In other words, we take care that the big picture is not forgotten either.
20 Likes