Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GoblinCookie]

The original proposal was tree population evolution after embark, not how to generate the embark tree population...

However, if "fixed locations" are supposed to mean only for embark tree population of the map (as opposed to how I understood it: cut down a tree, a new one grows up in exactly the same tile), that would probably sort of work. The problems with pre generated patterns are that:
- The terrain is uneven, so the pattern you'd try to fit would have holes in it for slopes, surface stone, various forms of water, etc.
- Embarks often contain several biomes, each of which would presumably have its own pattern.
- Finally, I don't think a reasonable speed evolution of the embark tree population would delay the embark by a significant time.

I don't understand the constant misunderstanding of the discussion about the situation in the embark to somehow involve generation of the complete tree population in the world. None of the other posters have discussed anything except the embark area. It's true adventure mode will have to handle trees in some way, but it does not have to be the same as the fortress mode one (and it probably shouldn't be).

That was the issue behind the issue.

The issue behind the issue is that we do not know how many trees there are *supposed* to be on the map because the initial number of trees on the map is definately not the number of trees that there ought to be.  At the moment there is no distinction between the desirability for tree growth of the whole biome, meaning that an even distribution of trees is what we inevitably end up with and the only argument then is how far apart the trees should be spaced.  However, since the number of trees on the map to start with is *not* the number the trees that *ought* to be there but only the number than the memory can cope with we cannot propose anything concrete since that is really down to whether we subjectively consider the number of trees too high or too low.  Now onto your points.

1. That is quite realistic.  The zones should have holes in them because they represent a single unified situation within a larger biome that is desirable or undesirable to tree growth, to have trees suddenly start or stop growing on inclines and the like is exactly what we want to see.   
2. Yes and there is no problem with that.
3. It might actually crash the embark, you are multiplying the already great memory requirements of embarking by adding a whole set of extra things that it needs to do.  Tree growth is presently a major memory sink, the whole idea of in an instant having how many decades worth of tree growth happening not causing CTDs given that a large embark often struggles to model a months worth of tree growth is not credible.

[Vattic]

GoblinCookie: Apologies if I've missed something, but how do we know that the current number of trees on embark isn't roughly how many there are supposed to be?

[Bumber]

Funnily enough I would say the number of cacti on embark is currently too low given how big saguaro forests can get in real life, but maybe I've just been unlucky.

Depends on the area. I don't know if DF has saguaro forests or not, but the foliage would need to be advertised as such on embark. They shouldn't spring up years later in a foliage-scarce area.

Having a fixed number of trees per embark is about the most artificial tree idea possible, it is basically like having some kind of localised version of the site limit, all the trees keep growing until they reach an arbitery limit and then for no apparant reason no more trees grow.  It leads to a situation where we end up having to cut down trees for no reason at all simply so our orchards can grow properly on a completely different part of the map.

Per arbitrary area is better, avoiding the orchard issue. It's not artificial, it's resource (moisture / nutrient) availability. This solution does not preclude tree death, either.

Trees do grow in fixed locations, nothing could be more natural.  Basically, trees grow everywhere that they can grow unless something (humans or animals) stops them from doing that, this means that at core it is all or nothing.  Either a place is a forest and has trees (of a particular type), or it does not have trees; in the former case the only limiting factor to how thick the trees can grow is the proximity of the trees to eachother, the more light, nutrients and water there is the closer together they can grow.  Those factors however (proximity) are already in the game I think so what isn't in the game is the limitations on where the trees can grow at all.

I'm not following. How fixed is fixed? Are we talking about biomes? Arbitrary areas? Tiles? DF recognizes varying foliage density on the embark screen and tree placement at embark. What it does not do is maintain this distinction afterward to the extent it should.

It doesn't so much matter were the trees are located (barring root interference and murky pond oases,) but the average density of the area. This and this are low density. This is not. Two trees have the same draw on a theoretical (unmodeled by DF) water table whether they are next to each other or not. Trees IRL can grow in bunches or scattered evenly (based on water distribution.) DF should try to emulate this look through as little effort as possible (i.e., tree count instead of actual water table.)

We initially carve the map up into random zones (until we can actually model the real-world factors) and then we scatter the initial starting trees only in those zones.  We then create our second generation of trees in an area around the first generation of trees, then we do so again and again until we get the number of trees that mathematically speaking would cover the whole forest zone with trees.  The more unforested your area is, the less of the map is covered by the random zones so that in a desert you will be lucky to get one small cluster of trees but in a woodland the whole map is all one forest zone.

This sounds like more or less the same as how it already works. It's not the initial trees that are the problem. The problem is you can't constrain future trees to this model because of player deforestation, land development, and orchard choices.

In any case, I am not talking about trees growing during play, I am talking about building up a model that reduces the need for new trees to grow after embark by simulating the growth of a forest over a period of time prior to the embark.  That will very much increase FPS since trees growing is a major FPS drain (why FPS always drops in Spring+Summer).

It only helps if gameplay trees follow the model as well. Currently they're only concerned about proximity, which means they'll just begin filling up your non-forest zones, ending in treesplosion.

It would make sense for the devs to have made the size of the kill zone bigger or smaller depending upon the biome.

That's a possible solution, but it doesn't allow for "patches" of trees.

The reason we have treesplosion is that the original trees are not supposed to be the final number of trees; they are also rather small, intended to grow larger over the course of the game in order to take up more space.  The question is thus a subjective one, how densely forested is the desert/savanna biome 'supposed to be'?

Spoiler (click to show/hide)

Again: it is supposed to stay roughly the same.  Seriously guys, this is the part you argue about, what it's "supposed" to be?  The initial embark, barring magmafloods and fires and dwarven woodcutters, should have the same density as twenty years later.

Indeed it supposed to but it cannot.  The game has to keep track of every single tree in the game and it cannot keep track of millions of individual trees all doing stuff, growing and dying off all the time.  This means for reasons of economy what we have a compromise situation where we intially start off with the few 'symbolic' trees, all of them basically identical in shape and far smaller than they will end up.  We then progress from that situation to having a situation with a forest of interesting trees of all manner of shapes and sizes, the situation that for memory reason cannot simply be created in world-gen.

The issue behind the issue is that we do not know how many trees there are *supposed* to be on the map because the initial number of trees on the map is definately not the number of trees that there ought to be.  At the moment there is no distinction between the desirability for tree growth of the whole biome, meaning that an even distribution of trees is what we inevitably end up with and the only argument then is how far apart the trees should be spaced.  However, since the number of trees on the map to start with is *not* the number the trees that *ought* to be there but only the number than the memory can cope with we cannot propose anything concrete since that is really down to whether we subjectively consider the number of trees too high or too low.

This isn't the issue at all. If the current generator can create a whole bunch of trees for a jungle embark, then why wouldn't it create an equal number of trees for a savanna on embark, instead of waiting for them to pop up?

It's memory trivial to use a noise function to give an interesting layout of the proper density of trees and just randomize their ages. And that's what DF does, minus the ages. Any disparity between what it ought to be and the reality is solely a tweaking issue. Tree growth lag is an issue during gameplay, not at embark, so why would we allow more trees later? Especially so if we start requiring them to die and start over?

[PatrikLundell]

I completely fail to understand why tree growth emulation pre embark would lead to a CTD. CTDs are caused by deficient programming (and C(++) is very good at not warning the programmer when mistakes are made, so C programmers have to be good). There is no reason a tree generation phase would use up more memory than a static one, so running out of memory at embark generation while avoiding it after embark won't happen unless the generation is faulty through a massive leak of memory.

Having said that, I agree with Bumber, that the current method, augmented with age randomization and target tree density at embark should be good enough.

[GoblinCookie]

I completely fail to understand why tree growth emulation pre embark would lead to a CTD. CTDs are caused by deficient programming (and C(++) is very good at not warning the programmer when mistakes are made, so C programmers have to be good). There is no reason a tree generation phase would use up more memory than a static one, so running out of memory at embark generation while avoiding it after embark won't happen unless the generation is faulty through a massive leak of memory.

Having said that, I agree with Bumber, that the current method, augmented with age randomization and target tree density at embark should be good enough.

CTD is what presently what happens if you try and load an embark area that is too large for your memory. 

GoblinCookie: Apologies if I've missed something, but how do we know that the current number of trees on embark isn't roughly how many there are supposed to be?

Because the mechanics that the devs have chosen to implement result in an increase the number of trees above that number and the trees themselves are far smaller than they should be. 

Per arbitrary area is better, avoiding the orchard issue. It's not artificial, it's resource (moisture / nutrient) availability. This solution does not preclude tree death, either.

That already exists, there are already is a limited number of trees that are allowed to grow within an area because the grown up trees prevent new saplings from growing up within an area. 

I'm not following. How fixed is fixed? Are we talking about biomes? Arbitrary areas? Tiles? DF recognizes varying foliage density on the embark screen and tree placement at embark. What it does not do is maintain this distinction afterward to the extent it should.

It doesn't so much matter were the trees are located (barring root interference and murky pond oases,) but the average density of the area.

Fixed because the area has certain places that are suitable for tree growth and these places are limited.  Naturally trees will spread to cover every single spot that there is that is suitable for tree growth, the only limitation being competition from other trees close by. 

This and this are low density. This is not. Two trees have the same draw on a theoretical (unmodeled by DF) water table whether they are next to each other or not. Trees IRL can grow in bunches or scattered evenly (based on water distribution.) DF should try to emulate this look through as little effort as possible (i.e., tree count instead of actual water table.)

The problem with the zone-wide tree cap solution is that it does not take into account the relative proximity of the trees overall within the zone.  If all the trees end up being on the far of the zone they inexplicitly stop the rest of the zone from growing trees rather than affecting the neighboring zone.  It is better to model factors like these by kill-zones (what already exist) rather than having an arbitrary tree-cap per arbitery area. 

This sounds like more or less the same as how it already works. It's not the initial trees that are the problem. The problem is you can't constrain future trees to this model because of player deforestation, land development, and orchard choices.

It does work that way already with clusters, the problem seems to be that the kill zone around trees is too small for certain biomes.  In non-forest biomes the kill zone around a tree should be bigger than it is in a forested biomes so the number of trees in a cluster ends up being forced to be smaller without us having to have a defined tree limit for the whole zone. 

It only helps if gameplay trees follow the model as well. Currently they're only concerned about proximity, which means they'll just begin filling up your non-forest zones, ending in treesplosion.

There is really no such thing as treesplosion.  The map is divided up randomly into forested zones and non-forested zones, from my experiences with the untouched southern end of my embark which is completely useless and only hogs FPS what you are calling treesplosion ends with the sky in all the invisible forested zones being completely covered by leaves but other neighboring zone being completely devoid of trees of any kind.  Probably in a less forested biome the forested zones are smaller and the open zones bigger but I only play forest biomes since the fruit picking release as I love to make orchards. 

That's a possible solution, but it doesn't allow for "patches" of trees.

Unless we allow the tree-growth zones to all have different kill zones averaged by the biome's general nature. 

This isn't the issue at all. If the current generator can create a whole bunch of trees for a jungle embark, then why wouldn't it create an equal number of trees for a savanna on embark, instead of waiting for them to pop up?

It's memory trivial to use a noise function to give an interesting layout of the proper density of trees and just randomize their ages. And that's what DF does, minus the ages. Any disparity between what it ought to be and the reality is solely a tweaking issue. Tree growth lag is an issue during gameplay, not at embark, so why would we allow more trees later? Especially so if we start requiring them to die and start over?

The trees the generator initially creates in whatever number are quite limited.  They are all of the same size (smaller than they should be) and they are all identical, that is probably because it would take too much memory for the map to actually have the world-gen realistically model all the millions of the trees actually growing or simulate the effect of this.  'Treesplosion' is the means by which the game creates a forest of trees that grow in an interesting manner, twisting around eachother and forming interesting shapes.  Simply getting rid of it would result in an artificial feel where all the trees grow identically a fixed distance apart, essentially how tree farms look in real-life.

We do not start off with the situation we should have in the biome so that in the end we end up with that the perfect situation in the end.  The 'tree-farm' solution would give us the correct number of trees to start with but would never give us a realistic forest setup which is what we get as the result of the present situation but not immediately. 

[PatrikLundell]

And I maintain that CTD due to running out of memory is due to poor programming (not checking the pointer returned after allocation because you [implicitly] assume you'll never run out, which a CTD proves was an incorrect assumption), as well as tree generation for the embark would have very little effect on the memory consumption. Any embark that would run out of memory due to tree generation on embark would run out of memory very shortly after embark as items are produced, if there is any memory effect at all.

Let's see if I can summarize what I think GoblinCookie is saying, including some unstated inferences (which I may have gotten wrong, of course).

A. Embark tree generation is the way it is because that's what the embark looks like in adventure mode, which also means the tree generation process is/was the same (I would assume the tree generation either took place during world generation, or, quite possibly, dynamically as an adventurer or embark party enters an area for the first time).

B. There is some kind of tree competition radius that can/will kill off saplings within it over time, if the saplings don't hurry up and mature before getting throttled. It's unstated/unknown what this radius is, what the "mature at the same time" time window is, and if the radius is dependent on tree species, biome, both, or is fixed.

Various arguments/proposals:

A.1: As stated by Bumber, updating the adventure mode/pre embark tree generation process to include both an age variation as well as a growth variation can be done by having tables of standard shapes (which implies ages), so instead of "generic ash" you'd plunk down "generic ash #14). The only complication I can see there is when trees are close enough to each other to get entangled, in which case I guess you could just get rid of one of the trees or use a mechanism to select compatible shapes.

A.2: I don't consider prior visit in adventure mode to be a sufficient argument against a more advanced pre embark tree generation replacing the previous one, but I'm sure some disagree. However, if the embark site has never been visited in adventure mode, I can see no logical argument against a more fully fleshed out pre embark generation process, apart from a "look and feel" one. If adventure mode trees do not evolve according to the same rules as embark ones do post embark, embarks otherwise untouched by logging or building would nevertheless look very different from non embark ones after only a few years, ruining any "look and feel" commonality.

B.1: A tree competition radius where the radius differed by species and biome with the competition value dropping off by distance is essentially what I proposed, only expressed in different terms (although I readily admit I didn't take species into consideration). I'd be quite happy with such a solution.

B.2: Even a more primitive radius fixed per biome with a 100% kill rate within the radius (unless the sapling races to maturation before the periodic scythe is swept over the area for the first time) would be OK, provided the radii are adjusted from the current one(s).

[Vattic]

Funnily enough I would say the number of cacti on embark is currently too low given how big saguaro forests can get in real life, but maybe I've just been unlucky.

Depends on the area. I don't know if DF has saguaro forests or not, but the foliage would need to be advertised as such on embark. They shouldn't spring up years later in a foliage-scarce area.

Agreed, at least not without just cause.

GoblinCookie: Apologies if I've missed something, but how do we know that the current number of trees on embark isn't roughly how many there are supposed to be?

Because the mechanics that the devs have chosen to implement result in an increase the number of trees above that number and the trees themselves are far smaller than they should be. 

I don't buy that how it currently works is intended even if it is the result of mechanics implemented by the devs. You would expect a range of sizes and ages represented in the trees of an active ecosystem.

[Bumber]

CTD is what presently what happens if you try and load an embark area that is too large for your memory.

Trees are just a drop in the bucket for the embark size issue. There are 100+ z-levels worth of tiles for every single surface tile.

GoblinCookie: Apologies if I've missed something, but how do we know that the current number of trees on embark isn't roughly how many there are supposed to be?

Because the mechanics that the devs have chosen to implement result in an increase the number of trees above that number and the trees themselves are far smaller than they should be.

That's not very convincing. It's just as likely the tree growth is overzealous. The size of the trees doesn't seem relevant other than to point out it doesn't consider age (or that the increased sizes were causing problems with placement.)

I would instead assert that tracking the density of trees after embark is more difficult than creating a spread of trees from scratch. It also takes years in-game to test the end result. IMO, the fault is more likely to lie here.

That already exists, there are already is a limited number of trees that are allowed to grow within an area because the grown up trees prevent new saplings from growing up within an area.

I have concerns that the search area might not be able to be increased much without performance hits (as a square area is 2xN^2 the kill distance.) In addition, any randomization in the growth area (too tired to think of example) would have to be stored for consistency. Furthermore, player orchards would be either fixed to this density, or have no effect on the health of the nearby trees (beyond the distance limit) when packing a bunch together.

The problem with the zone-wide tree cap solution is that it does not take into account the relative proximity of the trees overall within the zone.  If all the trees end up being on the far of the zone they inexplicitly stop the rest of the zone from growing trees rather than affecting the neighboring zone.  It is better to model factors like these by kill-zones (what already exist) rather than having an arbitrary tree-cap per arbitery area.

I don't see that as an issue. If you have a bunch of nearby trees, they're still taking the resources. Furthermore, it's a good thing since it varies tree placement, giving you something like this. In the kill-zone model, those trees are too close to one another. Any density that allowed that would end in this throughout the zone. The result is also dependent on zone size. Larger zones offer more flexible placement. Map features are currently divided into 16x16 tile areas, so take that how you will.

There is really no such thing as treesplosion.  The map is divided up randomly into forested zones and non-forested zones, from my experiences with the untouched southern end of my embark which is completely useless and only hogs FPS what you are calling treesplosion ends with the sky in all the invisible forested zones being completely covered by leaves but other neighboring zone being completely devoid of trees of any kind.  Probably in a less forested biome the forested zones are smaller and the open zones bigger but I only play forest biomes since the fruit picking release as I love to make orchards.

Being devoid of trees is a result of no trees being defined for a biome. It has nothing to do with kill zones.

That's a possible solution, but it doesn't allow for "patches" of trees.

Unless we allow the tree-growth zones to all have different kill zones averaged by the biome's general nature.

That does nothing to prevent uniformity within the zone itself.

The trees the generator initially creates in whatever number are quite limited.  They are all of the same size (smaller than they should be) and they are all identical, that is probably because it would take too much memory for the map to actually have the world-gen realistically model all the millions of the trees actually growing or simulate the effect of this.  'Treesplosion' is the means by which the game creates a forest of trees that grow in an interesting manner, twisting around eachother and forming interesting shapes.  Simply getting rid of it would result in an artificial feel where all the trees grow identically a fixed distance apart, essentially how tree farms look in real-life.

Again, it has nothing to do with millions of trees growing. Density is a property of biomes. I don't know what world you live in where an explosion (rapid increase in number) of trees in an area creates interesting shapes.

Spoiler: Which of these patterns is most interesting and natural? (click to show/hide)

   

We do not start off with the situation we should have in the biome so that in the end we end up with that the perfect situation in the end.  The 'tree-farm' solution would give us the correct number of trees to start with but would never give us a realistic forest setup which is what we get as the result of the present situation but not immediately.

This is the first I've heard of a 'tree-farm' solution.

[PatrikLundell]

I agree a frequent evaluation of a kill radius would cause a drain on CPU resources. This is the reason I proposed a single check at the sapling maturation time after a flat mortality check. This would delay the sapling death time, though. If you have a flat regular mortality check (possibly different percentages per biome) that didn't take competition into account I think it would be good enough.

An orchard COULD be handled similarly to how trees sometimes are grown in real life, i.e. initially pot grown and then the ones approved are planted at their destination when sufficiently grown, which in DF would mean you'd take a "mature" sapling from the pot and plant a matured tree. It would probably be easier to just mark player planted saplings as exempt from the normal competition mortality checks, though (I guess trampling would still be there). Another alternative would be to apply the mortality rules for orchards as well, but let the planting interface provide feedback on competition (if 100% kill zones are used, you shouldn't be allowed to plant anything within such a zone. If competition mortality probabilities are used you could color code zones into 3 - 10 different ranges).

[GoblinCookie]

And I maintain that CTD due to running out of memory is due to poor programming (not checking the pointer returned after allocation because you [implicitly] assume you'll never run out, which a CTD proves was an incorrect assumption), as well as tree generation for the embark would have very little effect on the memory consumption. Any embark that would run out of memory due to tree generation on embark would run out of memory very shortly after embark as items are produced, if there is any memory effect at all.

Let's see if I can summarize what I think GoblinCookie is saying, including some unstated inferences (which I may have gotten wrong, of course).

A. Embark tree generation is the way it is because that's what the embark looks like in adventure mode, which also means the tree generation process is/was the same (I would assume the tree generation either took place during world generation, or, quite possibly, dynamically as an adventurer or embark party enters an area for the first time).

B. There is some kind of tree competition radius that can/will kill off saplings within it over time, if the saplings don't hurry up and mature before getting throttled. It's unstated/unknown what this radius is, what the "mature at the same time" time window is, and if the radius is dependent on tree species, biome, both, or is fixed.

1. Yes, basically.  The reason we start of with so few trees (and so small and boring ones) is not that the devs wanted it but that the memory constraints of modelling the realistic growth of all the forests in the world would crash the game.  The present situation where the number of trees rapidly increases until we end up with a proper forest is a compromise between what the devs would like (a realistic spread of trees) and the memory constraints preventing those trees from simply being already there. 

2. That is definately the case.  What I am unsure of is whether the kill radius is anything other than the area in the shade of the tree but it appears to be the case that the map is randomly divided up into forested and non-forested zones, with trees only growing in the former. 

I don't buy that how it currently works is intended even if it is the result of mechanics implemented by the devs. You would expect a range of sizes and ages represented in the trees of an active ecosystem.

Somebody other than the devs clearly did not implement the mechanics Vattic.  Since it obviously not what the devs wanted to have, it is clearly something they were forced to do by the memory constraints of world-gen.  The way that the trees expand rapidly after embark is clearly intended as a compromise between the number of trees that the devs were able to implement and the number of trees they wanted to be there. 

Trees are just a drop in the bucket for the embark size issue. There are 100+ z-levels worth of tiles for every single surface tile.

At the moment there is nothing between world-gen and embarking.  This means that the total number of trees that we want to be there have to be created everywhere at once in order for us to be able to embark in a particular place and see those trees.  The more trees there are, the more memory is required to generate them in world-gen potentially causing that to CTD and the more memory is required to load the map in the first place since all that information has to be transferred to render the embark area, the more detailed our forest the more information we have to transfer. 

The only solution is to have a seperate embark gen between the two, a replay of the world history of that particular map area in order to populate it with trees and other details appropriate to the area without those things having previously existed outside of the world-gen. 

That's not very convincing. It's just as likely the tree growth is overzealous. The size of the trees doesn't seem relevant other than to point out it doesn't consider age (or that the increased sizes were causing problems with placement.)

I would instead assert that tracking the density of trees after embark is more difficult than creating a spread of trees from scratch. It also takes years in-game to test the end result. IMO, the fault is more likely to lie here.

If it were easy the devs would have already done it Bumber. 

I have concerns that the search area might not be able to be increased much without performance hits (as a square area is 2xN^2 the kill distance.) In addition, any randomization in the growth area (too tired to think of example) would have to be stored for consistency. Furthermore, player orchards would be either fixed to this density, or have no effect on the health of the nearby trees (beyond the distance limit) when packing a bunch together.

We already have randomised tree-growth and no-tree growth areas on the map randomly generated.  Players who plant their orchard trees too close together would suffer the consequences, I cannot see how that is anything but realistic. 

II don't see that as an issue. If you have a bunch of nearby trees, they're still taking the resources. Furthermore, it's a good thing since it varies tree placement, giving you something like this. In the kill-zone model, those trees are too close to one another. Any density that allowed that would end in this throughout the zone. The result is also dependent on zone size. Larger zones offer more flexible placement. Map features are currently divided into 16x16 tile areas, so take that how you will.

The trees are not taking the resources from randomly designated zones but from the general area around them within a given distance.  Kill-zones is a realistic depiction of this, tree-caps within arbitery zones is not. 

Being devoid of trees is a result of no trees being defined for a biome. It has nothing to do with kill zones.

Indeed it doesn't have anything to do with kill zones, that is what regulates the density within the areas of the map where trees are allowed to grow.  The biome itself is however divided up into random patches, some of these allow trees to grow in them and some of them do not.  This means that if we leave an area of the map completely alone we will find a patchy distribution of trees, with densely forested areas right next to treeless zones. 

At present the biome is divided up into random patches, some of them allow the biome's trees to grow in them (and the few initial trees are placed in them) and the other are empty or trees with trees refusing to grow in them.  The more forested the biome is, the greater the number of forest patches and the fewer the number of open patches defined invisibly on the map before any trees grow.  What appears to be lacking however is any variation of the kill zone between the biomes and individual patches within the biomes.  This is what is leading to complaints of 'treesplosion', the forested patches in an open area biome are ending up just as dense as a regular forest because there is no difference between the kill zones of trees in different biomes.   

That does nothing to prevent uniformity within the zone itself.

As is intended, the zone represents a set of uniform conditions.  It is an extension of what exists already, but is not binary in the way that what exists already is. 

Again, it has nothing to do with millions of trees growing. Density is a property of biomes. I don't know what world you live in where an explosion (rapid increase in number) of trees in an area creates interesting shapes.

It does when the memory cannot handle growing millions of interestingly shaped trees.  The rapid increase in the number of trees is a neccesery compromise between the inability of world-gen to handle the quantity of the trees when combined with the quality and the desire to have this situation arise on the map. 

Spoiler: Which of these patterns is most interesting and natural? (click to show/hide)

   

We do not start off with the situation we should have in the biome so that in the end we end up with that the perfect situation in the end.  The 'tree-farm' solution would give us the correct number of trees to start with but would never give us a realistic forest setup which is what we get as the result of the present situation but not immediately.This is the first I've heard of a 'tree-farm' solution.

The tree-farm solution is what the devs rejected as an option, it is what having the correct number of trees that are 'supposed' to be there would entail, given the limited memory available to world-gen.  It can only cover the world with enough trees if all the trees of the same type are identical and laid down in an identical pattern in relation to eachother, anything else would exhaust the memory of the game.

[Dozebôm Lolumzalìs]

Seriously, GoblinCookie, have you ever seen a player fortress in a savanna after a couple of decades? Every forest, every desert, every grassland turns into a jungle. That is not carping intended!!!!! Seriously, how can you say that the current situation is acceptable?

[GoblinCookie]

Seriously, GoblinCookie, have you ever seen a player fortress in a savanna after a couple of decades? Every forest, every desert, every grassland turns into a jungle. That is not carping intended!!!!! Seriously, how can you say that the current situation is acceptable?

I do not play savannas, I play forests.  I am quite aware of the inexplicable nonforested patches that exist in the forested map even after many years of play, which calls the lie to the whole notion there is some kind of uncontrolled tree growth in the game and leads me to believe that the whole 'treesplosion' concept is hearsay based upon players not understanding that the number of trees that are on the map at the start are not the total number of trees that mechanically should be there.  There are already plenty of mechanics in the game to limit tree-growth, which makes the whole thing a subjective argument about how many trees ought a savanna to have? 

I could turn the whole thing around and say "why does my forest not have total tree cover from one end of the map to the other?".

[Dozebôm Lolumzalìs]

Why do you not get it???! In the tree-having parts of the fortress zone, the trees multiply like rabbits until the sky is covered. We're not saying that the nonforested zones turn into forested zones, we're saying that the forested (even desert) zones turn into jungles.

Stop using a straw man!

[Dozebôm Lolumzalìs]

The whole thing [is] a subjective argument about how many trees ought a savanna to have...

No. You have never played a savanna. Go play a savanna and tell me that there is intended to be the same tree-density as a jungle after a few decades.

A handy picture:

Here's what the biomes look like at the beginning:

Code: [Select]

SAVANNA   JUNGLE
 T...T   T.T.T..T
 .....   .TT.T..T
 ....T   .TT.T.T.
And what they look like after a few decades:

Code: [Select]

SAVANNA   JUNGLE
 T.T.T   T.T.TT.T
 .TTT.   .TT.T.TT
 T.T.T   .TT.T.T.
See how they become the same? That is obviously wrong.

[Bumber]

At the moment there is nothing between world-gen and embarking.  This means that the total number of trees that we want to be there have to be created everywhere at once in order for us to be able to embark in a particular place and see those trees.  The more trees there are, the more memory is required to generate them in world-gen potentially causing that to CTD and the more memory is required to load the map in the first place since all that information has to be transferred to render the embark area, the more detailed our forest the more information we have to transfer.

Not so. Trees have no reason to exist in world gen whatsoever. All that's needed is a function that places them deterministicly (same result every time.) You don't think Minecraft needs to generate every single tree do you? (Minecraft worlds are very very large.)

The only solution is to have a seperate embark gen between the two, a replay of the world history of that particular map area in order to populate it with trees and other details appropriate to the area without those things having previously existed outside of the world-gen.

Trees don't change in world history. If they did, that's what you'd need to do. They exist as abstract data, like non-historical figures do. You don't track every single living dwarf's beard length, you calculate it when it comes up (assuming it ever does.)

If it were easy the devs would have already done it Bumber.

You can't assume that. Toady could have added gelding at any time before 40.19. Why didn't he? Priority.

We already have randomised tree-growth and no-tree growth areas on the map randomly generated.  Players who plant their orchard trees too close together would suffer the consequences, I cannot see how that is anything but realistic.

An orchard is an artificially increased area of trees maintained by extra resources. I suppose the tree models proposed in this thread could all become obsolete once soil quality is tracked.

The trees are not taking the resources from randomly designated zones but from the general area around them within a given distance.  Kill-zones is a realistic depiction of this, tree-caps within arbitery zones is not.

The internal logic is irrelevant, all that matters is results. Mine is a divide and conquer algorithm. Yours is exhaustive. Your model could be considered flawed for that same reason that tree placement isn't decided by proximity to other trees, but by actual resources (which can be influenced by proximity) and layout of the soil.

Indeed it doesn't have anything to do with kill zones, that is what regulates the density within the areas of the map where trees are allowed to grow.  The biome itself is however divided up into random patches, some of these allow trees to grow in them and some of them do not.  This means that if we leave an area of the map completely alone we will find a patchy distribution of trees, with densely forested areas right next to treeless zones.

I have not observed this. You'll have to show me a screenshot.

It seems I might have to summon Quietust for an explanation on how the current model works. Specifically, when, where, and how tree placement is decided, and how post-embark growth checks occur.