Inactive Organic Growth Simulator

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Edit: Moved to Incubator, Suggestions as an inactive initiative awaiting a curator

Name: Organic Growth Simulator
Summary: A more advanced growth simulator for plants, or series of different simulators
Scope: Engine work needed to support, but technically core content?
Current Goal: Port the simulator woodspeople supplied to Java; research and prototyping
Phase: Design / Prototyping
Curator: Needed
Related: #218, other procedural threads maybe

Putting a thread up for this topic for whenever it heats up, which may be soon :)

We've got a few involved pieces:

* L-system based trees (instant generation with world gen)
* Growth simulator (making grass out of soil, etc over time)
* Generic Groovy integration (making the growth / L-System stuff source settings from Groovy definitions) - https://github.com/MovingBlocks/Terasology/issues/81
* Tree meta block - https://github.com/MovingBlocks/Terasology/issues/88
* woodspeople being willing to help with thoughts here / has past experience with a fancy sounding plant simulator - viewtopic.php?f=7&t=114 :)

Should be able to know more about the potential soon, especially as we hit milestone 2 where I am personally committing to more exactly figuring out Tree metablocks. But most certainly am eager to hear feedback as we continue.
 
Last edited:

woodspeople

Member
Contributor
Design
Okay, I/we have been thinking about this for the past week off and on. Our/my thoughts would have made a VERY long post here, so I put them into a document instead. I don't seem to be able to put it here as an attachment (in RTF or PDF formats) so I put it on my web site instead, it is terasology_tree_notes.rtf. Feel free to add to this file or take what I wrote and do something else with it. Hopefully this will spur some helpful discussion! :geek:

woodspeople
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Great material! Lots of interesting trees. Still on board and looking for more, especially how to implement / how an alternative to L-systems would work :)

I can see some of the definitions would look in Groovy already for the actual benefits (like fruits, and to some extent growth speed and such), but defining how the growth would shape the tree and tree elements, and how you'd easily make vastly different trees - need more :D
 

metouto

Active Member
Contributor
Art
woodspeople said:
url=http://www.woodspeople.net/terasology/terasology_tree_notes.rtf]terasology_tree_notes.rtf[/url] Hopefully this will spur some helpful discussion! :geek: woodspeople
:shock: :shock: :shock: :shock: :shock: WOW :eek: :eek: :eek: :eek: :eek:

I have been reading and drooling over these "tree notes" posted by woodspeople :!:

Now, I am not a coder or computer geek of any kind .... I don't know an "L-systems" from a "Q-systems ( :?: ) " ..... but I love to play games ...

so in reading over what woodspeople has put in her notes I was dreaming of awaking in a new world knowing nothing of how I got there and this wonderful world I could explore and find out things I needed to exist in this new world .... food, water, shelter, etc etc etc .... then after finding those things expanding my life to create other things in this new world to protect, defend, enhance my life on this world I can not leave .....


Most of the games I play are single player .... not group play .... but I can see where this would draw the eyes of both groups of players .... I have not seen this type of world in many of the games I have been playing (manic digger, minetest, and the now :cry: nonworking atmosphire) but long for the time I could wonder through a world like this in an opensource free play game as a single player.

The one idea I like here is having a reason behind things ... a "Spiral tree" is in the game to climb and to look into the far beyond that you can't see from the ground (but is that the only reason :?: :?: :?: ) the "Hobble tree" is for a frame for a house or can trap a monster (but is that the only reason :?: :?: :?: ) and "Sharp needle trees" for Harvest, farm, plant them as defense hedges (but is that the only reason :?: :?: :?: ) ......

And also in a world of "strange" trees you would of course have "strange" monsters, people, animals to deal, ineract, buddy up with to even make your life more interesting

Maybe there is a place for me here ..... if only as a player .... but we will see what comes :D
 

begla

Project Founder and Lead Developer
Contributor
Architecture
Logistics
Love the idea of developing a new system for growing and generating plants, trees, ... :!: I've actually found a lot of papers a while ago which might be of interest. Some of the shown algorithms can be utilized to generate a vast amount of different tree types just by adjusting a hand full of parameters. One of this algorithms used differently transformed cylinders for example to generate the trunks and branches. It could be very interesting and even challenging to develop a system that uses a volumetric / voxel-based approach instead of primitive geometric shapes.

Tell me if your interested in those – then I would try to dig those up! :D
 

woodspeople

Member
Contributor
Design
Okay good, glad you all like it. Will move on to thinking about a system that can build these things next. Yes begla those papers would be excellent. I read a lot of that stuff back in the day, but that was more than a decade ago. An OO system is easiest to think about (I'm a branch and I want to do X) but those can be overly CPU consuming, and in Java that's a big issue. Even such things as trees that grow by a block a day can add lots more processing to the system. Since I don't have time to code the best thing I can do is write out how I would build the thing in pseudocode and leave the details for others. If that is helpful to you. Sorry I can't do more...over-committed...

If anybody thinks of more amazing trees why not add them to this forum thread (metouto maybe some come to mind?). The richer our "library" of possible trees the more complete our generation system can be.

The rules are:
  1. It must start with a real tree (species or specimen). (Why real? to stop from making trees that are just too far out to make sense as trees. Gotta have some coherence to the thing. Besides, real trees are amazing.)
  2. It must be an exaggerated version of the real tree: whatever is amazing about the real tree has to get more amazing.
  3. It must be of some real use in the game. And there has to be something you can learn to do with/on/under/around the tree that helps you with what you want to do in the game (whether it's survive, defend, conquer, build, discover, engineer). And some danger is good too.
Okay, will report back when I have something next to offer.

woodspeople
 

begla

Project Founder and Lead Developer
Contributor
Architecture
Logistics
Here is one of the articles I've found a while ago, but I've actually never found the time to fully implement it. It looks like a rather simplistic (but sophisticated) approach, but it can be used to create many realistically shaped trees as far as I remember. There are some colored images on the last page. :D

http://www.cs.duke.edu/courses/fall02/c ... -weber.pdf
 

metouto

Active Member
Contributor
Art
woodspeople said:
metouto maybe some come to mind?......

The rules are:
  1. It must start with a real tree (species or specimen).
  2. It must be an exaggerated version of the real tree: whatever is amazing about the real tree has to get more amazing.
  3. It must be of some real use in the game. And there has to be something you can learn to do with/on/under/around the tree that helps you with what you want to do in the game (whether it's survive, defend, conquer, build, discover, engineer). And some danger is good too.
woodspeople




:idea: :idea: :idea: :idea: :idea: :idea:

1) Weeping Willow Tree

2) Tree of Sorrows

3) You could get water from the branches because it is always "weeping" and "moaning" . You might be able to take the branches strip the leaves off and weave many of them together to make a rope. You can also sleep under a well developed tree and be safe from the weather.

Dangers .... prolonged stays under the tree may cause you to magnify the sorrows in your life to the point that those sorrows will taking control and causing your death by making you commit suicide.


Woodspeople is this what you had in mind :?: :?: :?: :?:
 

woodspeople

Member
Contributor
Design
This is exactly what I had in mind metouto. Great idea and I will add it to the table of amazing trees! Sorry to not respond sooner - too much work...

All, here is where we are with contributing. I was thinking about pseudocode, and I thought, I couldn't even begin to write pseudocode unless I know what your actual code looks like, for example how blocks are set and so on. So my son and I looked at the code on GitHub a few days ago. The tree generation stuff is much simpler than I expected. (I think I kind of forgot that this is a block world. :) I had envisioned masses of code but it is not really that much to take in. So I think I can actually code ... except, bear in mind, very slowly, like a few hours a week as an exploration of math/programming. So anyway I checked out the source and got it running in Eclipse last night. (Full disclosure: I got my husband to set things up .... he has ten times the patience for the endless configuration battles...) We futzed with the L-systems code and made some funny looking trees. I think now that writing pseudocode would be silly, because if you can't see it working as you go you can't improve it. So - expect little but - we can code.

Now just a few questions.

1. If players are able to travel via vast root systems, would it be possible to have a "crawl" stance (like C for crawl) so that they could fit through one-block-high "corridors" inside roots? Because otherwise the roots would have to be huge.

2. I can see looking through our table of amazing trees that some things would depend only on the tree generation procedures while others would require changes in the rest of the world. There is a kind of hierarchy: form only, form + interactions with world, form + interactions with world and player. It makes sense to do only the isolated things first, then tackle the more interdependent parts later. So I think a first shot should be form only.

3. It would save me a lot of time if I don't actually have to check in any code, so to maximize the efficient use of my time I propose I just take screenshots and then send you code which you can incorporate. I would probably only be changing/adding a small number of files anyway, at least at first (and later I might get more comfortable...). Does that sound reasonable?

4. Some other things I had written about are probably just impossible in the current system and should be struck completely. For example it would probably not be possible to have trees grow over time (instead of all at once when an area is generated), even though that would be really neat, because it would have to be possible to (a) save the data structures of tree information, not just voxel information, for each tree; and (b) visit every single tree in a the world each day to see if it can grow and do that. That all seems to me like it would up the memory and CPU requirements too much to be feasible. I will make a list of "probably impossible" items like this and check them with you. Okay?

Let me know if any of this is not okay with you.

woodspeople
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Great to hear the news! Yeah, code would be great, and probably not that hard when you are through the maze of initial setup :D

I'll have more feedback for your post later - 1 am here though, been a long day, I'll be sure to get something up tomorrow!
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Okay! Bit more replying here before I go to bed way too late already :)

Yes, there is nothing quite like tweaking the code and immediately seeing the effect in-game. Feel free to tinker with the L-System and just contribute some other rules right there that make other interesting trees. As an interim I'm sure we could differentiate the trees a bit more between biomes. We can tweak the biome code if somebody just comes up with some more nice and distinct looking tree types :geek:

1) Root systems. Cool idea, hadn't thought of it. Even at 1-block wide tunnels they'd be huge still. Might be better to just have normal tunnels that appear (and potentially generate along with tree growth) like they have all kinds of roots on the walls, dropping from the ceiling, etc? Down the road we could have CustomBlocks that essentially make up "pipes" by making a smaller tunnel within a single block, at which point a player who somehow managed to shrink himself could potentially walk through without requiring overly massive trees :)

(not that an absolutely huge mega-tree wouldn't also be cool - go Team "Home Tree"!)

2) Yes, simple stuff first would be good. We can probably come up with better interaction / fancy integration between multiple blocks making up one object when we've got "meta blocks" making up trees or entity-based component thingiemajiggies. Shouldn't be too long

3) An easy way to contribute code is to generate "Diffs" (not screenies) which is possible in various ways. I haven't actually tried/checked if Eclipse can generate easily exportable diffs or even "patches" but there's probably something out there (maybe hubby knows?). Another (simpler) alternative is to simply copy paste code blocks into the forum and surrounding them with the "Code" tag. Or using something like pastebin or even the GitHub Gists - https://gist.github.com (haven't tried that yet, but you can make it format in Java and such)

4) Totally possible and desired to have "grow over time" rules for trees. The CPU cycles needed can be set to low priority and only run in small batches every once in a while (as little as once per in-game day, one chunk at a time). When we go multiplayer the server would be responsible for that and expected to be "beefy" for high-quality worlds with fancy features enabled. Totally want that synthetic growth generator of yours working in-game :D

Imagine exploring and provoking generation of new chunks with trees on them that "have existed for x time" already and see a sped up growth cycle showing graphically how the tree grew over twenty years in twenty seconds.... :)
 

woodspeople

Member
Contributor
Design
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. :geek: 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
 

woodspeople

Member
Contributor
Design
By the way, when I said "the plant essentially asks each of its constituent parts", I had wanted the parts to talk to each other instead of some overlord plant master, but there was this nasty bug in Delphi at the time (I know, poor choice but C++ was taking THREE MINUTES to compile at that time) that meant we could not .... I don't remember what exactly was the problem, something with the stack. But anyway we had to write a "traverser" that ran around the plant negotiating with all the parts, when really the parts should have talked to each other: leaf to stem, stem to flower, etc. That would be more scientifically accurate and probably more interesting as well, because you would get locality/gradient effects, like the part of the plant that was shaded growing poorly and branching out in new ways, causing the tree to grow around obstacles. In Java I don't think this would be a problem, and it would be fascinating to make that work the way it should have all those years ago.

Of course having said that I have no more time than I did before, and I'm writing this with a sleeping child next to me who did not get his teeth brushed because I wrote this. :shock:

woodspeople
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Haha, neat! I know a good dentist if needed ;)

Great stuff, thank you very much. That sounds incredibly spiffy, and doable, even if it likely would take a lot of effort for something that ultimately isn't that huge a part of the game. Which is OK - we can build it slowly over time and tinker with L-shapes in the meantime. As long as somebody has an interest in helping push it forward there'll be plenty of ability able to provide feedback and do an occasional code sweep to add improvements.

I don't think the demands will be too crazy. Trees that aren't loaded into the active Chuck cache will just be a few parameters with no stored voxel info if all that can be regenerated anyway. So you'll never have thousands of trees trying to grow at the same time while being stared at by players. And with only having to update them once per in-game day or so the processing shouldn't be terrible, and we could easily make the detail level configurable.

On top of that we could possibly imbue some plants with sub-block detail level when we get more into Custom Blocks
 

woodspeople

Member
Contributor
Design
Oh no, I don't think it would take that much effort to build this. What did take a lot of effort was the year or so that went into figuring out how to build the system in the first place. :) Just re-implementing it in a simpler format for a blocky world would be quite easy, easy enough to use to show a kid how to program. If I wasn't busy doing other things I could probably do this in two or three weeks. (In Python, faster :) As it is it's hard to predict, but I'm up for trying.

And yes, the first thing my husband said when I told him what I wrote you was "why don't you use it to generate the sub-block plant images". But that's not as perfect a match for the block world. Trees, and trees you can do things with/on, are more interesting I think.

woodspeople
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Awesome! Take your time, make it educational, and I'd love to see it take shape and help provide feedback :D
 

woodspeople

Member
Contributor
Design
Good news: I have built you a dynamic, object-oriented, manipulable tree growth simulator that can (a) grow in a variety of parameter-specified shapes, (b) respond to conditions around it and (c) respond to the actions of a player making changes to it and around it as it grows.

Bad news: I built it in Python, and I didn't integrate it with Terasology.

There were four essential tasks in building a dynamic tree growth simulator for Terasology:
1) Building a variable, responsive, and manipulable simulation of tree growth.
2) Making the simulation work in a blocky 3D world.
3) Making it work in Java.
4) Making it work with the existing Terasology code base.

On reflection I realized that there was NO way I could ever have enough time to do all four of these things. But I had promised, and I hate to break promises. So rather than write a "sorry, can't do it" post (which I very nearly did), I carried out the first two tasks in hope that someone else would be able/willing to do the other two. Even doing only the first two tasks took far more time than I had to spend, so at this point I've taken this as far as I can (at least until my book is finished which will be another 3-6 months). It has been fun to revisit my old plant simulator, and my son and I have learned a lot. He didn't help with all the coding of course, but I have shown him my progress all along, and he has added some great ideas to the mix. So I'm glad I/we did this, but I really do need to move on now. What you Terasology folks (or the rest of our team, as you like it) do with what I've done is up to you. No offense will taken if you can't or don't want to use this as it is. But I hope you can, eventually :)

To avoid a really long post here I've written a web page about the project on my this-kind-of-stuff web site, at

http://www.woodspeople.net/terasology/t ... ption.html

woodspeople
 

Kai Kratz

Witch Doctor
Contributor
Architecture
Logistics
Very cool stuff! I think we can find an adopter for your code :)
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Wow! That looks amazing! Thank you so much for getting so far along with it, no problem on the Python parts etc, I'm hugely looking forward to consuming that and seeing it get into Java :)

Had begun worrying about you a bit, glad to see you're still around! Appreciate you going above and beyond, you didn't have to work in radio silence that long especially if you didn't really have the time.

Here's for hoping you'll still be able to keep up and see us do something crazy with your code - good luck with your book!
 

begla

Project Founder and Lead Developer
Contributor
Architecture
Logistics
Looks amazing. Thank you woodspeople! :eek:

I'm sure this will make it into the game in the near future. We'll keep you updated.
 
Top