Blender entered a new era of software development! What started with manual backups (1994), moved to cvs (2000), svn (2007) and now to git (2013). It’s almost the 7 year itch
Our online projects system also migrated, with GForge in 2003, to FusionForge in 2010, and now Phabricator. The Phabricator site has a lot better tools for organizing code work with large teams – including reviewing and managing feedback, research or patches. You can access it at developer.blender.org.
Special thanks to the awesome work on this migration by Brecht van Lommel, Campbell Barton, Sergey Sharybin, Dan McGrath and Julien Rivaud.
Brecht is working on a UI project and team announcement, will be posted in few days.
Meeting discussed work we could do on keymaps and how to manage defaults or presets. Jonathan Williamson will contact people who might be interested in managing the Maya and Max “defaults”. Brecht suggested to completely remove hardcoded C keymap definitions. This will be investigated further.
Meeting ended discussing a lot of interesting other code projects, like for painting tools (GSoC), Beveling options, modeling roadmaps, Cycles, etc. Ton suggested to try to work this out better in the coming weeks and make it a proposed target for 2.70 in wiki.
We keep hoping someday some users see Amd Cycles.O the Blender foundation of a little support to people in LuxRender so have better chance of getting it all worked with blender. Not only cycles.
Seguimos algunos usuarios esperando algun dia ver Amd Cycles.O que la fundacion de Blender de un poquito de apoyo a la gente de Luxrender para asi tener todos posibilidades de tenerlo mejor funcionado con blender. No solo cycles.
A unified cache system for all objects that generate/use a cache. For instance the fluid system can use a frame offset when reading in a cache but the smoke system can not. All cache systems should have an equal level of support/features.
The “break forward compatability” is very discouraging to see. I am in the midst of writing a complex python AddOn and from this post this would mean that my AddOn will most likely break or not work on 2.7. This gives my AddOn a version life of 0.1. I just want to cry, there is no getting ahead of the game in Blender AddOn development. I am always playing catch up.
Forward compatibility is not backward compatibility. You will still be able to load old data. But you cannot load a new blendfile with old Blender versions anymore. Forward compatibility is not very common anyways.
I have stopped looking at add-ons apart from the bundled ones for the code rot issue; I cannot stand the idea of getting accustomed to using a tool and then sometime later somebody comes and takes it away.
scriptable simulations? (a way to define keys as a function of the values of keys in a previous frame)
support for animating an armature that has been linked into the scene multiple times. (armatures is one of the things that I am still appending instead of linking)
When u have ball. And u take texture with a lot of scratches in all directions. And u set is as bump in Corona render will be like in real life, when u move spot lamp close to that lamp there will be ring sratches around that place where light hits. In cycles all scratches are just showed in place where light hits.
I believe there was a mailing list thread saying that 2.70 is not being planned as the type of release that will break all of the addons, the bigger breaking changes as of now are slated to be reserved for the 2.8x series or Blender 3.0.
On top of that, there’s been no mention of the devs. requiring the breakage of forward compatibility, it’s just that if a developer’s been waiting to make changes that would definitely prevent the loading of new data in older versions, he can.