[Bf-committers] The Future of Blender Projects WAS meeting notes

Tobias Oelgarte tobias.oelgarte at googlemail.com
Sun Jun 24 13:16:57 CEST 2012

Am 24.06.2012 01:59, schrieb Campbell Barton:
> On Sun, Jun 24, 2012 at 1:29 AM, Matt Ebb<matt at mke3.net>  wrote:
>> On Fri, Jun 22, 2012 at 12:05 AM, Ton Roosendaal<ton at blender.org>  wrote:
>>> with the evident benefits but also with as danger that it can go out of control with a huge pile of postponed todo items and issues. :)
>>> http://en.wikipedia.org/wiki/Technical_debt
>> This is an issue for blender, and has been for a while. It may not be
>> as exciting to rally volunteer developers around, but I think
>> post-2.6, a period of 'paying off these debts' would be very good for
>> blender users, especially those using it in production.
>> I think that this isn't just related to short release cycles though, a
>> lot of it's also due to the open movie projects ('Business pressures'
>> in that list, I suppose). They certainly have their benefits, but they
>> also leave a lot of unfinished work in their wake.
>> One of the original ideas for the open movies was to use a practical
>> animation project to 'get blender ready for production', however in
>> the heat of the project, under deadlines and resource pressures, this
>> becomes more like 'fit in the minimum required to allow this
>> particular production to get done'.
>> Using blender in production at the time, I was quite sensitive to this
>> happening during BBB, with features implemented well enough for the
>> team's specific purposes, but not so practical for other use cases. It
>> happened in Sintel (hair dynamics is one example), and it now seems to
>> be happening in Mango. One example that I'm familiar with right now is
>> how the render API seems to have been bypassed and all but forgotten,
>> during the rush to get Cycles in a usable state.
>> Another issue is that the open project are usually exploring new
>> territory for the development team - that's often a major reasons for
>> existence of the projects (eg. 'improve blender's furry hair styling
>> and rendering' or 'improve live-action vfx compositing'). It's great
>> to have a focused target, and it's often a good way to get things
>> done. The danger however is that often the coders and artists involved
>> have little experience in a particular field that they're exploring,
>> and the design decisions and implementations may turn out to not be so
>> good in hindsight, and maybe aren't so good to commit to for Blender.
>> There's a tendency to think that since a movie project got completed,
>> then that particular area of functionality is 'solved', eg. "BBB got
>> finished, therefore hair styling and rendering is done, and we can
>> move on". In reality, Blender users can be left with tools that really
>> don't work that well outside of the project's specific needs, or tools
>> that now with the benefit of hindsight and experience, should have
>> been implemented in a better way. However if developers keep moving on
>> to newer things, and if this happens across all areas of
>> functionality, the end result is an application made up of parts which
>> are all first-draft attempts, which work 'ok' in some situations but
>> not in others, and never smoothly and elegantly.
>> One positive example on the other hand was the render branch after
>> Sintel. The easy thing to do would have been to satisfy the casual
>> users who want to play with new toys, add it all in, and move on.
>> After all the development work that was done on it, it was really
>> commendable to see self-reflection and the willingness to step back,
>> critique it, and say "This isn't right for Blender and its users, it
>> needs to be done a better way", and throw a lot of it away. In the
>> end, it led to cycles, which I'm sure most Blender users will be much
>> happier using in the long term, and is hopefully shaping up to be
>> something that's actually a great tool to use, not just a 75% done
>> first-version.
>> This is also a good argument for doing movie project-specific
>> development in a separate branch. Adding these things into trunk as
>> they are coded makes it much more difficult to revert later on.
>> So! For these open projects to become more effective ways of achieving
>> the goal of improving Blender as a package, not as a project-specific
>> tool, there needs to be a period of critique and further work after
>> each project. I know from experience that at the end of a tiring job
>> when you just want to forget it all, have a rest, and move on, the
>> last thing you want to do is go back over it all and re-work it, but
>> that's the difference between doing this development for that movie
>> project only, or for Blender in general.
>> Questions need to be asked - "Is this the right way to go?" "Should we
>> revise this with better design decisions?" "What worked and didn't
>> work well during the course of the project?" "What hacks did we have
>> to do to make this work, that we should clean up?". And even if the
>> design is good, and it worked well, and you wouldn't do it differently
>> a second time around, it's still very important to ask "Is this enough
>> for general use by other Blender users, not just this open movie team
>> working on this project?". Some of these will come out as feedback
>> from other users during the course of the project. Each time a
>> response to feedback is: "It's not a target for our project", it would
>> be a good idea to write it down, and re-visit the idea in this
>> debt-paying period afterwards.
>> Anyway, this is just my observation from many years of watching these
>> projects, and quite a few of using Blender in production. I know in
>> the past I'd have found using Blender to have been a much more
>> positive experience if more effort had been spent on finishing
>> unfinished work and paying off these technical debts, rather than
>> moving on to newer things.
>> cheers
>> Matt
> Hi Matt, you hit the nail on the head!
> This is something I'm quite conscious of and try to avoid the habit of
> hacking in stuff just for the movie.
> Even so - we aim to make blender great for some open movie but only
> have 2-3 devs working on it and what with bug fixes, hardware failure
> and random features that are needed `yesterday`, We end up something
> much more limited/crappy - as you describe.
> It would be interesting to investigate ways to mitigate this effect
> (with follow up development projects, or more time spent before to
> meet the dev targets needed for the project).
I really would like to see a stabilizing phase that concentrates on 
refactoring and documentation, while at the same time fixing various 
postponed issues. 2.49b was nearly rock stable, 2.5 was a pain at first 
but got better over time and was quite stable with 2.6.2 or so, even if 
i have to admit that not all design goals for 2.5 were reached (still a 
lot of dependency issues). But recently i noticed several new bugs 
introduced through bloated code (mainly because of various fixes/hacks). 
The 3D view is a good example. One bug gets fixed two new bugs arise.

I would assume that there were to many new big things included at once 
in a too short time window, while many needed things/fixes moved onto 
the todo lists.

I'm happy that we have cycles now. But at the same time I'm a bit 
frustrasted because of the dependency: Why would i need a good renderer 
if several bugs keep me from creating the models and animations needed 
for a good looking render?

More information about the Bf-committers mailing list