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

[Daniel Salazar - 3Developer.com]

I have an idea, assign devs to help Blender studios around the world, ie:
patazstudio from Costa Rica :D That and limit open movies to 3 min films! :)

cheers!

Daniel Salazar
patazstudio.com

On Sat, Jun 23, 2012 at 5:59 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> 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).
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>