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 <ideasma...@gmail.com>wrote: > On Sun, Jun 24, 2012 at 1:29 AM, Matt Ebb <m...@mke3.net> wrote: > > On Fri, Jun 22, 2012 at 12:05 AM, Ton Roosendaal <t...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers