If you go into the controller settings, I think it's under "View", there is a key mapping for zoom. If you use that it will adjust the monitor zoom level, whether you're in VR or just using it 2D. I have it mapped to a key on my flight stick so I can adjust zoom levels for screenshots while in VR.
Odd... I have that same throttle, but I am not having this issue. Just tested to be sure. What I do see is that if I move the throttle via some other means, like using the touch controller, and then move my HOTAS throttle, the movement is damped until the HOTAS 'catches up' to the position of where I moved it with the touch controller. Then it responds normally again.
Is it possible that you have multiple axes mapped to the throttle in AeroFly? If I remember correctly, it is possible to have overlapping axis assignments from two different controllers (e.g. your flight stick and your throttle) and it's not very easy to see in the controller setup screens. After a recent update that reset all our controller mappings, I think that the slider on my flight stick was mapped by default to throttle, in addition to the throttle itself. So check that and see if it is the case. Just click on that throttle axis setting, press delete, and then repeat this a few times to make sure you've cleared anything else from being mapped to it.
Appreciate the leg work! Pulling down some IMGs now.
Are these screen shots the result of 1/3 or 1/9 arc second meshes?
Thanks, and good luck with your conversions! All my preview images in the beginning of the post were with the 1/3 arc second meshes, with the one exception of the San Francisco coastline before/after. That was done with the 1/9 arc second data. The default AeroFly mesh already appears to be pretty good right around San Francisco (and maybe other portions of the coast), so you likely won't see drastic improvement there with the 1/3 arc second data.
There are two reasons why doing this improves the default mesh in AeroFly: the first is that we are potentially using a data source with better resolution (though I can't be sure of that, it's entirely possible the IPACS crew is using this exact same data for the US ), but the other big reason is that the default mesh only covers level 7 in most areas and goes to level 10 in some of the more detailed areas. From my testing, it appears that converting the terrain through level 14 adds a significant amount of detail instead of those flat triangular facets we see with levels 7-10.
Let's do a fast calculation:
earth circumference divided by arc second:
40.000.000 meters / 1296000 (360 degrees*60 minutes*60 seconds) ~~ 31 meters/second.
So 1/3 arc second gives us approximately a 10 meters elevation grid. Right?
I think that is indeed correct Rodeo. That's the x-y resolution, but then there is also the vertical resolution. Since these geotiff files are 32-bit linear grayscale tiffs, and if we assume a single file contains elevations from sea level to the top of Mt. Everest (0m to ~8500m), that gives us 2^32 steps of resolution over 8500m, which is sub-millimeter vertical precision. Now I really doubt that all 32bits are going into the elevation info, because that kind of resolution is just absurd... but perhaps this really is the elevation resolution that a geotiff could potentially store, assuming it wasn't limited by the measurement source.
Also, another reason this seems to improve the default AeroFly mesh so much is that the default mesh only goes to level 10, and in many areas that don't have default scenery it only goes to level 7. So adding those extra levels alone helps quite a bit, and is probably where most of the improvement I saw with my mountainous regions came from.
Excellent job, congratulations!!!
I already have a request vogel69 :
Could you please add .tth file extensions to your FolderGrid function?
Then we could check the extension of our heightmaps as we can do for the ttc files.
Thanks to you guys!
This would indeed be really nice to have! As you may have seen in my tutorial video, these tiles work like the image tiles in that they will create mask tiles if you're not careful about the coordinate limits (except the 'disable mask' line appears to have no effect for the terrain mesh, it always produces masks if your tmc coordinates only partially cover the aerofly grid cells).
I'm sure the same issues of mask tiles that we have with the orthophotos applies to the terrain mesh as well, so it's best to again use vogel69's Google Earth tool or my Excel tool to find coordinate boundaries snapped to the aerofly grid, and then use those in the tmc file. I considered covering this in the tutorial, but thought it might over-complicate things for those doing this for the first time. But, it's absolutely best to geoconvert in a way that doesn't give you masked elevation tiles.
great ! thank you qwerty42 !
I've done a quick test with LIDAR data converted to geotiff but with no success at that time .tth files are generated by geoconverter but I don't see any difference in sim...
Have you an idea of what type of Geotiff are supported by geoconvert: 16 bit or 32 bit Geotiff ? Raster Geotiff ? Elevation Grid Geotiff ?
here a screen of .png file generated with .ttc files:[Blocked Image: https://tof.cx/images/2018/03/…5223b3daf8878c1833d0e.jpg]
Hi vogel69! I'm not sure if there are other formats that geoconvert works with, but I can say that the output of the tutorial demo is a 32-bit linear grayscale tiff file if you open it in Photoshop. Because of this, if you just try to open one of the output tiffs with something like Windows photo viewer, you probably shouldn't be able to see anything in the file.
All those stripes in your png files, if that really is elevation info, looks a lot like the same issues I was having at first when I was trying to use the "Rendered image" save option in QGIS. This writes out an RGB file instead of the 32bit grayscale file and will give you a huge number of 30,000ft tall spikes in AeroFly.
Also I'm reading up on the geotiff spec--it looks like with libgeotiff we can embed geotiff tags into any appropriate tiff image that doesn't already have them. For those new to geotiff, they are a special kind of tiff file that are tagged with embedded metadata, which is how geoconvert gets the elevation data out of them.
If you can point me to your data source, I can try converting them to a working geotiff too and let you know if I find a working method.
Here is the tutorial for how to do this, finally.
Prerequisites you'll need:
- geoconvert from AeroFly SDK
- QGIS (get it from here: https://www.qgis.org/en/site/forusers/download.html)
- These files: mesh convert files.zip
If you follow the video exactly, you shouldn't have any issues. Sorry for how long it is and my incredibly boring delivery, but there's always double-speed button in YouTube if you can't handle my rambling
Outline of what you'll be doing (this is all covered in detail in the video):
(1) Read the disclaimer in this post here first! : Creating terrain heightmaps
(2) Go to USGS site and get your terrain data files
(3) Open the terrain data files in QGIS and re-save them as geotif files
(4) Create a .tfw file for each of your geotifs (you'll do this at the same time as step 3)
(5) Edit the .tmc file that geoconvert uses
(6) Move the input files into the geoconvert folders and start the conversion
(7) Move the output files into your \Documents\Aerofly FS 2\scenery\elevation folder
How to reverse this if it breaks something in the sim:
All you have to do is move or delete the converted files back out of the \Documents\Aerofly FS 2\scenery\elevation folder.
Tutorial video is here:
I did some checking for issues along the borders of the refined mesh areas, and there is indeed a small discontinuity/short invisible wall varying in height exactly at the border of the refined mesh areas. You can see where this is with the floating line of trees in the image below. In this case, the highest point I could find in the invisible boundary was ~650ft above ground level. On either side of this boundary line, it is unaffected. What this means is if you're flying very low to the ground and cross this line, you might suddenly crash.
So, if you do decide to try this, be aware that you may create short, invisible collision walls at the boundaries of your refined region.
Fortunately, each section of the USGS data covers a very large area, and it doesn't take long to convert, so it's not difficult to just convert a large enough area so that any issues like this only appear out the in the middle of nowhere or away from airports.
Disclaimer, please read:
I'm assuming that anyone here who wants to do this already knows they are tinkering with the nuts and bolts of the sim, so please, just be smart about it, and if you encounter issues due to this, don't go complaining to the IPACS team. They are already pretty reluctant about letting me share this, and not only do I not want a headache for them, but I also don't want to be the guilty party if they take issue with me telling people how to do this in the future. It's very easy to reverse this if you have issues, and I will make sure you know how to do so in the tutorial.
Ok, with that out of the way... I'll be working on the tutorial this evening and should hopefully have it posted up here in 6 hours or less!
I think Jeff was talking about the borders of your newly defined terrain heightmaps. At the border it could have conflicts.
Gotcha, I will check that.
Also, the underwater topo mentioned above was my fault -- the data from USGS has some that are labeled "topobathy" which (obviously) include underwater terrain. They have others for the same regions that don't include the water.
We have to insure that the changes in heightmaps don't cause airports, scenery objects, and cultivation to float above or get eaten by the changes to the maps not read directly by the sim engine. I'm very concerned with this and haven't had a chance to test its effects yet.
Those that try this please proceed with caution for now.
I did some testing in the San Francisco Bay area to see if this is a problem or not. All of the trees, buildings, etc. seemed to be unaffected by the new mesh and auto-adapted to the height. SFO also looked good including the freeway overpasses anchored to the ground correctly.
The only issue I did find was that in certain places, this USGS data actually includes terrain underneath water. Because of this, the SF Bay was shaped like the ground underneath, including the underwater pilings to the Golden Gate Bridge (cool to look at but obviously not 'correct'!). I think the regions where they have this underwater data is limited, and it's also possible they had a different data file available that doesn't include the underwater topography. I'll have to go back and check. The rest of the coastline along the ocean looked correct.
The zillion-dollar question for me, will be how this affects existing scenery. In particular, I would like to see how it affects existing buildings in flattened areas.
As far as I can tell, it has no effect on that. Existing objects appear to auto-adjust to the new elevation heights just fine.
Here's a before/after of some cliffs on the California coastline with the default AeroFly imagery. Cliffs actually are cliffs now instead of steep slopes. With some higher-res orthophotos here I think this would look really amazing like my mountain scenery:
I'll try to get that tutorial up by tomorrow night so those who want to try it will have the weekend to test. I haven't been so excited about this sim since the first time I tried flying in VR. The realism with a detailed mesh and good quality photoscenery is just amazing. And like we've come to expect from AeroFly, it doesn't seem to have any effect on the performance that I can see. I'm still running this in VR on a 3GB GTX1060.
Sorry to be a tease, but I just had to share some example shots from some of the scenery I've converted. The quality with -1 resolution orthophotos combined with a high res topo mesh is mind-blowing. Yes, really, mind-blowing. It's at least as good as Google Earth now. Imagine that, flying a plane in Google Earth... amazing! Here are some before/afters. They may not look like it, but they are showing the same locations (angles are slightly different):
And lastly, just a shot of some mountain texture. Having the bumps in the mesh under the shadows and boulders just looks amazing when you're flying around it!:
For those looking for the tutorial, this link will jump you to it: Click Me
I have figured out how to refine the AeroFly mesh for the U.S. quite easily using USGS NED data (publicly available). It's a pretty serious improvement on the default AeroFly mesh, especially for valleys in mountainous terrain. This data is available for the entire contiguous U.S.
For those who are interested, I'll be posting a how-to here in the next couple days. You'll need another program called QGIS (open source, many of you already have this if you're geoconverting already). It's easier than converting aerial imagery, and can be reversed by simply deleting the files you create from your Documents folder.
I was asked to put a disclaimer so I'm saying it now, and will repeat it again when I post the tutorial: do this at your own risk, and if you edit the terrain meshes for some of the default airports, it might break certain things about them. I haven't tested already-developed areas enough yet to know if this is likely to happen. In my opinion I think this is very safe and is just as easily reversed, but know how to do the reversing before you begin!
Thats allso... Picture must over working .... Google Text on Ground.
This is true, but after running it through geoconvert you really can't see it in AeroFly (this is in VR, not sure if it's more visible in 2D). I think I've only noticed a visible watermark two or three times in all the many areas I've converted.
Hi Uli, you actually can get the same satellite imagery in FSET as Google Earth (unless you're referring to the 3D modeled city imagery in Google Earth, which doesn't come from their satellite imagery servers). I don't think I'm allowed to post the .ini file info here unfortunately, but it's just a matter of having the latest Google server number in the FSET ini file. I think the latest version changed again a month or two ago. You can fish it out with the developer pane in Chrome if you know how to use that.
Hmmm... I don't see anything immediately obvious that looks incorrect, although I'm not very experienced with sceneProc yet either.
One minor thing, that probably doesn't make any difference, is in your .tsc file: on the lines that say "[tmsimulator_scenery_cultivation][element]", I always have that number after [element] increasing for each new .toc. So the end of those lines would be [element], [element], [element], etc. But I really don't know if that's necessary or if it makes any difference at all..
... If AI framerate can be implemented, perhaps when in VR it could degrade the outside edges first as blurring of the peripheral outer 40% of the image already occurs due to the "sweet spot" nature of Fresnel lenses in HMD's.
This is called foveated rendering and is very likely something we will see in VR HMDs in the future. The idea is that you combine this with eye tracking, so it follows your pupil and only renders the center of your field of vision with max quality, and matches the sharpness in your peripheral vision with the eye's capabilities so you're not wasting GPU resources in those areas. This will probably be a necessary technology to enable much higher resolution in future VR devices without sending the system requirements through the roof!
Yes, that's where I started, too. Unfortunately, I found orthophotos are not always available for download at all resolution levels.
Kind regards, Michael
Your statement made me realize that something with that table should probably be clarified that may be confusing to new geoconverters:
You can either use the recommended download resolution, or any finer download resolution (meaning a lower number), with each line in that table. In other words, it would perfectly fine to use a -1 download resolution with every geoconvert level from level 9 to level 15... but I doubt anyone would actually do this because that would be a HUGE download.
The reason for having it broken down as the table does it is just to be efficient with your scenery downloads vs. the size of the area you're covering.
TL;DR: it's fine to use a better (lower number) download resolution than what it says for each line in the table. Just avoid using a coarser (higher number) download resolution, because then you will start to see visual quality degrade.
Hmm, that's very odd. Are you using sceneProc to create the toc files? If so, my best guess is that you're missing the entry in your .tsc file for those regions (or the syntax is wrong), but if those missing regions aren't each in their own .toc file then that shouldn't be the cause.
FWIW, I have used a single .tsc file to add trees to an area about the size of 6 level nine tiles, but within that single .tsc file it contained references to 32 different .toc files. So I'm not sure if there's an upper limit on trees in a single .toc, but there doesn't appear to be a limit within a single .tsc (or if there is, it's very large).