[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