scenProc generating trees inside buildings

[Epsilon90]

Hello all,

I'm having an annoying problem when compiling the autogen with scenProc. I am trying to make all the area of Luxembourg with photoreal terrain and autogen over it.
I have no problems with generating it, everything goes smoothly, I'm seeing houses, trees (at least the maximum amount my FSX can generate as there are a real lot!) and warehouses.
The problem comes on this last: I uploaded a screenshot where it's clearly visible that generated trees are going through the largest buildings and I have no idea how to fix this (and to be honest I'm not optimistic at all about this issue).

As always, help of any kind is much appreciated!

 

[MyPC8MyBrain]

there is nothing wrong with scenProc's output there!
you need to better prep your data or refine your script,

 

[iangbusa]

Either clip the tree polygons in QGIS using your building polygons or your chosen GIS or use scenProc steps to clear some space in your vegetation polygons. See SubtractFeatures in the documentation.

 

[Epsilon90]

there is nothing wrong with scenProc's output there!
you need to better prep your data or refine your script,

Either clip the tree polygons in QGIS using your building polygons or your chosen GIS or use scenProc steps to clear some space in your vegetation polygons. See SubtractFeatures in the documentation.

Thanks to both for answering, but the problem is that a few trees are spawned outside the vegetation boundaries: in the .shp file opened in QGIS, the buildings.shp and vegetation.shp shapes don't touch each other so there isn't really anything to fix there; I'm sure this is a known issue (I've noticed it even in Arno's tutorials) that a few trees spawn outside the boundaries defined in the shapefile, but has this problem been solved somehow in the years?

 

[MyPC8MyBrain]

not sure where you read that; its not a known issue atm,

 

[arno]

It could depend on your FS settings. There is a setting that determines which resolution is used when drawing the vegetation. Try increase that and the shape gets more accurate.

 

[Epsilon90]

It could depend on your FS settings. There is a setting that determines which resolution is used when drawing the vegetation. Try increase that and the shape gets more accurate.

Thanks for replying dear Arno, do you remember moreless the name of this one? Is it in the FSX Settings or where?

 

[arno]

It's in the fsx.cfg file, see a sample below. Increase the value to get a better shape (but at the cost of some performance of course).

[TERRAIN]
IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=16

 

[Epsilon90]

It's in the fsx.cfg file, see a sample below. Increase the value to get a better shape (but at the cost of some performance of course).

[TERRAIN]
IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=16

Thanks Arno, I'll give it a try once I'm back home later today.

 

[Epsilon90]

Ok so thanks a lot to everyone for the help you're trying to give me; unfortunately the method Arno mentioned didn't work at all, everything just remained the same. Could this be a bug resulting from a too high autogen density setting (mine is set to the max)?

 

[RicherSims]

Could you provide a screenshot of your vector data for the area in your GIS software? As well as your code for scenproc? Maybe that might help us identify your issue.

 

[Epsilon90]

Could you provide a screenshot of your vector data for the area in your GIS software? As well as your code for scenproc? Maybe that might help us identify your issue.

I attached two screenshots of my loaded data in QGIS: buildings and natural of the whole country of Luxembourg (and as you can see, in the zoomed screenshot, the layers are made specifically not to touch each other).
This is the code:

Spoiler: Code

IMPORTOGR|C:\Users\utente\Desktop\Luxembourg\Autogen\natural.shp|*|*|NOREPROJ
IMPORTOGR|C:\Users\utente\Desktop\Luxembourg\Autogen\buildings.shp|*|*|NOREPROJ
#
SPLITGRID|AGN|*|FROMFILE=buildings.shp
#
CREATEAGNPOLYVEG|FTYPE=POLYGON|{e8b937fd-a1f2-4bd5-8548-2c80d30102af}
#
CREATEAGNGENBUILD|FTYPE=POLYGON;FROMFILE=buildings.shp;FWIDTH<20|{5ae04eb6-934c-4f63-bb48-5e7dee601212}|MAXRATIO=2
CREATEAGNGENBUILD|FTYPE=POLYGON;FROMFILE=buildings.shp;FWIDTH>20|{6089A0BD-CED1-4c47-9A9E-64CDD0E16983}
#
EXPORTAGN|FSX|C:\Users\utente\Desktop\Luxembourg\Autogen\texture

 

[GaryGB]

Hello:

You may wish to test additional numeric values for the "IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS" parameter value.

AFAIK, FS will show no perceptible performance hit on a modern computer with a parameter value setting of 1024, and this will increase the precision with which the FS terrain scenery engine renders autogen vegetation polygons at run time.

https://www.google.com/#q=site:www.fsdeveloper.com+"IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS"


PS:

Arno, because some developers utilize either of (2) methods for annotating vegetation, and in a general non-FS context, a square or rectangle is technically also a "polygon", and since all such object types used for annotating vegetation technically also 'closed poly-lines':

* could you please tell us whether Vegetation Rectangle / 'square' annotation IS- or is NOT- subject to processing by the parameter value cited immediately above

...as FS Autogen SDK documentation could be interpreted by some as inferring that parameter value may impact < only ? > Vegetation Polygons:

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

"Note

• Polyline vegetation is rasterized into a sampling bitmap. The granularity of the rasterization is determined by the following setting in the ESP.cfg file:
  
• [TERRAIN]
  IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=16
  
  The value of this setting is set at the minimum, 16, and can be any value up to 2048. The higher the number the more accurately a curved polygon will be rasterized. The value 16 indicates a rasterization of approximately 80 meters down to approximately 0.5 meter accuracy for the 2048 setting. There is a performance penalty with the time it takes to rasterize a region, and the memory required for the resulting sampling bitmap."

IIUC, FS SDK Annotator treats Vegetation Rectangles / 'squares' differently from Vegetation Polygons.


Thanks in advance for your clarification of this functionality, also recently discussed in this thread:


http://www.fsdeveloper.com/forum/threads/revisiting-autogen-vegetation.438168/


GaryGB

 

[RicherSims]

It does in fact look like the sim is simplifying your vectors. Increasing the IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS may work, but even if it does, your users will have to edit their CFG... or you will have to do it for them. A process many try to avoid.

Here is another solution you can look into.
Instead of using large polys for your vegetation, consider using smaller vegetation rectangles.
You can either use scenproc to fill your polys with REPLACEPOLYGONSBYRECTANGLES or use your GIS software to create points within your polys and then convert those to rectangles in scenproc.
(I find the 2nd method to be faster, for some reason it took many hours for REPLACEPOLYGONSBYRECTANGLES to complete on a rather small dataset on my machine).

GlobalMapper does this extremely efficiently, but since you are using QGIS:

1) Load your vegetation polys
2) Go to Vector > Research Tools > Random Points
3) Set the Density of Points under Stratified Sampling Design (Individual Polygons)
Note: You may get no output from QGIS using the density method, if that fails you will be forced to use a total Number of points under Unstratified Sampling Design (Entire Layer)
4) Specify the output shapefile.
5) Click OK

I recommend working on a subset of your dataset to see if this works for you at first, as these processes tend to take a while.

Then use Scenproc's CREATEAGNRECTVEG with the filter set to points. This should create vegetation rectangles at each point, which will more accurately remain within the boundaries of your original polygons, and, more importantly, not get simplified by the sim.

Let me know if this works for you.
Regards,
Zev.

 

[arno]

Arno, because some developers utilize either of (2) methods for annotating vegetation, and in a general non-FS context, a square rectangle is technically also a "polygon", and both objects use 'closed poly-lines':

* could you please tell us whether Vegetation Rectangle / 'square' annotation IS- or is NOT- subject to processing by the parameter value cited immediately above

...as FS Autogen SDK documentation could be interpreted by some as inferring that parameter value may impact < only ? > Vegetation Polygons:

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

"Note

• Polyline vegetation is rasterized into a sampling bitmap. The granularity of the rasterization is determined by the following setting in the ESP.cfg file:
  
• [TERRAIN]
  IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=16
  
  The value of this setting is set at the minimum, 16, and can be any value up to 2048. The higher the number the more accurately a curved polygon will be rasterized. The value 16 indicates a rasterization of approximately 80 meters down to approximately 0.5 meter accuracy for the 2048 setting. There is a performance penalty with the time it takes to rasterize a region, and the memory required for the resulting sampling bitmap."

IIUC, FS SDK Annotator treats Vegetation Rectangles / 'squares' differently from Vegetation Polygons.


Thanks in advance for your clarification of this functionality, also recently discussed in this thread:

As far as I know that setting is only for the polygonal autogen indeed, not for the rectangular one.

 

[GaryGB]

Thanks for that clarification, Arno !

GaryGB

 

[GaryGB]

Hi Zev:

I have not yet had time to tinker with ScenProc in any extensive detail on a project such as the one under discussion in this thread, but after looking at the above screenshots by the OP, and examining the Open Street Map "gis.osm_natural_free_1.shp" file containing 'Points' for trees in that part of Luxembourg on a ESRI ArcGIS World Imagery background in Global Mapper, IMHO, it appears from tree positions displayed in FS, that the autogen annotation polygons themselves may be imprecise (perhaps more due to the derivation achieved during vegetation detection as a function of color selection settings the OP used with aerial imagery in ScenProc ).

One might wonder whether the OP may have detected some (real world) building shadows and dark rooftops ...as vegetation ?

< ...linked from the OP attachment above in this thread >

Google Earth download URL: https://www.google.com/earth/

Google Earth view "placemark" KMZ:

http://www.fsdeveloper.com/forum/attachments/luxembourg-stahlskulptur_kmz-zip.31439/

Open Street Map SHP file URLs:

http://download.geofabrik.de/europe/luxembourg.html

http://download.geofabrik.de/europe/luxembourg-latest-free.shp.zip

Since the OP uses QGIS, what would you additionally suggest that the OP consider doing to combine the 'Tree' Point data in ex: "gis.osm_natural_a_free_1.shp" with the results of converting his existing autogen annotation vegetation polygons to autogen annotation vegetation rectangles / squares ?


And, would you further suggest he:

* clip the initial SHP data set of vegetation polygons to other vector objects (ex: buildings) in luxembourg-latest-free.shp.zip

...or:

* clip the subsequent SHP data set of vegetation rectangles / squares to other vector objects (ex: buildings) in luxembourg-latest-free.shp.zip

...or:

* manually clean up the *an.agn files after output by ScenProc and SDK compilation


[EDITED]

Alternatively:

It is apparent that the OP is using Generic buildings as output by ScenProc after that type of "object detection" from either within ScenProc or via imported SHP files, and perhaps via a 'hybrid' method as you recently described in this thread:

http://www.fsdeveloper.com/forum/th...agery-for-autogen-creation-in-fsx-p3d.437969/.


It seems that shape / positioning of those Generic buildings output by SceneProc after having interpreted what was detected / derived from original 'real world' aerial imagery ...only "approximate" those in the original imagery.

Since the 'derived' vegetation polygons are based on original 'real world' aerial imagery, and do not in all cases match the shape / positioning of the Generic buildings as interpreted / created by ScenProc:

* does ScenProc have the ability to output a SHP file of those 'derived' vector areas of FS' Generic buildings (IIUC, originally output as BGLComp-type XML) that the OP can use to "clip" the 'derived' autogen vegetation data set output by ScenProc ...to remove trees from vector areas of those FS' Generic buildings?


But perhaps this is yet another question to be answered by Arno, as it would seem from the documentation for ScenProc that although one can currently create and export XML scenery, one can not yet import BGLComp-type XML either directly from BGLs or indirectly from de-compiled BGLComp-type BGLs.

One might wonder whether there is at least a BGLComp-type XML intermediate work product accessible from somewhere within ScenProc, that one may retain and further utilize to generate such a SHP file of those 'derived' vector areas of FS' Generic buildings ?


But I can also see a number of other useful applications for expanding the ScenProc feature set to include import of BGLComp-type XML, either directly from BGLs or indirectly from de-compiled BGLComp-type BGLs.

[END_EDIT]


Thanks in advance for sharing more of your insights on this interesting topic.

GaryGB

 

[RicherSims]

Gary if I am understanding your post correctly you are assuming that he has derived vegetation polys using scenprocs FEATUREDETECTION. I do not think that that is the case. They seem to be vector data from an online GIS source.

As for the polys themselves being imprecise; I also doubt that is the case, as trees and buildings do not overlap in the GIS software (hence clipping of any datasets cant be done), but they do in the sim.

 

[GaryGB]

Hi again, Zev:

Indeed, I assumed that (1) or more SHP files saved to disk by ScenProc was utilized in the code shown by the OP above:

http://www.fsdeveloper.com/forum/th...ng-trees-inside-buildings.438647/#post-757761

IMPORTOGR|C:\Users\utente\Desktop\Luxembourg\Autogen\natural.shp|*|*|NOREPROJ
IMPORTOGR|C:\Users\utente\Desktop\Luxembourg\Autogen\buildings.shp|*|*|NOREPROJ
#
SPLITGRID|AGN|*|FROMFILE=buildings.shp
#
CREATEAGNPOLYVEG|FTYPE=POLYGON|{e8b937fd-a1f2-4bd5-8548-2c80d30102af}
#
CREATEAGNGENBUILD|FTYPE=POLYGON;FROMFILE=buildings.shp;FWIDTH<20|{5ae04eb6-934c-4f63-bb48-5e7dee601212}|MAXRATIO=2
CREATEAGNGENBUILD|FTYPE=POLYGON;FROMFILE=buildings.shp;FWIDTH>20|{6089A0BD-CED1-4c47-9A9E-64CDD0E16983}
#
EXPORTAGN|FSX|C:\Users\utente\Desktop\Luxembourg\Autogen\texture

But, however it was that the "natural.SHP" file cited above by the OP was originally derived, it seems to me as though there might have been a color pattern recognition algorithm used which may have "detected" vegetation in areas where there is a particular mix of adjacent dark and light colors.


IMHO, when the OP screenshot from FS is compared with the Google Earth aerial imagery (ex: using the provided KMZ file I posted above to 'jump' to that part of Luxembourg), "imprecision of vegetation detection" can be seen in the areas of:

* Luxexpo conference & exhibition center building roofs

* Auchan shopping mall near Association des Armuriers et Négociants d'Armes and Chambre des Métiers du Grand-Duché de Luxembourg

* BGL BNP Paribas Business Center (Luxembourg)-Bank

* RBS Global Banking

* DekaBank Deutsche Girozentrale


I do agree, though, that in other areas, vegetation detection certainly seems to have been quite accurate, but some trees appear to be 'out of place' ...primarily due to the size and type of the Generic buildings ScenProc placed over them.


Until the OP posts detailed local screenshots of the "natural" and "buildings" SHP files used in the above ScenProc processing in a composite image showing them super-imposed on top of the local aerial imagery in a similar view to that of the OP's FS screenshot, we certainly might be speculating as to the precise shape of the vegetation polygons that the OP used in the ScenProc IMPORTOGR step shown in the code quoted above.


One might wonder whether the ScenProc detection / creation of Generic buildings (whether from processing of imported SHP or analysis of aerial imagery) might be further fine-tuned to more accurately match the footprints of the real world buildings in aerial imagery ?


Or perhaps the OP might be able to further adjust the FWIDTH or other parameters discussed in the wiki "Luxembourg" example:

http://www.fsdeveloper.com/wiki/index.php?title=Autogen_from_OpenStreetMap_data_with_scenProc


...in the ScenProc PDF documentation file:

http://www.fsdeveloper.com/forum/threads/download-scenproc.111509/


...and in:

http://blogs.msmvps.com/arnogerretsen/2011/10/24/scenproc-improved-filtering/

"I used the FWIDTH parameter to filter on the object width. That way I tried to filter houses from bigger buildings."


http://www.fsdeveloper.com/forum/threads/in-need-or-config-for-buildings-using-shp-files.435294/

https://www.youtube.com/watch?v=09RrJMWQ7cI

Thanks again for sharing your insights and perspectives on this interesting ScenProc project.

GaryGB

 

[GaryGB]

Hello again, Epsilon90:

Would you be willing to disclose where / how you got these source files processed by ScenProc as shown in your code posted above:

IMPORTOGR|C:\Users\utente\Desktop\Luxembourg\Autogen\natural.shp|*|*|NOREPROJ

IMPORTOGR|C:\Users\utente\Desktop\Luxembourg\Autogen\buildings.shp|*|*|NOREPROJ


If those SHP files are from earlier phases of your work-flow in ScenProc, could you please post those files or link to them for purposes of learning how the autogen vegetation has appeared inside both the real world and Generic building areas seen in the OP FS screenshot and in Google Earth ?

Thanks in advance for helping us help you better, and for facilitating this exploration of the work-flow options available to improve end results with the QGIS software, and with the existing (and possible future) features as implemented by ScenProc.

GaryGB