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