[Bf-committers] 2.50 Codebase Question

Toni Alatalo antont at kyperjokki.fi
Tue Oct 28 09:17:40 CET 2008

David Bryant kirjoitti:

a brief reply based on my dated and limited knowledge, just 'cause no 
one else has seemed to reply yet. i wasn't able to attend the conference 
this year (due to family issues up here), and am guessing the people in 
the know are still recovering from the weekend or something :p

> Question #2:
> If new feature patches continue for now to be written by those who submit 
> them, they will be compatible with the 2.4x codebase but will they be 
> compatible with 2.50 so as to be commited to the new codebase?

the guts of the 2.50 will be the existing codebase, all the tools and 
functionality are ported from 2.4x, not rewritten. 2.50 is about the 
'framing': how the windows are set up, how mouse and keyboard events are 
handled, and how the different tools in Blender can register to the 
application and get hooked to display and control things, and how those 
different parts communicate internally (the event system).

so the answer to this question is that features that work in 2.4x don't 
automatically work in 2.50 but need to be ported to the new system, but 
that is true to i guess basically all the tools in Blender, and am also 
betting that changing the UI things  for a tool is not typically a huge 
job. so if you write something useful for 2.4x now it can be ported over 
like everything else.

> All other packages uses shader attributes that acts on a material index 
> instead of compositing channels in a post render sequencer fix (as Blender 
> does now). It's much faster and targets a specific material index (you can

so based on what i know, the 2.50 refactor is not at all about 
compositing, and i'd expect the internals of the compositor and of the 
nodes remain pretty much unaffected by the move from 2.4x to 2.50. am 
guessing that the compositor overall UI code and perhaps individual node 
UI codes may well change, but that is unrelated to your issue.

> I will still write it for the 2.4x codebase because I need it personally 
> but, if I submit the patch for review, will it be rejected because it wont 
> fit in with the 2.50 code API?

i'd say go ahead if it makes sense to you. i don't know the answer to 
your Q #1 about possible 2.49 etc, but in any case the differences in 
2.4x vs. 2.50 with regard to the compositing pipelines are pretty much 
irrelevant, so best to implement it in a way that enables you to start 
using it right away, i.e. in svn trunk head. (am guessing that 2.50 is 
still not functional enough to even have a compositor :)

> Maybe the developers want to stick with the current method ?

that is a totally separate question and i don't know much about 
compositing so am leaving that unanswered, but hope that clarified the 
2.50 plan a bit (and that am not totally misinformed about it based on 
what saw 6 months ago..)

> Digikiller 


More information about the Bf-committers mailing list