-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
Mesh based problems
- Thread starter meshman
- Start date
- Messages
- 1,025
- Country
Hi Lance,
Your export from Global Mapper should be fine, although I'd recommend 32 bit settings on export rather than 16 bit.
Can you post a copy of your .inf file?
It looks like the issue is the location of where your source files are...
This is what I normally use as my settings:
[Source]
Type=GeoTIFF
SourceDir="G:\United States\Arizona\NED\WGS84"
SourceFile="AZ-3231-109110.tif"
Layer=Elevation
scale=1
MaxValidData=5000
MinValidData=-5000
[Destination]
DestDir="d:\"
DestBaseFileName="fsds-meshplusaz"
DestFileType=BGL
FractionBits=3
LOD=Auto
CompressionQuality=85
Sometimes I use compression quality of 100 but that tends to glitch... You can also eliminate the fractionbits=3 setting if you want to reduce file size and have whole meters vertically...
If your source or destination directory is in the same folder as resample then try the following...
[Source]
Type=GeoTIFF
SourceDir="."
SourceFile="AZ-3231-109110.tif"
Layer=Elevation
scale=1
MaxValidData=5000
MinValidData=-5000
[Destination]
DestDir="."
DestBaseFileName="fsds-meshplusaz"
DestFileType=BGL
FractionBits=3
LOD=Auto
CompressionQuality=85
Your export from Global Mapper should be fine, although I'd recommend 32 bit settings on export rather than 16 bit.
Can you post a copy of your .inf file?
It looks like the issue is the location of where your source files are...
This is what I normally use as my settings:
[Source]
Type=GeoTIFF
SourceDir="G:\United States\Arizona\NED\WGS84"
SourceFile="AZ-3231-109110.tif"
Layer=Elevation
scale=1
MaxValidData=5000
MinValidData=-5000
[Destination]
DestDir="d:\"
DestBaseFileName="fsds-meshplusaz"
DestFileType=BGL
FractionBits=3
LOD=Auto
CompressionQuality=85
Sometimes I use compression quality of 100 but that tends to glitch... You can also eliminate the fractionbits=3 setting if you want to reduce file size and have whole meters vertically...
If your source or destination directory is in the same folder as resample then try the following...
[Source]
Type=GeoTIFF
SourceDir="."
SourceFile="AZ-3231-109110.tif"
Layer=Elevation
scale=1
MaxValidData=5000
MinValidData=-5000
[Destination]
DestDir="."
DestBaseFileName="fsds-meshplusaz"
DestFileType=BGL
FractionBits=3
LOD=Auto
CompressionQuality=85
HolgerSandmann
Resource contributor
- Messages
- 392
- Country
Hi Lance,
similar to what Dean has said, this could be three issues: either your inf doesn't correctly point to the location of the tif, or the file name is wrong, or the tiff tags don't work properly.
I always place the georeferencing information into my inf file because that way I have it available without having to start GM or some other utility. Also, it's easier this way to define subsets via UseSourceDimensions if that's desirable.
For example:
[Source]
Type = Geotiff
Layer = Elevation
SourceDir = "SourceData"
SourceFile = "NED+CDED1_1arcsec_N58-60_W132-140_SEN.tif"
ulxMap = -140.05000000
ulyMap = 60.49000000
nCols = 28405
nRows = 9145
xDim = 0.00027777777777778
yDim = 0.00027777777777778
[Destination]
DestDir = "Output"
DestBaseFileName = "4_mesh_multiLOD_4-10_GlacierBay"
DestFileType = BGL
UseSourceDimensions = 0
NorthLat = 60.48500000
SouthLat = 57.95500000
WestLong = -140.04500000
EastLong = -132.16500000
CompressionQuality = 95
LOD = 4,10
After exporting my Source geotiff file I load it again into GM and then use the MetaData tab to copy and paste the georeferencing information into my inf.
Hope that helps.
Cheers, Holger
similar to what Dean has said, this could be three issues: either your inf doesn't correctly point to the location of the tif, or the file name is wrong, or the tiff tags don't work properly.
I always place the georeferencing information into my inf file because that way I have it available without having to start GM or some other utility. Also, it's easier this way to define subsets via UseSourceDimensions if that's desirable.
For example:
[Source]
Type = Geotiff
Layer = Elevation
SourceDir = "SourceData"
SourceFile = "NED+CDED1_1arcsec_N58-60_W132-140_SEN.tif"
ulxMap = -140.05000000
ulyMap = 60.49000000
nCols = 28405
nRows = 9145
xDim = 0.00027777777777778
yDim = 0.00027777777777778
[Destination]
DestDir = "Output"
DestBaseFileName = "4_mesh_multiLOD_4-10_GlacierBay"
DestFileType = BGL
UseSourceDimensions = 0
NorthLat = 60.48500000
SouthLat = 57.95500000
WestLong = -140.04500000
EastLong = -132.16500000
CompressionQuality = 95
LOD = 4,10
After exporting my Source geotiff file I load it again into GM and then use the MetaData tab to copy and paste the georeferencing information into my inf.
Hope that helps.
Cheers, Holger
- Messages
- 1,025
- Country
Holger, wouldn't it be nice if we could find a programmer to automatically transfer the TFW data into an inf file?
I'd love to be able to automate going from Photoshop layered TIFFs straight into resample without having to manually use libgeotiff to retag the source files, as GM doesn't take alpha channels... :-(
One of the drawbacks to trying to watermap all the scenery.
I'd love to be able to automate going from Photoshop layered TIFFs straight into resample without having to manually use libgeotiff to retag the source files, as GM doesn't take alpha channels... :-(
One of the drawbacks to trying to watermap all the scenery.
HolgerSandmann
Resource contributor
- Messages
- 392
- Country
Hi there,
Dean, could you tell us what the advantage of using 32-bit tiffs would be? If the original data is in 16-bit format doesn't switching to 32-bit just lead to oversampling? Or have you found that the internal interpolation (anti-aliasing) of Global Mapper in combination with 32-bit format does lead to better results?
Lance, how about using 2 fraction bits instead of 3 as a compromise? I'm suggesting this because the potential issue with using separate files is display priority. Generally, you can force this with a higher LOD but that often leads to pop-up of the higher-LOD mesh at short distances (a "good" example of that is the new Mount St. Helens mesh in FSX Acceleration; fly the mission and you'll probably see the LOD11 mesh pop up in a rather startling fashion).
If, instead, you keep the smaller mesh file at the same LOD and try to force display via alphanumerical order or folder priorities then you'll find that FS will often stick with the mesh it loaded first, which, on approach, will be your larger area base mesh.
Cheers, Holger
Dean, could you tell us what the advantage of using 32-bit tiffs would be? If the original data is in 16-bit format doesn't switching to 32-bit just lead to oversampling? Or have you found that the internal interpolation (anti-aliasing) of Global Mapper in combination with 32-bit format does lead to better results?
Lance, how about using 2 fraction bits instead of 3 as a compromise? I'm suggesting this because the potential issue with using separate files is display priority. Generally, you can force this with a higher LOD but that often leads to pop-up of the higher-LOD mesh at short distances (a "good" example of that is the new Mount St. Helens mesh in FSX Acceleration; fly the mission and you'll probably see the LOD11 mesh pop up in a rather startling fashion).
If, instead, you keep the smaller mesh file at the same LOD and try to force display via alphanumerical order or folder priorities then you'll find that FS will often stick with the mesh it loaded first, which, on approach, will be your larger area base mesh.
Cheers, Holger
- Messages
- 1,025
- Country
Hey Holger,
Ah gosh over a year and a half ago when I was doing a lot of testing with the formats I found that 32 bit lead to a lot less banding and tiger striping, pretty much eliminating it... 16 bit actually creates a lot of stepping/banding issues. The NED based data is primarily 32 bit source, although the metadata in some tiles shows that 16bit was how it was compiled and it's easily seen when you see the terracing effect on those quads. The USGS is working at replacing those tiles once they become available.
I turn off anti-aliasing as it's not needed on the NED data I've been using (Was it you that recommended I do that? lol), it's all fractional to begin with. Justin also compiles under 32 bit now as well after I passed that info onto him long time ago...
Yeah basically I discovered 32 bit GeoTiff worked nicely for me, as I had major banding issues in 16 bit around Mt Charleston in Southern Nevada, 32 bit fixed all the issues for me, the file sizes may be larger but these days massive drives are cheap...
One thing I'd like to do eventually is render each LOD separately to make the mesh even nicer, as the mesh can become sharp at lower LOD's under the autoLOD option... Maybe I'll get to that soon... I kinda wish that we could use separate sources for each individual LOD 'layer' with the resample tool but that's just not possible...
Cheers,
Dean
Ah gosh over a year and a half ago when I was doing a lot of testing with the formats I found that 32 bit lead to a lot less banding and tiger striping, pretty much eliminating it... 16 bit actually creates a lot of stepping/banding issues. The NED based data is primarily 32 bit source, although the metadata in some tiles shows that 16bit was how it was compiled and it's easily seen when you see the terracing effect on those quads. The USGS is working at replacing those tiles once they become available.
I turn off anti-aliasing as it's not needed on the NED data I've been using (Was it you that recommended I do that? lol), it's all fractional to begin with. Justin also compiles under 32 bit now as well after I passed that info onto him long time ago...
Yeah basically I discovered 32 bit GeoTiff worked nicely for me, as I had major banding issues in 16 bit around Mt Charleston in Southern Nevada, 32 bit fixed all the issues for me, the file sizes may be larger but these days massive drives are cheap...
One thing I'd like to do eventually is render each LOD separately to make the mesh even nicer, as the mesh can become sharp at lower LOD's under the autoLOD option... Maybe I'll get to that soon... I kinda wish that we could use separate sources for each individual LOD 'layer' with the resample tool but that's just not possible...
Cheers,
Dean
Last edited:
Thanks for that tip. I have been using 16 bit for some reason I assumed resample wouldn't like 32 bit.
I also sometimes have the "file not found" problem. At one time I thought it might be that I was outputting 8 bit grayscale black is 0 which GM always uses packbits compression on, and maybe resample didn't like that but IIRC I did have success on using the geotiff right out of GM, so maybe it was something else (in the worst case just put the inf parameters in). This was for season data.
I recently did a small remesh to get rid of the plateau effect at KPUB, and had no problem with using 16 bit elev right out of GM.
For Meshman: have you tried to do any minor HI islands? When FSX first came out as a training I was working on mesh for Ka'ula but the USGS doesn't have consistent NED data for the whole island. I tried to merge some SRTM data into the hole but it didn't blend very well and I put it on the back burner.
scott s.
.
I also sometimes have the "file not found" problem. At one time I thought it might be that I was outputting 8 bit grayscale black is 0 which GM always uses packbits compression on, and maybe resample didn't like that but IIRC I did have success on using the geotiff right out of GM, so maybe it was something else (in the worst case just put the inf parameters in). This was for season data.
I recently did a small remesh to get rid of the plateau effect at KPUB, and had no problem with using 16 bit elev right out of GM.
For Meshman: have you tried to do any minor HI islands? When FSX first came out as a training I was working on mesh for Ka'ula but the USGS doesn't have consistent NED data for the whole island. I tried to merge some SRTM data into the hole but it didn't blend very well and I put it on the back burner.
scott s.
.
Last edited:
- Messages
- 1,025
- Country
Oh Scott, I didn't notice you were in Hawaii. I should pass on to you an early render of Oahu at 1 foot per pixel photoscenery...
I've gone back to square one on her but have plans to resurrect her soon...
Also I have some secret plans for Hawaii right now, but I am still lining some things up...
I'm considering moving back to either Oahu or the Big Island soon.
Oh the other bit of info I didn't respond to from Holger earlier. The USGS NED is in 32 bit format from the start. Both the GeoTiff and other format they produce from seamless.
The main advantage of 32bit GeoTiffs is for the fractional elevation settings. Scott, you'll find it a cinch to use 32 bit GeoTiffs for rendering and you'll find you get better results on the end BGL. Also because 32bit gives millions of colors it removes the 4096 limits that 16bit has. It's why I started using 32bit because it just simplifies stuff, produces better renderings without banding/tiger striping and allows for high definition fraction bit settings. Which are definitely needed if you produce 5, 2 or 1m elevation BGL's as those definitely need fraction bits enabled, otherwise you end up with a pineappling effect...
Hmm, let me try and make sense lol. The problem with 16bit when it comes to fraction bit renderings is that it does have a limit on elevation heights. When using 32 bit you no longer need to worry about calculating offsets and everything, you can just punch the data straight into resample and your fraction bits will work right away. Because 32bit has 24 million colors and another 8 million greyscale levels (which is what controls the elevation), you can have millions of fraction bits defining elevation points, compared to only 8-10,000 which is all that 16bit gives. I hope that makes sense. Basically the elevation samples in 32bit are in the extra bits between 24bit and 32bit. Basically at 32 bit you end up with a possibility (say your fraction bits are accurate to 10cm vertically), of 800,000m from bottom to top, that's approximately 2.6 million feet. Even with fractional settings accurate to 1cm vertically, that will give 80,000m vertical elevation units or approximately 262,000 feet vertical range.
Honestly 32 bit gives better definition, the only thing is the expense of hard drive space and a bit longer rendering times, but the results and ease of use are defintely worth the trade. When you can get about 1TB of drives for about $200 now it's worth the investment...
I've gone back to square one on her but have plans to resurrect her soon...
Also I have some secret plans for Hawaii right now, but I am still lining some things up...
I'm considering moving back to either Oahu or the Big Island soon.
Oh the other bit of info I didn't respond to from Holger earlier. The USGS NED is in 32 bit format from the start. Both the GeoTiff and other format they produce from seamless.
The main advantage of 32bit GeoTiffs is for the fractional elevation settings. Scott, you'll find it a cinch to use 32 bit GeoTiffs for rendering and you'll find you get better results on the end BGL. Also because 32bit gives millions of colors it removes the 4096 limits that 16bit has. It's why I started using 32bit because it just simplifies stuff, produces better renderings without banding/tiger striping and allows for high definition fraction bit settings. Which are definitely needed if you produce 5, 2 or 1m elevation BGL's as those definitely need fraction bits enabled, otherwise you end up with a pineappling effect...
Hmm, let me try and make sense lol. The problem with 16bit when it comes to fraction bit renderings is that it does have a limit on elevation heights. When using 32 bit you no longer need to worry about calculating offsets and everything, you can just punch the data straight into resample and your fraction bits will work right away. Because 32bit has 24 million colors and another 8 million greyscale levels (which is what controls the elevation), you can have millions of fraction bits defining elevation points, compared to only 8-10,000 which is all that 16bit gives. I hope that makes sense. Basically the elevation samples in 32bit are in the extra bits between 24bit and 32bit. Basically at 32 bit you end up with a possibility (say your fraction bits are accurate to 10cm vertically), of 800,000m from bottom to top, that's approximately 2.6 million feet. Even with fractional settings accurate to 1cm vertically, that will give 80,000m vertical elevation units or approximately 262,000 feet vertical range.
Honestly 32 bit gives better definition, the only thing is the expense of hard drive space and a bit longer rendering times, but the results and ease of use are defintely worth the trade. When you can get about 1TB of drives for about $200 now it's worth the investment...
Last edited:
- Messages
- 1,025
- Country
Hi Lance,
Yeah I believe Justin's was rendered at 97% compression quality, but version 1 was only rendered at non-fractional whole meter settings. Version 2 should be out from FSG shortly which will be fractionally based.
Raimondo's was also rendered non-fractional whole meter. Also his data for Molokai I think it was has a huge sink hole in it and how he managed to do that no one has any clue. I'd definitely avoid his mesh for the islands... At the file sizes it sounds likely that it may have been rendered at 100% uncompressed but he also has a lot of extra data around the islands that is basically 0 elevation value so that also is likely behind the file size increase.
I've had a few instances of resample crashing with elevation samples being rendered fractionally at 100% quality, it seems that 99-97% is the best to work around that problem if it pops up...
I had rendered the Hawaiian Islands previously but lost the data in a hard drive crash about a year ago and didn't get around to re-downloading the data from seamless again... At the moment I've cancelled all my plans for working with NED based data for future products as I have something else in the pipeline that I'll be announcing very soon...
I'll definitely keep you in the loop, but I'd say you may want to set aside the work you're doing right now because better days are coming and hopefully within the next 4-8 weeks ;-)
Cheers,
Dean.
Yeah I believe Justin's was rendered at 97% compression quality, but version 1 was only rendered at non-fractional whole meter settings. Version 2 should be out from FSG shortly which will be fractionally based.
Raimondo's was also rendered non-fractional whole meter. Also his data for Molokai I think it was has a huge sink hole in it and how he managed to do that no one has any clue. I'd definitely avoid his mesh for the islands... At the file sizes it sounds likely that it may have been rendered at 100% uncompressed but he also has a lot of extra data around the islands that is basically 0 elevation value so that also is likely behind the file size increase.
I've had a few instances of resample crashing with elevation samples being rendered fractionally at 100% quality, it seems that 99-97% is the best to work around that problem if it pops up...
I had rendered the Hawaiian Islands previously but lost the data in a hard drive crash about a year ago and didn't get around to re-downloading the data from seamless again... At the moment I've cancelled all my plans for working with NED based data for future products as I have something else in the pipeline that I'll be announcing very soon...
I'll definitely keep you in the loop, but I'd say you may want to set aside the work you're doing right now because better days are coming and hopefully within the next 4-8 weeks ;-)
Cheers,
Dean.
- Messages
- 1,025
- Country
Lance don't give up, it will be a good learning experience and I'm sure you'd find satisfaction from the results...
It's a good learning curve
Plus the islands look better in 10m dem especially at 100% quality rendering...
It's a good learning curve
Plus the islands look better in 10m dem especially at 100% quality rendering...
Thanks for the updates. I currently am running FSG mesh v1 for Hawaii (requires both US ver and world ver for NW Hawaiian Islands), UTX USA, Mega-Oahu, and DillinghamX (aerosoft). I need to do a few things (I think there is an addon on avsim to get rid of the lakes UTX puts on Ni'ihau, for instance). From time to time I've played around with PHHI, might go back and work on that again.
scott s.
.
scott s.
.
- Messages
- 1,025
- Country
Cool, I'm looking at moving back to either Oahu or the Big Island sometime later this year and setting up our office in the Islands again...
I have to head back to Australia for a little bit first though... Hopefully I might be able to get some work on NCL out of Honolulu for a few months...
I have to head back to Australia for a little bit first though... Hopefully I might be able to get some work on NCL out of Honolulu for a few months...