3.5cm per pixel

rhumbaflappy

Moderator
Staff member
Resource contributor
#1
The sim is stated as having up to 7cm per pixel photoreal resolution. But the FSX.cfg file can be edited to force 3.5cm per pixel resolution:

Code:
[TERRAIN]
LOD_RADIUS=4.500000
MESH_COMPLEXITY=96
MESH_RESOLUTION=23
TEXTURE_RESOLUTION=[COLOR="Red"][B]30[/B][/COLOR]
AUTOGEN_DENSITY=5
DETAIL_TEXTURE=1
WATER_EFFECTS=2
As to what good this does is another question. The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit!






Here's a view with all the LOD filled in ( 12,20 ):



The quality depends on your source, of course. Google now has images of many areas at zoom level 20, which is close to our FSX LOD20.

In the above, I layered the surfaces onto a more FSX-like grass field... and added seasonal variations of that field, and night... then blend-masked the edges of the whole airfield, added autogen...

A couple of fun days, and another project would take much less time, as I familiarized myself with the process.

This requires a lot of hand editing of the INF files and the images ( cut'n'pasting to eliminate parked cars and planes and building footprints, blurring and smudging to clean it up, layering onto a grass texture, sharpening the final results.

Here's the INF:

Code:
[Source]
   Type = MultiSource
	NumberOfSources = 6

[Source1]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_hw.bmp"
   Variation = January, February, March, November, December
   Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source2]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_sp.bmp"
   Variation = April, May
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source3]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_su.bmp"
   Variation = June, July, August
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source4]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_fa.bmp"
   Variation = September, October
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source5]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_lm.bmp"
   Variation = Night
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source6]
   Type = Tiff
   Layer = None
   SourceDir = "."
   SourceFile = "mask.tif"
      SamplingMethod = Gaussian
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07
   
[Destination]
   DestDir = "."
   DestBaseFileName = "Photo_c59"
   DestFileType = BGL
   LOD = 12, 20
   UseSourceDimensions = 1
   CompressionQuality = 85
LOD = 12, 20 yields 120mb for this small airfield.
LOD = 12, 19 yields 45mb, and the quality is nearly as good. Considering the radius of the LOD20 is so small, it hardly seems worth the effort, but it is possible.


Dick
 
#2
As to what good this does is another question. The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit!
Uh oh, soon there will be some payware developer hawking their wares with full 3.5cm texture resolution. Thanks, Dick...

There is 30cm photo source and 1m mesh source available for a mid-western state. And plenty of people who think they have a computer capable of rendering at all that LOD. Fools, they are.

I want to take some photo scenery and include one portion in the middle that will be tagged with the LOD level all over the area. Each separate LOD will be compiled to a file. As the user gets into the tagged area they should be able to recognize at what LOD they can really enjoy on their "super" computer. Especially those who feel autogen has no direct relationship to texture clarity or to mesh clarity.
 
#3
I beg to differ, if someone thinks that's the way FSX works and that systems can't handle 30cm imagery and high res mesh, then I'm not sure if they understand how the LOD system in FSX works...

The fact is that with FSX 30cm imagery has very little impact on FPS as does high resolution elevation data, it's not displaying all that data at once, as Dick has shown, 3.5cm only extends a very short distance around the aircraft...

The further away from the aircraft you go the lower the resolution of what you are seeing, hence data throughput and both CPU and GPU usage is really not affected much at all.

The things that impact FPS most in FSX are 3D objects and shader 2.0 effects... Those are what are the FPS killers in FSX...

I run a lowly 2.6GHz quad core (note only load times are sped up by the quad core) and a 512mb 9800GT videocard... Even with a P4 2.4 and a 128mb card I was able to get a solid 24fps with high res mesh and imagery, i had to turn down the RAM gobbling stuff like autogen (which I've had to do every release of FS in history)...

If a person is getting poor FPS in FSX with stuff it's more likely they've turned up their detail settings too high in the other areas such as autogen and shader 2.0 effects and are trying to push more data through their systems than it can handle. When that happens virtual memory kicks in (i.e. hard drive) and everything slows down to a crawl...
 
#4
You can "beg to differ", Dean, but your response does not deal with the subject. You mention FPS five times I believe. I didn't mention FPS once.

I do understand the rendering process and LODs, both for photo scenery and mesh. My posting deals with how that radius ring in rendered backwards to the user's position and how much FSX can process in the rendering loop before it starts over. If the loop finishes before the last LOD or two is drawn, then the added resolution gets wasted.

Flying over similar terrain and mesh with an older CPU vs. a new CPU produced a definite difference in clarity of mesh and photo. Both systems maintaining their locked FPS level, the older system at 25fps and the newer system 60fps.

I'm about to recompile a small area of some work I've been doing and I think it will be a good example for a "what LOD level is showing" test area. Little extra work to compile separate LODs and mark all the source with little, but visible numbers.
 
#5
That's where understanding compression technology and streamlining data comes into the picture and how to maximize your performance... The biggest issue facing most users is data being read off the hard drive...

I mean how old a system are we talking here? I had a P4 and never had problems with blurries at 1m per pix imagery and 5m post spaced elevation data... I had a problem on a 1.6GHz laptop with integrated video and 1GB of RAM but that was asking way too much of a system...

Again it's a matter of other areas trying to be pushed through that are breaking a system...

There is 30cm photo source and 1m mesh source available for a mid-western state. And plenty of people who think they have a computer capable of rendering at all that LOD. Fools, they are.
It's this statement that I find false... I've been doing it with a pentium 4, I find there to be no truth to the above statement...

BTW I don't know who's got a 30cm image and 1m elevation data product...

Anyway why the angst in your original post in this thread?

I want to take some photo scenery and include one portion in the middle that will be tagged with the LOD level all over the area. Each separate LOD will be compiled to a file. As the user gets into the tagged area they should be able to recognize at what LOD they can really enjoy on their "super" computer. Especially those who feel autogen has no direct relationship to texture clarity or to mesh clarity.
I did post to add detail to this comment... Your statement is close to truth but you are correct here that it's the autogen that has a direct relationship to texture and mesh clarity, however it's not the imagery/mesh LOD's that are the main issue although it can be to a certain degree...

A couple of years ago there was a great program called memstatus which would give you a visual cue of how much GPU ram being used and how much system RAM was being used. If too much data started being pushed across either one of those the entire sim would topple leading to blurries because it was the reverting to using the virtual ram system in windows... i.e. writing the extra bits to hard drive. this always led to blurries and loss of LOD fidelity...

Now my background is 20+ years in professional film & television production and one of my specialities is in image compression and optimization... I'm one of a few people in the film & tv field who understand codecs and image compression and how to streamline the bits to get things across busses, cpus and gpus as optimally as possible... I'm yet to run across anyone else in the motion picture business that has begun to understand this stuff... The ones who do are the ones usually writing the post production software...

The last 4 years I've spent perfecting my own routines to streamline imagery and what I've learned is there's several factors that can lead to textures blurring (i.e. LOD degradation in sim. The following three being the biggest culprits)...

A) Imagery not being optimized correctly, i.e. lots of visual noise, contrast issues etc all lead to increased data size = more data to pass from hard drive and across both CPU and GPU
B) Imagery not being optimized for compression, i.e. leads to increased data size = more data to pass from hard drive and across both CPU and GPU
C) Hard drive speed, i.e. a 5400rpm drive is useless for FSX, a 7200rpm is just passable, a 10,000 rpm drive is ok but too pricey and not fault tolerant, the most cost effective solution is a raid setup

Both A) & B) above are something that become a delicate balance between quality and peformance...

Getting back to the quote above:

I want to take some photo scenery and include one portion in the middle that will be tagged with the LOD level all over the area. Each separate LOD will be compiled to a file. As the user gets into the tagged area they should be able to recognize at what LOD they can really enjoy on their "super" computer. Especially those who feel autogen has no direct relationship to texture clarity or to mesh clarity.
I can say from experience that using separate LOD's in the type of test mentioned above will not provide an accurate representation of the loading, as what will happen and believe me I learned this years ago, separate BGL files for separate LOD's lead to massive load time lag, so much so that when I did it originally with Oahu it crashed the system, it was simply too much for FSX to handle. The test would be flawed because there'd be so much lag loading in each separate LOD BGL that it would actually create a huge slowdown in the system... I mean I don't discourage you from trying but I can guarantee that the above test will not be an accurate representation of a BGL that is all in one with each level of detail included in the one BGL file....

Personally I've been there, done that... Ends up being really really really bad news...
 
Last edited:

rhumbaflappy

Moderator
Staff member
Resource contributor
#6
I'll quote myself here:

The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit!
This means that resolution would be good mostly for screenshots... not for flying. And lots of simmers collect and buy aircraft basically for the screenshots. It's a very popular aspect of the hobby as evidenced by the large number of screenshot posts in the forums. I would guess scenery collectors would have similar demands.

A recent post related how customers of payware aircraft ( and scenery I suppose ) react positively to this type of detail. Bill Ortis, of Lionheart Creations has developed a process for including incredible detail in his models... overcoming some limitations of the tools we use.

Does it matter if you can see the detail on the panel screws while flying at mach 1? But it does matter to customers that like to set up screenshots and drool over photorealistic details. And if that's what customers demand, then I might expect this trick to be included in some commercial scenery... as have other tricks we have found.

My original post was to just inform of another trick I found in the sim. I'm sure the radius of that detail can be extended a bit... but really, why?

I've used 7cm per pixel detail in some homemade airfields, and it does work pretty well. But for flying, landing and takeoffs, it is a bit over the top. I mean, shouldn't we be looking for other aircraft, at gauges, listening to the traffic controller? ( Rather than looking at panel screws and cracks in the runway ).

Some endusers will demand as much detail as we can generate. Others just want a process that simulates flight, and could care less about visual details. Some of us obsess about relative accuracy of landmass and water... or elevations or landclass.

Some of us will purchase obscenely tweaked gaming systems to display our purchases and get 17 FPS, rather than 13 FPS with a "normal" setup. Others will enjoy 30 FPS on older systems by just moving the sliders a bit to the left.

It's the nature of the sim, and developers are usually near the edge of what is possible, both through curiosity and sometimes through the quest for profit.

Dick
 
#7
Just referring back to something alluded to earlier in the thread before replying on the 3.5cm stuff... Not all are the payware developers the unscrupulous type just out to make money...

Some only have to sell stuff due to the commercial nature of the source data, *not for profit* but because there is no other alternative data at that resolution freely available in the public domain, and as such the cost to the corporate entity that provides the source data and has staff and air fleet to maintain has to be recouped.

I personally make my own money from Film & TV production, any surplus from FS stuff is donated to those in the 3rd world. Cost of equipment which so far includes 11TB of drives and rendering machines are also covered by the price of the data. There is a cost involved to develop stuff and it's a choice of nothing otherwise.

There needs to be a reality check on some of the statements made about 'commercial development'. It costs a minimum of $240 a month to run a dedicated server to deliver data, the source data at 5m elevation post spacing costs MILLIONS to obtain if you were to purchase it directly. Factor in data delivery costs (usually 15-30c per GB), a person's time, the cost of the source data, electricity (running about $200 month), internet to upload data ($100 month), you're talking big $$$. Unfortunately some in the FS community want the moon and they want it for free and they want it in a 1MB download. Unfortunately reality is far different when what is actually involved is fully understood. So bottom line is, some things for FS have to cost money by their nature, that is the reality of life. The fact that we can even have access to some datasets at a minimal cost compared to millions of dollars is actually not such a bad thing after all.

Now for me I have always been a supporter of freeware where it is possible to do so, and have spent more than 25+ years in the freeware FS Community... I personally believe that data which is freely available and is quick to render and uses very little computing and electrical power is stuff that should be released as freeware because public domain data should remain public domain. That is something that is my own personal approach. The caveat being that if it takes $10,000-20,000 in equipment to make it available those costs have to be recouperated otherwise the developer ends up out of pocket and there are such things as wives and families that would scream at that amount of money being used.

Anyway, getting back on topic the following is an initial test render for a freeware release, which I'm doing on my own time which is an airport I've waited 25+ years to see at this level of detail. Unfortunately 7cm detail is not clear enough for taxiway markings, and taxiing is an important part of the flight, especially if you're using the sim to practice procedures before going up in real life. Now if only FSX could model the taxiway bumps when you hit a light with your nosewheel.

http://www.youtube.com/watch?v=jN1-x4yg1-w&hd=1

Again not everything in the FS community is possible to be done as freeware. Sometimes the choice is a cost involved or nothing at all. However bashing a developer because something isn't freeware without understanding the factors involved behind the actual cost to develop certain things only shows an ignorance of the situation and is unbecoming.

As for 3.5cm imagery, possible, but as mentioned with LOD Radius = 4.5 it will only show to the nose of the aircraft. If LOD Radius was to be changed to say 8, 9 or above that then extends the distance that LOD is visible away from the aircraft, which would be useful for taxiing an aircraft but not for actual flight operations.
 
Last edited:
#8
Dick,

Excellent topic, and thx a lot.

The following discussion is over mye head; but I post to tell you this:

I made the Gardermoen ENGM photoscenery for FSX. I bought it for my own money. It is 20cm, and I have to say, honestly, try it. You can download it from Flighsim.no and Flighsim.com. It is sharper than you are used to, believe me. Try it, and set your FSX resolution to 15cm (if memory serves).

SBuilder cold not take the TIF; it was too big. So I had to go straight for resample.exe and make an inf, as the pic is (downsized, 8472 x 14.500 pixels). Thanks to you, Dick, and the SDK readme, I made it.

My point here is:

I am now working on a photoscenery for ENZV, together with a good friend of mine, which also is way ahead of me regarding gmax and such. He is also into this madness of buying good data, which I believe is 20cm. The photo is so good, that in ADE, I have set taxiways to be PATHS, using the photo for textures, using MS only for the markings. We now use the photo itself, even at "only" 20cm, as taxiways, and bye-bye gmax and all that labour :D

Bottom line:

Here I am working with a 20cm photo, making it possible to use the photo, contra 3,5cm. I am not trying to analyze anything here. Just made this post to tell everyone that sucess is within reach even with a 20cm photo, if quality is OK :)

EDIT:

Pic shows 20cm photo taxiways, with only MS markings on top.
 

Attachments

Last edited:

rhumbaflappy

Moderator
Staff member
Resource contributor
#9
Hi Andrew.

I do agree with you in this. I find it a hard to justify all the work of using paint-program textures when resample does such a good job down to 7cm.

But, just as some end-users demand dimples on the aircraft rivets, so will they also demand 1 cm per pixel tarmacs. It's a screenshot thing, as no one could use this visual data in a moving aircraft.

A tip for resample is that you can use multiple source images, and compile them as one BGL through resample. This way you can get the huge source file split into manageable pieces.

Dick
 
#10
Thanks again for the tips.

I too find it is just way too much labour to make all the runways and taxiways with gmax. Being responsible for soon 30 airports, it is a long time ago I gave up on using gmax for ground polygons. Gmax is just lousy for such. So I decided the end-user had to live with the MS stuff. As you point out, the demands for details are huge, but I decided to not deliver, regardless of what people say. This is the good thing about being a freeware designer; no pressure :D

Also, what is important? Counting rivets on the plane? Maybe. Counting sand particles on ground? Nooo...aren't we supposed to be mostly flying?

Speaking about this, one could ask what the next FSX/FS9 scenery program should be. In my eyes, a simple program that lets the user make their own runways, aprons, taxiways (with a huge set of textures to choose from), and colour of the markings by choice. Plus the ability to make own markings. The interface for this could look like the one we already have in Afcad2/ADE for making taxiway signs. I am also playing with the thought of using Photoshop for making sharp "Rwy Ahead" markings directly on a photo.

Oh, and correction to my previous post (typo): I am not doing the photo, only the ADE part of the job. For my own Gardermoen scenery, I might try to use the photo for taxiways as well. In that regard, yes, it is less gmax work, but tons of hard work in Photoshop, removing all the lines. If I get time, I'll see if it is possible to draw sharper lines on top of the 20cm photo (via a layer), but this is only thoughts, new land to break in.

PS, Hollywood:

You are correct hi-rez photos have little or no effect on fps. Only on the hard drives, but those are huge these days. I was very surprised to see my Gardermoen 20cm scenery (rendered at 87%) with 85% UT II traffic, at 40 fps, seeing the terminal and all the gates. Of course static gates make a difference; had they been moving, it would have been a lot slower, but only slow the time the scenery is "starting up".

Cheers,
:stirthepo
 
Last edited:
#12
UPDATE: I restored some (IMHO, 'important') missing images via a saved web page from FireFox for the original thread post above by the OP:


http://www.fsdeveloper.com/forum/threads/3-5cm-per-pixel.21121/

The sim is stated as having up to 7cm per pixel photoreal resolution. But the FSX.cfg file can be edited to force 3.5cm per pixel resolution:

Code:
[TERRAIN]
LOD_RADIUS=4.500000
MESH_COMPLEXITY=96
MESH_RESOLUTION=23
TEXTURE_RESOLUTION=[COLOR="Red"][B]30[/B][/COLOR]
AUTOGEN_DENSITY=5
DETAIL_TEXTURE=1
WATER_EFFECTS=2
As to what good this does is another question. The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit!











Here's a view with all the LOD filled in ( 12,20 ):






The quality depends on your source, of course. Google now has images of many areas at zoom level 20, which is close to our FSX LOD20.

In the above, I layered the surfaces onto a more FSX-like grass field... and added seasonal variations of that field, and night... then blend-masked the edges of the whole airfield, added autogen...

A couple of fun days, and another project would take much less time, as I familiarized myself with the process.

This requires a lot of hand editing of the INF files and the images ( cut'n'pasting to eliminate parked cars and planes and building footprints, blurring and smudging to clean it up, layering onto a grass texture, sharpening the final results.

Here's the INF:

Code:
[Source]
   Type = MultiSource
    NumberOfSources = 6

[Source1]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_hw.bmp"
   Variation = January, February, March, November, December
   Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source2]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_sp.bmp"
   Variation = April, May
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source3]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_su.bmp"
   Variation = June, July, August
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source4]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_fa.bmp"
   Variation = September, October
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source5]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_lm.bmp"
   Variation = Night
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source6]
   Type = Tiff
   Layer = None
   SourceDir = "."
   SourceFile = "mask.tif"
      SamplingMethod = Gaussian
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Destination]
   DestDir = "."
   DestBaseFileName = "Photo_c59"
   DestFileType = BGL
   LOD = 12, 20
   UseSourceDimensions = 1
   CompressionQuality = 85
LOD = 12, 20 yields 120mb for this small airfield.
LOD = 12, 19 yields 45mb, and the quality is nearly as good. Considering the radius of the LOD20 is so small, it hardly seems worth the effort, but it is possible.


Dick


NOTE
: Example images shown by the OP in the post linked above are of standard "terrain-mesh-clinging" custom photo-real aerial imagery made via FSX SDK Resample, and does NOT have shadowing / flickering / visible seams or gaps / autogen exclusion issues ...associated with G-Polys ! :teacher:

GaryGB
 

Attachments

Last edited:
#13
This is another restored version of the original post above, ...that opened this interesting and informative thread:

WHY: Original images converted by the 'new' forum software to *.PNGs from the attached *.JPGs appear slightly 'sharper', IMHO.


https://www.fsdeveloper.com/forum/threads/3-5cm-per-pixel.21121/post-139886

The sim is stated as having up to 7cm per pixel photoreal resolution. But the FSX.cfg file can be edited to force 3.5cm per pixel resolution:

Code:
[TERRAIN]
LOD_RADIUS=4.500000
MESH_COMPLEXITY=96
MESH_RESOLUTION=23
TEXTURE_RESOLUTION=[COLOR="Red"][B]30[/B][/COLOR]
AUTOGEN_DENSITY=5
DETAIL_TEXTURE=1
WATER_EFFECTS=2
As to what good this does is another question. The radius of the LOD20 wouldn't even extend beyond the nose of a large jet... you would never see it from the cockpit!


lod202.png



lod201.png


Here's a view with all the LOD filled in ( 12,20 ):


lod203.png



The quality depends on your source, of course. Google now has images of many areas at zoom level 20, which is close to our FSX LOD20.

In the above, I layered the surfaces onto a more FSX-like grass field... and added seasonal variations of that field, and night... then blend-masked the edges of the whole airfield, added autogen...

A couple of fun days, and another project would take much less time, as I familiarized myself with the process.

This requires a lot of hand editing of the INF files and the images ( cut'n'pasting to eliminate parked cars and planes and building footprints, blurring and smudging to clean it up, layering onto a grass texture, sharpening the final results.

Here's the INF:

Code:
[Source]
   Type = MultiSource
    NumberOfSources = 6

[Source1]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_hw.bmp"
   Variation = January, February, March, November, December
   Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source2]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_sp.bmp"
   Variation = April, May
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source3]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_su.bmp"
   Variation = June, July, August
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source4]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_fa.bmp"
   Variation = September, October
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source5]
   Type = BMP
   Layer = Imagery
   SourceDir = "."
   SourceFile = "ground_lm.bmp"
   Variation = Night
      Channel_BlendMask = 6.0
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Source6]
   Type = Tiff
   Layer = None
   SourceDir = "."
   SourceFile = "mask.tif"
      SamplingMethod = Gaussian
   ulyMap =  42.6402729263184
   ulxMap = -88.6026763916016
   xDim =  1.34110450746479E-06
   yDim =  9.8664492525824E-07

[Destination]
   DestDir = "."
   DestBaseFileName = "Photo_c59"
   DestFileType = BGL
   LOD = 12, 20
   UseSourceDimensions = 1
   CompressionQuality = 85
LOD = 12, 20 yields 120mb for this small airfield.
LOD = 12, 19 yields 45mb, and the quality is nearly as good. Considering the radius of the LOD20 is so small, it hardly seems worth the effort, but it is possible.


Dick
 
Last edited:
Top