[Bf-committers] Meeting minutes summary March 13th 2005

Tom M letterrip at gmail.com
Mon Mar 14 23:19:28 CET 2005

1)Meeting minutes for external sites
Tom Musgrove wanted to know whether it would be acceptable to have the
meeting minutes sent to Linux Weekly News.  Ton suggested that
'Development Digests' like those that were done on a monthly basis by
Nathan Letwory would be more appropriate. Tom volunteered to do start
doing the development digests.

2)Requirements for getting code committed in releases
Ton felt that 'new functionality in blender all should be in CMS
before releases' and preferred it be done either the coders submitting
the new functionality, or it being the responsibility of the coders to
find someone to do the documentation.  A minimal requirement would be
a text explanation of what it does and how it works, sample images and
screen shots, and a blend file to be used for regression tests.
Martin Poirier stated that the documentation needs to be done earlier
and not at the last minute, 'so we don't wait for release docs when
code is release ready'.  Martin also requested that if possible it
would also be nice to have video demonstrations of the new
functionality in action.
For video demonstrations Tom Musgrove suggested wink for usage on windows
which can output to flash videos or png (which can then be turned into
video with blenders sequencer).
Also a brief reminder that developers who have code/projects they are
working on should either update the wiki with their projects status
or contact Chris Burt or JLuc Peuriere with the status of their code
and they will update it for you.  Python scripts do not need to be in
the project status page, however Ton emphasized that they DO need
documentation (the py-doc plus screenshots should usually be

3)Current Projects – New Transform
According to Martin Poirier the new code has about 90% of the
functionality of the old code.  Still missing are shrink/fatten, free
rotate, 'extrude by vector', and moving the camera in camera view, and
assorted api work for exposing constraints, and context. Ton will do
pose mode and dependency update related work, and cameragrab.  Ton
stated that new transform code should should now be the default
compile.  Emilie Brown will help Martin with the documentation of the
new Transform functionality.

4)Current Projects – OpenEXR
Ton stated that while supporting an open hidef image format is
desirable 'it should be properly wrapped in a C library' and that 'we
have to keep all exr dependencies external' - 'it should either work
like quicktime, or as static lib'.  For now 'OpenEXR goes back to the
drawing board, to design a good compiling lib for blender first'.

5)Current Projects – HEMesh
Joe Eager states that his HEMesh work is going well and is currently
waiting on feedback from JLuc Peuriere on what 'major rewrites' will
be needed.  Ton queried whether it was ready for conclusion in
tuhopuu.  It was decided that JLuc will review the code this week and
then a decision on suitability for inclusion on tuhopuu will be made
at the next meeting.

6)Bug Tracker
It was noted that the majority of bug reports in the tracker (or that
have been moved to a separate tracker) fall in three categories 1)
OpenGL compatibility issues with video accelerator cards both on Linux
and Windows 2) Game Engine 3) Python

Python – not much was said regarding the python bug count other than
it is of concern to Ton.

OpenGL - For OpenGL issues there is a need for individuals who are
capable in OpenGL and who have access to the cards that have problems
(ATI on Windows and Linux).  Ton stated that OpenGL is 'easy'.  Martin
Poirier has the OpenGL Redbook on his Amazon.com wishlist (it was
pointed out that it can be downloaded in PDF or html format here -
http://www.opengl.org/documentation/red_book_1.0/ )
Christ Burt and Emilie Brown will try learning OpenGL to try and
contribute in that respect, but other developers are strongly
encouraged to do so.  (Ton claims it is easier to learn and use than
python.  Also Blender only uses widely supported OpenGL so just
version 1.2 of the API is sufficient)

Game Engine- There is really only one active developer of the game
engine, Kester Maddock, and a single part time developer is not
sufficient to maintain the game engine.  A number of suggestions were
made about 'what to do about the game engine problem'.  Suggestions
ranged from – issue a call for developers, to temporary removal, to
complete removal, to potentially integrating a different open source
engine.  Jens Ole Wund noted that 'i don't see much difference between
a good physics driven animation system and a game engine'.  Ton
believes that Kester needs to be consulted before any decision is
If separation does happen, sufficient code for doing things like
walkthroughs will be kept in the main blender tree.

More information about the Bf-committers mailing list