FT Ortho4XP Conversion Tool 1.14 = Odd Results?

[Torbin]

Hello,

I'd like to thank you first and foremost for making the scenery for X-Plane. LAS serves as a very nice hub for those that fly in the US, particularly those that like to use online ATC services such as PilotEdge.

A friend and I both ran the conversion tool as per instructions but we both came up with the same results. I am linking a video that provides two examples with observations, along with the log file and scenery pack INI. Any advice you could give to help us fix this issue would be greatly appreciated.

NOTE: Change the .JPG on the log & scenery_packs to .txt... Would not let me add those files with their original extensions.

Video: dropbox dot com/s/roc01fm2h322rna/KLAS%201.0%20Ortho4XP%20Scaling.mp4?dl=0

You'll have to ^^^ put in the actual HTTP and . to get the link to work. Forgive me for trying to bypass the rule of the new guy not being allowed to post links, I thought in this case since it's a bug report it might be warranted.

Thank you!

[Torbin]

Seems I can't attached the log or ini...

Snippet from ini:

SCENERY_PACK Custom Scenery/DD_NY_Airports_v2_XP Documents/
SCENERY_PACK Custom Scenery/DD_NY_Airports_v2_XP_1KEWR-KCDW-KLDJ_Roads/
SCENERY_PACK Custom Scenery/DD_NY_Airports_v2_XP_1KJFK-KLGA-KTEB_Roads/
SCENERY_PACK Custom Scenery/DD_NY_Airports_v2_XP_KEWR-KCDW-KLDJ/
SCENERY_PACK Custom Scenery/DD_NY_Airports_v2_XP_KJFK-KLGA-KTEB/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_airport/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_city/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_overlays/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_1_overlays/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_2_Photoreal/
SCENERY_PACK Custom Scenery/Photopolys4FlyTampa_+36-116/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_3_Mesh/
SCENERY_PACK Custom Scenery/imaginesim KAUS Austin XP11/
SCENERY_PACK Custom Scenery/L_000 Drzewiecki Design Library/

I'll skip pasting the log text since its a ridiculous amount of text to paste in a forum...

[MediumRareBaku]

Having a similar but different issue.

[jsnapp]

I found that remove the divide by 2 on lines 383-386 solved this problem for me. From a quick read of the code it wasn't clear why the divide by 2 is there. But it seems intentional to have coded that this way, so I highly doubt the PROPER fix is to for all conversions to remove the division by 2.

Code: Select all

                     outpout_file.write("POLYGON_POINT "+str((lon-(x_dis/2)))+" "+str((lat-(y_dis/2)))+" 0.00 0.00\n")
                     outpout_file.write("POLYGON_POINT "+str((lon+(x_dis/2)))+" "+str((lat-(y_dis/2)))+" 1.00 0.00\n")
                     outpout_file.write("POLYGON_POINT "+str((lon+(x_dis/2)))+" "+str((lat+(y_dis/2)))+" 1.00 1.00\n")
                     outpout_file.write("POLYGON_POINT "+str((lon-(x_dis/2)))+" "+str((lat+(y_dis/2)))+" 0.00 1.00\n")

I might suggest that the developer of this tool put it on github with a permissive user license as it seems like it could be highly useful for other sceneries that also fail to have an ortho4xp patch file.

[jsnapp]

I spoke too soon. The above change seemed to fix around the airport but not further away.

Looking a bit more at the code is the problem that this tool assumes ALL imagery is at the same zoom level? This part doesn't seem to be done on a per image basis, and instead is done only on the first few lat, lon values in the sorted set. That doesn't seem like it would work for multi-zoom level imagery, especially if the wrong zoom level happened to be in the lower right corner of the tile... :-)

Perhaps the difference in some people getting stripes and others getting the gridded pattern has to do with how this initial sort shakes out....

Code: Select all

       latset = [(tile_l[i][0]) for i in range(len(tile_l))]
       latset = set(latset)
       latset = sorted(latset)

       lonset = [(tile_l[i][1]) for i in range(len(tile_l))]
       lonset = set(lonset)
       lonset = sorted(lonset)

       tilesize = tile_l[0][2]
       print("Tilesize here is ", tilesize)

       x_res = abs(lonset[1] - lonset[0]) / tilesize
       y_res = abs(latset[1] - latset[0]) / tilesize

       x_dis1 = abs(lonset[1] - lonset[0])
       x_dis2 = abs(lonset[2] - lonset[1])
       x_dis3 = abs(lonset[3] - lonset[2])
       x_dislist=[x_dis1,x_dis2,x_dis3]
       x_dis=min(x_dislist)

       y_dis1 = abs(latset[1] - latset[0])
       y_dis2 = abs(latset[2] - latset[1])
       y_dis3 = abs(latset[3] - latset[2])
       y_dislist=[y_dis1,y_dis2,y_dis3]
       y_dis=min(y_dislist)

       px_x_tile_mask=int((x_dis*px_x_mask)/(elon_mask-wlon_mask))
       px_y_tile_mask=int((y_dis*px_y_mask)/(nlat_mask-slat_mask))

[Yannis[flytampa]]

Hello,

I'd like to thank you first and foremost for making the scenery for X-Plane. LAS serves as a very nice hub for those that fly in the US, particularly those that like to use online ATC services such as PilotEdge.

A friend and I both ran the conversion tool as per instructions but we both came up with the same results. I am linking a video that provides two examples with observations, along with the log file and scenery pack INI. Any advice you could give to help us fix this issue would be greatly appreciated.

NOTE: Change the .JPG on the log & scenery_packs to .txt... Would not let me add those files with their original extensions.

Video: dropbox dot com/s/roc01fm2h322rna/KLAS%201.0%20Ortho4XP%20Scaling.mp4?dl=0

You'll have to ^^^ put in the actual HTTP and . to get the link to work. Forgive me for trying to bypass the rule of the new guy not being allowed to post links, I thought in this case since it's a bug report it might be warranted.

Thank you!

Thanx for the video ;) .... As mentioned in the readme pdf, the tool does not support mixed zoom level tiles

[Yannis[flytampa]]

I found that remove the divide by 2 on lines 383-386 solved this problem for me. From a quick read of the code it wasn't clear why the divide by 2 is there. But it seems intentional to have coded that this way, so I highly doubt the PROPER fix is to for all conversions to remove the division by 2.

Code: Select all

                     outpout_file.write("POLYGON_POINT "+str((lon-(x_dis/2)))+" "+str((lat-(y_dis/2)))+" 0.00 0.00\n")
                     outpout_file.write("POLYGON_POINT "+str((lon+(x_dis/2)))+" "+str((lat-(y_dis/2)))+" 1.00 0.00\n")
                     outpout_file.write("POLYGON_POINT "+str((lon+(x_dis/2)))+" "+str((lat+(y_dis/2)))+" 1.00 1.00\n")
                     outpout_file.write("POLYGON_POINT "+str((lon-(x_dis/2)))+" "+str((lat+(y_dis/2)))+" 0.00 1.00\n")

I might suggest that the developer of this tool put it on github with a permissive user license as it seems like it could be highly useful for other sceneries that also fail to have an ortho4xp patch file.

I suggest not to change the code..removing the divide, may fix some tiles but will cause problems to others :). As x is the distance of one tile ( must be the same all over the one arc ortho tile.. no mixed zoom levels) , the left and right edge are calculated from the center ;)

[Torbin]

Hi Yannis,

I did as you suggested by building an ortho4XP tile at one zoom level (ZL17), but I'm still experiencing limited results. They say "a picture is worth 1000 words", so here's an edited video showing my results and running through some if/thens to what I found and where I'm lost!

https://www.dropbox.com/s/1ndzjt1he2x53 ... s.mp4?dl=0

The video starts off showing all textures loading with only the native ortho4XP_36-116 (Photopolys4FlyTampa_+36-116 or FlyTampa_3_Mesh REMOVED), then I show two angles with the Photopolys4FlyTampa_+36-116 and FlyTampa_3_Mesh properly installed.

I look forward to a solution. Please advise... Thanks!

[deshain]

Hi Torbin, i red your post yesterday but did not had time to answer ... this is unfortunately today also the case ... i might have the chance later (my) day ... i had a quick look at your videos and i noticed something crucial that my solve all the issue ... So even in the past, (now with Vulkan even more) you should not move far away with free cam from the plane ... The ortho textures are loaded only when the plane is "near" ... So what i would suggest now is that you try again but this time you take the plane "with you" .... Its easy, just spawn with the plane, open the xplane map and click on your plane .. by clicking you can give it some parameters (altitude, speed, pitch) and then, you can move the selected plane around the map ... So before i dig in further (as is never had issues with the conversion tool (NAIP Source ZL17 1/3" NED Mesh) i would highly suggest you to try my method and if you can reproduce the issue ... bear in mind, if you "slew" too fast to far you might need to wait a little bit until xplane "catches up" and loads the textures ...

SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_airport/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_city/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_overlays/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_1_overlays/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_2_Photoreal/
SCENERY_PACK Custom Scenery/Photopolys4FlyTampa_+36-116/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_3_Mesh/

just to make sure we are talking about the same "installed correctly" :) ...

[jsnapp]

Did you test this before release? Because just taking off and flying up 5000+ feet and I can clearly see stock xplane rather than ortho displaying.

I also see a very weird reflectivity to the polygon files are or near sunset.

If you have trouble reproducing this let me know and I can post images and sim setting / art control value details.

I HIGHLY urge you to create an OBJ8 patch file for ortho4xp users.

[S3rg1o]

Post deleted and opened a new thread
Sorry for the inconvenience

[Torbin]

Hi Torbin, i red your post yesterday but did not had time to answer ... this is unfortunately today also the case ... i might have the chance later (my) day ... i had a quick look at your videos and i noticed something crucial that my solve all the issue ... So even in the past, (now with Vulkan even more) you should not move far away with free cam from the plane ... The ortho textures are loaded only when the plane is "near" ... So what i would suggest now is that you try again but this time you take the plane "with you" .... Its easy, just spawn with the plane, open the xplane map and click on your plane .. by clicking you can give it some parameters (altitude, speed, pitch) and then, you can move the selected plane around the map ... So before i dig in further (as is never had issues with the conversion tool (NAIP Source ZL17 1/3" NED Mesh) i would highly suggest you to try my method and if you can reproduce the issue ... bear in mind, if you "slew" too fast to far you might need to wait a little bit until xplane "catches up" and loads the textures ...

SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_airport/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_city/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_0_overlays/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_1_overlays/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_2_Photoreal/
SCENERY_PACK Custom Scenery/Photopolys4FlyTampa_+36-116/
SCENERY_PACK Custom Scenery/FlyTampa_LasVegas_3_Mesh/

just to make sure we are talking about the same "installed correctly" :) ...

Hello deshain, thank you for chiming in!

The first part of my second video address the camera placement limitation factor. I know you mentioned you didn't have a lot of time, but if you get to rewatch the video, you'll see the first example I provide is with a regular Ortho4XP tile made with only ZL 17 using the 1/3" NED mesh source. This one has no problem fully drawing in. As someone who has built the entire US under the old G2XPL tool, then all over again with Ortho4XP 1.20b, and then re-converted all those tiles in Ortho4XP 1.30, I've probably spent too much time becoming proficient on camera angle limitations when inspecting for tile flaws haha :) That being said, I also gave extra time (several minutes) for the specific FlyTampa tool's replacement tile to load in case it might be taking longer for whatever reason. I do normally use the technique you mentioned so I can experiment with typical altitudes I fly at in GA and airliners, so here are some screenshots to further illustrate the issue. BTW, I also removed the FlyTamps_LasVegas Photoreal folder and verified the ini file ordering as per scenery tool manual!

To help further outline the problem, I made a third video clearly showing that the Photopolys4FlyTampa_+36-116 tile has too small a draw distance compared to the adjacent standard built Orth4XP tiles. Before I started recording, I did wait a few extra minutes despite further adjacent tile textures already loaded and drawn in. In this video you'll see my aircraft flying at 33,000 ft above LAS toward the northwest. The photo textures by Creech AFB start to draw in very late despite the 36-117 already drawn in. Then at the end we swing the camera to see the LAS portion of 36-116 gone to stock textures, but the regular Ortho4XP 35-116 and 36-115 tiles are still showing photo textures even though they are further away. Last note, this is under 11.50 Vulkan enabled beta 16:

https://www.dropbox.com/s/ssugzypkod9nd ... 2.mp4?dl=0

[deshain]

ok i think i got it now ... i tested on lower altitute (UWXP on) and it was first not visible ... now i did some tests with perfect sight conditions (disabled UWXP haze) and >FL300 and there is indeed some "lazy" load observed ... but on my side its not that dramatic as on your video ... i think this is really an xplane performance bottleneck ... the Poly's of course are heavier then simple ortho's and now with vulkan and the vram management they might produce such issues ... with normal weather conditions (running UWXP / ASXP) i do not notice this because of the "haze" and limited visibility ... i dont know if there is a solution for that but at least i know whats the issue now and how to reproduce :)

here my screens ... some from the first lower flight and then quick jump into FL300

https://imgur.com/a/IvpPiZ7

[Torbin]

ok i think i got it now ... i tested on lower altitute (UWXP on) and it was first not visible ... now i did some tests with perfect sight conditions (disabled UWXP haze) and >FL300 and there is indeed some "lazy" load observed ... but on my side its not that dramatic as on your video ... i think this is really an xplane performance bottleneck ... the Poly's of course are heavier then simple ortho's and now with vulkan and the vram management they might produce such issues ... with normal weather conditions (running UWXP / ASXP) i do not notice this because of the "haze" and limited visibility ... i dont know if there is a solution for that but at least i know whats the issue now and how to reproduce :)

here my screens ... some from the first lower flight and then quick jump into FL300

https://imgur.com/a/IvpPiZ7

Hello deshain,

Thanks for taking the time to help acknowledge what's happening.

An excellent additional solution will be for FlyTampa to provide an additional/alternate mesh application method that I just outlined in a separate post, part of which jsnapp suggested (last line below) about creating a patch file. These work great, are easier for the end user to use, and allow for multi-zoom level imagery and multi-custom meshed airports to exist within the same tile. This is already in use by several other X-Plane payware and freeware airport / scenery developers! http://www.flytampa.org/forum/viewtopic ... 34&t=14116

Did you test this before release? Because just taking off and flying up 5000+ feet and I can clearly see stock xplane rather than ortho displaying.

I also see a very weird reflectivity to the polygon files are or near sunset.

If you have trouble reproducing this let me know and I can post images and sim setting / art control value details.

I HIGHLY urge you to create an OBJ8 patch file for ortho4xp users.