Preparations for the 2.66 release are being made (check out the test builds!), and 2.67 targets are becoming visible.
Ton Roosendaal writes:
Hi all,
Here's notes from today's meeting in irc.freenode.net #blendercoders:
1) Upcoming 2.66 release
- Main release showstopper is problems with Cycles GPU rendering for 32 bits systems. Brecht van Lommel and Sergey Sharybin will work on this the next few days.
- Bug tracker has enough issues to keep fixing, but no (other) showstoppers are there. Assuming the Cycles topic gets handled, we'll call for a Release Candidate on wednesday.
- Next sunday meeting we'll review the results of the RC release and decide on an actual release day.
2) Other projects, targets for 2.67
- Freestyle: no news... but still possible.
- Ton Roosendaal will work on a nice C implementation (+ Py access) for Pie menus.
- Brecht: Current Cycles roadmap: SSS, 'Ubershader', Displacement, Volumes, and then Baking.
- Stuart Broadfoot will work on Cycles hair closure and a minimum pixel width.
- Proposals are being reviewed for Rigid Body Constraints editing and visualization.
- Sergey will work on tools for more automatic motion tracking.
- Antonis Riakiotakis: will further work on texture paint.
- Campbell Barton now has a 3d printer, he already works with Dolf Veenvliet on good tools to help 3D print designers.
- Ton will work on cleanup of .blend file read/write flagging. This should enable 'template files' for example (like having multiple startups).
-Ton-
31 Comments
Concerning Freestyle...
GET some news.
MAKE IT HAPPEN.
It's an awesome thing that I've been hearing was near trunk since 2.5.
dudee.. not cool.
You're absolutely right. I was saying it with a smile on my face and lighthearted frustration, but that doesn't come through. I have used Freestyle branch when I needed it, but it's just a little more annoying than having it in trunk, and it's exasperatingly like Alice in Wonderland: Freestyle in the next version, always the next version, but never in the trunk.
Anyway, yes, I definitely came across as more demanding than a user of free software has any right to be, and I'm sorry.
Yes it is near trunk, but has some stability issues which will prevent it becoming trunk. There is not enough active development on the integration of freestyle to fix all the bugs.
My guess is that freestyle will make trunk in 2.7, but if you want it sooner I believe the developers are taking donations, if there is funding it will make it to trunk sooner.
-Alex
I didn't occur to me to do that, I shall do so forthwith.
You know what would be awesome? Vector paint.
I mean painting based on editable curves, much like AE's paintbrush tool, without having to go through setting up dynamic paint.
So finally, the day came where it's no longer the 64bit releases that are troubling but the 32bit ones start to be.
Oh if only there could be some movement on OpenCL! It's not the fault of the Blender devs, but it seems crazy that at least half of (and some of the most powerful) graphics cards can't be used for GPU rendering, and that one company effectively has a monopoly on hardware for Blender users.
Unfortunately this is mainly due to the fact that Nvidia pours a lot of money and development into making their cards work with everything, where as ATI does not.
ATI will probably reach full support in the next few years but nvidia is where the power is at the moment.
-Alex
"Nvidia pours a lot of money and development into making their cards work with everything"
can you elaborate on this? I find it hard to believe that nVidia, or ATI take Blender into account when developing hardware.
Nvidia have developers that work on making their cards more compatible with games and such, I believe blender is able to interface with this better, ATI has trouble with a lot of games and their drivers as they do not have the extent of support. And it wouldn't surprise me if Nvidia had a developer make compatibility for blender, it would not be difficult for them and blender is used in a lot of indie games so is quite well known
-Alex
Thanks.
That makes more sense than the way I originally read it. And I wasn't trying to single out Blender Foundation. The same confusion could be applied to EA Games or Autodesk. In hindsight, it only makes sense that hardware manufacturers would use input from developers to help determine needs and limitations as new tech (such as CUDA or OpenCL) gets rolled in. that is, if you can call a 10 year old specification 'new'.
Cycle baking finally officially scheduled yes! :)
And i hope to see OpenCL supported like Reaction said, AMD graphic cards are pretty good, the HD 7970 is up to two times faster than a GTX 580: http://images.anandtech.com/graphs/graph5699/45164.png
And i hope also to see little tools like:
_A snap to grid
_We use at 90 % snap to grid or snap to vertex, so have a shortcut for each of them by default
_Shift+r (after a shift+d or alt+d) need to work more efficiently like an array modifier (increment position, rotation and scale) like Maya does.
_Double sided automatically disabled by default to increase drastically the performance of the viewport especially for high poly and sculpting.
_A merge vertex tool with previsualisation like in Maya, the wheel to change the mode between "to center" and "at last". We have split and edge loop with preview so this can be in the continuity.
What problem is there with snap to grid?
You can integrate python with the repeat last command to do this easily, I don't think it would be a trunk feature yet.
Double sided being disabled on enter to sculpt mode would be fantastic, I have spoken to the dev about this.
-Alex
This sounds like something I encountered the other day as well, when I was doing a vertex slide. The direction of the vertex slide was a diagonal, and to get it to land precisely with the specific horizontal or vertical location of a given edge or gridline without pulling the sliding vertex off-center from its directional-normal was non-trivial... I had to eyeball it while zooming in progressively to maximum zoom. (I don't know if I'm explaining this well without a picture, or if this is even what the original poster was describing.)
Texture Baking is REALLY important. I'm working on a simulation in Unity now and I'm using Blender Internal.
Cycles baking would make what I'm working on out of this world.
But.. if SmallLux rendered can render with OpenCL .. why Cycles can't.. ? I'm no programmer, but it really seems weird.
It comes down to compatibility, ATI use a different architecture than Nvidia, GPU's are vastly complex.
-Alex
I love my CUDA card and Cycles, but I've been wondering the same thing Karlis. Anybody know why Lux devs find success where Cycles devs hit AMD roadblocks?
From the Luxmark site: "AMD has used LuxMark as one of the 5 GPU computing benchmarks to present the new HD7970."
Cycles is a very different engine than SLG. The materials system is much more robust and it has many things in the code aimed at making it a real production renderer rather than just an experiment. These things create a very large kernel that needs to be compiled, much larger than that of SLG, and the AMD complier simply can't handle the size.
Ah! Mystery solved. Thanks!
Then you should be coordinating with LLVM/Clang and it's Target R600 branch to see the status of it's OpenCL stack and kernel size boundary limits.
How About the game engine!? make some improvements on it, like adding and improving the realtime reflections on the official build..
Game engine is currently being worked on, but nothing is ready for trunk yet to my knowledge
-Alex
I'm wondering:
Are there plans for a general use node editor? Like Maya's node editor, or ICE in Softimage.
Since people are throwing requests around, here's one: Blender recently got a weights transfer tool, and it generates a decent starting point if you set it to "nearest vertex", but you inevitably need to refine the result. Softimage's GATOR however, takes a weighted average of many neighboring vertices (according to distance I think). The result is pure magic, and I rarely need to tweak it.
I'd love a node editor for general stuff like modifiers, constraints, materials, even datablocks like meshes :D often tonnes of objects use identicle modifiers, properties, or scenes use the same settings so it'd be great if there was a quick node based way to link some properties and allow others to be adjusted per object.
I often do this with materials,for example having a generic node group for wood with inputs for UVs, dirt and scratch maps, since if there are lots of objects that are essencially the same wood but have different scale UVs and images for the maps, I can still control all those objects at once inside the group and keep the differences separate.
Agreed. Constraint/driver nodes especially would be amazing...
Awesome, guys. Awesome.
I'm looking forward to all of the finalized new additions in the upcoming official 2.66 and 2.67 builds. I'm especially looking forward to the texture paint features, since I prefer to do my overall texturing in 3D texturing before moving on to details in an 2D image editor but would like to be better able to do some detailing from right within the 3D texturing.
I've been using the Graphicall builds for the new texturing tools, and I love where the texture tools are headed. I'm looking forward to having another well-developed 3D painting software solution out there, all built right into Blender. I'm looking forward to the rest of the developments as well.
Not that this comment section is a request line, but just to merely mention a stellar feature out of hoping, something I hope gets implemented in Blender someday soon is vector displacement maps.
I'd love to be able to use vector displacement maps with sculpting to create some highly-detail and easily-added 3D forms sculpted independently of my model.
Plus, you can never have too many programs that extract out vector displacement maps--even though that's something in Mudbox and ZBrush, this feature is otherwise far and few between.
Man, this is enough to make me want to sharpen my developer skills some more to look at how something like this could be implemented into Blender. Though, I'd need like a freed-up summer break to do something like that.
So like normal map used for sculpting? Nice idea :)
Separable Subsurface Scattering
http://www.iryoku.com/separable-sss-released