2.64 is coming along, but work on some issues it causing a delay of the release to the end of July.
Ton Roosendaal writes:
Hi all,
And here's a summary of today's topics at irc.freenode.net #blendercoders
1) Blender 2.64 progress
- Bug tracker is now down to 262 open issues - 45 new reports came in in last week, 74 were closed.
- Linux maintainer (Sergey Sharybin) will remove trunk/lib/ for linux libraries, it gives more issues than benefits. The compile docs will get updated.
- Tiles Compositor is currently a showstopper for release; it has issues artists perceive as a regression. If this would be fixed, the tile system would show off much better. Issues as noted are:
- Make the common nodes tile aware (if node requires a buffers it blocks the process).
- Jeroen Bakker will make a list of 'bad' nodes, so everyone can help fixing
- Provide user with ways to work with non-tile nodes nicer (draw early tile previews or disable node)
- Buffered nodes: for fast viewing, and to ensure recomposites only do the minimum required buffers.
- Minimize pre-process (no perceivable delay between interaction and updates)
- Solve issue with slow recomposites (as if threads refuse to stop)
- Solve issue on load of .blend, auto-recomposites with image file loading block the UI now
- Other developers (Sergey, Campbell and Brecht) are available to help Jeroen with Compositor work.
- In order to tackle open issues, proposal is to postpone release to end of July.
- Ton Roosendaal suggested to then also allow for the next weeks work on approved topics in svn - like cycles updates, mask editing, Opencolor, etc.
- Sergey proposes to release a testbuild this week, he'll coordinate it.
2) Other projects
- Bastien Montagne: works on improvements for Grease Pencil to curve tool.
- link all strokes into a single curve
- record timing in strokes, to make a real-time path animation possible
- Lukas Toenne works on custom nodes/node groups in 2.65. Below a sneak peek:
3) GSoC
- There were no issues to note for the meeting log.
Laters,
-Ton-
17 Comments
sounds cool!
Yeaa , thansk you !
And I want share something I found today ;)) maybe some from this can help cycles or event BGE:
Brigade2 - Real time ray tracing
http://igad.nhtv.nl/~bikker/
Greetings!
Must...not....download....CPU....will.....melt....
I know that 2.64 is coming with many great improvements but when is bevel going to be improved ?.
At the moment to get cleaner results i have to add extra edge loops and then remove them after, slows your workflow down greatly.
I'll have to agree with steven here....
we have bmesh and still not a production ready bevel.... well, we don't have a production ready bevel since 2.49b (which of course was a python script but it worked)...
This may be seen as a small thing, but I am constantly aware that I lack the proper tools to clean and/or reduce my object meshes. Among other things this would be: finding polygons below a certain size, finding non-planer polygons, finding overlapping polygons, holes in my mesh, etc.
That reminds me of something I was wondering about. Is it possible to enable backface culling in semi transparent mode. ("z" in edit mode ?). I work as a video game artist and this is a very useful (and probably unintentional) feature in 3ds max I use for cleaning meshes. This mode makes it super easy to spot overlapping polygons and non welded vertices.
Basically if you are in xray mode with backface culling set to on, if you look through the model at the interior, if you see edges or vertices, that means there's a problem since a clean mesh would simply be hidden by the backface culling.
Is there an alternative to this in Blender ?
I would want to see someday in BGE tools to creating Multiplayer games ;)
I would like to see Freestyle Rendering in the next release.
I know that having a two-month release cycle is working out fairly well so far, but I've always thought that maybe a three-month would be better for the developing and testing aspects, as is the case here... and no, I don't have any programming knowledge whatsoever :P
Anyway, sounds like some great features are on the way! The tile-based compositing tools look especially awesome :D GO DEVS!
I think the two months cycle works very good, and if more time is needed it can be easily extended like the coming release.
Personally I find the two month cycle a nice idea in theory (get features to users faster) but like you say, it leads to problems with testing and quality. You'll notice most proprietary software has release cycles anywhere from 1 year to 4+ years. A lot of that time is spent testing; and not just your little "oh, yep it works" sort of tests; not if they're good. If they're good, they test it in every screw ball way they can come up with with the sole goal of trying to break the software. But that kind of testing takes time an man power.
Short cycles also lead to the somewhat subtle "problem" of instability. By that I don't mean instability in a runtime/programming sense (although that can happen too), I mean from the perspective of the user. With short release cycles, the software is always changing and the user hardly gets a chance to use the current version before a new version shows up and then there's pressure to update. For example, since the tracker was introduced in 2.61 we've seen major updates every version since. And as I recall 2.64 is going to represent a complete rework of the tracker, again. This means that people have to re-learn how to use the tracker, even if they're just small changes it's still a significant usability impediment.
Short cycles also kill any notion of bug fixes; devs are completely focused on the next version so the answer to most bugs is "get the latest version" or "wait for the next version" and again enter update pressure. Well what if you're 6 months into a huge project and can't just "update"; what if you're dependent on some quirk in a previous version but need a bug fixed. Short cycles also tend to kill backwards compatability. Bender is pretty good about this except in the scripting front where the API changes regularly.
So, yeah, short cycles tend to present some problems for large, complex software. At least that's what I think.
I think at the moment 2 months cycles is good because it is giving motivation to the team to get long term projects that been sitting on the shelf forever out to the public.
Perhaps Blender foundation could release a yearly version that is only updated with major features once a year but will get all of the bug fixes. Like Mozilla has done with Firefox.
There should be more BGE stuff... Harmony guy has some good stuff.
I like the two month release cycle. Though comments by other posts here do have points to the issues associated with that. I would like to see a full release like 2.65 be nothing but bug fixes and optimisations. And do something like that every .05 release. or every .03 release. That would allow a lot of new features and enough time to also do bug fixes.
What ever the decision will be, I'm just happy about both the community as well as the blender nerds who make Blender possible. That includes you Ton :P
I think we need some motivating small things for users those are involved in bug searching process. Make some ratings of this :) I think that if a guy/girl not just found a bug but also pointed exactly on it's true conditions (so it will be really easy to find and fix in code), then it MUST be noted as a little achievement (some points or "bug-heads", "bug-legs" or something funny and motivating).
After the every release the best bug seeker (or fixer if a man also provides patches) could be rewarded. Not something expensive... But memorable :) Maybe - tickets to Netherlands and a dinner with Blender team (1-2 days enough I think), a little room in Blender Institute to live in (I think it's much cooler than a hotel or hostel). Some cool t-shirts (with funny stories about bugz or something... by people's best choice), cool 3d-printed models.... Here can be a lot of stuff to reward 2nd and 3rd places.
I'm thinking about this because I see often that people report bugs with laziness, not with courage. This cause to delay developers those (usually) explain things with details even if it's not a bug. It's not bad but eats time. It's opposite to bug-hunting (IMHO).
P.S. I like to spent some time with bug-hunting (although I'm not a coder)... it's a geek way but it's funny sometimes :)
I love it how whenever you see these developer meeting notes get posted, some folks start making a request line out of it.