TERRAIN_MAX_AUTOGEN_TREES_PER_CELL

[arno]

Does anybody know how the TERRAIN_MAX_AUTOGEN_TREES_PER_CELL settings works with polygonal vegetation? Does a polygon count as one tree or do they count as multiple after the polygon is rasterized?

 

[GaryGB]

Does anybody know how the TERRAIN_MAX_AUTOGEN_TREES_PER_CELL settings works with polygonal vegetation? Does a polygon count as one tree or do they count as multiple after the polygon is rasterized?

Hi Arno:

I was intrigued by this possible interaction, so I reviewed this thread and its linked threads:

http://www.fsdeveloper.com/forum/threads/installing-custom-autogen-configuration.428760/page-3


IIRC, the consensus at that time was 'minimally-small-sized' autogen annotator vegetation polys were effectively treated by the rendering engine as capable of rendering as little as 1-tree (IIUC, due to the resulting rasterized pixel size).

But, IIUC, if a AGN annotator vegetation poly is larger, and at run time one gets more trees rendered within that poly, would not each displayed ex: tree ...count towards the internal ex: 6000 tree limit the rendering system has for display of individual AGN vegetation objects ?

I wonder what the actual number of "vegetation objects" rendered from vegetation "polys" were that Holger demonstrated in the fascinating (and at that time, vigorously debated) thread on autogen display and the pros / cons of "autogen attenuation tweaks" (see attached 'FSX - Holger's Autogen Tweak - AVSIM controversy with Nick_N.zip' archive with pix ...of the original AVSIM thread here):

http://www.fsdeveloper.com/forum/threads/increase-number-of-autogen.20381/#post-141363


It would indeed be an interesting test to see if, when the autogen "cell" was already super-saturated at the max (6000) trees [per_LOD-13 / QMID-15 _sized ] quad tile, whether the rasterization sub-system yields more trees inside very small AGN vegetation polys !


https://support.microsoft.com/en-us/kb/555739

https://msdn.microsoft.com/en-us/library/cc526979.aspx#CreatingBuildingFootprints


Hope this helps with achieving a more definitive answer to your question in the OP.

GaryGB

 

[HolgerSandmann]

Hi Arno,

back in 2010 I did some systematic testing on this and found that TERRAIN_MAX_AUTOGEN_TREES_PER_CELL applies to each vegetation rectangle or polygon separately, meaning the sim will display up to the given value in each rectangle or poly with spatial extent being the density constraint. For example, if one places multiple rectangles or polygons covering an entire landclass QMID15 cell using the maximum value of 6000 then one ends up with multiples of 6000 trees on that cell. It's a great way to bring any PC to its knees ;-) Below are some of the notes I kept from that test.

Cheers, Holger


======================
In Annotator I created a regular grid of 1x1 pixel annotation rectangles, which makes it easy to determine whether all trees are showing in the sim. In total there are 7 x 7 100-tree grids meaning 4900 trees per QMID15 cell.

With the autogen slider set to Extremly Dense it makes no difference what value I choose for TERRAIN_MAX_AUTOGEN_TREES_PER_CELL. Even at "0" all 4900 trees show up, which confirms that the number of annotator rectangles overrides any TERRAIN_MAX_AUTOGEN_TREES_PER_CELL setting.

Moving the autogen density slider to the left each notch drops ~20% of the trees from the test area, meaning the autogen density slider works as expected. Interesting side note: FSX doesn't appear to remove trees at random but rather in clusters. I assume that approach is computationally more efficient. It's less obvious with the typical irregular distribution of trees but I checked and it happens with all vegetation classes and probably buildings too.

For the next test I replaced the grid of 1x1 boxes with a single box covering most of the QMID15 cell. I don't have an actual tree count in this case but it's obvious that the TERRAIN_MAX_AUTOGEN_TREES_PER_CELL parameter has an effect. Without this value you're probably seeing up to 4500 trees in the QMID15 cell while a value of 1000 removes about 80% of those trees as expected.

Now, when I add a second box (with a different tree type) and keep the limit at 1000 the density increases and again if I add a third box. That's what made me realize that this is what TERRAIN_MAX_AUTOGEN_TREES_PER_CELL does: it limits density for each annotation box independently and not overall density for the QMID15 cell.

I've cross-checked this by comparing three big boxes at TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=1000 with one big box at TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=3000. Indeed, they show the same overall tree density.

The same thing happens with polyregions, the irregular "boxes" that also can be used for vegetation; for each additional large polyregion in the same QMID15 cell you get another full set of trees determined by TERRAIN_MAX_AUTOGEN_TREES_PER_CELL.

In another test I placed several non-overlapping rectangles of different sizes and varied the TERRAIN_MAX_AUTOGEN_TREES_PER_CELL setting. The density in each box always remained the same meaning the limit that TERRAIN_MAX_AUTOGEN_TREES_PER_CELL imposes for each rectangle is the proportion of the rectangle of the the entire QMID15 cell. In other words, with TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=1000 a rectangle covering half a QMID15 cell displays 500 trees, a quarter-size rectangle 250 trees, etc. Thus, TERRAIN_MAX_AUTOGEN_TREES_PER_CELL really only becomes ineffective with overlapping boxes.

 

[arno]

Thanks for the feedback, interesting information.

I'm asking this because sometimes when there are too many trees in a cell, no trees will show at all. So I'm thinking about adding a warning to scenProc to inform when you go over the limit. But then I need to understand how the limit works first

Holger, do I understand you correctly that it's a limit per rectangle/polygon, but I think there is also a limit on the maximum amount of rectangles you can have. I had some issues with many small (one pixel) rectangles when I tried to make sense bushes.

 

[HolgerSandmann]

Hi Arno,

Indeed, we found that there does seem to be a "stress" limit with placing 1x1 vegetation rectangles and that's about 6,000 (I don't know whether it's coincidence that it's the same number as the maximum listed value for TERRAIN_MAX_AUTOGEN_TREES_PER_CELL listed in the SDK). In our experience going above that number can lead to (random) loss of autogen as well as vegetation being displayed on nearby waterbodies. Thus, we generally try to stay below 5,500 rectangles per QMID15 cell.

And, yes, TERRAIN_MAX_AUTOGEN_TREES_PER_CELL controls the max amount of trees per rectangle or polygon, not per QMID15 cell. Interestingly, the parallel TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL parameter does in fact work as a cap on the entire QMID15 cell, which is why it took me a while to wrap my head around the difference.

Cheers, Holger

 

[arno]

Hi Holger,

Thanks, that confirms what I see as well. I think it will be save if I add a check for the amount of vegetation objects and buildings in scenProc, with a user selectable limit (which should be in line with the default settings of FS).

Do I understand you correctly that the tree limit of TERRAIN_MAX_AUTOGEN_TREES_PER_CELL per object does not really result in missing vegetation, it more controls the maximum density you can reach?

 

[GaryGB]

In consideration of the test results cited above, I'm wondering if "(random)" autogen blanking Holger reported, may have been associated with:

* Overlapped vegetation polys in a single "layer" yield a local "child" polygon area interpreted by FS rendering engine as > 6000 autogen Tree / Vegetation object limit ?

http://www.fsdeveloper.com/forum/threads/increase-number-of-autogen.20381/


* Overlapped vegetation polys in multiple "layers" yield a local "child" polygon area interpreted by FS rendering engine as > 6000 autogen Tree / Vegetation object limit ?

http://www.fsdeveloper.com/forum/threads/adding-more-autogen-to-default-scenery-landclass.52826/


* Overlapped vegetation polys in either single or multiple "layers" yield a local poly interpreted by FS rendering engine as a "child" polygon area exceeding the > 6000 autogen Tree / Vegetation object limit; this then yields a area object density exceeding > 43690 triangles per material ?

http://www.fsdeveloper.com/forum/threads/texture-vertices-limit.424405/


* Overlapped vegetation polys in multiple "layers" yield a local poly interpreted by FS rendering engine as a "child" polygon area exceeding the > 6000 autogen Tree / Vegetation object limit ...when transparent 'properly' blend-masked custom photo-real land class ...is annotated,
thus maxing out when merged with annotations from land class layers underneath the PR layer ...that "show through to the top" in FS at run time ?

http://www.fsdeveloper.com/forum/th...alpha-channel-is-present-c.21460/#post-142021


* Overlapped vegetation polys in multiple "layers" yield a local poly interpreted by FS rendering engine as a "child" polygon area exceeding the > 6000 autogen Tree / Vegetation object limit ...when otherwise 'invisible' custom photo-real land class or the non-visible portion of land class polygons (extending from the periphery of the visible poly to the tile borders) ...are annotated, thus maxing out when merged with annotations from land class layers underneath the PR layer ...that "show through to the top" in FS at run time ?

http://www.fsdeveloper.com/forum/threads/autogen-on-transparent-photoscenery.424378/


* Large size of vegetation polys used with low pixel count parameter values for "IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS" creates Autogen areas which when rendered by FS at run time are interpreted as 'spilling over' onto adjacent QMID grid Autogen tile areas ?

http://www.fsdeveloper.com/forum/threads/fsx-autogen-crashes.5835/

http://www.fsdeveloper.com/forum/threads/installing-custom-autogen-configuration.428760/page-3

https://msdn.microsoft.com/en-us/library/cc526979.aspx#CreatingBuildingFootprints


I'm also curious whether the same general principles / limits for vegetation polygons apply to vegetation rectangles, while also considering the 1/10th lesser density of Tree / Vegetation objects limit in FS9 ?

http://www.fsdeveloper.com/forum/threads/fs2004-scenproc-autogen-causes-fs9-crash.424608/

http://www.fsdeveloper.com/forum/threads/detectfeatures-and-rectangular-vegetation.430935/

http://www.fsdeveloper.com/forum/threads/agn-merge-tool.396534/



FYI: Many of us still use the SDK Annotator manually, and may also merge those annotations with those derived from AutoTrees and/or AgenT from the FS9 AGN XML file format, and may even further combine those source files with the output from ScenProc.

Thus, it would be helpful to know how these limits actually work with regard to FS9, so we will know how to set up any applicable limits to our annotation data in source files, since reportedly annotation density is tolerated / ignored beyond the limits of what the FS9 run time rendering engine can / will display, but those same FS9 source files are also able to be further processed to make autogen for FSX (...which may incur a newer set of rules and "gotchas").


Thanks in advance for any additional clarifications for these questions, and for consideration of the possible uses for this info within FS9 as well.


PS: Sorry for interjecting so many "as-yet-un-answered-questions-about-how-MSFS-autogen-works" into Arno's information-gathering thread, but IMHO these issues may have a bearing on how ScenProc evolves, and how FS developers work with autogen for FS9 / FSX / P3D ...now and in the future, using ScenProc as well as 'other' autogen tools.

GaryGB

 

[stonelance]

I can look at the code and find the exact answer for you, but my understanding is that the value is used as a density, and not a max. For rectangular annotations, it takes the normalized area (where a rectangle covering the entire texture has an area of 1) and multiplies it by the TERRAIN_MAX_AUTOGEN_TREES_PER_CELL and by a density scalar based on the autogen density slider. In Flight there was special logic for handling of small rects that only placed one tree, but I think that behavior was slightly different than FSX, so I need to look it up. Can't remember off the top of my head how polygon annotations work, but I expect they are based on density similar to rectangles. I believe the density is also affected by the size of the tree. There is some logic to try to prevent vegetation from being placed within a certain radius of each other, but I think it only applies for vegetation generated from the same rect\poly.

 

[HolgerSandmann]

Hi guys,

I agree with stonelance, i.e., the TMAT parameter regulating density, with the important point that this is applied independently to each vegetation annotation rectangle or polygon. I've attached below a couple of screenshots from my tests. The first pair shows 4900 trees placed on a QMID15 with individual tiny rectangles so that each rectangle provides only space for a single tree. Note that TERRAIN_MAX_AUTOGEN_TREES_PER_CELL is set to 1000 yet all trees are displayed meaning this parameter is not a cap on tree numbers or density per QMID15. In contrast, changing the autogen density slider from extremely dense to dense removes ~40% of the trees (20% per slider notch).

The second pair shows how polyregions are treated independently. It's a bit hard to see but tree density per polgon remains the same while tree numbers are additive in terms of the QMID15 cell.

The third pair shows the effect of TERRAIN_MAX_AUTOGEN_TREES_PER_CELL when using four overlapping vegetation rectangles that cover the entire QMID15 cell. With TMAT set to 1000 each rectangle is capped at ~1000 trees and thus the total number displayed is ~4000; with TMAT set to 4500 one ends up with ~18,000 trees (!) on the QMID15 cell -- and a slide show...

Cheers, Holger

 

[arno]

Thanks for all the additional information. Makes sense in a way TMAT determines the maximum amount of trees per tile, for an area that covers the entire tile. But if we overlap areas we can go above this limit (until we kill the performance too much).

Just curious why I had some cells with all vegetation disappearing recently. I must have gone over some other limit in that case. But I can't find or reproduce it yet. I just tried to place a lot of vegetation rectangles (more than 100000 per cell) and they just show . I'll continue searching for the limit here...

 

[HolgerSandmann]

Hi Arno,

I never had any issues in my test areas either, only when using files that went "above limits" in projects, meaning it appears that local context (e.g., adjacent CVX components) is important. In one case we had a forest tile with >6000 rectangles that displayed fine in the test area but placed trees on the water in the scenery area; dropping back under 6,000 solved the issue.

One thing I've always wondered about, though only indirectly related: how does Annotator compile coordinates from the out-of-bounds areas of a given landclass QMID15 tile? As you probably know it's possible to draw parts or all of rectangles/polyregions outside of the tile's 1024x1024 area. Does Annotator wrap those sections around (like on a torus) or are they simply clipped? The out-of-bounds parts are invisible in the Annotator GUI but can be selected; moreover, they are still there after saving the .agn and re-loading the tile, which points against clipping.

Cheers, Holger

 

[arno]

I would expect those coordinates are just stored as they are in the agn file. The rendering engine might clip them. I'll have a look, should be easy to check

 

[arno]

Hi Holger,

I checked what happens with vegetation rectangles that cover multiple tiles. Annotator only places them in one AGN file (where the start point is). But the size of the rectangle is too big in that case to fit in one cell. I haven't tested in FS yet how they are rendered, if they are clipped at rendering or not.

 

[stonelance]

Coordinates are normalized (I think -0.5 to 0.5) in the agn file if I remember correctly. You can put values outside that range, and it will just place them outside the QMID. I know in Flight if you do this it will still render them, but since the rendering code assumes everything is within the QMID, they will get culled incorrectly, so you will end up with vegetation disappearing randomly, or not showing up when it should. I think you can also end up with vegetation over water. Since FSX is batched, it may have different behavior and not be affected by culling as much.