The Blender 2.65 release planning is now known; it looks like we'll have a Release Candidate before the end of the year. In addition, Ton has started the discussion on the 2.7x and 2.8x roadmap!
Ton Roosendaal writes:
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.
- How to 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-
42 Comments
The plans that Ton have shared for 2.7 and after just seems truly awesome. I can already hear a lot already shouting their joy for the BGE :). Big thanks to all the team for all the works you guys are doing.
"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."
YES. YES! A THOUSAND TIMES YES!!!!
Am I dreaming?? Is this real life!?
Is this just fantasy?
Caught in a landslide...
No escape from reality...
Another +1 for BGE!
Cheering!
(chants)
BGE! BGE! BGE! BGE!
Does this mean that the nurbana project is on hold for the foreseeable future?
I hope not... Having basic support for trimmed nurbs would make blender a lot more useful for visualization and product design.
Does anybody know the status of this project, or if it is possible to compile nurbana with trunk?
If mesh editing truly catches up to the potential of bmesh, Cycles reaches a reasonable plateau of production-readiness, and Dyntopo and Freestyle get trunked... I wouldn't mind using a frozen stable 2.69b+ for quite a while.
While eagerly playing with wildly fluctuating development builds on the side.
+1 for Freestyle.
Im definately looking forward to blender game engine upgrade.
+1
Blender has been my favourite tool of choice for the past year or so, in doing 3D and I am thrilled to see it grows and expand into the new fields. However, I know that as it grows it becomes more complex to handle and thus the bug count mounts, and that than translates to the stability issues and usability issues.
Wouldn't be easier or more manageable to split trunks into task specific versions of Blenders? Cause if Blender tries to be all in one, which is ideal form, the increasing complexity might cause too many problems and turn, the initially good idea, into a bad one at the end.
But with the task oriented versions of Blender the process of development could be more streamlined and thus more productive.
There are people whom love to model and sculpt only, so the modelling version of Blender (let’s call it the Foundry) than focuses at the modelling, sculpting and uv mapping. This version of Blender is used to produce all kinds of models that can be used for variety of tasks. So after the modelling and texturing is done in the Foundry, that model can be exported to other task specific versions of Blender.
So for the people who excel in rigging and animation there is a version of Blender that is tasked for that purpose. It still has some very basic modelling tools but it is focused primarily on rigging and animation. So it has I don’t know, advanced skeletal rigs, muscle system, motion capture, physics, advanced crowd behaviour. Also it treats geometry different, since it is primarily meant to fulfil animation needs; it creates very low poly proxies of the non-animated and non-moving objects while the objects that are animated are represented in full.
Once the animation is complete than those models can be exported to the third version of blender that is used for rendering, video editing and post processing and it is focused only at those two tasks. It also keeps basic modelling and animation capabilities but it is focused on delivering the finished animation and renders.
The last version of Blender is game developing version and itself it is focused only at the game production.
Now I know that this might sound stupid, I am not a developer or a programmer so I really don’t know how this works, but somehow I think that specialising the versions of Blender for specific tasks would give more streamlined end results and avoid the “mammoth-isation” of the software that can do all things but it is too unstable or unfinished and then it needs to rely on plugins (like the commercial software) to do these things properly.
With task specific versions of blender that have an unified file system that allows them to communicate seamlessly between each other the task specific versions of blender would allow much more focused development without need to worry about the compatibility with other features like it is with the all in one solution.
While it's a fun idea to muse about for a bit, I'm afraid it'd create more problems and annoyances than it would solutions.
From a developer POV, maintaining 3 different apps seems far more cumbersome than just one, especially when features have to be shared, as well as separated and recreated into different versions.
From a user POV, I really like having all tools at my disposal throughout the entire workflow. We can now very fluidly model something, rig and pose it, render to see how it looks, make adjustments, etc for example. We also have things like Vertex Groups and Weight Paint being used throughout the different fields. This could partly be solved by the seamless communication you mentioned, but it would still be an extra step to switch apps.
Yes, Blender is turning quite big, but that's a good thing imho. If I buy a swiss army knife, I don't -have- to use the screwdriver, but it's also not in the way of my blade or corkscrew. Also, if there' a bug in the blade, that doesn't (shouldn't) affect my opening of a bottle. ;)
The only point on which I agree here would be the BGE (sorry BGE fans!). Right now it seems it's pretty separated out from the rest already anyways, and imo a full-fledged game engine is just too massive to be included in Blender (Could you imagine Blender and Unity or UDK in one app?). (Here's an old blog post I made on the subject in case anyone's interested: http://senshisentou.blogspot.nl/2012/03/my-views-on-blender-game-engine.html)
Cheers,
Patrick
I see.
Well, than one feature would be really awesome, maybe for the 3.0 version of Blender and that is the crowd system. Imagine being able to create mass scenes that can be used for both simulations or movie production and I am sure that this feature would propel the Blender to the very top of industry, giving it unprecedented functionality. Just imagine armies’ collide or swarms of giant wasps attacking the city or simulating fire or earthquake evacuation, I mean whatever the reason for creating a crowd is, without any doubt crowd in itself is an awesome sight to see…
Hi Patrick. I've replied to your blogpost, and I also have an additional point to make here.
You state that the Engine is too large to be included in Blender.
For this reason, should we not remove particles, or the compositor? Should we omit Bmesh work? I don't believe we should. Codebase shouldn't be a determining factor in inclusion.
I see what you're getting at. I agree that if blender were split up into a suite of tools like the Adobe Creative Suite, that it could become much more streamlined.
However, I believe this would be detrimental to streamlining the creative process of using all of these tools in concert to explore new ideas that one might not be capable of achieving otherwise.
Well,yes and no. Maybe this won't be the best example but I think that it is close.
If you are having a lunch, first you get the soup or a stew, than you have the salad and the steak and at the end you have treat. Now although all of them end up in your stomack, somehow I think that it would be difficult for a cook to preapare the soup, the steak and the cake in the same dish and serve it in one plate. It is easier for a cook to preapare the soup, the steak and the cake separatley and serve them as such and than you can pick which one you want to eat, how much you want to eat and when you want to eat.
I am just affraid that the increasing compexity of all in one solution might lead to the software becoming overcumberd, sluggish and unstable. Separating the versions for modeling,rigging and animation, rendering and composting would mean that if the modeling version is stable and polished, there is no need to work on it and the developers whom worked at it can join to the rigging and animation team and help them with their version of blender. All three versions can be developed independently from each other and they can go in what ever direction they want, only one rule must not be broken and that is that those two must read the models form the modeling version.
With all due respect, I think you're missing one of the key foundations to Blender:
Tool Versatility
"one feature would be really awesome, maybe for the 3.0 version of Blender and that is the crowd system."
I can imagine that once the new particle nodes system is in place, that generating anything from crowd systems(boids), to chain mail/sweaters, to galaxies, to even seamless textures, will be a cinch to do using nodes...
Trick point, all of that is possible now! =]
The point I'm really trying to make is, splitting blender up into a suite of tools could or, would not only take away from the near complete versatility that it has right now, but it could also instil development deviations that would take away from its inherent versatilities - thus creating development conflicts.
Then how it will be "Blender"? Blending everything in is one of the points.
Also, imagine how many features would plain die with time as their versions would not keep up with core changes. With time they'll grow apart and won't be compatible anymore. Then one gets less attention for a year and then it's too late to fix it as there are no more real users of the branch.
The best solution would then to have applications developped like plugins (dll's). The user could load exacly what he need at runtime.
Benefits:
- it would force developpers to have very clean, high level interfaces
- it would ease maintenance and developpement process
- it would reduce the size of the executable
Not a good practice to call own opinion "the best" - it's merely an opinion :)
Again on topic - big part is loaded as scripts and those are ones taking time of loading as the executables aren't really heavy, especially compared to weight of content it works with. Have you seen Word? :)
Also don't see it as a good idea to force developers on anything. It's not that it's easy as it is.
And as I mentioned in previous post, splitting functionality would make completeness of separate components less obligatory as it won't affect overall stability, thus degrading quality of less often used ones (less often used is not less needed).
One more important point, probably the most - one can make a dll closed source - a straight way to ruin Blender. Produce a fancy closed source addon for blender to hook users on that, then make next version commercial and so on - possible scenarios are countless and you can't help it afterwards. Python is not compiled at least and trunk is guaranteed open.
Of course this all is imho and I could be wrong.
commercial plugins? an excellent idea... a possible source of revenues for the fundation if they share their profits.
Commercial plugin itself is nothing bad, if it shares revenues - even better. But commercial plugin that slips into a "must-have" category will effectively make Blender not free anymore thus ruining the idea. And these things happen quickly as soon as money shows up on the horizon. Money is a great resource and I wish developers all the best, but there are lots of things I would do for a friend that I wouldn't for money. Money can destroy initiative same as create one it if it's not under smart control.
I got an idea :
We could even help people to sell their plugins by creating a sort of APP store.
Just like the apple store, there would be a default set of free plugins
I generally been thinking along the same lines. But splitting it up along these lines instead;
Blender modelling and animation and texturing tools.
Blender Game engine
Blender video editor.
Mainly for UI purposes. I agree there are other issues, Blender foundation resources in supporting each programme and keeping them all functioning together would require extensive management skills, may be a mini dictator which does not go down that well when you working with volunteers.
But I think the issues of Blender ever evolving complexity cant be put off forever.
Glad to see there is still love for the BGE.
Also, interested to see what new tools are incorporated into the 2.7+, 2.8+ development that would aid product designers. Ideally, an edge fillet and better control over measurements would be a good start.
Yay, the dependency graph. That's long overdue and will help a lot.
I wonder how many people know what is a dependency graph and how wonderful a new and complete one would be: better than most anything else.
I'd gladly contribute 200$ to that effort and I am not a riche man in any way.
I'm only suspecting what you're talking about and it seems nice, but could you clarify how dependency graph would work for Blender?
Wow, I'm learning more in Blender than in Maya.
I used Maya for 10 years before switching to Blender...
Since then I've been learning things in Blender that I never would have thought of attempting in Maya. =]
Glad to see the bug count being addressed aggressively. Just as important as new features. Please no more silly bugs like 'texture node not working in cycles'. I mean after you put something in, it should be at least tested by the dev to see if it works.
That one killed an entire Sunday for me.
Onward!
Actually it is our responsibility to test Blender and report the bugs. This can easily be learned. We are lucky to have the ear of the dev team as readily as we do with Blender.
Indeed - I once had a project-stopper bug that was resolved in a matter of hours. Some packages might have better testing but have you seen any that takes care to fix bugs in less than couple of weeks? Some even do it on yearly basis or so.
Also, we are able to test for bugs while the developer works on something new, but it doesn't works other way around.
Delighted to see the roadmap for the future... but before all that Blender needs to become rock-solid and bug free, otherwise new users will be discouraged. I have two bugs to report, one long running (random additional vertex selection in the 3D window when using B or C selection tools) and the other I only just noticed (image sequence textures are not updated in 3D view). The first is pretty fundamental, and the other plain annoying, but both would leave a beginner tearing their hair out wondering what they were doing 'wrong'.
And for that don't forget to report these bugs to the bug tracker (if possible with a test file)
http://www.blender.org/development/report-a-bug/
Image sequence updating in on the 'to-do' list.
Awesome news as always!
MOAR BGE! MOAR!!!
"even compositing" - Yes! Please make it come true. Pretty please!