Wolfgang Draxinger wrote:
> I'm currently developing vegetation creation scripts for the
> Blender 3D modelling software. The first attempts work nice, but
> they're far to inflexible IMHO.
>
> First let me introduce how the system works: The user supplies a
> series of building elements of the plants to be generated (e.g.
> stem, stipe, leaf, branches, blossom) and associated those with
> template 3D models. For each of those elements there is a list,
> which elements can be attached with the current element, and a
> probability function, that takes the various parameters for the
> element to be constructed (distance to the last branch, distance
> to the root, thickness of the last stipe, how much light is
> there). Then a pseudo random generator chooses one of the given
> elements with the given probability, the element is aligned to
> various physical conditions (gravity, light direction). It is
> important, that the tree is constructed with a equal distance to
> the root, i.e. not whole branches and subbranches at a time, but
> first branching level 0, then level 1 and so on. The reason is,
> that with every construction level some of the environment
> condictions (weight of the material, amount of light) change, so
> it's reasonable, that the grow process of the virtual plant
> resembles the real one, even if it's a simplified modell.
>
> Now one cool thing would be, if one could use python to describe
> the plant model itself, too.
>
> Since the Elements are not to be instanciated, but a collection
> of parameters and functions that are fed with the environment
> variables.
>
> class Branch(BasicPlantElement):
> def p():
> return light_scale * light()**light_exponent *
> k/distance_to_root()
> def geom():
> return (light_track * light_vector() - weight() * gravity(),
> position())
>
> But obviously this is not valid python (it lacks the self
> argument). One might now think of a dictionary
>
> Branch = { "p"=lambda:..., "geom"=lambda:..., }
>
> If you look closely, you also see, that the functions are not
> prameterized. Instead, they use some global scope functions.
> Here the idea is, that the environment parameters are put on a
> stack and each recursion copies the topmost element on the stack
> and changes happening there are carried on the stack. But this
> is of course very memory consuming. But the real problem is, to
> bring those values somehow into the scope of the PED (Plant
> Element Descriptor)
>
> Now the challenge:
> - I'd like to write the Plant Element Descriptors in a
> class/member like notation, but don't instanciate it - not
> directly at least. Eventually there will be factory functions,
> that take a PED and create a reparameterized version of it.
> - Calling the functions in the PED somehow needs to bring the
> branching stack into the scope. I have no idea how to do that.
>
> Of course all this might not be possible directly, but that would
> then mean, that I can't use python to describe plants, but have
> to invent a custom language for that then. (Something like POV
> Scene Description Language or similair).
Let me see if I understand:
You have a bunch of physical parameters (gravity, light
direction,etc.).
Every time you recurse to a deeper level, all these physical parameters
change (I suppose because there's a transformation of coordinates).
When creating a new Branch, using some data called Element as a kind of
template, you want to first update the parameters to their new values,
then use those parameters to create a new Branch. And you hope that
you can do both things (update parameters, generate branch) with a
single class. How close am I?
You're doing this recursively, so there's really no way to get rid of
the stack entirely. I don't know much about your code, but I quite
doubt that it would put much strain your memory at all.
We can, perhaps, help you organize your code better, though. But I
think you'll need to make another pass at describing your problem.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
