[Bf-committers] Blender developers meeting notes: November 4 2012

Ton Roosendaal ton at blender.org
Sun Nov 4 17:49:39 CET 2012

Hi all,

Here's the notes from today's meeting in irc.freenode.net #blendercoders:

1) Blender 2.65 release targets

- Target list and planning:

- Dynamic topology sculpt: Sergey and Nicholas worked on it last week. They see too many open issues now to guarantee a stable merge this week. It would also mean a lot of work, taking them away from other 2.65 work (like bugs). Therefore they propose to move it to 2.66. And just stick to bimonthly release.

- Open Shading Language and script nodes are now in trunk! 

- Brecht van Lommel and Lukas Toenne patched the OSL library. Added support for loading shaders from memory, build fixes and cmake cleanup. The OSL team has been been informed to accept the patches.

- Compile with OSL:

- Thomas Dinges will put llvm library and OSL in release environment (compiled libs). He might need help with llvm from the other Windows platform maintainers.

- Sergey Sharybin will make a script for Linux users, how to get all external libraries and compile it. That will replace the current Linux libs in svn entirely.

- Jens Verwiebe will make sure OSX compiling for OSL works for 10.8 as well.

- Sergej Reich is still working on finalizing a merge. Brecht will check monday. There's a good chance also this branch needs more time to mature (i.e. get merged at beginning of a release cycle), it's quite a lot of changes in existing Blender code. Sergej will mail the codereview link of his patch to this list.

- Lukas Toenne will have Python defined nodes (nodes that can be defined by external engines for example) and new group code ready this week. Will get careful review, especially to not break reading 2.65 in previous versions.

2) Other projects

Ton proposed to start thinking of roadmap for Blender 2.7x and 2.8x:

For a 2.7x series we could focus on a number of steps to tackle all depsgraph related woes in Blender. It's not just a simple under-the-hood fix of an isolated piece of code, it has relationships with everything in Blender, the animation system, physics, ways we draw objects, render, etc. A reminder, old notes from early this year:

Doing it as "2.7x" means we can also drop some compatibility (like particles, point caches, proxy, ways how physics work). All this ending up in a 2.8x series that's kept more stable and compatible again (like 2.6x after 2.5x).

Another candidate for refactor in 2.7x days could be the Blender Game Engine. If we recode Blender to be much faster in drawing, threaded, with advanced & better drawing methods (compositing even), it would be a shame if the GE wouldn't benefit from it too. We could check on sharing code better.

While revamping of 2.7x then goes on, we can still work on maintaining the 2.6x versions (with bimonthly releases, we have almost a year to go still :).

Brecht pointed out that we should attempt to structure this in smaller refactor steps. Fix one part completely, and keep rest working. That way each of the 2.7x versions might be fully usable still. Whether that's possible depends on a lot of unknowns still. It's Ton's impression that we better do it good from scratch - get everything prepared to work with the new specs from the first release 2.70 on (even when it means only few things are ready).

Food for thought, we have time for it! Nice project for 2013 :)


Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

More information about the Bf-committers mailing list