[Bf-funboard] Genetic Algorithm approach

jgray at grayengineers.com jgray at grayengineers.com
Fri Mar 13 16:50:18 CET 2009

See also:  http://www.blenderstorm.org/qapoll/ideas/idea/846

I'm now convinced this is a good place to discuss implementation 
strategy.  If I'm wrong, please direct me.

I've already started implementation, and hope to finish most of it with 
little or no disturbance to on-going work.

I have several critical design decisions already:

1) I've already decided to add a new window type, Genetic Algorithm, 
alongside 3D View, Outliner, etc.  I can put in a few weeks here before 
I need to make any more decisions.  I already have the window (with a 
new icon) in a 2.44 codebase.  I plan to switch to the latest 2.50 
19272 I just got.  Should I just wait till 2.50 is done?

2) How to implement a Gene.  I think I have this conceptualized well 
enough.  I intend to describe almost all GA types (texture, field, car, 
town) with a very generic data structure.  The idea is that to add a 
new type, someone should be able to add to an already defined struct 
ga_types[] list of types without any real code.  My question is:  would 
it be acceptable for me to use C++?  (I don't mind sticking with C, but 
want a lot of function pointers.)

3) Modifier or Container (the big question).  In many ways, it makes 
sense for a GA to be a modifier to an object; a plane would be modified 
with a GA/field or a cylinder with a GA/tree.  On the other hand, it 
also makes sense to make a group/container object; when converting a 
plane to a GA, the GA would generate completely new OBjects to replace 
the plane; while in progress, the GA would 'contain' the original and 
all variants, but display only the selected one.

The modifier approach seems difficult for textures, too.  I really 
don't want the approach to be drastically different between textures & 
surfaces.  My plan for textures was to select one or more objects, then 
hit a 'Texture with GA' button.  Each selected object would be linked 
to a new texture.  A new empty OBject would also be linked to the new 
texture (other empty OBjects would link to candidate textures).  The GA 
would contain the new empty object(s) and (indirectly) the published 
texture (and all other candidates).

I understand that 'contain' is probably a poor description since the 
database isn't exactly hierarchical.  It would be more accurate to say 
'reference', but the 'referenced' objects would have their 
visible/selectable/drawable flags turned off or on by the GA.

Any preference?  Comments?

4) (may be a long time off) Whether and how to add button controls.  It 
may be useful to show the actual genes as you work.  It would help with 
debugging, but may also help when you just can't quite get the color or 
shape you want.  Genetic Engineering isn't for the novice, but might 
speed up the process.

I didn't plan to submit any code till I had enough done to be useful 
for texture generation.  Would it be better to submit incrementally?  
Perhaps with #ifdef to keep my window off the window selection menu?

More information about the Bf-funboard mailing list