Jump to content
Sign in to follow this  
kjjj11223344

Ortho4XP for FSX/P3D

Recommended Posts

14 minutes ago, cwburnett said:

Rob, when I do what you're describing, my O4XP reuses the osm files, so something different with your setup. Do you have a Base Folder setup?  My step 1 and step 2 complete in 60 seconds for a grid I've already downloaded.

Here's what I see when I re-run a grid...


Batch build launched for a number of 1 tiles.
Dealing with tile  1 / 1 : +41+027

Step 1 : Building vector data for tile +41+027 : 
--------

-> Dealing with airports
    * Recycling OSM data from ..\OSM_data\+40+020\+41+027\+41+027_airports.osm.bz2
   LTBU   Tekirdağ Çorlu Atatürk Airport                               1 runway , lat= 41.14, lon= 27.91
   Loading elevation data and smoothing it over airports.
    * Min altitude: -5.0 , Max altitude: 1026.0 , Mean: 204.62967
   Auto-patched 1 runway and 5 pieces of taxiway.
   Flattened 33 helipads.
   Number of edges at this point: 1090
-> Dealing with roads
    * Recycling OSM data from ..\OSM_data\+40+020\+41+027\+41+027_big_roads.osm.bz2
    * Checking which large roads need levelling.
    * Buffering banked road network as multipolygon.
      Encoding it.
    * Encoding the remaining primary road network as linestrings.
   Number of edges at this point: 32463
-> Dealing with coastline
    * Recycling OSM data from ..\OSM_data\+40+020\+41+027\+41+027_coastline.osm.bz2
    * Encoding coastline.
    * Reconstructing its topology.
      Found  3 contiguous patch(es).
   Number of edges at this point: 32887
-> Dealing with inland water
    * Recycling OSM data from ..\OSM_data\+40+020\+41+027\+41+027_water.osm.bz2
    * Building water multipolygon.
      *  Marmara Denizi will be masked like the sea due to its large area of 11179 km^2.
      Cleaning it.
      Encoding it.
      Separate treatment for larger pieces requiring masks.
      Encoding them.
   Number of edges at this point: 61537
-> Inserting edges related to the orthophotos grid
-> Inserting additional boundary edges for gluing
-> Transcription to the files  S:/Apps/Ortho4XP_Data\zOrtho4XP_+41+027\Data+41+027.poly and .node

Final number of constrained edges : 73517

Completed in 42.00sec.
_________________________________________________________________________________________________

Step 2 : Building mesh for tile +41+027 : 
--------

-> Modifying curv_tol weight map according to runway locations.
-> Modifying curv_tol weight map according to coastline location.
    * Recycling OSM data from ..\OSM_data\+40+020\+41+027\+41+027_coastline.osm.bz2
-> Start of the mesh algorithm Triangle4XP.
   Loading altitudes from DEM file.

   Loading curv_tol geographic weights.

   Computing curvatures from altitudes.

   Constructing Delaunay triangulation by divide-and-conquer method.

   Recovering segments in Delaunay triangulation.

   Spreading regional attributes.

   Adding Steiner points to enforce quality.

   Computing altitude and normal maps.

   Node file S:/Apps/Ortho4XP_Data\zOrtho4XP_+41+027\Data+41+027.1.node written to disk.

   Tri file  S:/Apps/Ortho4XP_Data\zOrtho4XP_+41+027\Data+41+027.1.ele  written to disk.



   Statistics:



   Input vertices: 71374

   Input segments: 73517

   Input holes: 0



   Mesh vertices: 201,853

                   -----------------

   Mesh triangles: ---> 395,363

                   -----------------

   Mesh edges: 597215

   Mesh exterior boundary edges: 8341

   Mesh interior boundary edges: 78983

   Mesh subsegments (constrained edges): 87324



-> Loading of the mesh computed by Triangle4XP.
-> Post processing of altitudes according to vector data
   Smoothing inland water.
   Smoothing of sea water.
   Treatment of airports, roads and patches.
-> Writing output nodes file.
-> Writing final mesh to the file S:/Apps/Ortho4XP_Data\zOrtho4XP_+41+027\Data+41+027.mesh

Completed in 20.77sec.
_________________________________________________________________________________________________

Step 3 : Building DSF/Imagery for tile +41+027 : 
--------

-> Initializing providers with potential data on this tile.
-> Opening download queue.
-> Computing the pool quadtree
     Number of buckets: 64
     Average depth: 3.0 , Average bucket size: 3155.734375
     Largest depth: 3
Process interrupted
_________________________________________________________________________________________________
Process interrupted
_________________________________________________________________________________________________

 

That may be my problem. I don't have any of the folder pathways setup in Ortho4P3D, as I think the guide here suggests its unnecessary.

How have you got your pathways set up?

If I point the Base Folder to drive:/<Ortho4P3D Folder>/Tiles (containing the same data as a custom scenery folder if I'd moved the X Plane tiles), my tiles show up on the map view, but I've still got no evidence of reusing most of the OSM data. Did I choose the wrong folder? I've also tried setting this to the main Ortho4P3D folder, still doesn't work plus my built tiles no longer show on the map

There are also pathways in the config for custom_dem and custom_overlay_src. I have used both of these in Ortho4XP, but they would seem to be unhelpful/irrelevant here..

FInally, there is the custom_scenery_dir path in the config settings. I've tried setting this to where my created XP tiles are currently stored (drive:/<Ortho4XP Folder>/Tiles, but still no luck with the OSM data reuse:

From a tile that I just built, and are now re-running a build on as a test, it gives the following initial output: (ie the same as if no OSM data existed)

Downloading OSM data for ScenProc, this might take some time, please wait...
If OSM server rejects our request due to too many requests, will keep trying until successful.
Attempting to download OSM data from 37, 23 to 37.25, 23.25
Download successful
Attempting to download OSM data from 37.25, 23 to 37.5, 23.25
Download successful
Attempting to download OSM data from 37.5, 23 to 37.75, 23.25
Download successful

It's been a while since I used Ortho4XP, so I'm guessing that I'm just doing something basic wrong in the path settings. Do you have different path setup from what I describe?

 

 

 


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites

Addendum:

With my paths setup as above, if I JUST choose the "Assemble vector data" - and nothing else - from the "Batch build tiles" tick boxes on the map, it runs like it should:

------------------------------------------------------------------------------------------------------------

Batch build launched for a number of 1 tiles.
Dealing with tile  1 / 1 : +38+024

Step 1 : Building vector data for tile +38+024 : 
--------

-> Dealing with airports
    * Recycling OSM data from ..\OSM_data\+30+020\+38+024\+38+024_airports.osm.bz2
   LGSY   Skyros Airport                                               2 runways, lat= 38.97, lon= 24.49
   Loading elevation data and smoothing it over airports.
    * Min altitude: -12.0 , Max altitude: 1377.0 , Mean: 39.94991
   Auto-patched 2 runways and 25 pieces of taxiway.
   Flattened 9 helipads.
   Number of edges at this point: 1258
-> Dealing with roads
    * Recycling OSM data from ..\OSM_data\+30+020\+38+024\+38+024_big_roads.osm.bz2
    * Checking which large roads need levelling.
    * Buffering banked road network as multipolygon.
      Encoding it.
    * Encoding the remaining primary road network as linestrings.
   Number of edges at this point: 24864
-> Dealing with coastline
    * Recycling OSM data from ..\OSM_data\+30+020\+38+024\+38+024_coastline.osm.bz2
    * Encoding coastline.
    * Reconstructing its topology.
      Found  6 contiguous patch(es).
   Number of edges at this point: 54092
-> Dealing with inland water
    * Recycling OSM data from ..\OSM_data\+30+020\+38+024\+38+024_water.osm.bz2
    * Building water multipolygon.
      Cleaning it.
      Encoding it.
   Number of edges at this point: 55162
-> Inserting edges related to the orthophotos grid
-> Inserting additional boundary edges for gluing
-> Transcription to the files  D:/X-Plane Custome Scenery 2020\zOrtho4XP_+38+024\Data+38+024.poly and .node

Final number of constrained edges : 89221

Completed in 30.85sec.

----------------------------------------------------------------------------------------------------------

 

Unfortunately, once I select all five necessary tick boxes, including "Build for ESP (FSX/P3D", I'm back to:

Batch build launched for a number of 1 tiles.
Dealing with tile  1 / 1 : +38+024

Step 1 : Building vector data for tile +38+024 : 
--------

Downloading OSM data for ScenProc, this might take some time, please wait...
If OSM server rejects our request due to too many requests, will keep trying until successful.
Attempting to download OSM data from 38, 24 to 38.25, 24.25
Download successful
Attempting to download OSM data from 38.25, 24 to 38.5, 24.25
Download successful
Attempting to download OSM data from 38.5, 24 to 38.75, 24.25
Download successful
Attempting to download OSM data from 38.75, 24 to 39.0, 24.25
        OSM server MAP rejected our query, new tentative in 2 sec...
        OSM server MAP rejected our query, new tentative in 4 sec...

Download successful
Attempting to download OSM data from 38, 24.25 to 38.25, 24.5
        OSM server MAP rejected our query, new tentative in 2 sec...
        OSM server MAP rejected our query, new tentative in 4 sec...
        OSM server MAP rejected our query, new tentative in 8 sec...
        OSM server MAP rejected our query, new tentative in 16 sec...
        OSM server MAP rejected our query, new tentative in 32 sec...
        OSM server MAP rejected our query, new tentative in 64 sec...

 

-------------------------------------------------------------------------------------------------------------------------

As well as using more OSM data, it's taking me a long time to download the OSM data per tile when the servers are busy (seems to be a very common problem at the moment), sometimes to the point where Step 1 gets stuck.

I'm running the .exe. version rather than python.

Edited by OzWhitey

Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites
2 minutes ago, OzWhitey said:

It's been a while since I used Ortho4XP, so I'm guessing that I'm just doing something basic wrong in the path settings. Do you have different path setup from what I describe?

Since I don't have my scenproc stuff specified, since I run that separately, maybe that's the difference?

But, here's how I'm setup...

I use my 8-drive QNAP NAS for all this stuff, so everything's on the NAS. The share is mapped as my S: drive.

fzPBHSF.png

I run two instances of Ortho4XP (just duplicated the folder and renamed it) so I can run two instances downloading at the same time.

In Ortho4XP I just have specified the same base folder, which was just an empty folder called Ortho4XP_Data, so they both use that folder and a new subfolder gets created with various data for each grid I process.

However, as you note, the OSM data is stored separately in the actual Ortho4XP folder in OSM_data.

So I guess I'm not sure why yours is downloading again and mine isn't.


5800X3D | Radeon RX 6900XT

Share this post


Link to post
Share on other sites

Based on your update, I think it is because you're running scenproc each time. I'd suggest initially disabling scenproc, or in any case, only running it once. or better yet, don't use scenproc connected to O4XP, but instead run it separately with data downloaded (much faster) from http://download.geofabrik.de/index.html

Scenproc is intimidating, but I used the script that came with O4XP and modified it. That gives you the flexibility to adjust vegetation types and building heights for the region you're running it on.  I'd be happy to share my scenproc script. I added street lights to it as well.

Edited by cwburnett
  • Like 1

5800X3D | Radeon RX 6900XT

Share this post


Link to post
Share on other sites
16 minutes ago, cwburnett said:

Based on your update, I think it is because you're running scenproc each time. I'd suggest initially disabling scenproc, or in any case, only running it once. or better yet, don't use scenproc connected to O4XP, but instead run it separately with data downloaded (much faster) from http://download.geofabrik.de/index.html

Scenproc is intimidating, but I used the script that came with O4XP and modified it. That gives you the flexibility to adjust vegetation types and building heights for the region you're running it on.  I'd be happy to share my scenproc script. I added street lights to it as well.

OK, I've now decided it's not a path issue.

If I run tile via batch build with assemble vector data, triangulate 3D mesh, draw water masks and Build for ESP ticked (ie NOT selecting build imagery/DSF), it reuses the data beatifully for the first 3 steps, completing them in about 2 minutes. BUT it doesn't run the critical "Build for ESP" step. 

If I do what I usually do and have all five boxes ticked - including  build imagery/DSF - it does not recycle the previously created data. Interesting.

Re: disabling scenproc. Are you suggesting altering this line from the Ortho4CP config? : ESP_scenproc_script=default.spc

If so, what would you set it to, or does it just get left out entirely?


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites
1 minute ago, OzWhitey said:

OK, I've now decided it's not a path issue.

If I run tile via batch build with assemble vector data, triangulate 3D mesh, draw water masks and Build for ESP ticked (ie NOT selecting build imagery/DSF), it reuses the data beatifully for the first 3 steps, completing them in about 2 minutes. BUT it doesn't run the critical "Build for ESP" step. 

If I do what I usually do and have all five boxes ticked - including  build imagery/DSF - it does not recycle the previously created data. Interesting.

Re: disabling scenproc. Are you suggesting altering this line from the Ortho4CP config? : ESP_scenproc_script=default.spc

If so, what would you set it to, or does it just get left out entirely?

Mine just says this; I left the scenproc untouched pointed to an invalid directory...

ESP_scenproc_loc=C:\\Users\\fery2\\Desktop\\scenproc_latest_development_release_x64\\scenProc.exe
ESP_scenproc_script=default.spc

I think you could either delete those lines or just don't actually point scenproc to the right place. I'd try it just as a test at least.

  • Like 1

5800X3D | Radeon RX 6900XT

Share this post


Link to post
Share on other sites
Just now, cwburnett said:

Mine just says this; I left the scenproc untouched pointed to an invalid directory...


ESP_scenproc_loc=C:\\Users\\fery2\\Desktop\\scenproc_latest_development_release_x64\\scenProc.exe
ESP_scenproc_script=default.spc

I think you could either delete those lines or just don't actually point scenproc to the right place. I'd try it just as a test at least.

Am trying it right now!

As for scenproc - yes, it would be great if you could share your script. Any pointers as to instructions/video to try and get my head around scenproc? Most people seem to give up before succeeding as the instructions are infamously hard to follow.


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites

@OzWhitey

Re Scenproc, there are basically three big steps that it all comes down to, and each of these big steps needs to be in your .spc file.

1) Importing the data - so you can pull data from lots of places - shapefiles, osm files, existing AGN files, etc.

2) Processing the data - reading different pieces of the imported data and creating AGN objects from them to be written.

3) Writing the objects into AGN files.

So, in this case we just want to import an OSM file, and we have the option to import only part of the data or all of the data. We can choose a geography to import and we can choose what fields to import. Remember that an OSM file is really just an XML file - so just lots of text and it is all coded by field names, so we can pick what we want to import.

As for processing, we want to identify landuse types to associated autogen vegetation with and we want to import building footprints, then classify those buildings so we can assign autogen to them.

Then, we want to find roads and place points along those roads for light poles.

Lastly, we want to create the AGN items and write them to files.

Here is a version of the script I use, which was modified from the one included:

# Credit to Harry Otter for the default ScenProc script!
# IMPORTOGR|@0@|*|building;landuse;natural;leisure|NOREPROJ
ImportOGR|C:\Users\cwbur\Documents\GIS Files\Greece\karpathos.osm|*|landuse;highway;building;natural;leisure|AUTODETECT
#ImportOGR|C:\Users\cwbur\Downloads\test.shp|*|landuse|AUTODETECT
#ImportAGN|D:\ORBX Library\p3dv5\ESNQ Kiruna Airport\ORBX\FTX_EU\FTX_AA_ESNQ\Texture|EXISTINGCELLSONLY
#
SplitGrid|AGN|*|building="*"
#
SETAGNBUILDINGHEIGHT|*|0.6;0.3;0.1;0.0
#creation de la vegetation
CreateAGNPolyVeg|FTYPE="POLYGON" And landuse="forest"|{a91a9e12-d0ae-433b-9153-c6c2e8143f3d};{64da6e09-6d2c-4eac-bf32-f79cbaddcffb};{f92dfb07-9e9d-4db9-a936-4dde2ece3fbf};{46537aa4-0f85-4840-ac15-bb1198111254};{51abd43d-294d-4fbb-93b1-61f35ac8891c};{b39919c5-083e-4be0-a5df-cfb43cee439d};{0a85e154-6aff-4ec6-9640-8d46758d9c55};{bcf582df-fe10-43a1-bf91-74cb004451d0};{e738b5f2-0b4e-42af-955f-96f24fc50043};{5fc298b3-6a99-40be-a6d2-51d49a1f6310};{d9139817-a733-4609-8b91-cccb3bda8528};{88a689ae-958f-4588-8805-0c48ae8d923d};{494e699d-5f5e-4191-85c9-8ed41b96aa3e};{13c6b576-38a1-4daf-bbfd-99a3da908a54};{7337b46a-4e7c-4167-85d4-31a08794317d};{08eafa28-5200-4e5e-aa76-2cbd934108aa};{3fff1747-e528-472e-a5e5-e7dfc44240b6};{cc321ca5-c258-4584-996e-0dd3f3bc531d};{f423294e-5624-499e-80ef-73d8cefe61c1};{5b87d25c-f98e-4401-a3f7-ee667749f7c3};{95dc5b85-13ca-4c36-8c90-1124b71a5769};{e258071f-4026-447a-8227-fdd1e16f5097};{6b0ae83d-41bc-4171-9f04-45b4694b43f3};{9683c859-7b37-41fb-9d40-828477713f06};{9d2d1501-9135-4b2d-808f-5c6a8d0c3ce7};{59413a8e-065d-4706-ba20-d1756f0f25e2};{c4378eea-8d57-4afc-abb6-d63eb6da9c15};{2957ebf1-5ef6-47ce-aa79-31a3d0fa849a};{64b9ff09-f918-4e96-9262-57b07629f6c0};{3daebd73-10e7-41a3-b57a-4bc9e646ac5f};{98c043f3-661a-4ac0-8239-712948a602ec}
CreateAGNPolyVeg|FTYPE="POLYGON" And natural="scrub"|{2fde0277-1697-4dab-b481-c3985c80596f}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And landuse="orchard"|{56a4998d-c1e5-416c-a37b-c35ce16504b6}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And landuse="conservation"|{72e37d90-824e-4e97-9187-a60491864a49};{ad0c30b6-5b47-4d96-9bab-38f58e251c5e};{b7c05b80-45e9-4faf-9548-6a3e59c02dd6};{bc6396b0-6e51-4a4f-ab4f-5386c84609a6}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And natural="wood"|{dcf543b7-c0d5-4fd4-b970-83965c2911c9}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And leisure="nature_reserve"|{dc5c8dcb-551e-4980-867d-ee6d12695c50}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And leisure="garden"|{2368c260-177d-4af7-94d4-da882778108f}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And natural="tree"|{acd89c1c-2a87-4168-8cb6-a1ca8e2859ac};{1cdb2a6c-b20f-4923-9e12-4aa636441d4d};{7dc6ef4e-92a5-4d0d-b94b-212dd1fa936d}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And natural="tree_row"|{51abd43d-294d-4fbb-93b1-61f35ac8891c};{b39919c5-083e-4be0-a5df-cfb43cee439d};{e738b5f2-0b4e-42af-955f-96f24fc50043};{8fa52b1e-4d35-428c-9adc-dea62fc92bab};{34126b61-fee1-4343-bdf9-1bd65ae91ae7};{5fc298b3-6a99-40be-a6d2-51d49a1f6310}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And natural="wetland"|{0533d2b5-2a93-4c4a-9660-069a3f73b921};{224fafba-241a-4dbb-b36f-280bcead2110};{ad0c30b6-5b47-4d96-9bab-38f58e251c5e};{0f069be1-b5ef-4a03-9455-b8507846ea73}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And leisure="park"|{e04669c0-9f7b-42e8-a2c7-eee870c59d8e}
CREATEAGNPOLYVEG|FTYPE="POLYGON" And leisure="golf"|{2fbf9f8d-6ba2-4cc1-8d8e-af218f65d0e8}
# Add attribute to indicate the type of building
# 1 = ALMOST RECTANGLE (BASED ON AREA RATIO)
# 3 = REGULAR SHAPED (MANY PARALLEL EDGES)
# 4 = CONVEX POLYGONS
# 5 = CONCAVE POLYGONS
AddAttribute|FTYPE="POLYGON" And building="*"|Integer;BUILDTYPE|5
AddAttribute|FTYPE="POLYGON" And building="*" And BUILDTYPE=5 And FAREARAT>0.80|Integer;BUILDTYPE|1
AddAttribute|FTYPE="POLYGON" And building="*" And BUILDTYPE=5 And FNUMVERT<10 And FNUMPERPANG>3 And FNUMNOTPAR<2|Integer;BUILDTYPE|3
AddAttribute|FTYPE="POLYGON" And building="*" And BUILDTYPE=5 And FCONVEX=1|Integer;BUILDTYPE|4
# Classify industrial/commercial buildings
AddAttributeIfInside|FTYPE="POLYGON" And building="*"|LUCODE=16|String;BUILDCAT|INDUSTRIAL
AddAttributeIfInside|FTYPE="POLYGON" And building="*"|LUCODE=15|String;BUILDCAT|COMMERCIAL
# Add attribute for roof type
AddAttribute|FTYPE="POLYGON" And building="*" And FWIDTH>5|String;ROOFTYPE|PEAKED_ALL
AddAttribute|FTYPE="POLYGON" And building="*" And FWIDTH>5 And FLENGTH<12|String;ROOFTYPE|PEAKED_SIMPLE
AddAttribute|FTYPE="POLYGON" And building="*" And FWIDTH>20|String;ROOFTYPE|PEAKED_LOW_PITCH
AddAttribute|BUILDCAT="INDUSTRIAL"|String;ROOFTYPE|PEAKED_LOW_PITCH
AddAttribute|BUILDCAT="COMMERCIAL"|String;ROOFTYPE|PEAKED_LOW_PITCH
# Remove complex buildings
ReplacePolygonByBuildingRectangles|BUILDTYPE=3|0.8;4;4|0.25;2.0;0.5|Integer;BUILDTYPE|2
# Create buildings autogen
CreateAGNGenBuild|BUILDTYPE<3 And ROOFTYPE="PEAKED_ALL"|{c05c5106-d562-4c23-89b8-a4be7495b57c}|MAXRATIO=2
CreateAGNGenBuild|BUILDTYPE<3 And ROOFTYPE="PEAKED_SIMPLE"|{d4ee02a2-ed47-4f10-b98c-502516983383}
CreateAGNGenBuild|BUILDTYPE<3 And ROOFTYPE="PEAKED_LOW_PITCH"|{a9b0e686-0758-4294-a760-9bb4fd341621}
#
CreateAGNGenBuild|building="*" And FWIDTH<20|{5ae04eb6-934c-4f63-bb48-5e7dee601212}|MAXRATIO=2
CreateAGNGenBuild|building="*" And FWIDTH>20|{6089A0BD-CED1-4c47-9A9E-64CDD0E16983}
# lights
# GCC roads
LineToPoint|FTYPE="LINE" And highway="secondary"|CONTINUOUS|150;150|5;5|0|String;type|light|hdg
#
PointToPolygon|type="light"|8;8|hdg|String;type|lightpoly
#
CreateAGNLibObject|type="lightpoly"|{0017a263-464f-14fd-f77f-2996fed44864}
#
#CreateXMLLibObj|type="light"|{47c97ced4e4bc4e610b19f8e62ea9e98}|0|0|0|0
#
#ExportBGL|P3D v2|lights|S:\scenprocoutput|KEEPXML
#
EXPORTAGN|P3D v2|C:\Users\cwbur\Documents\autogen\greece\karpathos\

So, the # is stuff that's commented out, and I tend to use that so I can easily replicate a script for a new area. One thing you'll see at the top is a commented out example of importing existing AGN - I use this when solving for the annoying area around third party airports with no autogen. We need to merge autogen to get full coverage and I just place those files in both the airport texture folder and the underlying scenery texture folder as well, to be sure I get full coverage.

Remember that if you hover over things, you get a 'tooltip' that tells you how to use that function...

Some notes on the above:

1) Importing OGR files like OSM or SHP files:

ImportOGR|C:\Users\cwbur\Documents\GIS Files\Greece\karpathos.osm|*|landuse;highway;building;natural;leisure|AUTODETECT

After the filename, there are two filter fields separated by |

The first is for the geographic area you want to process - in minx;maxx;miny;maxy format, so if you only wanted to process the grid 36N16E for example, you'd swap that first * for 16;17;36;37.

The second is for the fields, or attributes, you want to import. OSM files have standard attributes, and these work well: landuse;highway;building;natural;leisure

The last field is for the projection. Best to leave it as AUTODETECT unless you know you're importing a dataset in a non WGS84 projection.

So, if we wanted to specify a particular grid, that line would read:

ImportOGR|C:\Users\cwbur\Documents\GIS Files\Greece\karpathos.osm|16;17;36;37|landuse;highway;building;natural;leisure|AUTODETECT

2) Setting building heights:

SETAGNBUILDINGHEIGHT|*|0.6;0.3;0.1;0.0

This just sets a distribution for building heights in the specified region. The star can be replaced by a filter for specific autogen cells, but I don't know how to use that properly, so I actually run the script for different regions using the filter in step 1 if I want to adjust building height by area.

After the second pipe, we specify distribution between buildings that are 1-2 floors;3-5 floors;6-9 floors;10-12 floors. These can each be 0-1, but for simplicity sake, I always make sure that the four add up to 1, so I can think of them as percents, so in this example, 60% of the buildings will be 1-2 floors, 30% will be 3-5 floors and 10% will be 6-9 floors.

3) Creating Vegetation Autogen Polygons:

CreateAGNPolyVeg|FTYPE="POLYGON" And landuse="forest"|{a91a9e12-d0ae-433b-9153-c6c2e8143f3d};{64da6e09-6d2c-4eac-bf32-f79cbaddcffb}

Here's where it gets fun. This is where we get to specify WHAT autogen objects will appear in the sim.  For this you need to be sure you've setup your paths correctly and, sadly, you do need P3D installed on the computer for this to work right. I'll include my setting screen below, but basically IF you have your scenproc setup to point to your P3D version, then you can right click on the GUID and you'll get an option to "Select GUID..." and if you click that, you'll get a menu to open will hundreds of autogen options for different vegetation types. This is important if you don't want your Mediterranean island populated with Douglas Furs or your Swedish forest populated with coconut trees...

Options Screen:

HkfWOZy.png

GUID list:

XPl6B6L.png

You can add as many GUIDs to each line as you like and it will randomize, but what you may have noticed in my Sweden autogen is that it appears to assign a different type for each autogen cell, so that's why in Sweden we see the forest abruptly change tree type at the edge of a grid - not ideal, so maybe best to stick to one or two types of trees instead of the 10 or so I selected...

4) Creating Building Autogen:

So I haven't changed this at all from default, so all of the ADDATTRIBUTE and CREATEAGNGENBUILDING lines I've left alone. I'm sure they could be tweaked, but I haven't done that.  So leave it as it is for now and you should get buildings. All of Sweden was created with these settings.

5) Creating Street lights or similar objects:

This part I learned and added to the script from the scenproc manual. Basically what we're doing is taking a line and converting it to tiny polygons to place autogen street lights in. Again you can hover over each line to see what the variables do, but we're first creating points from a line, we're placing them every 150 meters, starting a 150 meters from the start of the line, we're offsetting them 5 meters from the line (so the light poles are next to and not in the middle of the street), and we give these new points an attribute name. Then we create 8x8 polygons for each point and give those objects a new name. Lastly, we create a library object for each polygon and here, again, we are using a GUID we have selected from the menu.

6) Writing the autogen to files:

The last thing we do is write our AGN files with the EXPORTAGN line and we write them into a folder we create just for this autogen package. When this is done, you have it all.

7) Merging autogen files:

The easiest way to merge autogen files is in the tools menu. Use this if you created autogen for a region from multiple scripts, for example if you did just a city with taller buildings or something like that.

Y65ynsG.png

tALhP3q.png

Basically, select your main folder (if there is no main folder, then just select any of your folders as the 'main' folder). Then select each additional folder that contains autogen that you want merged as 'other folders' and then make and select a new folder for the merged files and click 'merge'.

You would only use the 'only merge AGN files that exist in the main folder' if you wanted to merger bordering areas that share an AGN cell. So for combining 4 different Lat/Long grids, just select any of the four as the main and the other three as other folders - won't matter which is which - and do not check 'only merge'.

However, say you already have autogen Stockholm, but you wanted to merge in my Stockholm data also, but you didn't want all the rest of my autogen for all of Sweden. Then, you'd select your existing Stockholm autogen as the Main, you'd select mine as the "Other" and then you'd choose 'only merge AGN files that exist in main folder" - that would DISCARD all of my autogen that isn't in the same area as your autogen is in, and would merge yours and mine in the region covered by your existing autogen.  This can be particularly useful for merging autogen with that of a third party airport.

Hopefully that helps get you started! Let me know if you run into trouble or need help trying to get some specific outcome. I am FAR from an expert, but have managed to get it to work for my needs.

Edited by cwburnett
  • Like 1
  • Upvote 2

5800X3D | Radeon RX 6900XT

Share this post


Link to post
Share on other sites

Hi guys,

 

Now that I'm awake again, I think I can provide some decent data and clarify the question/situation.

Here is my data in three situations:

1. 'Batch build tiles' tick boxes: all 4 "normal" x-plane boxes selected: Assemble vector data, trinagulate, draw water masks, build imagery/DSF.

Batch build launched for a number of 1 tiles.
Dealing with tile  1 / 1 : +36+022

Step 1 : Building vector data for tile +36+022 : 
--------

-> Dealing with airports
    * Recycling OSM data from ..\OSM_data\+30+020\+36+022\+36+022_airports.osm.bz2
   LGSP   Sparti Air Base                                              1 runway , lat= 36.97, lon= 22.53
   Loading elevation data and smoothing it over airports.
    * Min altitude: -17.0 , Max altitude: 2375.0 , Mean: 111.07116
   Auto-patched 1 runway and 0 piece of taxiway.
   Flattened 2 helipads.
   Number of edges at this point: 333
-> Dealing with roads

Outcome: OSM data recycled as it should be

 

 

2. 'Batch build tiles' tick boxes: all 4 "normal" x-plane boxes selected as above PLUS the "Build for ESP (FSX/P3D" box:

Batch build launched for a number of 1 tiles.
Dealing with tile  1 / 1 : +38+021

Step 1 : Building vector data for tile +38+021 : 
--------

Downloading OSM data for ScenProc, this might take some time, please wait...
If OSM server rejects our request due to too many requests, will keep trying until successful.
Attempting to download OSM data from 38, 21 to 38.25, 21.25
Download successful
Attempting to download OSM data from 38.25, 21 to 38.5, 21.25
Download successful
Attempting to download OSM data from 38.5, 21 to 38.75, 21.25
Download successful

Outcome: OSM data is re-downloaded (this is what I am trying to avoid)

 

 

3. 'Batch build tiles' tick boxes: all 4 "normal" x-plane boxes selected as above PLUS the "Build for ESP (FSX/P3D" box PLUS 'ESP_scenproc_script=default.spc' line removed from Ortho4XP config file.

Batch build launched for a number of 1 tiles.
Dealing with tile  1 / 1 : +38+021

Step 1 : Building vector data for tile +38+021 : 
--------

Downloading OSM data for ScenProc, this might take some time, please wait...
If OSM server rejects our request due to too many requests, will keep trying until successful.
Attempting to download OSM data from 38, 21 to 38.25, 21.25

Outcome: OSM data is re-downloaded, behaviour unchanged from scenario 2 i.e. removing this line from the Ortho4XP config file is not the solution.

 

Findings:

You will note that selecting the "build for ESP" option add this line/step to the process, even with the scenproc path removed from the config file.

"Downloading OSM data for ScenProc, this might take some time, please wait...
If OSM server rejects our request due to too many requests, will keep trying until successful."

If you run the "build for ESP" step by itself, it does not use the previously downloaded data and no tile results. So far, I can only generate a tile by re-running all 5 steps.

Questions:

1. Is there a way to rebuild a tile using only the "build for ESP" step?

2. If I need to run all 5 steps to rebuild a P3D tile - as appears to be the case - is there a way to force the program to re-use the existing OSM data, or is in an intrinsic part of this modified Ortho4XP version that the ESP build requires fresh OSM data each time a tile is built?

Note that I am not trying to use Scenproc to generate overlays, rather I am just trying to rebuild basic ortho tiles after post-processing the existing bmps. As per my previous notes, this works for me but is very slow and places unnecessary stress on the OSM servers when rebuilding large areas. 

 

 

 

 

 


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites

This is so odd @OzWhitey because I don't even have those steps.  I'm running some tiles right now... here's what I get:

FSX/P3D building requires both the tile and mask zooms to equal. Setting the mask zoom to the tile zoom of 14
Batch build launched for a number of 34 tiles.
Dealing with tile  1 / 34 : +34-002

Step 1 : Building vector data for tile +34-002 : 
--------

-> Dealing with airports
    * Downloading OSM data for ('node["aeroway"]', 'way["aeroway"]', 'rel["aeroway"]')
   GMFO   Oujda Angad Airport                                          2 runways, lat= 34.79, lon= -1.93
   ****   ****                                                         1 runway , lat= 34.05, lon= -1.66
   Loading elevation data and smoothing it over airports.
    Downloading  ..\Elevation_data\+30-010\N34W002.hgt from Viewfinderpanoramas (J. de Ferranti).
    * Min altitude: 105.0 , Max altitude: 1829.0 , Mean: 994.7998
   Auto-patched 3 runways and 10 pieces of taxiway.
   Number of edges at this point: 1754
-> Dealing with roads
    * Downloading OSM data for way["highway"="motorway"]
    * Downloading OSM data for way["highway"="trunk"]
    * Downloading OSM data for way["highway"="primary"]
    * Downloading OSM data for way["highway"="secondary"]
        OSM server DE rejected our query, new tentative in 2 sec...
        OSM server DE rejected our query, new tentative in 4 sec...
        OSM server DE rejected our query, new tentative in 8 sec...
        OSM server DE rejected our query, new tentative in 16 sec...
    * Downloading OSM data for way["railway"="rail"]
    * Downloading OSM data for way["railway"="narrow_gauge"]
    * Checking which large roads need levelling.
    * Buffering banked road network as multipolygon.
      Encoding it.
    * Encoding the remaining primary road network as linestrings.
   Number of edges at this point: 60315
-> Dealing with coastline
    * Downloading OSM data for way["natural"="coastline"]
   Number of edges at this point: 60315
-> Dealing with inland water
    * Downloading OSM data for rel["natural"="water"]
    * Downloading OSM data for rel["waterway"="riverbank"]
    * Downloading OSM data for way["natural"="water"]
    * Downloading OSM data for way["waterway"="riverbank"]
    * Downloading OSM data for way["waterway"="dock"]
        OSM server DE rejected our query, new tentative in 2 sec...
        OSM server DE rejected our query, new tentative in 4 sec...
        OSM server DE rejected our query, new tentative in 8 sec...
    * Building water multipolygon.
      Cleaning it.
      Encoding it.
   Number of edges at this point: 66234
-> Inserting edges related to the orthophotos grid
-> Inserting additional boundary edges for gluing
-> Transcription to the files  S:/Apps/Ortho4XP_Data\zOrtho4XP_+34-002\Data+34-002.poly and .node

Final number of constrained edges : 76043

Completed in 5m5sec.
_________________________________________________________________________________________________

Step 2 : Building mesh for tile +34-002 : 
--------

-> Modifying curv_tol weight map according to runway locations.
-> Modifying curv_tol weight map according to coastline location.
    * Recycling OSM data from ..\OSM_data\+30-010\+34-002\+34-002_coastline.osm.bz2
-> Start of the mesh algorithm Triangle4XP.
   Loading altitudes from DEM file.

   Loading curv_tol geographic weights.

   Computing curvatures from altitudes.

   Constructing Delaunay triangulation by divide-and-conquer method.

   Recovering segments in Delaunay triangulation.

   Spreading regional attributes.

   Adding Steiner points to enforce quality.

   Computing altitude and normal maps.

   Node file S:/Apps/Ortho4XP_Data\zOrtho4XP_+34-002\Data+34-002.1.node written to disk.

   Tri file  S:/Apps/Ortho4XP_Data\zOrtho4XP_+34-002\Data+34-002.1.ele  written to disk.

   Statistics:

   Input vertices: 74414

   Input segments: 76043

   Input holes: 0



   Mesh vertices: 214,302
                   -----------------

   Mesh triangles: ---> 420,295

                   -----------------
   Mesh edges: 634596

   Mesh exterior boundary edges: 8307

   Mesh interior boundary edges: 75103

   Mesh subsegments (constrained edges): 83410

-> Loading of the mesh computed by Triangle4XP.
-> Post processing of altitudes according to vector data
   Smoothing inland water.
   Smoothing of sea water.
   Treatment of airports, roads and patches.
-> Writing output nodes file.
-> Writing final mesh to the file S:/Apps/Ortho4XP_Data\zOrtho4XP_+34-002\Data+34-002.mesh

Completed in 23.00sec.
_________________________________________________________________________________________________

Step 2.5 : Building masks for tile +34-002 : 
--------

-> Reading mesh data
   *  S:/Apps/Ortho4XP_Data\zOrtho4XP_+34-003\Data+34-003.mesh
   *  S:/Apps/Ortho4XP_Data\zOrtho4XP_+34-002\Data+34-002.mesh
   *  S:/Apps/Ortho4XP_Data\zOrtho4XP_+35-003\Data+35-003.mesh
-> Construction of the masks
   Creating 6528_8096.tif
   Creating 6512_8096.tif
   Creating 6544_8096.tif
   Creating 6496_8096.tif
   Creating 6480_8096.tif
   Creating 6496_8112.tif
   Creating 6512_8112.tif
   Creating 6528_8112.tif
   Creating 6544_8112.tif
   Creating 6480_8112.tif
   Creating 6512_8128.tif
   Creating 6496_8128.tif
   Creating 6480_8128.tif

Completed in 24.26sec.
_________________________________________________________________________________________________

Step 3 : Building DSF/Imagery for tile +34-002 : 
--------

-> Initializing providers with potential data on this tile.
-> Opening download queue.
-> Computing the pool quadtree
     Number of buckets: 64
     Average depth: 3.0 , Average bucket size: 3349.375
     Largest depth: 3
   Downloading missing orthophoto 6512_8128_EOX214.bmp
-> Encoding of the DSF file
     Final nbr of nodes: 222171
   Downloading missing orthophoto 6496_8112_EOX214.bmp
     DSF file encoded, total size is : 5694072 bytes (5.4M)
   Downloading missing orthophoto 6544_8096_EOX214.bmp
   Downloading missing orthophoto 6528_8096_EOX214.bmp
   Downloading missing orthophoto 6480_8128_EOX214.bmp
   Downloading missing orthophoto 6496_8128_EOX214.bmp
   Downloading missing orthophoto 6512_8096_EOX214.bmp
   Downloading missing orthophoto 6480_8096_EOX214.bmp
   Downloading missing orthophoto 6496_8144_EOX214.bmp
   Downloading missing orthophoto 6512_8112_EOX214.bmp
   Downloading missing orthophoto 6480_8144_EOX214.bmp
   Downloading missing orthophoto 6496_8096_EOX214.bmp
   Downloading missing orthophoto 6528_8112_EOX214.bmp
   Downloading missing orthophoto 6480_8112_EOX214.bmp
   Downloading missing orthophoto 6528_8144_EOX214.bmp
   Downloading missing orthophoto 6528_8128_EOX214.bmp
   Downloading missing orthophoto 6512_8144_EOX214.bmp
   Downloading missing orthophoto 6544_8128_EOX214.bmp
   Downloading missing orthophoto 6544_8112_EOX214.bmp
   Downloading missing orthophoto 6544_8144_EOX214.bmp
 *Download of textures completed.
 *Activating DSF file.
Starting ESP queue with a max of 4 processes. *Resample windows will open minimized to the task bar. This process will take a while... you will be notified when finished

Completed in 10m18sec.

Nowhere in my process does the word scenproc even appear.  Could you post your ortho4xp.cfg file?


5800X3D | Radeon RX 6900XT

Share this post


Link to post
Share on other sites

I've been doing some ZL18 squares around the East coast of Australia (Qld) using Bing imagery and find many areas where the Orbx/default scenery is display in-sim, not the Ortho.  I haven't dug back through logs.  

Does anyone have suggestions if this is a conflict or perhaps missing Bing data, and how I might pin down what's going wrong?  Had similar happen when doing ZL16 and ZL17 - just different size squares missing.

Share this post


Link to post
Share on other sites
On 6/27/2020 at 3:51 PM, RobF2 said:

I've been doing some ZL18 squares around the East coast of Australia (Qld) using Bing imagery and find many areas where the Orbx/default scenery is display in-sim, not the Ortho.  I haven't dug back through logs.  

Does anyone have suggestions if this is a conflict or perhaps missing Bing data, and how I might pin down what's going wrong?  Had similar happen when doing ZL16 and ZL17 - just different size squares missing.

Orbx ortho (included with both AU2 and airports) may display through your scenery as some of it is higher resolution than what you are producing. Orbx landclass should not. I have AU2 installed, and have not noticed this anywhere in Australia where I have ortho tiles (mainly ZL16, with some ZL17).

Btw, I've built a lot of northern queensland over the past few months, and have found ARC to be a great source.


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites

By the way, regarding the original topic.

I've been using Ortho4P3D extensively since I posted. I have come to the conclusion that the redownload of the vector data is just a feature of the P3D version of the program. CWBurnett, I think that you do not experience this as you are not using Ortho4XP to compile your BGLs. Perhaps try rebeuilding a tile sometime with the standard five boxes - including "Build for ESP (FSX/P3D)"  - option ticked. I bet that Ortho4P3D will want to re-download your vector data as well, and if you deselect the "Assemble vector data" box when rebuilding, the program will not generate a usable .bgl.

So TL;DR, this is just the way the P3D version of Ortho4Xp works. If anyone disagrees, please let me know!

 


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites
1 hour ago, OzWhitey said:

Orbx ortho (included with both AU2 and airports) may display through your scenery as some of it is higher resolution than what you are producing. Orbx landclass should not. I have AU2 installed, and have not noticed this anywhere in Australia where I have ortho tiles (mainly ZL16, with some ZL17).

Btw, I've built a lot of northern queensland over the past few months, and have found ARC to be a great source.

Thanks Rob, will have to check out ARC (have been using Bing).

After some weeks of trial and error I did figure out my issue.  I had been building the same tile with increasing Zoom settings from the main dialogue but without increasing the Mask and Mesh zoom values.  I thought I had been deleting the older low res masks via the program, but they were still there.  Manually deleted the pre-existing mark directory and less ZL18 as the default Mask and Mesh setting in CFG and all is good.

Absolutely amazing flying around half-dozen tiles for Brisbane and SE Qld.  Coupled with V5 smooth frame rates and A2A Bonanza, up there with my top sim experiences (and have only been doin' this on and off for about 34 years....!  🙂 )

Share this post


Link to post
Share on other sites
5 minutes ago, RobF2 said:

Thanks Rob, will have to check out ARC (have been using Bing).

After some weeks of trial and error I did figure out my issue.  I had been building the same tile with increasing Zoom settings from the main dialogue but without increasing the Mask and Mesh zoom values.  I thought I had been deleting the older low res masks via the program, but they were still there.  Manually deleted the pre-existing mark directory and less ZL18 as the default Mask and Mesh setting in CFG and all is good.

Absolutely amazing flying around half-dozen tiles for Brisbane and SE Qld.  Coupled with V5 smooth frame rates and A2A Bonanza, up there with my top sim experiences (and have only been doin' this on and off for about 34 years....!  🙂 )

v5 plus ortho is great, and fits well with the australian orbx airports.

i tried building oz a while back in x-plane, but the data available was poor. Very happy with everything i’ve seen so far from Arc for northern and central australia.


Oz

 xdQCeNi.jpg   puHyX98.jpg

Sim Rig: MSI RTX3090 Suprim, an old, partly-melted Intel 9900K @ 5GHz+, Honeycomb Alpha, Thrustmaster TPR Rudder, Warthog HOTAS, Reverb G2, Prosim 737 cockpit. 

Currently flying: MSFS: PMDG 737-700, Fenix A320, Leonardo MD-82, MIlviz C310, Flysimware C414AW, DC Concorde, Carenado C337. Prepar3d v5: PMDG 737/747/777.

"There are three simple rules for making a smooth landing. Unfortunately, no one knows what they are."

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...