 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Winter is coming. It's a good time for a group project.
Is there anybody who would be interested to participate
in developing the most advanced plant system ever created?
Just kidding :) And now seriously.
After implementing POV-Tree program I still have a lot of
ideas for plant generating system which are not there. I
think only now I understand how it should look like :) Some
of those ideas I cannot implement myself just because I don't
have enough knowledge in that area. The others are just too big
for one person etc.
I guess you also have many ideas but never had a time
or knowledge to implement it.
So, the idea is to develop POV-Ray oriented plant system
which could cover all or almost all plants - real and
imaginative. It could include generators for grass, flowers,
bushes, trees. It could also include different plants
distribution algoritms/scripts.
All that development we could make on dedicated web-site
which could keep some kind of forum for sharing ideas
and code plus gallery for displaying the results of that
development. It could also have repository for scripts,
textures, ready-to-use models.
So, if you are interested in such development and if you
have good knowledge in POV-Ray scripting, trigonometry,
splines, advanced 3D algoritms let me know just replying
to this message in this forum and we will discuss details.
Even if you don't have any mentioned skills but have a
patience to scan a lot of high-resolution leaves textures
or can write a good documentation you are also welcomed :)
The project is POV-Ray oriented (scripts and only scripts)
and is not commercial. Probably later on we can think
about some kind of GUI.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 05 Nov 2005 04:30:32 -0500, Gena wrote:
> So, the idea is to develop POV-Ray oriented plant system which could cover
> all or almost all plants - real and imaginative. It could include
> generators for grass, flowers, bushes, trees. It could also include
> different plants distribution algoritms/scripts.
>
<snip>
> The project is POV-Ray oriented (scripts and only scripts) and is not
> commercial. Probably later on we can think about some kind of GUI.
Sorry for late reply.
Would that Plant system also include
- animation i.e. grow plant on arbitrary object
- react on external parameters i.e. sunlight, wind, gravity
Willem
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Gena.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gena wrote:
> Willem de Wilde <wil### [at] nomailcom> 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
|
|
| |
| |
|
|
|
|
| |
