X Plane Ortho

[Roman Bayramdurdiyev]

Thisstill requires DSF and terrain files from Ortho4XP or the like, but does not require the imagery during setup time. Instead that is pulled in as you fly. Ortho4XP should be configured to not download imagery for this.

The configured imagery source will be used up the max resolution you set. Since this occurs on the 'fly' your mileage will vary depending on your internet speed, the source type you choose, etc. It's also entirely possible that certain source types might rate limit you or block you. That's a risk you take by using this. (Though I would expect this would cause far less load than a normal Ortho4XP setup.)

Thanks for the link of that other project. It sounds like a similar technique is being used. I could see combining the ideas and doing on the fly compression if a jpg/png is available, otherwise fetching. Shouldn't be hard to implement.

The reason this is Linux (and likely Mac) only ATM, is due to using a virtual filesystem technique called FUSE. There are some projects now such as WinFSP that could make this possible: So it's _feasible_ that project could make something like this possible. I don't have a great way to test that, but I do have an old Windows laptop somewhere that might be able to run x-plane on low low settings.

You mention internet bandwidth, but from what I'm seeing so far, it's more likely the allowed bandwidth from the APIs you are hitting are the bottleneck. I have quite low-end and flaky broadband, I'll bet most of you all have quite better internet.

Due to this, I have a number of optimizations in the processing. Effectively, tile fetching has a 'deadline' that if not met, will return a lower resolution tile in order to keep things running. The high resolution tile fetch will still be backgrounded and therefore next fetch it will be cached, and therefore quick.

Besides the image provider - also consider the IP provider throttleing you or put data caps on These data caps or surcharges are well below 20 bucks of hard drive a month here in the US - so some local caching seems a must.

That's pretty close to what it does now. For instance when it loads a DSF it pulls in low res tiles. Only when the the tiles are close by will it pull in high res versions. If you are flying fast, it will reduce the resolution of the requested tile. Would be straightforward to include altitude into that logic.

Yeah if you have severely capped internet then you probably want to stick with the built in scenery and not bother with orthos in general. I've definitely been in that boat in the past. My current internet may be slow but it's at least not capped!

That said, the newer versions I have are working fine for me even in 2022 on XP11 point whatever is the latest. In fact, better than they did under whatever XP rev was around in 2017. I'm hopeful it will continue working in XP12 as well. I could, in principle, upload a new version, I'm just skeptical of how much that project should really be pushed.

@VogonZarniwoop it might be interesting to see your updates on Github or what not if you want to share. I have been poking a bit through your code, particularly how you are dealing with creating he sparse files.

OK, I'll see what I can do. It might take me a while to get to though. Recent change have been solely for my own use and I got a bit lax about updating documentation. I also have open source irons in the fire unrelated to flight simulation which takes up time. But I'll polish it up when I can and re-upload.

Just pushed an update to my project:

* Better detect starting locations and pull in high quality tiles around the area. This assumes using a higher ZL around airports. I also gather high quality tiles surrounding this area. X-Plane does not directly indicate starting location via API, but I was able to infer this by how tiles are accessed.

* Smarter speed detection and reduction of ZL based on deadlines. Essentially, I determine how many tiles you are covering based on the current ground speed. As tiles are fetched, I calculate the average fetch time at a ZL. From this I can infer if a tile you request at a particular ZL is likely to be met in time, if not, I reduce the ZL until we have a good idea we'll fetch in time.

Will XPlane detect new ortho tiles added to custom scenery without a restart? Because I thought it loaded the scenery tiles when starting a flight, and if the scenery content is not there when the flight starts, I thought it didn't know it existed and wouldn't suddenly load it.

These lightweight tiles would avoid the urban areas because who needs more squashed buildings in their lives, and would only highlight the areas that make an "impact on your mind" when you fly. For example, flying out of CYLW, Kelowna, I would want the hills/mountains ortho and leave the valleys (whether latticed with roads and buildings as autogen, or as fields) alone, except for the odd thing that actually adds visual interest.

No scenery reload is required for this - only the textures. Those can be swapped out "on-the-fly". You can test this yourself in the built-in texture browser available via the menu "Developer -> Show Texture Browser" and double-clicking on any texture and hitting the "Reload" button after replacing the texture file with something else.

So there is a bit of logic that occurs with X-Plane with scenery loading. I had to do a bit of observing of behavior, but essentially what happens is that when a flight is first loaded it pulls in the DSF area and surrounding DSF files for a total of 9 DSF files. These files may refer to terrain files which may point to DDS files that contain the actual terrain.

All this needs to be essentially in place for X-Plane at this point in time, otherwise X-Plane will not be aware of the terrain. Now that doesn't mean that X-Plane has necessarily fully read in each DDS file, just that it is aware of it (reading in a portion of the file). For your initial takeoff area, X-Plane will open and read in the full contents of the already detected DDS files. The number of these will vary depending on a few factors but for ZL16, you are talking around 300 or so tiles.

As you fly, X-Plane will pull open and read in DDS files as you go. Often more than once.

So with my on the fly Ortho fetching that's precisely what I do. You can pretty easily cut a requested ZL down 4 notches, due to how the slippy map tiles and X-Plane tiles work. So a ZL18 tile can have a low res place holder of ZL14 done with little trouble.

Nothing major, besides a few tweaks. I want to re-work some of the internals when I have time in order to be more efficient with how I retrieve tiles, and such. I also intend to package this up into a python 'zipapp' which should make it a bit easier to setup.

If OK with moderators, I'd like to set up this thread for sharing knowledge on how MAC users can try out auto ortho.Specifically, how to install/ set up AO, and best practices, etc. I am using a Studio Max, and hoping it has enough CPU power to work with AO.

Developer has notified community that AO can work on MACs, so I'm excited. So far, I've been following thread below, which covers Auto orthos for community. Lots of useful stuff, but not much dealing with MAC issues. Also, somewhat confusing. For example, first iterations required separate Python installation, but later on it seems developer incorporate Python in the software itself.

Is the app working on the Mac now? The last time I looked at the Mac fork on github a month or two back, it was compiled but everyone trying it was saying it wasn't working, due to dependencies or some other technical issues.

If there are people there running this on Apple silicon Macs and reporting it's working for them, it's worth perservering with (and I'll certainly give it a try), but until it actually *works*, there's not much point in battling with running it on your system.

Honestly, until it's confirmed working, it should be regarded at best as "in development" and "doesn't seem to work yet", so until that changes, or you want to take part in development to get it to work, it's not worth investing any time on imo.

@beebon Yes, I agree. I am not well versed in the world of scripting so really waiting on someone from the community to help out. I tried and it does not work at least on my M1 machine. For now I continue to download tiles but once I know it is working I will give it a try. I think this thread that is started will help keep the focus on Macs. We wait and see.

The UI loads and I was able to install different regions, but when I click run the interface disappears and in terminal I get a message the aoiage.dylib is not in arm64 format. In GitHub, another user using an M1 Max Studio managed to get it working and was kind enough to share his 'build' (is it you, @kemosabe?), but even then I get the same error. I've tried every possibility including installing various programs via brew etc., but to no avail.

3a8082e126