[Bf-committers] 2.36 release wednesday! (irc meeting minutes dec 19)
Ton Roosendaal
ton at blender.org
Sun Dec 19 21:04:33 CET 2004
Hi all,
After trying again to disect the exact error with the game engine, and
evaluating a Linux testing build from Kester (which behaved better but
still crashed conveyor after a while), we found the following possible
scenarios to continue;
- Only release test build RC3 this week and wait for a fix to come in
- Or release 2.36 asap
- without game engine
- with engine, but engine checkout of dec 4
- with game engine of current CVS
The main reason for a release is to make CVS open for new development
again. Not to mention we have a buggy 2.35 on our site now, and it's
about time to present the work as was done the past 5 weeks.
With 2.36 presented as a bug-fix release, releasing current CVS isn't
an option. That's what everyone agreed on. Tests done with the 4
december engine show it's stable, although physics got faster thanks to
later commits.
Postponing the release until after tuesday will conflict with holidays
(xmas) and new year (I'm away from dec 28 to jan 2). What also counts
is that Kester doesn't seem to have time available now.
Opinions in the meeting varied... so I took the liberty to cut the knot:
- wednesday release (tuesday release AHOY with splash + release code
commit)
- game engine (only source/gameengine/) will be based on cvs of
december 4, unless Kester or someone will can solve the current
issue(s).
- a couple of days later we can open CVS again
Release builders Simon (Windows), Yann (linux) and Jean-Luc (OSX)
agreed on it, and are standby. Hopefully Chris can be aroud for the CVS
tag and Irix build? Kent, for solaris? Hans, FreeBSD?
With Kester we then can use the period up to 2.37 to get the engine
issues sorted out. Such work just takes its time, but is no showstopper
to block release.
----------
New projects:
- the animation system cleanup. Armatures, displists, vertextroups,
constraints...
(No actual work done, still need to do lots of reading. Many good ideas
and proposals stream in!)
- Softbody support (Jens Ole)
Is ready to start being integrated in main tree
- Dependency Graph (Jean-Luc)
First tests promising, work will continue. Is very related to the
animation system.
- Parallax texture mapping
Discussed on list here, will be checked on later, but before 2.37!
- Yafray & Aqsis
Alfredo agrees on that's worth checking on the current integration
code to be re-used by others. We need to start a discussion on that
topic soon.
He also proposed to add 'real physical' light support (as option) in
Blender, to make it easier for people to use Blender for testing
lighting setups. Proposal will follow.
And, as inbetween pet project, I've further worked on cleanup of the
render code. Parts of it was done for 2.32 (allowing raytracing). The
current cleanup will:
- remove more globals from code (like ugly ones in texture.c)
- further merge code used by both unified and normal rendering, to
solve weird differences and errors (like alpha, halos and sky)
- make both render systems delivering true 4x32 bits RGBA, also
internally (removing old 'fast' conventions with chars and shorts makes
it faster even!)
- allow multithread render (with SDL). (got dual cpu here, goes great!)
- remove abuse of rendercode variables in Blender itself (= make it
nicer API)
Especially making the code threading safe uncovered quite some nasty
issues. The cleaner code (no globals, no static variables) actually
benefited the complete render system, also in speed.
-Ton-
------------------------------------------------------------------------
--
Ton Roosendaal Blender Foundation ton at blender.org
http://www.blender.org
More information about the Bf-committers
mailing list