Christoph Hormann wrote:
> I don't understand why it is more difficult to compile a patched POV-Ray 
> than compiling an imaginary 'plug-in'.

In case of plug-in you should know just a plug-in subset of the whole 
API. In case of patch you should learn the whole API and define where
to fit your piece. In case of plug-in you are in sandbox, you still
can destroy the functionality of the whole program but IMHO you have
less changes than in case of patch :)

> Sure.  There is an internal plant generator that generates a mesh 
> object.  There is a SDL interface to this which can be used to define 
> the plant system rules that are interpreted by the plant system.  In 
> terms of language syntax it would be a new shape which behaves exactly 
> like a mesh.  The rules could be given with classical L-System strings 

> set of macros could be created that generates common plant shapes with a 
> limited set of adjustable parameters.

Got you. You are talking about custom patch. Of course it will work but
how many people can write POV-Ray patch? :) I would still prefer don't
touch POV-Ray itself. In your scenario you use only mesh generator from
POV-Ray the rest is patch itself. As you mentioned already mesh
generation is not big deal. So the whole functionality can be
freely implemented outside of POV-Ray.

L-Systems, rules based systems are good to a certain extent. But when
you need the whole control of the geometry it doesn't work. For example
it doesn't work when you need the trunk pass through particular
coordinates <0, 1, 0.3> etc. IMHO the best approach is a combination of 
automatic generation and ability to manualy adjust all geometric
parameters. The system which we are talking about could allow that.

Gena.

Post a reply to this message