Removing Docks from Lakes and Bays

[jgarnold]

I hope that this reply will bring the thread to the 'top' of the list as I have experienced a different problem implementing CGL aerials for a different location.
I obtained the 256x256 image and saved it as a .PNG then created a new project just for the CGL.
I loaded the project into dev mode and did a BUILD ALL with no errors.
I placed the Package into the community folder and started MSFS and started a flight at the location.
Firstly I got the image below which has also masked out everything where I painted over the 'ghosts'.
Secondly (and more importantly) when I start the flight and use developer camera to view the area the 'ghosting' still appears even though it isn't seen in the select airport 'window.
At first I thought the problem was that I didn't save my .png file as a 32 bit file including the alpha channel but I thought that I fixed that choosing 'apha channel' (in the Paint Shop Pro export png) with the area for transparency set to 'existing image or layer'.
The entire project including the CGL aerial png file can be downloaded from https://mega.nz/folder/BMYwHYib#YrGU9yQrYavbeXNyL02VOg

Any ideas?

 

[GaryGB]

Hi John:

I am attempting to learn how to utilize this GUI as we can not read MSFS CGLs with TMFViewer (which is able to read FS2Kx terrain BGLs).


I have not looked at this info for quite some time, so I am going slowly through the steps for the process outlined above in DevMode menus.


When you selected Aerial Images to be included in the set you made for a test CGL, what assigned Quad "LOD" did you pick (as shown here) ?

CGL
Before:
View attachment 85709

After:
View attachment 85710

I cheated.:

I stole the QUAD level 17 from here, which is as detailed as it gets in the original tiles. I extracted/resized an 2048x2048 png of the tile from a screensave using paint.net to resize to level 20. I then cut and pasted, and blurred a bit, to eliminate the docks. I then used xnview to split the PNG 8x8 to get 64 level 20 PNGs at 256x256. I found just the ones that formerly showed the docks, named them as level 20 Quads, and made my CGL using the SimpleAerial sample from the SDK as a guide.

This had no blending color issues because I used what the sim uses as an aerial tile. The only hard part was finding the right QUAD naming for the few tiles I replaced. I only used 6 of the 64 split. I used no alpha blending, although that would be an option. Worked pretty good.

It might be easier to Copy the image, resize, split, rename, and then edit the tiles you want to replace...

I noticed you have (1) QUAD ID Tile in your custom Aerial Imagery CGL PackageSource tile set that was compiled for your defined area:

02121222211320132.png


I am thinking it would be a good 'test' to match / exceed MSFS' local Aerial Imagery resolution (at a max assigned QUAD Zoom Level "20").

In MSFS, it's like matching / exceeding LOD-13 / QMID-15 resolution in FS2Kx to ensure display of custom (Secondary)- over default-(Primary)- Aerial Imagery LC tiles.


Also, I am still trying to find info on how to see if MSFS' default PG TIN extent can be visualized via DevMode menu GUI as vectors.

(As a reminder, thus far MSFS' default PG TIN meshes are just that ...vector TINs (and not 3D glTF models, as in GEDOT methods for 3D G-Polys)


If MSFS' default PG TIN overlaps the seaplane area in question, IIUC, we may also need to "exclude" that part of PG triangles as done here:

https://www.fsdeveloper.com/forum/t...otogrametry-monolith-trees.455740/post-905555

Reportedly, a MSFS' default PG TIN exclude may only "flatten" a TIN mesh to (0) Meters AMSL, so Primary (default) Aerial Imagery may 'persist' locally.


So IIUC, we must test whether we can display a (edited) Secondary Aerial Imagery CGL on top of it.

https://web.archive.org/web/2021092...imulator.com/questions/1400/cgl-over-tin.html


If not, a terrain vector Polygon may be the next indicated test, using Aprons of the 'proper' types stacked ...with (fake ?) water on top.


Alternatively, I am not certain if Aprons of the proper types stacked with (fake ?) water on top ...can be superimposed 'over' GEDOT 3D G-Polys.


PS: I plan to research 'Fake Water' (aka "Water Test Material" in MSFS SDK Docs) cited by seattledec in your other recent thread ...here:

You might try using the 'fake water' material; and than cover up again with a water polygon. It is a last resort; do not have water waves effects but it is ok to cover defects such as in this case.
Draw a polygon over the ghost artifacts; on the material editor type 'water' scroll down the low end you will see 'water test' is the last at the bottom.

assign the fake water material to the polygon and play with color to match the area you work on; after again a new water polygon to cover it. It can work in case like this.

GaryGB

 

[jgarnold]

Hi Gary,

It seems such things can be a can of worms. Vagaries?

Firstly I had to try many many times before 'Aerial' was displayed as Available and the 256x256 'tile' was displayed for 'clipping' and even after I managed to get it to be available I have tried since and cannot. Really weird.

Anyway -


I contacted Rhumbaflappy and he said that using tile 'overlays' would not fix the problem of satellite ghosting and advised to use two polygons the first an 'exclude TIN' polygon and a duplicate polygon (shape and area only) set to a texture polygon with a water texture and setting the RGB color values to blend in with the surrounding water and with a priority set to 1 which has worked.

I find it strange that (I now remember) that I had a similar problem 2 or 3 years ago and was advised to add an APRON with RGB color values set accordingly. Maybe Asobo has changed 'things' since.

I never tried 'fake water'.

 

[GaryGB]

Do you now have an updated Project Folder chain (only) for the latter described "fix" as described above, which you could link for us to examine and learn from as a 'working example' ?

I am interested in seeing what Asobo is doing in these scenarios, as they just added a MSFS default PG TIN to one of my MSFS W.I.P. project areas, that AFAIK has no high resolution GIS source data available from which to create what appears at run time to be an "AI Hallucination" PG extrapolated from low resolution IRL GIS data.

FYI: Google Earth PG seems also to be sourced in a number of areas I am familiar with IRL, from what I believe to be lower resolution GIS source data, thus suspect IMHO, for over-sampled / extrapolated in order to derive PG that does not reasonably match IRL.

Within the MSFS area of my project in question, the noticeably "spiked" configuration of the ground surfaces does not reasonably match IRL, and is characteristic of anomalies I have previously seen when low resolution elevation data (8-bit) is processed by FS2Kx SDK Resample, for example.

It is interesting to see 'experimentation', being done by Asobo, but the results in my project area were IMHO "not ready for prime time" in a Flight Simulator 3D world we might all wish to take seriously. Worse yet, in my project area, I must fit water into a narrow rocky canyon with both 'terrain' surface types in close proximity, so I need to be able to fully eradicate the new MSFS PG.

Thanks for following up to share a potential solution in the FSDEV public forum, so all here can learn from these MSFS "Vancouver Vagaries".

GaryGB