[Bf-committers] Blender 2.5+ Roadmap (Proposal)

[Kent Mein]

In reply to Michel Selten (michel.s@home.nl):

Great to get the ball rolling on this :)

First off I think we all agree that yes modularizing components of blender 
will make things nicer for developers.  Some places it was already done:
image formats, anim formats, texture, postprocessing(sequencer), GUI(GHOST).

I think your missing a key component of modulaization, the whole point
of modules is that you create an interface and don't worry about the format of
the data.  Modularization means you don't need to decide on blend vs xml vs
3ds etc. You don't have to use png, or gif etc.
You don't have to force your developers to use python or c++ or c.  
The last one may be a little too far but I don't think so, look at the
gimp for example, we should be making it easyer for developers to work with
stuff that is the whole issue with blender currently right?

What we need to work on is what is going to be the core of blender, and 
how are the various modules going to talk to the core.
Translation: What are the basic data blocks blender is going to work with
, how do you talk to them, and can you make it so that these things are 
extesable(both the datatypes and how you talk to them).
We have this happening on multiple layers so things are quite complicated.
Basic blocks I can think of:
You have the 2ddata   (image,animation data)
You have the 3ddata     objecttypes and their properties.
Material data           This may be considered part of 3ddata but I think
        its large enough to seperate it, you could probably argue the same
        with all of these.
You have animation data like ipos.
Converting 3d -> 2d. (rendering, maybe would be cool to do other way
around as well)

A good place to start would be breaking it down like the the windows do,
and make sure its easy and well documented how to add a new window type
and or subtype.   A subtype might be new rendering interface.

To scale the talk back each component needs to have generic functions
written that we want to support.  And a well documented way to add
a new system.  For an example of this look at the current SoundSystem
in the intern directory.  If we look at SND_C-api.h we see the
functions a new sound system would need to implement.

I'd also like to add that I think we should shoot high.  We can
support 64bit color in blender so we should, and also hopefully
make it upgradeable in the future.

If we standardize this so all modules have similar interfaces the
source will be a lot easier to deal with and if we have are modules
planed out correctly it will be a lot easier to find things in the source.

I'm not saying we can't start small but I think getting the general structure
we want down would be a good idea.

Kent Mein
--
mein@cs.umn.edu