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

Gena wrote:
> 
>>- 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?
> 

With interaction i mean interaction with the scene geometry - a tree 
being limited by a house, a plant growing on a wall etc.

POV-Ray features that can be used could for example be the use of 
patterns to control leaf properties.

> 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? :)

I don't know much about the Tomtree inner workings but I think all SDL 
based systems available are rule based with a fixed set of rules with 
various parameters that can be set.

Rule based simply means that the plant is generated using a set of 
recursive drawing rules.  Of course any mesh could theoretically be 
translated back into a set of mesh generation rules.  So it only makes 
sense to speak of a rule based plant generator if at least some of the 
rules are generic, meaning they are used multiple times in the tree 
generation process.  For example you could have one rule that generates 
all first level branches of a tree (which might contain random elements 
so not all branches are identical).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

> With interaction i mean interaction with the scene geometry - a tree
> being limited by a house, a plant growing on a wall etc.
>
> POV-Ray features that can be used could for example be the use of
> patterns to control leaf properties.

That makes sense. I don't know POV-Ray inner architecture
but I think in case of geometry you have to touch many
places in order to make such patch. Maybe it's time to
start learning it :)

I also kept pattern-based logic in mind. That was partially
the reason for SDL :) For example pattern-based distribution,
pattern-based bark etc.

Just to recap our long discussion.
You convinced me that SDL is not so good for coding any advanced
systems :)

Regarding patch or stand-alone I would prefer the latter one. I
understand that you sacrifice all those advantages which POV-Ray
gives you for free. But in return you get freedom to make your
own design/architecture which doesn't depend on POV-Ray design,
freedom in language. Also you don't depend on POV-Ray's development
cycle in particular on version number - after any changes in POV-Ray
you don't have to change your program to be in sync.

How about traditional command-line C++ (or Java) program which
takes properties file as input and generates mesh2 as its output?

Gena.

Post a reply to this message