Print

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

[PatrikLundell]

If Quiestust knows how it works, yes, summoning him would allow us to discuss the matter at hand based on knowledge of the current situation, rather than various conflicting more or less fact based impressions of what the current situation is.

[Sizik]

I think that the trees are all generated/placed at embark time anyway*, so it makes no sense to argue that treesplosions happen because "the memory constraints of modelling the realistic growth of all the forests in the world would crash the game.".

* If someone can verify/refute this, it would be greatly appreciated.

[GoblinCookie]

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!

I know from experience that the tree density never gets very high even in actual forested biomes.  In a proper forest you should not be able to drive a wagon through, but in every case they can do just that.  A gameplay neccesity I know, but I fail to see what the treesplosion people are complaining about actually is given how the actual forests are far less dense than any really existing forest would be. 

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

That is not the model that the game has gone for and for good reason.  It is the 'tree farm' solution by which you end up with identical trees in an identical pattern, it does save memory however and that is why the original trees that we have on embark are so boring, worldgen could not really model the growth of a forest over time so we got a pattern of identical trees along the kind of lines you mention above.  All it can track is the location and the type, nothing more. 

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

Indeed, that is the problem with having all the trees already there in the correct number upon embark. 

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

In this case he is not added anything, we are talking about mechanics that have already been added being unsatisfactory. 

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.

Mine don't really become obsolete since we simply go from the zone as a whole randomly having a different kill zone to the zones having different levels of nutrients. 

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.

You do not get the correct results in a game like DF without the right internal logic.  As the trees  consume resources in the immediate vicinity, the distinction you are making is completely senseless. 

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.

Here is the extreme south-western area of my 7-year old fortress which is located in a forested area.  Nobody has cut down any of the trees in this area, it has been untouched by loggers since the begining of the game, left free to treesplode to their hearts content. 





As you can clearly see from the bottom map, the result is an essentially random set of clusters, the trees grow close together in clusters with nearby areas being completely devoid of trees, forming  glades in the middle of the forest.  Some of these glades are rather large, look at the one west of the lake in the north-eastern corner of the screenshot, there is a whole area there with only non-tree vegetation while the other side of the lake is a cluster of trees that is quite thick.  Despite having had 7 years to sprout up and a nearby cluster of trees, there is barely a sapling to be seen anywhere in that zone. 

[Bumber]

That is not the model that the game has gone for and for good reason.  It is the 'tree farm' solution by which you end up with identical trees in an identical pattern, it does save memory however and that is why the original trees that we have on embark are so boring, worldgen could not really model the growth of a forest over time so we got a pattern of identical trees along the kind of lines you mention above. All it can track is the location and the type, nothing more.

Again, it doesn't have to track anything when it can pull a pseudo-random number. Age and shape can be random, so long as they conform to the surrounding area. There is ample time to calculate this as the dwarves are embarking (slightly less so for an adventurer, but still doable.) Only after the area has been loaded for the first time do you need to keep track, as is the same with every other tree you decide to put there after.

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

Indeed, that is the problem with having all the trees already there in the correct number upon embark.

What is the problem? If you're referring to not knowing the correct number, you define the correct number on embark, based on how it works out.

Your method is more difficult here because you'd have to somehow check to make sure no more trees would grow, because placement affects count in the distance model. More could spring up later if you didn't check every single tile for availability. Although I don't suppose that level of detail matters. It's close enough.

In this case he is not added anything, we are talking about mechanics that have already been added being unsatisfactory.

Multi-hauling. Combat/move speed split. Non-spore breeding. Body part pulping (as opposed to zombie HP.) Take your pick.

Mine don't really become obsolete since we simply go from the zone as a whole randomly having a different kill zone to the zones having different levels of nutrients.

Mine goes from zones having a random cap on number of trees, to a dynamic cap calculated by nutrients. Toady will likely do something more in depth than either.

You do not get the correct results in a game like DF without the right internal logic.  As the trees  consume resources in the immediate vicinity, the distinction you are making is completely senseless.

If both methods are capable of producing correct results, then the distinction is FPS. Mine can keep a simple count of trees and use the current distance check. Yours requires quadratic increase in time with distance and re-checking that every time a new tree grows.

My areas are also immediate vicinity, but rounded to a grid (just like the current DF fishing, etc.)

Here is the extreme south-western area of my 7-year old fortress which is located in a forested area.  Nobody has cut down any of the trees in this area, it has been untouched by loggers since the begining of the game, left free to treesplode to their hearts content. 

-snip-

As you can clearly see from the bottom map, the result is an essentially random set of clusters, the trees grow close together in clusters with nearby areas being completely devoid of trees, forming  glades in the middle of the forest.  Some of these glades are rather large, look at the one west of the lake in the north-eastern corner of the screenshot, there is a whole area there with only non-tree vegetation while the other side of the lake is a cluster of trees that is quite thick.  Despite having had 7 years to sprout up and a nearby cluster of trees, there is barely a sapling to be seen anywhere in that zone.

The area you speak of is 5x5. Having a few of those is explainable by random chance, if I even considered those 'glades'. Notice how the large glade you pointed out is in the proximity of 3 small trees (one of which has no leaves at all,) which would otherwise overshadow the area. The area just south-east of the lake has a similar gap on the ground, but this one is shaded by leaves above.

I can't distinguish any clusters. All I see are O's evenly spread across the map with a few breaks in the pattern.

[Quietust]

I don't know how tree growth is handled in the current version, only in previous versions, and back then it was limited according to your embark location's tree density (with subterranean areas having a fixed density value).

As far as I can recall, the values were "reasonable" back in version 0.23 (i.e. the 2D era), so it's possible some formula got broken during the transition to 3D (e.g. the per-embark tree limit becoming a per-region-tile limit) - I'd have to look closer to figure out exactly how it works now.

[Bumber]

As far as I can recall, the values were "reasonable" back in version 0.23 (i.e. the 2D era), so it's possible some formula got broken during the transition to 3D (e.g. the per-embark tree limit becoming a per-region-tile limit) - I'd have to look closer to figure out exactly how it works now.

It could just be the fact that single-tile trees were small, resulting in what was an acceptable density back then. The multi-tile trees have leaves and branches that clutter up the z-level above and harm FPS.

I don't know what version this screenshot is from (definitely not 2D), but it looks to be slightly more dense than DF2014 without interfering too much:

It helps that you can barely distinguish them at a glance.

Spoiler: Here's another screenshot of a more arid embark (assuming it's not a beach): (click to show/hide)

Maybe they grow slower, but you still got a bunch of trees. That each gave you only one wood meant you were chopping them down more often.

[GoblinCookie]

Again, it doesn't have to track anything when it can pull a pseudo-random number. Age and shape can be random, so long as they conform to the surrounding area. There is ample time to calculate this as the dwarves are embarking (slightly less so for an adventurer, but still doable.) Only after the area has been loaded for the first time do you need to keep track, as is the same with every other tree you decide to put there after.

Yes I know, you can just randomise a forest when you need the forest to actually be loaded, however that is not how the game is actually constructed.  Instead the game creates every object in the game randomly and then stores their location for later use.  Reducing the number and detail of the objects allows more objects to be stored in memory, hence why we have fewer than the number of trees that we should have and all the trees are less diverse as well.

What is the problem? If you're referring to not knowing the correct number, you define the correct number on embark, based on how it works out.

Your method is more difficult here because you'd have to somehow check to make sure no more trees would grow, because placement affects count in the distance model. More could spring up later if you didn't check every single tile for availability. Although I don't suppose that level of detail matters. It's close enough.

The correct number is the number of trees that ought to be on the map according to the presently in use model of tree growth and local conditions.  The question that perplexes me is why the number of trees that are initially placed on the map during world-gen are fewer in number than the number of trees that will actually grow on the map given the model of tree growth.

Multi-hauling. Combat/move speed split. Non-spore breeding. Body part pulping (as opposed to zombie HP.) Take your pick.

There are already mechanics in the game to regulate the post-embark growth of trees.  Toady One could have added in the correct number of trees to start with, he obviously chose not to hence there is a reason for that. 

If both methods are capable of producing correct results, then the distinction is FPS. Mine can keep a simple count of trees and use the current distance check. Yours requires quadratic increase in time with distance and re-checking that every time a new tree grows.

My areas are also immediate vicinity, but rounded to a grid (just like the current DF fishing, etc.)

Mine works fundermentally as things do at the moment, with grown-up trees preventing saplings from springing up.  Your proposal is to replace the natural way that things work with an artificially regulated arbitery tree number for an arbitery area.  In essence you propose replacing the present system with a system that is worse. 

The area you speak of is 5x5. Having a few of those is explainable by random chance, if I even considered those 'glades'. Notice how the large glade you pointed out is in the proximity of 3 small trees (one of which has no leaves at all,) which would otherwise overshadow the area. The area just south-east of the lake has a similar gap on the ground, but this one is shaded by leaves above.

I can't distinguish any clusters. All I see are O's evenly spread across the map with a few breaks in the pattern.

What random chance?  The trees are supposed to exponentially spread across the map, without any checks or limitations; this means there should be saplings all over the glades but what we see instead is not that.  Yes the treeless zones are randomly generated, that is exactly what I said; I would figure that the less forested the area the more of these zones there are and the larger they are. 

[Bumber]

Yes I know, you can just randomise a forest when you need the forest to actually be loaded, however that is not how the game is actually constructed.  Instead the game creates every object in the game randomly and then stores their location for later use.  Reducing the number and detail of the objects allows more objects to be stored in memory, hence why we have fewer than the number of trees that we should have and all the trees are less diverse as well.

Again, there is no memory difference between placing them at embark or having them grow later. I shouldn't have to keep repeating this.

The correct number is the number of trees that ought to be on the map according to the presently in use model of tree growth and local conditions.  The question that perplexes me is why the number of trees that are initially placed on the map during world-gen are fewer in number than the number of trees that will actually grow on the map given the model of tree growth.

Likely because it's difficult to regulate. It's easy to place down a set density of trees. It's harder to maintain that density, especially if you're opposed to an artificial cap, and what you get is a "best guess" for how it should be. Whether the current disparity in the model is due to placeholder, technical limitations, or something broken, only Toady could give a proper answer as to intent.

There are already mechanics in the game to regulate the post-embark growth of trees. Toady One could have added in the correct number of trees to start with, he obviously chose not to hence there is a reason for that.

It's starting to look like there wasn't any sort of check at all in v0.34 besides trampling, in which case an embark could've theoretically become nothing but trees after a sufficiently long time. It's possible the mechanics only regulated how long that took, with the player's need for logs previously keeping that in check. "Choice" implies he was able to determine what the correct number should be and that everything is working as intended.

Mine works fundermentally as things do at the moment, with grown-up trees preventing saplings from springing up. Your proposal is to replace the natural way that things work with an artificially regulated arbitery tree number for an arbitery area. In essence you propose replacing the present system with a system that is worse.

The present system isn't sufficient. From what I can tell, the DF2014 addition looks like it was solely designed to stop trees from growing into each other. If I'm understanding Quietust correctly, the 2D version actually had an artificially regulated number, and may have been transferred incorrectly to the 3D version. Then it follows that there actually is an arbitrary tree cap for an arbitrary area, but it's set way too high.

What random chance? The trees are supposed to exponentially spread across the map, without any checks or limitations; this means there should be saplings all over the glades but what we see instead is not that. Yes the treeless zones are randomly generated, that is exactly what I said; I would figure that the less forested the area the more of these zones there are and the larger they are.

Saplings are placed randomly on a regular interval, not spread from existing trees. As the map fills up, it gets more likely they'll be placed somewhere they can't grow. It's possible they will be filled, eventually, at a 1/[Number of Surface Tiles] chance. There's also the chance that some of your trees have grown in such a way where there's just short of enough space to place another, in which case you'd have to chop them down and see if they grow differently.

Addendum:
I'd also like to point out that embark trees are actually randomized at least in branch / leaf configuration. The heights are all disappointingly exact per tree type, however.

[GoblinCookie]

Again, there is no memory difference between placing them at embark or having them grow later. I shouldn't have to keep repeating this.

That is just wrong, provided you want the detail that we end up with to exist in your embark trees you will have to do all the tree-growth calculations for decades at least in one instant.  You could place all the trees in their default boring state to cover the map as much as the mechanics say it should be covered, but that results in a tree-farm effect. 

Likely because it's difficult to regulate. It's easy to place down a set density of trees. It's harder to maintain that density, especially if you're opposed to an artificial cap, and what you get is a "best guess" for how it should be. Whether the current disparity in the model is due to placeholder, technical limitations, or something broken, only Toady could give a proper answer as to intent.

The disparity is there because it is the only means possible given the limited memory to end up with a realistic looking forest. 

It's starting to look like there wasn't any sort of check at all in v0.34 besides trampling, in which case an embark could've theoretically become nothing but trees after a sufficiently long time. It's possible the mechanics only regulated how long that took, with the player's need for logs previously keeping that in check. "Choice" implies he was able to determine what the correct number should be and that everything is working as intended.

The old 2d tree model was replaced with a new 3d one, so how things used to work is not exactly relevent.  Toady One is not supposed to exactly determine anything, the game is supposed to have mechanics that result in the desired outcome, the mechanics dictate the total number of trees on the map and it does not seem to me that they dictate that the whole map should be trees. 

The present system isn't sufficient. From what I can tell, the DF2014 addition looks like it was solely designed to stop trees from growing into each other. If I'm understanding Quietust correctly, the 2D version actually had an artificially regulated number, and may have been transferred incorrectly to the 3D version. Then it follows that there actually is an arbitrary tree cap for an arbitrary area, but it's set way too high.

It does not look like it is too high to me, the tree density is extremely low for realism in that you cannot normally drive a wagon through a forest.

Saplings are placed randomly on a regular interval, not spread from existing trees. As the map fills up, it gets more likely they'll be placed somewhere they can't grow. It's possible they will be filled, eventually, at a 1/[Number of Surface Tiles] chance. There's also the chance that some of your trees have grown in such a way where there's just short of enough space to place another, in which case you'd have to chop them down and see if they grow differently.

Addendum:
I'd also like to point out that embark trees are actually randomized at least in branch / leaf configuration. The heights are all disappointingly exact per tree type, however.

If trees do not spread out from existing trees then there would not be any observable cluster effect such as the one that we see in my screenshot.  The saplings are being placed everywhere, the only limitation being the proximity of existing grown-up trees.  Cluster effect means that the saplings are not being placed everywhere at once, since given 7 years of time they have basically got the time to place saplings on every inch of the map but for some reason not a single sapling was placed in some patches of the map.  If you cut trees down however, you get a whole swarm of saplings popping up in no time, this leads me to conclude that the map is randomly divided up into 'place-trees' and 'don't place trees' zones and the proximity factor is a second factor that helps to prevent the place-trees zones from becoming completely covered in trees.

[PatrikLundell]

I agree with Bumber that there is no memory difference between placing trees on embark or grow them later. GoblinCookie invokes the unstated growing of trees for decades as an implication of placing them on embark, and from there that the CPU consumption of that growing would lead to memory consumption (which someone used to Java might very well indeed do when trying to write C(++)). A grown individual tree with branches, twigs, etc. probably consumes more memory than a newly matured one, and it certainly would consume more than a pointer to one of a bunch of "standard" trees, but I would expect all trees on the embarks to be individuals (possibly cloned off of "standard" ones at embark). However, the trees would consume the same amount of memory regardless of whether they were placed on embark or grew later (of course, trees grown later would require memory later so there's a delayed memory consumption, but that's not what Bumber talked about).

GooblinCookie constantly refers back to his forest embark when everyone else talks about sparse embarks. Regardless, I don't think a bit over two sapling maturation periods (7 years) is sufficient to reach an end density state even in his case, ESPECIALLY if the meager mechanisms to reign in the treesplosion he talks about are there.

If you distribute stuff randomly, you're bound to randomly get empty patches as well as denser areas. Furthermore, I suspect saplings compete with herbs for placement, so you'd never get both in a tile, which means that the tile won't again be eligible for the sapling placement lottery until the herb dies.

[GoblinCookie]

I agree with Bumber that there is no memory difference between placing trees on embark or grow them later. GoblinCookie invokes the unstated growing of trees for decades as an implication of placing them on embark, and from there that the CPU consumption of that growing would lead to memory consumption (which someone used to Java might very well indeed do when trying to write C(++)). A grown individual tree with branches, twigs, etc. probably consumes more memory than a newly matured one, and it certainly would consume more than a pointer to one of a bunch of "standard" trees, but I would expect all trees on the embarks to be individuals (possibly cloned off of "standard" ones at embark). However, the trees would consume the same amount of memory regardless of whether they were placed on embark or grew later (of course, trees grown later would require memory later so there's a delayed memory consumption, but that's not what Bumber talked about).

That only makes sense if you are talking about memory in general as opposed to RAM. 

GooblinCookie constantly refers back to his forest embark when everyone else talks about sparse embarks. Regardless, I don't think a bit over two sapling maturation periods (7 years) is sufficient to reach an end density state even in his case, ESPECIALLY if the meager mechanisms to reign in the treesplosion he talks about are there.

If you distribute stuff randomly, you're bound to randomly get empty patches as well as denser areas. Furthermore, I suspect saplings compete with herbs for placement, so you'd never get both in a tile, which means that the tile won't again be eligible for the sapling placement lottery until the herb dies.

I do not refer to anything, Bumber asked for a screenshot to back up my understanding of how trees grow and I gave him one; I would be interested to see pics the sparse biome treesplosions people are complaining about.  Given how many saplings are placed on the map every year, there should not be any patches left if all after 7 years, since it takes about a year for a new tree to reach maturity and the new saplings are placed in areas that are not immediately adjacent to the existing trees the map should fill up completely by 7 years if there were no zone limitations on tree placement.

[PatrikLundell]

I'm talking about RAM. Regardless, you'd need a huge number of trees on the embark for their numbers to make a noticeable dent in the memory of a reasonably modern computer (i.e. hundreds of megabytes available to DF). If you're very inefficient and use 1 KB per tree 10000 trees will still not consume more than 10 MB, so memory will not be what limits you from completely covering the surface (and the caverns) in trees. And before you go back to the world wide tree count: I'm talking about the embark(s). I believe there is an agreement that the tree population outside of embarks need an efficient, probably generic, handling of some sort.

It takes about 3 years for a sapling to reach maturity (check the tree farm wiki page. I've also confirmed it recently with the first blood thorns in my farm reaching maturity after about 3 years).

[Bumber]

Again, there is no memory difference between placing them at embark or having them grow later. I shouldn't have to keep repeating this.

That is just wrong, provided you want the detail that we end up with to exist in your embark trees you will have to do all the tree-growth calculations for decades at least in one instant.  You could place all the trees in their default boring state to cover the map as much as the mechanics say it should be covered, but that results in a tree-farm effect.

The calculations are not all that difficult (and I disapprove of the use of the term 'instant' here. First embark can take about a minute.) It is less memory intensive to handle all the trees up front as abstract than it is to have new trees entering into your model after you've made them physical and lost the ability to optimize. You could flood fill the map with trees of varying ages and shapes (avoiding the tree farm effect,) but I must point out that it misses the entire point of the thread.

It does not look like it is too high to me, the tree density is extremely low for realism in that you cannot normally drive a wagon through a forest.

It's fine for an actual forest. It's not fine for a savanna, a valley, a grasslands, a forest glade, etc.

If trees do not spread out from existing trees then there would not be any observable cluster effect such as the one that we see in my screenshot.

That does not follow. The proof is that a forest embark that has been clear-cut does not replenish starting near surviving trees. Do you see a cluster effect here? (Notice the strangely-familiar gap near the top right.)

The saplings are being placed everywhere, the only limitation being the proximity of existing grown-up trees.

If you mean the limit is that they only can't get too close, this statement is in direct contradiction to your cluster assertion. If you mean they are placed in a set range, this is demonstratively false.

Cluster effect means that the saplings are not being placed everywhere at once, since given 7 years of time they have basically got the time to place saplings on every inch of the map but for some reason not a single sapling was placed in some patches of the map.

That isn't sufficient proof if it's randomized. Suppose you have a twenty-sided die. How many rolls does it take to land on every number at least once?

If you cut trees down however, you get a whole swarm of saplings popping up in no time, this leads me to conclude that the map is randomly divided up into 'place-trees' and 'don't place trees' zones and the proximity factor is a second factor that helps to prevent the place-trees zones from becoming completely covered in trees.

That's not sufficient. Where are the trees popping up? Can you identify these same zones each time?

[GoblinCookie]

I'm talking about RAM. Regardless, you'd need a huge number of trees on the embark for their numbers to make a noticeable dent in the memory of a reasonably modern computer (i.e. hundreds of megabytes available to DF). If you're very inefficient and use 1 KB per tree 10000 trees will still not consume more than 10 MB, so memory will not be what limits you from completely covering the surface (and the caverns) in trees. And before you go back to the world wide tree count: I'm talking about the embark(s). I believe there is an agreement that the tree population outside of embarks need an efficient, probably generic, handling of some sort.

It takes about 3 years for a sapling to reach maturity (check the tree farm wiki page. I've also confirmed it recently with the first blood thorns in my farm reaching maturity after about 3 years).

That simply is not true.  Modelling even one day's worth of tree growth on a large forested biomes taxes the RAM (or is it processing power?) of most modern computers, as I know from bitter experience.  What you are proposing is that during embark the RAM cope with the whole growth of a forest over years in a single moment!  There is a way around it however, the way round is to take 'time out' of the embark (or when loading a new area of the adventurer map) and dedicate the whole memory to filling the loaded area with trees that did not need to exist before.  At the end of tree-gen the trees are simply saved into the save-game file and can then be loaded into the game since static trees take far less memory to load than the process needed to grow them does.

It does not matter if it takes 3 years for a sapling to reach maturity because it certainly does not take that long for the saplings to be placed in the first place.  If there was 'treesplosion' the whole map should after a number of years be covered in saplings even if said saplings are not yet all grown trees.

The calculations are not all that difficult (and I disapprove of the use of the term 'instant' here. First embark can take about a minute.) It is less memory intensive to handle all the trees up front as abstract than it is to have new trees entering into your model after you've made them physical and lost the ability to optimize. You could flood fill the map with trees of varying ages and shapes (avoiding the tree farm effect,) but I must point out that it misses the entire point of the thread.

That is the tree farm solution and it is what is already in play for the initial trees that are placed on the map.  The devs have however clearly opted to make these trees few in number and not fully grown.  They have clearly rejected the tree-farm model, which even if randomised can still only manage a very limited array of shapes compared to the dynamic and competitive growth model which makes very interesting trees indeed. 

They could have just have the game calculate how many trees should be on the map given the local mechanics and then flood the map with that number of trees so that unless trees are cut down or tree dying is introduced things will remain static but they chose not to; stopping their automatic tree placement model from simply running until it cannot place any more trees. 

It's fine for an actual forest. It's not fine for a savanna, a valley, a grasslands, a forest glade, etc.

None of those are DF pictures so I have no idea what the final situation in those biomes looks like. 

Do you see a cluster effect here?[/url] (Notice the strangely-familiar gap near the top right.)

I do not see much of a cluster effect at all, there a small amount of clustering only because the dots are small and the number of them is small.  If the dots were large and they were free to multiply across the board, placing new dots at random locations in the white area it would not take very long until we end up not with a distribution of dots but a black sheet of total uniformity. 

If you mean the limit is that they only can't get too close, this statement is in direct contradiction to your cluster assertion. If you mean they are placed in a set range, this is demonstratively false.

I am talking about how the growth of trees are regulated within a tree-growth zone, where saplings are free to be placed randomly.  Within the tree growth zone the regulatory factor is the proximity of adult trees, new saplings do not get placed (and existing saplings get snuffed out) if they are too close to a grown up tree, the bigger the tree the further they have to be away from it. 

Strictly speaking the zones do not control the growth of adult trees but only the placement of new saplings, the adult trees are free to grow over the treeless zone to the limit of their size.  The map is divided up into "place saplings here" zones and "do not place saplings here" zones and that is why there is no 'treesplosion' as such.

That isn't sufficient proof if it's randomized. Suppose you have a twenty-sided die. How many rolls does it take to land on every number at least once?

400 rolls, is this supposed to be a mathematics puzzle?

If the distribution of something is indeed truly random then as the number of the item placed increases, the clustering in the placement of the items *must* decrease or else the situation is not truly random.  That there are, in an sapling-less area after 7 years of uninterrupted sapling placement then something is clearly going on.

That's not sufficient. Where are the trees popping up? Can you identify these same zones each time?

I have already identified such a zone Bumber, there is clearly one to the west of the lake in the south-east of the map; I could draw them if I wished by drawing around all the saplings and tree trunks on the map.  At the end of the day it does not matter, because I do not have to prove a negative, you have to prove that treesplosion exists and not I the reverse, especially given how extraordinary a claim it is to have the devs make such a detailed tree-growth model without putting in place any checks on tree growth even in arid treeless areas.

If your argument is simply that 7 years is not long enough for random increase to result in uniformity then come up with a 20-30 year map that shows the resulting uniform distribution of trees with no clusters in site.  Mere hearsay that such a thing as treesplosion exists is not sufficient. 

[PatrikLundell]

You clearly seem to confuse consumption of CPU cycles (and thus time) with consumption of RAM. I've never disputed creating an embark would take longer if trees were grown/generated at that time, and I don't think it's much of a problem if embark generation takes a bit longer (although it would be nice with a confirmation that the embark order had been given).

I do not dispute growing trees take a toll on the CPU (that's one of the complaints about the current DF version, after all), but a growing tree or a static tree of the same size takes the same amount of memory. Depending on implementation, adding a new branch may get stored into a tree object already allocated, or be generated as a new object on the heap (using maybe 20 bytes). As I've said before, you can use "template" or "standard" trees to have several trees on the map actually refer to the same tree object and thus save memory, but that's not very suitable for an embark, where trees ought to be distinct objects.

My tree farm had varying sapling density across the roughly 30*30 area after 3 years, but it was very far from dense. The embark has no other vegetation, so the sapling did not have to compete with either herbs or moss for a space on the farm. Not a single sapling had died at the end (with 4 trees on the farm, but fairly short time after those trees matured).

It's definitely false that new saplings do not appear right beside existing trees. I've manually (using dirt roads) killed off all unwanted vegetation in an orchard on a different embark from the tree farm above. Saplings have appeared right next to existing trees.

Nope, there is no number of rolls (except infinity) that guarantees the appearance of all sides on a D20. The number of rolls required to land all numbers with a given probability (e.g. 50%, 89%, 95%, 99%, etc) can be calculated, but there is a non zero probability for any finite number of rolls you chose to fail to display all sides.
If you randomly place saplings on an otherwise completely empty stretch of land you end up with random clusters with a probability extremely close to 100% (provided the area is of a reasonable size), i.e. always in practice. If the process continues unchecked, it will gradually change into a pattern of random blank patches, and eventually get completely saturated. This means clusters will always appear in practice. Letting the same embark grow unchecked from the same initial save for 30 years would probably result in two completely different sets of overgrown maps with random gaps in it. There is a small risk the same RNG seed is used isolated for tree and sapling generation, in which case you'd end up with the same overall pattern (trampling would still generate minor differences), but probably the RNG seed is shared among everything in the fortress, so anything the player does early on will desynchronize the RNG numbers. Digging into a single rock tile would draw a pseudo random number to determine if a boulder was generated or not, moving any dorf would probably result in a trampling pseudo random number draw, etc. Unfortunately, it requires work to do this comparison test, since the dorfs would die off well within 30 years, so you can't just start it up and let it run in the background (unless there is some DFHack or similar intervention that would permit the embark to continue without any dorfs present).