FSXA Resample Tool CompressionQuality

[mmann]

I am working at the moment with a mesh for Vancouver Island. I decided to try half of the area (the southern portion with portions of the BC Mainland and the US San Juan Island area) but ended up with a bgl of 168 MB which I consider too large a file.

I started to experiment on a smaller portion to see the results of altering my .inf file. First I changed my LOD from 4,12 to 4,11 which resulted in a much smaller file but also an unacceptable loss of elevation data.

Next I changed the FractionBits but I found that I had to leave this set to 2 in order to obtain the detail I desired.

Finally I changed the CompressionQuality to 97 from the default 100 and I received the quality I wanted with a significant savings in bgl file size.

Now the questions:

1. What is the sweet spot value for CompressionQuality?

2. Is there any performance penalty in FSX with more compression?

3. Is there any performance penalty to using two 70 MB bgl's instead of one 140 MB bgl?

 

[LCSims]

I think you've found the sweet spot for compression.

Also, file size is increased using a FractionBits setting. A lot. If you "think" you see a difference, use it. But all it introduces is a decimal reading of the data point, so that 100 meters might now be read as 100.25 meters. If you can tell the difference, use it. It doesn't add any data points over what the source file contains, so if they were at 10 meters before, they will still be 10 meters apart.

 

[mmann]

Unfortunately it is not a matter of "thinking" I can see a difference with the FractionBits set to 2, it is totally obvious when I look in FSX at a small island just south of the island that the Cape Beale Lighthouse is located on. Without the FractionBits set to 2, the small island is completely flat with zero elevation. With FractionBits set to 2 I have a nice rocky little island just like in the real world.

 

[Tejal Bernardo]

I used Fraction bits to fight the "terrace effect", and it's seem to me that work, I can't use lod because always I get weird displays, and I think it's good to use comprension quality, because I don't see any remarkable difference with a 85 compresion quality. anyone know where it's posible to find something about this matter, it's difficult to know something about fsx mesh.

 

[mmann]

I think maybe the reason it is difficult to find information on FSX mesh is because many of the developers that really know this subject are also payware oriented. When you consider that the US and Canadian DEM data files are available for free then the main thing of value is the knowledge of what to do with that data.

 

[ollyau]

Well, in regards to your questions:

1. What is the sweet spot value for CompressionQuality?

I've heard/use around 85. Seems to work well for orthoimagery, for me at least. For DEM I leave it at the default value (100, I believe) and usually get reasonable sized files.

2. Is there any performance penalty in FSX with more compression?

Not that I've noticed.

3. Is there any performance penalty to using two 70 MB bgl's instead of one 140 MB bgl?

According to this thread, bigger files are better: http://www.fsdeveloper.com/forum/showthread.php?t=9924.

Also, this article describes FractionBits pretty well: http://msdn.microsoft.com/en-us/library/cc707102.aspx#UsingScaledElevationValues.

 

[mmann]

Thank you both for your feedback.

I have read the SDK on FractionBits many times and have no problem with understanding that parameter. I have also reread the post on one bgl vs multiple bgls but the example given is not really germane to my question of two versus one as the post wasn't talking of just two bgl's but 35,000!

I have looked closer to what some of the payware mesh files look like and it seems that FSGenesis Canada doesn't use a file larger than 388 MB for its 23 bgl files and Orbx PNW doesn't use a mesh bgl larger than 145 MB for the 8 files they used. Microsoft uses a large number of smaller bgl's for their mesh.

 

[LCSims]

Microsoft creates their mesh files based upon QMID level 4 boundaries and while they may cover a large area, they are generally low in resolution and quite heavy in compression %.

Mike, I don't want you to think I was implying earlier that you needed your eyes checked. It's just people hear numbers or settings and think lower must be better. Too often that's not the case. People who think they will really see 7cm textures around an airport loaded with scenery objects, planes, autogen? OK, if that's what they think. But I digress, sorry!

You mentioned your attempt at making mesh with no entry for FractionBits gave you a flat area, so I went and did a quick check. The delay was waiting for some files to finish downloading. I cut out the area around Cape Beale LH and made two files. One has a FractionBits setting of 2, the other doesn't. Copied both files into separate folders for FSX, which allows me to quickly toggle things. Two screen grabs are in the attached Zip file, along with the two BGL files. Other than some very minor visual effects, they look much the same to me. Yet one file is 441kb and the other is 790kb. Is the size difference worth it? For this area, who cares. Large scale project, no, it's not worth the file bloat.

I'll admit to jumping on the FractionBits bandwagon. Then a little pondering made me realize that it's not something that is necessary within FSX or FS9 or Flight!. The data points don't get any closer, there isn't a magical smoothing of terrain done by the Resample compiler, there isn't a whole lot to it. But taking the picture from the SDKs as evidence of it's miracle workings, the FB setting must be required. But to get the right perspective from the picture in the SDK I would need to lay flat on the ground and turn my head to look up the terrain.

Could the FB setting come in handy? Maybe? I have an area that has 1/2 meter source sitting on one of my HDs. Is it useful in FSX or Flight? No! Unless I got in one of the drivable cars and motored around.

And respects to file size, FSX won't recognize a file larger than 2gb. For smaller files my opinion is that it's not going to matter much. File I/O operations go pretty fast, unless there are Drawcalls involving MDL files, of which I don't understand, nor have a need to understand. Sooner or later the plane is going to get to an area where four mesh files may need to be opened and data read from them. I've yet to see or encounter a performance hit because of that. Not saying it doesn't occur, just that I've not noticed it.

And making mesh is pretty simple, I'm a testament to that. It's what you do when making the mesh that matters. Unless it would infringe upon my work or what I have learned over the years, I "generally" don't have a problem pointing people in the right direction towards making mesh. A detailed step-by-step tutorial? I'll add it to the list of things to do...

 

[mmann]

My mistake for not explaining what I have done so far. The terrain mesh is actually step number 2. Step number 1 was creating accurate water features in SBuilderX using the Canadian National Hydro Network (NHN) data to create accurate coastlines with the multitude of islands.

Default FSX is lucky if it has 100 to 200 islands in the Vancouver Island region (I didn't count them), with just about all of these being located in the Strait of Georgia area. My island count is over 10,100 which doesn't include the freshwater islands (so far). It is with this improved coastline that the FractionBits of 2 was very noticeable on the smaller islands, the islands that don't exist in default FSX.

 

[GHD]

I'll admit to jumping on the FractionBits bandwagon. Then a little pondering made me realize that it's not something that is necessary within FSX or FS9 or Flight!.

I am surprised. This is without FractionBits (note the terracing)



From the ground.



This is with FractionBits (no terracing)

 

[HolgerSandmann]

Hi guys,

for most 10-m terrain mesh files I use the following parameter values:

CompressionQuality = 97
LOD = 4,12
FractionBits = 2

The FractionBits option is very valuable to prevent visible terracing, especially on gentler slopes, like George's screnshots prove. However, in order for this to work properly one needs to make sure that the source files have sub-meter vertical accuracy (meaning not stored in integer format with 1m or 1ft stepping) and also that any re-projected or subset input files (via Global Mapper or other tools) are stored in floating point (32-bit) format.

As for mesh file sizes I don't think it really matters in terms of performance. However, if FSX encounters two files of the same compiled LOD with different spatial extent then FSX will keep loading the one it encountered first (assuming a user flying across those mesh files) regardless of their scenery library priorities, unless one forces a scenery library refresh. For that reason larger files are probably the better choice.

Cheers, Holger

 

[mmann]

Thanks for your suggestions, Holger. I also want to thank you for previous advice you gave me on another thread about using Global Mapper in conjunction with SBuilderX. Global Mapper is worth every bit of its price as it is such a time (sanity) saver for FSX terrain development.

 

[rhumbaflappy]

All bgls from resample are compressed. CompressionQuality only effects the level of data loss you are willing to introduce to further the compression. 97 indicates there is a slight level of loss, verified by a reduction in file size.

But why would you allow any loss of data? If you have a file source that allows an accurate mesh LOD of 11 or 12, why allow any fantasy induced by lowering the quality of the end-product? If you have accurate data, why not have accurate mesh made from it?

My thinking is that if file size is a problem, just reduce the maximum LOD, and retain the reasonable accuracy of the source elevations. Resample itself will introduce interpolations of elevation points. In other words, the source data is translated ( resampled ) to produce points that match the world QMID grid of FSX. This means we've already deviated from the accurate source data to a world of closely related QMID representation. Lowering compression quality just further distorts the source data. The logic of having an accurate source, then abandoning it to save disk space seems a bit odd.

Using the fraction bits to reduce terracing probably indicates poor source data or oversampling, unless the source is as Holger indicated, is already fractional in measurement ( not whole meters ). But again, resample will interpolate the data points to the QMID grid, from the lat-long grid.

If I had really good source data, I wouldn't want to distort it in the sim. You can make LOD 11 mesh from bad sources, and introduce smoothing and lower the compression loss level, and still get a "bumpy" looking environment in FSX. And it wouldn't be much worse than what you get from distorting good sources.

It's not always easy to tell which is most accurate... CQ of 100, 50 and 0:

These are all from the same geotiff, and same settings, but with changes in the compression quality. They are all bumpy-looking, but the 100 would be as close to accurate as we can get. And isn't that the point of having LOD 11 mesh?

Dick

 

[Tejal Bernardo]

Hi, I got recently a mesh for my region of 5 mts. great news ¡¡. and Holgersandmann say that for 10 mts this .inf file would be good:
for most 10-m terrain mesh files I use the following parameter values:

CompressionQuality = 97
LOD = 4,12
FractionBits = 2

What could be the appropriate for this mesh 05, Lod 13 I think, I left Lod=auto, I follow the advice of Rumbaflappy and did compresion=100 , but the weight of the files are really different. but for a little scenery don't should be a problem. I must say that the scenery look great, but I have doubt about the Lod though, regards.
edit: I have the impresion that in the exterior views the way the scenery display is a little worst than before.
Here a interesting discussion about 32 bit, fraction bits, and compression http://www.fsdeveloper.com/forum/showthread.php?t=8415

 

[marcoh]

I,

I also got recently a mesh of France in 20 meters.

I uses the folowings parameters, because compression quality seem to be a JPEG system. It's realy not usuefull to keep 100%, but find a value beetwin 80 and 95%.
I used also the "split" parameter because the whole France in one file is too bigger. I read also that a payware compagny use this parameter for LOD13 mesh because the performances is improved compare to bigger area.

So, better is you mesh, much small must be the area covered in one file.

FractionBits = 3
SplitFileLOD = 6
LOD = 5,11
CompressionQuality = 95

 

[Tejal Bernardo]

Thanks for reply, yes, about the compression quality I have could see that no big difference between 100/ 95 , where I have not very clear the ideas is the Lod stuff, I compiled "auto", I see that the mesh at distance work great, I am a very exigent because I don't like to feel that have a good stuff and you are spoiling the business , By now the only thing I could see is that in the exterior views the visualization is not so good as before.Don't know how work splitefilelod.
In my case I get the files as 32 bits geotfif files mesh 05 (lod13), and the region are islands.

 

[marcoh]

SplitFileLOD is an order to cut the final BGL in multiple smalest BGL.

Then i supose it's more easy for the sim to find data in smalest files.

 

[Tejal Bernardo]

Oh yes, that has been discussed here, little files or only one file, and seem you are right.