Can, and if yes how could this be done elegant?

Discussion in 'Python' started by Wolfgang Draxinger, Aug 22, 2006.

  1. 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).

    Wolfgang Draxinger
    --
    E-Mail address works, Jabber: , ICQ: 134682867
    GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E
    Wolfgang Draxinger, Aug 22, 2006
    #1
    1. Advertising

  2. Wolfgang Draxinger

    Carl Banks Guest

    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
    Carl Banks, Aug 22, 2006
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven T. Hatton
    Replies:
    9
    Views:
    451
    Steven T. Hatton
    Jun 5, 2004
  2. teo
    Replies:
    3
    Views:
    511
  3. Florian Wollenschein

    Code - what could be done better?

    Florian Wollenschein, May 9, 2009, in forum: Python
    Replies:
    1
    Views:
    267
    Bruno Desthuilliers
    May 11, 2009
  4. Jamie Herre
    Replies:
    1
    Views:
    167
    why the lucky stiff
    Jan 7, 2005
  5. Zhidian Du
    Replies:
    0
    Views:
    130
    Zhidian Du
    Feb 21, 2004
Loading...

Share This Page