I am using 23 m elevation data(GeoTIFF format) and 5 meter imagery(8 bit, GeoTIFF format). I am generating terrain in TerraPage and Metaflight format. I have disabled image compression at import.
Now, when i see the generated terrain in 3D, it is too blur and i can easily identify piexels even if my camera is at `2km height from mountains.
In fact, even if i use better satellie image; pixels are easily identified!!
I dont want to compare 5 meter with camp pendelton product but 5 meter cant be so dirty to show pixels!!
what could be the possible way to overcome the problem?
Does it look the same in TerraPage and in MetaFlight? What viewer are you using? I’ve found that a TV MetaFlight imported in VegaPrime requires you to change the substitution texture line in the .mft or you see vt_sub instead of your clipstack.
Also - I have generated Camp Pendleton using the same source with the same output resolutions (.6m) after painstakingly going throught the calculator to set stuff up both with TV and with CTS (the dirty word). CTS pretty much auto-sets everything to capture the highest resolution of texture, allows you to constrain terrain design to the clipstack design, and then uses a better smoothing filter when processing the virtual texture (clipstack). Are there TerraVista parameters that assign bilinear or cubic convolution filters when doing its resampling that you really can’t avoid?
the resultant clipstacks are so different that my customers immediately complain when they accidentally load the TerraVista version about pixel blockiness. Could be some secret token I don’t know about, though ....
Following are the details of my project:
Block Size: 2048
Texture Size: 512*512
No of LODs : 3
the attached snapshot gives the full details.
yes, i have checked using both terrapage output and meta flgiht output. i can say that both of them are almost similar, i cant identify any great difference between two.
I need to generate terrain for a larger area, i can use best resolution for some specific region(airport) but for a fly-through 5.6 m resolution should be more than just sufficient data! but the output of the terravista is horrifying.
could you please identify if i am commiting some parametric error? or any new way to get the things in place.
There are open source software that have got good resolution visualization. just to cross check is it possible to use any of open source data as an input to TV???
Can you post a snapshot of the database? form 100’ and 500’ (ish) Those pictures will tell 10,000 words .... and maybe somebody from Presagis can look at the parameters 8*)
If you’re talking about the pendelton sample that comes with Creator (and presumable TV), I thing the texture resolution is somewhere on the order of .5m, meaning that it is 11.2 times better, and there would be 125 pixels in the scene for every one in the 5.6m Also - the 5.6m is presumably being resampled at some point to 5m, 5.2m or something not exactly 5.6, so you wind up getting a little artifact from that.
With 5.6m imagery, a 2 lane road will be 1 -2 pixels wide, an international runway may be 13 pixels wide.
And as a rule of thumb, not knowing your FOV etc, I usually say you get 1000’ of altitude per 1m of resolution, meaning 1m looks seamless at 1000’, 5.6m looks seamless at 5600’. this varies widely when you get into display specifics, but its a good starting point. if your flyover is < 1000’, 5.6m imagery is going to look poor.
Where is your database geographically located, and whom do you work for. There may be public domain available. If you want to ask me offline, my e-mail is in fact in my profile.
Your source is 5m. Your terrain is set up for 4m,2m and 1m (3LOD). This is probably not intended. 5m source as Kent wisely commented is only good for ~5000ft. Up-sampling 5m to 1m will not improve the visual quality.
If you would like further help with setting up your terrain structure correctly to match your source imagery resolution I’d suggest go ahead and contact TV support directly.
Following attachments show the generated terrain results.
As per your suggestions, changing the parametric values and flying through at above certain height does not affect the result and the visualization remains same!:-(
I have noticed similar artiacts in TV database production even at higher resolutions. I have complained about the difference in quality between a TV generated virtual texture, and a CTS generated virtual texture, both built with the exact same design parameters and resolutions.
I believe it boils down to CTS having a bilinear filter when resampling the texture and maybe TV does not? Maybe Johny O could suggest some setting that result in smoother filtering during the inevitable resampling that goes on during database gerenation?
i really think that with a smoother resampling filter that would clean up pretty nicely.
Just to set the record straight here. Since I wrote the VT image code for both TV and CTS, I thought I should comment.
Terra VIsta does in fact use a simple filtering for its GeoPaint process - Nearest Neighbor. It uses this same algorithm regardless of the quality setting in the GeoPaint settings However, that is only used in creating the GeoPaint textures. That is, any texture that is the size of a Block or smaller (in coverage, that is). The other, lower level VT textures (e.g., those that are larger than a Block in coverage) are created using the same algorithm as CTS - that is, it is a blinear filter. These are the textures created by the VT Compiler.
Yes, it is not optimal and it is an issue that we know about. It is logged and we will get to it, but I cannot say when.
Having said that, most of the time quality issues are not due to filtering - CTS is nice in that it automatically adjusts your output VT coverage to precisely fit your source imagery data. TV does not do this, it is a manual process - TV has always been a more terrain-centric tool and it does not have this capability yet.
Mismatches in the source imagery ground sample distance (GSD) compared to the output VT’s GSD are quite often the cause for discrepancies in output VT when compared to the original source data. Again, this is something we will improve upon, I just cannot say when. We are working on making this a more automated process.
I think we’re actually saying the same thing. Any mismatch or discrepancy between the design output and the source leads to resampling using a simplistic filter that makes your texture kinda blocky. This is also true if the output projection of the database is different fromthe source. TV will auto-project it, but again ANY resampling will lead to artifacts of some sort.
So the first thing MEETMAK needs to do is make sure the input projection and resolution match the design output. Easier said than done - but we’ve pretty much always pre-processed our imagery using a dedicated specialty tool like ERDAS or ENVI or Global Mapper to minimize these artifacts (not an endorsement of any specific product) using the calculator, set up the terrain design to match the 5.6m input as output.
If you have multiple resolutions - you said you had higher res around the airport I recommend pre-resampling everything to be at a power of two multiple of eachother. If you want to maintain your 5.6, upsample the 1m to .7 using a tool with a good resampling filter. Based on the source we usually get, we do either .25m, .5, 1, 2, 4, 8; or .6, 1.2, 2.4, 4.8 ... Everything is resampled to the design output projection at one of those resolutions so all the VT generator should have to do is dice the tiles and put the pixels in the right place.
Word on the street is that Presagis is offering a CTS trade-in to transition users away from CTS and toward TerraVista. Any chance you may thing about allowing TVusers to have a CTS license strictly for generating the Virtual textures? We’ve had good luck using both tools and laying the CTS VT on the TV terrain.
Hi Kent… as for the CTS to Terra Vista transition, we have a standard migration policy that allows for an even swap of TV for CTS… but… we also understand there may be special circumstances where a combination of the two tools makes the most sense for certain workflows. If you (or others) have these special workflows and would like for me to work-out a custom agreement, just send me an email and we can begin the discussions to see if we can craft the correct agreement for your organization.
I’m set - i think other users might be interested in whether you can fast-track at least the incorporation of a better/smoother resampling filter in TV when using GeoPaint. You know I’ve been vocal about it for over 18 months ... I think lot of users may have similar issues and just not realize it.
Then you can do a staged approach for overhaul to simplify the design process to be more imagery-focused 8*) But for now - that one improvement would be universally useful.
Like CTS, this should be automatic process!! its so very hard to do it manually, specially when you are going for multiple datasets that too at various resolutions!!
Another thing is that, a normal user needs to have complete knowledge of GIS.
TV is a terrain generation tool, so darpping a texture over elevation is one of the major processes. Presagis should automate this process as soon as possible, or they should provide CTS license also, atleast for this purpose!!
The input data is very costly so naturally one would not like to compromise in any way!!
