Christoph Hormann <chr### [at] gmxde> wrote:
> This is a fallacy, to link a new feature dynamically to the program
> won't give you any technical advantage.  And whatever API you are
> talking about this is no different when implementing a new feature in
> POV-Ray than as a separate module.

If you don't mind let's stop this branch of discussion because it's
too global question and doesn't fit to our subject :)

> - to be able to make the plant generation interact with the rest of the
> scene.
> - to be able to use other POV-Ray features in the plant generation process.

Could you clarify?

> Thinking a bit about it a well designed modular plant generator might be
> possible to work both as a POV-Ray patch (offering the above advantages)
> and outside (without those options).  This would probably not make the
> implementation easier but it would at least force a clean design. ;-)

I prefer the latter more because I still don't see (maybe after your
clarifications) the advantages of having it inside except the need to
parse mesh file.

> This is not made impossible by a rule based plant generator.  The rules
> just have to force such constraints.  In fact i think rules are the only
> feasible possibility for geometry control with complex plants.

Maybe I'm just not aware of such rule based systems :(
Probably there is a need to define what we mean saying -
rule-based system. Is Tom-Tree or any other POV-Ray tree generator
a rule-based system? When you specify a set of properties for the
system do you specify the rules or not? :)

Gena.

Post a reply to this message