[Bf-funboard] Genetic Algorithm approach
alainlioret at wanadoo.fr
Fri Mar 13 19:48:42 CET 2009
Hey, Wonderful !
Have you read my presentation at Blender Conf 2008 ?
(see http://www.blender.org/community/blender-conference/proceedings/ my PDF about :
Alain Lioret: An Artificial Intelligence Nodes module inside Blender for expert modeling, texturing, animating and rendering.
> Message du 13/03/09 16:50
> De : jgray at grayengineers.com
> A : bf-funboard at blender.org
> Copie à :
> Objet : [Bf-funboard] Genetic Algorithm approach
> 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?
> Bf-funboard mailing list
> Bf-funboard at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-funboard