Posts by qwerty42

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!

Quote from Jet-Pack

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.

Quote from drhotwing1

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.

Quote from HiFlyer

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:

Ok, I couldn't resist, 8 more screenshots of how terrain looks now. Just incredible. In VR I almost feel like I'm home!

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!

Quote from uli057

Ok Google...

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][0]", I always have that number after [element] increasing for each new .toc. So the end of those lines would be [element][0], [element][1], [element][2], etc. But I really don't know if that's necessary or if it makes any difference at all..

Quote from RoyPettit

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

Quote from pmb

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

This is from the wiki and based on my own tests it's a good recommendation to follow. I usually download very large regions with download resolution of 3 or 4, and convert that from levels 9 to 11. Then I refine smaller areas with download resolution of 1,0, or -1 (depending on how big it is and good I want it to look at close distances) and convert those from levels 12 thru 14 or 15. With most of the publicly available ortho images, you really hit diminishing returns if you go all the way to level 15, though.

Are you able to launch Oculus titles from Oculus home? That may give us an idea if it's something to do with the Oculus installation. Also did you install the recent Oculus patch to fix their expired cert for the runtime? It requires you to go to their website to download it.

Here's a new version that should fix the issue. The problem is actually FSET. When you use the C button, it copies according to the system format, but when you use the P button, it will only work if the decimal marks are periods instead of commas.

This new version of the Excel tool compensates for that issue and should work with it whether your system uses commas or periods: https://www.dropbox.com/s/zv3clcl5i6v5…_v1.6.xlsm?dl=1

Please test it and let me know you encounter any other problems!

Quote from pmb

It's FSET saying invalid. Fortunately, I could reproduce it. Screenshot is attached.

Kind regards, Michael

Can you check something for me? Can you draw a rectangle somewhere in FSET (doesn't matter where), then click the "C" button to copy, and then paste the output in a reply here? I need to see if the commas get passed by FSET back to Excel also. It should look something like this:

#--- Partial FS Earth Tiles ini datas ---

[FSEarthTiles]

AreaDefinitionMode = 2Points

NorthWestCornerLatitude = 49deg 50min 16.74sec north

NorthWestCornerLongitude = 7deg 48min 0sec east

SouthEastLatitude = 41deg 14min 41.18sec north

SouthEastLongitude = 22deg 12min 50.63sec east

WorkingFolder = C:\fset\work

SceneryFolder = C:\fset\scene

Oh! I bet it's because of the comma used for the decimal mark rather than a period (e.g. 51,1055 vs. 51.1055). I wish the whole world could standardize on one or the other, and have the U.S. finally switch to the metric system too! I can probably fix it I think... check back in 20 minutes or so.

Quote from pmb

I am sorry to be nasty, but I get an Input Invalid with 1.5 of the Excel tool as well. I just followed the video, made a rough map around Germany in FSET, copied and pasted into the Excel sheet, choose level 10 copied using the orange button and pasted into FSET.

Any logfile or the like I can send?

Thanks and kind regards, Michael

Hi Michael, is it the Excel tool saying input invalid, or is it FSET? Can you send me a screenshot of both of them so I can see what the inputs are?

Quote from Jetjockey10

This current version appears to be running but there are no output scenery files to be found. duh.

Does the geoconvert window show the conversion happening and say it's finished? If so, one possibility is that you're converting with mask tiles disabled (a good thing to do), but your downloaded images don't fully cover the tile area you're trying to convert. In that case it will look like it's converting, but no output will be written.

If this is indeed the issue, see the thread in this forum 'Image Tile Coordinates'