Well! I agree that having trees grow over time would be much better, and much more interesting to me as well.
Let me describe briefly how the day-to-day growth worked in my previous simulation (PlantStudio) and we will see if you have any ideas (or horrors) in response.
Each plant shepherds a collection of recursively linked objects, of these types.
-
Internodes are segments of stem between the nodes where leaves come out. They photosynthesize a little, if they are not woody. On trees they would be woody of course, though you could also have giant bendy plants which would be cool (maybe catapult plants that would fling you...)
-
Meristems are buds. They build the whole rest of the plant, like plant part factories. They can be apical (at the end, or apex, of a stem) or axillary (in the axil, or leaf angle, between and leaf and the stem). Apical buds produce a hormone that inhibits the growth of axillary buds (unless you snip them off, of course, or set a parameter to do that). Plants are often divided into those where two axillary meristems appear per internode (opposite) or one (alternate). There are also whorled leaves (more than two per internode), and some other niceties I forget that create an array of shapes.
-
Leaves photosynthesize a lot, but they also respire, so they both provide and require energy. They wilt when water is scarce. If things get really bad they fall off (absciss).
-
Inflorescences are like internodes but they hold up flowers and fruit. They may photosynthesize a little bit. They have a lot of funky branching patterns, from sunflowers to Queen Anne's lace to I don't know what.
-
Flowers are reproductive organs that turn into
fruits. I did not model these as separate objects, just objects that change state, though I can't remember at the moment if I regretted this later. Flowers and fruits demand a lot of energy (fruits more than flowers), and when it is the right time they take precedence over all other demands. A plant can have bisexual flowers, or it can have separate male and female flowers (you need this for things like corn and pine trees), or it can be an entirely male or female plant.
Each day, the plant essentially asks each of its constituent parts how much energy it wants, then allocates the available energy to the parts according to parameters that determine whose demands get the most attention. The individual plant parts then do things, like grow, or in the case of meristems, produce new plant parts, if the energy they got is sufficient. The plant also asks who has any energy to provide, and the leaves pony up some photosynthate. The allocation algorithm is meant to simulate the flow of xylem and phloem that carries photosynthate (and water and minerals) throughout the plant. I did not simulate roots before, but by definition there would be a root meristem and a root internode, and the water and minerals could move in the same way as the photosynthate. Also changing the model to a tree rather than an herbaceous plant is not a big deal: it's the same basic system.
Translating this to a voxel world creates a few challenges. First there is the issue of what maps to what. You would still have meristems and internodes. You could easily have a parameter for whether buds show as blocks or are too small to show. Internodes are fairly simple lines, even if they do crazy things like have internal bulb-shaped hollows or get really fat or tall or curve wildly or have ladders inside. All leaf axils would have to be 90 degrees (rather than the staggering variation in reality), but that's okay. Leaves could still have petioles (leaf stalks) though they would have to be uniformly one block wide. One leaf would become a block of leaves, or leaf-matter-stuff. I guess the trick would be to figure out how to produce the
shapes of leaves. It would be boring to make each generated "leaf" be only one block, because a lot of the parameter variation (and random variation) would be in the shapes of things beyond just the basic branching structure. For example if the leaves were to hang down like a weeping willow, that would be in the leaf shape specification (though probably also in the branches). In PlantStudio I used a "3D object" made of polygons to draw the leaves, flowers, fruits and buds (and one could build these in something like Blender and import them, thus creating teapot plants, hat plants and so on). Figuring out how to translate this to voxel shape specifications would be interesting....
The other issue is one of storage and data integrity. The structure of the plant - the information each plant part requires to make decisions about growing - needs to be kept in some way, and kept up to date. For example each plant part needs to know things like how old it is, how much energy it needs (and for leaves, has to provide), how much biomass it has (alive and dead), its gender (important for flowers), and so on. This information has to be stored from one day to the next in order for the plant to grow in a coherent way. Structural information is entirely separate from the visual depiction of the plant parts: the voxels. In fact part of the challenge is to make sure the voxels match up with the plant model information. The relationship is one-way: you can redraw the voxels from the plant parts, but you cannot regenerate the plant parts from the voxels. So if somebody walked up and started hacking away at a tree, TS would have to tell the plant it got hacked, and the plant would have to modify its assemblage of objects to reflect that; otherwise the next day the hacked bits would come back. I did add pruning to PlantStudio: it was possible to snip leaves and whole branches off the plant, and the plant model would look up which part you clicked on and remove it from its model assemblage. So I did do that before and it can be done.
If processing is not an issue - I take your point about background processing - I don't
think memory has to be an issue either. Am I right? (Yes I
do remember writing code that had to fit into 1K of RAM.
) Most plant part objects would have not much more than five or ten critical floats and ints and pointers. If a tree had a lot of parts it could be huge, but in that case there could not be that many in an area. Many trees would only contain a small number of parts, like say 20 or 30, which is basically nothing in memory terms. But what I wonder is, if you had a whole forest of 10K trees... it might add up to something less nice. What do you think?
So what I'm saying is, as you can guess this would be a lot more code than the simple short L-system implementation you have now... and you need to think about whether you really want that degree of complexity thrown into your nice clean code base.
Another thing is, and I'm sure begla knows this, L-system implementations can get
much more complex than what you have now, with stochasticity and even analogues of the transmission of energy around the system, similar to what I have described above. So they
work. They just make my brain make a buzzing noise and stop working. But just because
I have never been able to make useful sense of them doesn't mean they are not useful in general.
Btw I didn't mean screenies of code! That would be ridiculous. I meant screenshots of
trees growing in-game, and pasting code in the forum. My husband suggested the Diffs thing also. He can help me when it comes to that. Let's just see what we are doing right now :?
woodspeople
