Some weeks ago I posted the stupid idea to let a plant grow to light by using
the mesh cam, distribution type 3, into the p.a.u. Inspired by the paper "A
Simple but Effective Algorithm to Model the Competition of Virtual Plants for
Light and Space" by William Van Haevre and Philippe Bekaert (2003). Paolo
Gibellini was so kind to give me the link to his basic L-parser. So I gave it a
try. The result is very, very, very simple, but under very lucky conditions it
works even with all the given limitations so far (e.g. a very lucky random seed
to yield only this poor result).

I have introduced a third dimension into Paolos code and some simple probalistic
rules. But the l-system is still context-free. The alphabet is still given by
simple characters, so I decided to have only 25 possible directions of growth
change. The next limitation is that I used strings to store the production as
Paolo did. Finally I found a trick to store strings longer than 256 charcters (a
limitation of #write and #read) to file and read them back again within the next
frame (see the code for details). And there are a lot of other things which can
be improved: the determination of the brightest spot could be improved (if there
are areas with similiar brightness one could choose one of them by random), With
a context-sensitive grammar one could produce realistic trees and better prune
them.

Within the following animation the walls are made of glass only for
visualisation, the mesh cam sees solid blue walls and the stems are black to the
mesh cam and not yellow. The animation is not intended to be a movie but only to
explain the idea. So please forgive the simple textures.

I worked a while with a mesh from Wings for the mesh cam but yielded strange
results. May be only due to the fact that Wings changes the x-coordinates, a
thing my brain is to stupid to compensate for sometimes. Than I created my own
mesh for the cam und suddenly all worked so much better, since I had full
control about the camera now. The mesh camera consists of a whole stem segment
(two spheres connected by an cylinder) but the uv-mapping is concentrated at the
top of the stem segment, the upper half sphere. The stem and the lower half
sphere have only very small areas in the uv-mapping and are not evaluated (upper
left corner the lower half sphere, upper right corner the cylinder). (In
difference from the baking occlusion map issue: the mesh cam can see colors now,
since there are in the scene!)

Even if the result is poor, I will give the code in the p.b.s-f since one can
get the general idea from it and may be Paolo is interested in the havoc I
wreaked to his code... Thank you again, Paolo. And one can see the mesh cam
working. The animation here is only half of the frames, the other half is done
by the mesh cam. As usual with animations run "main.ini" and not "main.pov".

This experiment was intended as a test of concept only and not as an ultimate
solution. So I'm content with it, but it could have worked out better :(

Best regards,
Michael

Post a reply to this message

Attachments:
Download 'main.mpg' (2904 KB)

"MichaelJF" <mi-### [at] t-onlinede> wrote:
> Some weeks ago I posted the stupid idea to let a plant grow to light by using
> the mesh cam, distribution type 3, into the p.a.u. Inspired by the paper "A
> Simple but Effective Algorithm to Model the Competition of Virtual Plants for
> Light and Space" by William Van Haevre and Philippe Bekaert (2003). Paolo
> Gibellini was so kind to give me the link to his basic L-parser. So I gave it a
> try. The result is very, very, very simple, but under very lucky conditions it
> works even with all the given limitations so far (e.g. a very lucky random seed
> to yield only this poor result).
>
> I have introduced a third dimension into Paolos code and some simple probalistic
> rules. But the l-system is still context-free. The alphabet is still given by
> simple characters, so I decided to have only 25 possible directions of growth
> change. The next limitation is that I used strings to store the production as
> Paolo did. Finally I found a trick to store strings longer than 256 charcters (a
> limitation of #write and #read) to file and read them back again within the next
> frame (see the code for details). And there are a lot of other things which can
> be improved: the determination of the brightest spot could be improved (if there
> are areas with similiar brightness one could choose one of them by random), With
> a context-sensitive grammar one could produce realistic trees and better prune
> them.
>
> Within the following animation the walls are made of glass only for
> visualisation, the mesh cam sees solid blue walls and the stems are black to the
> mesh cam and not yellow. The animation is not intended to be a movie but only to
> explain the idea. So please forgive the simple textures.
>
> I worked a while with a mesh from Wings for the mesh cam but yielded strange
> results. May be only due to the fact that Wings changes the x-coordinates, a
> thing my brain is to stupid to compensate for sometimes. Than I created my own
> mesh for the cam und suddenly all worked so much better, since I had full
> control about the camera now. The mesh camera consists of a whole stem segment
> (two spheres connected by an cylinder) but the uv-mapping is concentrated at the
> top of the stem segment, the upper half sphere. The stem and the lower half
> sphere have only very small areas in the uv-mapping and are not evaluated (upper
> left corner the lower half sphere, upper right corner the cylinder). (In
> difference from the baking occlusion map issue: the mesh cam can see colors now,
> since there are in the scene!)
>
> Even if the result is poor, I will give the code in the p.b.s-f since one can
> get the general idea from it and may be Paolo is interested in the havoc I
> wreaked to his code... Thank you again, Paolo. And one can see the mesh cam
> working. The animation here is only half of the frames, the other half is done
> by the mesh cam. As usual with animations run "main.ini" and not "main.pov".
>
> This experiment was intended as a test of concept only and not as an ultimate
> solution. So I'm content with it, but it could have worked out better :(
>
> Best regards,
> Michael

Sorry I did not really understand this animation stuff. Download the file to
disk and view it than. Directelly from here it doesn't work.

Best regards,
Michael

Post a reply to this message

On 1/27/2013 5:07 PM, MichaelJF wrote:
> Some weeks ago I posted the stupid idea to let a plant grow to light by using
> the mesh cam, distribution type 3, into the p.a.u. Inspired by the paper "A
> Simple but Effective Algorithm to Model the Competition of Virtual Plants for
> Light and Space" by William Van Haevre and Philippe Bekaert (2003). Paolo
> Gibellini was so kind to give me the link to his basic L-parser. So I gave it a
> try. The result is very, very, very simple, but under very lucky conditions it
> works even with all the given limitations so far (e.g. a very lucky random seed
> to yield only this poor result).
>
> I have introduced a third dimension into Paolos code and some simple probalistic
> rules. But the l-system is still context-free. The alphabet is still given by
> simple characters, so I decided to have only 25 possible directions of growth
> change. The next limitation is that I used strings to store the production as
> Paolo did. Finally I found a trick to store strings longer than 256 charcters (a
> limitation of #write and #read) to file and read them back again within the next
> frame (see the code for details). And there are a lot of other things which can
> be improved: the determination of the brightest spot could be improved (if there
> are areas with similiar brightness one could choose one of them by random), With
> a context-sensitive grammar one could produce realistic trees and better prune
> them.
>
> Within the following animation the walls are made of glass only for
> visualisation, the mesh cam sees solid blue walls and the stems are black to the
> mesh cam and not yellow. The animation is not intended to be a movie but only to
> explain the idea. So please forgive the simple textures.
>
> I worked a while with a mesh from Wings for the mesh cam but yielded strange
> results. May be only due to the fact that Wings changes the x-coordinates, a
> thing my brain is to stupid to compensate for sometimes. Than I created my own
> mesh for the cam und suddenly all worked so much better, since I had full
> control about the camera now. The mesh camera consists of a whole stem segment
> (two spheres connected by an cylinder) but the uv-mapping is concentrated at the
> top of the stem segment, the upper half sphere. The stem and the lower half
> sphere have only very small areas in the uv-mapping and are not evaluated (upper
> left corner the lower half sphere, upper right corner the cylinder). (In
> difference from the baking occlusion map issue: the mesh cam can see colors now,
> since there are in the scene!)
>
> Even if the result is poor, I will give the code in the p.b.s-f since one can
> get the general idea from it and may be Paolo is interested in the havoc I
> wreaked to his code... Thank you again, Paolo. And one can see the mesh cam
> working. The animation here is only half of the frames, the other half is done
> by the mesh cam. As usual with animations run "main.ini" and not "main.pov".
>
> This experiment was intended as a test of concept only and not as an ultimate
> solution. So I'm content with it, but it could have worked out better :(

Some tips:

* The rotation speed is too fast until the end, when it slows down.
* The blue structure is distracting.
* The checkered texture is probably making your MPEG files bigger than 
they need to be.  I'd recommend a neutral-colored plane with a faint 
granite normal pattern.

Regards,
John

Post a reply to this message

Am 28.01.2013 00:07, schrieb MichaelJF:

> This experiment was intended as a test of concept only and not as an ultimate
> solution. So I'm content with it, but it could have worked out better :(

Looks promising enough to me...

Post a reply to this message

> Some tips:
>
> * The rotation speed is too fast until the end, when it slows down.
> * The blue structure is distracting.
> * The checkered texture is probably making your MPEG files bigger than
> they need to be.  I'd recommend a neutral-colored plane with a faint
> granite normal pattern.
>
> Regards,
> John

Thanks for the hints. Yes I'm not content with the blue structure but I wanted
to visualise the obstacle the plant has to go round. May be Thomas's proposal to
avoid the rotation and a good camera position would be better. This would most
likely reduce the file size too. In such a scene a checkered plane is a must
have ;-)

Best regards,
Michael

Post a reply to this message

>MichaelJF  on date 28/01/2013 0.07 wrote:

> Even if the result is poor, I will give the code in the p.b.s-f since one can
> get the general idea from it and may be Paolo is interested in the havoc I
> wreaked to his code... Thank you again, Paolo. And one can see the mesh cam
> working. The animation here is only half of the frames, the other half is done
> by the mesh cam. As usual with animations run "main.ini" and not "main.pov".
>
> This experiment was intended as a test of concept only and not as an ultimate
> solution. So I'm content with it, but it could have worked out better :(
>
> Best regards,
> Michael
>
Starting from my poor work it's an impressive result.
I'm not very familiar with animations, but I will surely get a look to 
your code.
;-)
Paolo

Post a reply to this message

Paolo Gibellini <p.g### [at] gmailcom> wrote:

> Starting from my poor work it's an impressive result.
> I'm not very familiar with animations, but I will surely get a look to
> your code.
> ;-)
> Paolo

I must contradict you. Your work isn't poor. It's the first implementation of a
L-System with POV and L-Systems are a very complicated issue. You did a great
job here. I never have came up with my extensions to your code having not seeing
it.

Best regards,
Michael

Post a reply to this message