 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gena wrote:
> Willem de Wilde <wil### [at] nomail com> wrote:
>
>>Would that Plant system also include
>>- animation i.e. grow plant on arbitrary object
>>- react on external parameters i.e. sunlight, wind, gravity
>
>
> Why not. Unfortunately I don't see too much interest
> in such project. It's difficult to do the project of
> such scope alone.
I somehow forgot to post a reply to this although i really intended to.
I did various attempts for plant generation systems myself in the past
and based on that a few notes:
- the most difficult thing is to find a compromise between universality
and quality of the results. A plant system that can generate any kind
of plants will be extremely difficult to design for good results in all
situations. Example: joints between branches in a tree. This is a
weak spot of a lot of growth systems (also xfrog for example). It is
quite possible to create a system generating good looking joints for any
configuration of a single branching (where one branch splits into two).
In an universal system this however will not be sufficient - you will
have to be able to generate joints with a larger number of branches as well.
- script based plant systems are quite straight away and nice to use,
you can implement interaction of the growth with the environment quite
easily as well. But they have one extremely weak point: They are slow.
A plant is often a very complex object and a script based plant
generator is slow in two ways: First of all the generation algorithm is
implemented in slow interpreted code and second the generated plant has
to be parsed in text form after that which takes time as well. I tried
it and a plant generator integrated into POV-Ray can be faster than
parsing the plant mesh alone.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
At last, some interest :)
Christoph, I agree with almost all your comments.
> - the most difficult thing is to find a compromise between universality
> and quality of the results...
It can be a sequential process. So that complexity will be added
step by step. The problem is to predict further improvements and
make development keeping it in mind so that in the future you won't
rewrite everything from scratch :)
> - script based plant systems are quite straight away and nice to use,
> you can implement interaction of the growth with the environment quite
> easily as well. But they have one extremely weak point: They are slow.
It's obvious. But I think you'll agree that when you have a solid
algoritms and data models in place it's just one step to its
implementation in any other language. One example - Tom-Tree and
POV-Tree. Scripting language is more convinient as a starting point
for prototyping, as a proof of concept.
> to be parsed in text form after that which takes time as well. I tried
> it and a plant generator integrated into POV-Ray can be faster than
> parsing the plant mesh alone.
This is ideal variant. Unfortunately POV-Ray doesn't have plug-in
structure. Otherwise it could be just 'plant' plug-in. Right now
you have to write patch in C (or C++ ?) which is less common than
POV-Ray scripting for the majority of POV-Ray users.
So, if there is any interest I could share the main ideas for discussion.
Gena.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gena wrote:
>
> It's obvious. But I think you'll agree that when you have a solid
> algoritms and data models in place it's just one step to its
> implementation in any other language. One example - Tom-Tree and
> POV-Tree. Scripting language is more convinient as a starting point
> for prototyping, as a proof of concept.
No, i don't agree here. You are seriously limited in what techniques
you can use when implementing a plant system in SDL. Most part of
developing a plant generator is not the code generating the actual mesh
but the underlying stuff generating the plant structure. Making this
both flexible and intuitive to use at the same time is the real
challenge and quite impossible with the limited means of the SDL.
>>to be parsed in text form after that which takes time as well. I tried
>>it and a plant generator integrated into POV-Ray can be faster than
>>parsing the plant mesh alone.
>
>
> This is ideal variant. Unfortunately POV-Ray doesn't have plug-in
> structure. Otherwise it could be just 'plant' plug-in.
Oh come on - what is this talk about 'plug-ins' about? What do they
make possible that is not possible right now?
> Right now
> you have to write patch in C (or C++ ?) which is less common than
> POV-Ray scripting for the majority of POV-Ray users.
Well - the idea of a patch is not to have the user code in C to use it.
The best approach IMO is to have a fairly low level interface to SDL
that allows very flexible use but have the actual plant generation
internally for good performance.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> No, i don't agree here. You are seriously limited in what techniques
> you can use when implementing a plant system in SDL. Most part of
> developing a plant generator is not the code generating the actual mesh
> but the underlying stuff generating the plant structure. Making this
> both flexible and intuitive to use at the same time is the real
> challenge and quite impossible with the limited means of the SDL.
But there are several different tree system implemented already in SDL :)
I think that currently available SDL features would be enough. I don't
state that SDL is ideal for this purpose. The idea of using SDL is just
to attract more developers from POV-Ray community. I can talk many
languages and if there are people who are interested and can talk C++ or
Java we can use it instead of SDL :)
> Oh come on - what is this talk about 'plug-ins' about? What do they
> make possible that is not possible right now?
I meant that now you have to write patch and recompile the whole
program rather than just write plug-in for it.
> Well - the idea of a patch is not to have the user code in C to use it.
> The best approach IMO is to have a fairly low level interface to SDL
> that allows very flexible use but have the actual plant generation
> internally for good performance.
Could you clarify what you mean?
Gena.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gena wrote:
>>No, i don't agree here. You are seriously limited in what techniques
>>you can use when implementing a plant system in SDL. Most part of
>>developing a plant generator is not the code generating the actual mesh
>>but the underlying stuff generating the plant structure. Making this
>>both flexible and intuitive to use at the same time is the real
>>challenge and quite impossible with the limited means of the SDL.
>
>
> But there are several different tree system implemented already in SDL :)
> I think that currently available SDL features would be enough.
That's not the question, of course you can in theory implement anything
in SDL. But i doubt anyone will really write an universal plant system
in SDL let alone maintain it.
The currently existing SDL based plant generators are quite simple and
quite specialized. For a really universal plant system you need to be
able to not just adjust parameters of a fixed growth algorithm but must
be able to define the growth rules themselves. Advanced things like
self collision detection would be extremely ugly and slow with the
current SDL.
>
> I meant that now you have to write patch and recompile the whole
> program rather than just write plug-in for it.
I don't understand why it is more difficult to compile a patched POV-Ray
than compiling an imaginary 'plug-in'.
>>Well - the idea of a patch is not to have the user code in C to use it.
>> The best approach IMO is to have a fairly low level interface to SDL
>>that allows very flexible use but have the actual plant generation
>>internally for good performance.
>
> Could you clarify what you mean?
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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gena wrote:
>
> 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 :)
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.
>
> Got you. You are talking about custom patch.
I was talking about this all the time - as said i consider the
possibilities for SDL based plant generators as very limited.
> 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.
Of course it can. And the second possibility after a POV-Ray patch is a
separate program. The main reasons for implementing a plant generator
in POV-Ray and not in a separate program would be:
- to avoid the need to parse the resulting mesh. Note while this is an
important point it is much smaller than the difference in performance
between parsing a plain mesh and generating it with an SDL based plant
generator.
- 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.
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. ;-)
> 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.
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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
