Accurary and problems with the water masks: Screenshots

[Guest cbuchner1]

This is with DXT1 tiles containing single bit alpha water masks. This texture format would also be FS9 compatible. The source data is NASA SRTM V2 data rendered to a bitmap at 1 arc second pixel resolution. First, a very small lake near Bolzano, Italy. You see that the data appears to be about 1 "pixel" off. But overall still a pretty good hit.http://forums.avsim.net/user_files/175809.jpgSome lakes obviously haven't been completely scanned by the satellite. Possibly obscured by the shadow of the steep rock formations when viewed from space.http://forums.avsim.net/user_files/175810.jpgParticularly complex coast lines don't quite get resolved so well by the SRTM V2 data.http://forums.avsim.net/user_files/175811.jpgThe next step would be to try to get rid of the jagged edges. The following approach comes to my mind:Upsample the 30 meter data at least 4-fold, interpolating for example with a bilinear algorithm.For DXT1 textures, convert back to 1 bit alpha using single bit quantization. That would make the jagged edges somewhat more diagonal.For DXT3 textures, encode as 4 bit alpha which allows for some blending effect between land and water.In the future, a more advanced (but slow!) algorithm could try to match the bitmap to the image content, potentially allowing for "perfect" rendition of the coast line. Of course this will only work when there is a clear and sharp line between land and water.Note that for the sake of simplicity I have dropped the idea to render NASA's original vector data to a bitmap during flight in the Tileproxy program. This would have created smoother edges, but would have been too slow. Instead I am storing the land/water mask as a bitmap and I am going to interpolate this bitmap. By the way, this worldwide bitmap adds about 52 MB in size to the Tileproxy installer at the resolution you see in the screenshots.Christian

[Guest Challenger604]

With the coast lines fixed that is awesome!!

[Farlis 2,286]

Ah. Kalterer See, I see.

[Guest cbuchner1]

You sure know your South Tyrol. ;-) Thanks for correctly pinpointing the screenshot.

[Guest wyoming]

Could IR data used to differentiate between ground and water?

[Guest wolfram_ravenwolf]

That's looking good - and it's just the beginning...But I still think that all things considered, the best results would be had if TileProxy turned into or added an "offline" mode which could create pre-rendered "stand-alone" scenery. If it created standard BGL scenery files of favorite areas, slow optimizations wouldn't be a problem, it could run for a while and then a finished scenery would be compiled (complete with "add-ons" like water masks and possibly even autogen). The online mode is great for temporarily caching newly or seldomly visited areas, but a permanent version of regular flying areas would be best both for users (speed/quality) and servers (no continuous use of bandwidth). If autogen annotation files could be created and shared by users for their favorite areas, even that could be done. I envision a community-expanded scenery based on photoscenery downloaded individually from one's favorite map provider...Wouldn't that be a possiblity to further expand TileProxy's reach? I'm dreaming of something like it where I simply specify an area and it downloads, optimized and compiles the area! And if I fly outside of it, it dynamically downloads and temporarily stores the newly visited areas. Offering updates when the compiled scenery's photos have been updated by the map service and offering to compile an area if it's visited all the time. Well, one may dream, I'm closely watching how TileProxy evolves whichever way you decide to take it.Keep up the great work! :)

[Guest cbuchner1]

Some preliminary results from this weekend:Erosion and Dilation are fundamental operations in mathematical morphology. Not that I have any clue about it, but they seem suited to shape my lakes a bit better.I invented something that I would call "conditional erosion and dilation" where I take water pixels away if the terrain "looks like" land and I add water pixels where terrain "looks like" water.Now that "looks like" criterion is hard to define, and my first experiments resulted in partial flooding of the area. Oh well, it's just experimentation. But there are some very convincing results in some areas.ChristianNicely round lake. Some pixels inside the lake got rejected though.http://forums.avsim.net/user_files/175991.jpgOh no, the villagers are going to hate me. I flooded their fields.http://forums.avsim.net/user_files/175992.jpgNow THAT's a nice coast of Lago Di Garda. Even floods the docks. But why is the water climbing up the hill there?http://forums.avsim.net/user_files/175993.jpg

[Guest cbuchner1]

I believe I solved the problem with determining land and water boundaries quite well now.I am using something similar to flood fill algorithm and I am applying a statistical analysis of the R,G,B color components and H,S,V color components of the land and water pixels.The lower the standard deviation of one of these color channels is, the higher I am weighing this color channel in determining whether we have land or water.As a result, the recognition performance has become very good. No more flooding of innocent villages. ;-)Christian

[Guest Arry]

Hello Christian,that sounds very good.RegardsArry

[hmar 0]

Hi Christian,Thanks for all the nice work you are doing. I am very curious about the next version. Are the "FS9 dwell textures" working also that well?Hugo

[Truthan 75]

That's a very creative approach to the water boundary issue. I had the instinct you were conjuring up something brilliant CB. For me at least,(with all due respect to the ACES team), TP has brought FS so far so fast it's astonishing that a single creative individual such as yourself could have succeeded in providing for us long time simmers what an entire team of experienced FS designers simply missed entirely, an Earth that looks like Earth. Even with all FSX's improvements (if you'll pardon a culinary metaphor), the default landclass issue was such an astringent libation it simply spoiled the meal. TP is like the fine wine that washed away the bitter taste in one rich, full bodied sip...bursting with flavor and complexity, with an after taste that continues to linger and improve. To #### with autogen...more wine please... Needless to say, I too am looking forward to the next TP release with great anticipation.

[maxymaxy 0]

I agreed Ed...I'll drink to that. Cheers Christian you are brilliant!

[Guest cbuchner1]

Iam now trying to generate "smooth" DXT3 blend masks but I have some problems getting the transition to "deep sea" right.This is what I observe:When alpha = 0 and r,g,b channels are 0, FSX displays the default water class.When alpha = 0 and r,g,b contains texture data, FSX displays a blend of shader water and the texture.When alpha descends from 15 to 0 (4 bit quantization) and r,g,b contains texture data, the texture smoothly transitions into water. However even at alpha = 0, the texture remains visible as described above.So I tried fading (modulating) the r,g,b data to 0 with decreasing alpha. But this looked extremely bizarre. It transitioned into black before the deep FSX water kicked in.How can I get the transition to normal FSX water right? Would I have to blend into some shade of blue instead? Hmm, I am clueless here.

[Truthan 75]

Wish I could offer some advice CB, but being outside of the "process" you're using it's hard to offer any constructive help. Most of my work with water and other textures that use alpha blends have been with static "replacement" texture sets from FS9 and before and didn't involve creating water masks, so probably wouldn't help much.Your last idea of using a shade of blue to replace the "black transision" could provide a temporary fix, but the problem of course would be to find a "general" color that would pass to emulate the transistion zone in question for a variety of water types. It's understandably not a "perfect" solution though. If TP could somehow "sample" the nearest water body texture color (i.e. that underlying the nearest mask area) and emulate that RGB data into the transistion zone color... Again, being outside the process I don't have a clue if that's even possible.I'd sure love to see some screenshots of what your seeing though. It'd provide a clearer idea of the visual transistion problems you're experiencing and maybe trigger an idea from some other tech-savy user ay?.

[Guest buzzle74]

Hi Christian, Congrats on the pics so far.. didnt think youd be able to get it so close based on that 30m data. I used the photoshop magnetic lasso tool running about 50 pixels away from the lakes shore and letting it stick to the shore based on contrast etc..guess the code your using does something similar. Even manually it wasnt always accurate and had to be adjusted. In regards to the above how far out are you planning to run out from the shore. Are you going to replicate the shoreline as the blend line 50 meters out? Are you blending all the way out to the line. How does it look just blending the alpha and cutting straight to the fsx water. Maybe you can try a black pixel mesh or spary interwoven with the texture increasing in density..Anyway good luck...