https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796680
Interesting issue ! I was wondering how to reduce terracing. I used 32-bit method but not floating point. Also I used FractionBits=2 in inf. file to resample.
Mesh looks identical to the freeware I found with whole Canary Islands, but my purpose was to make just one to ensure everyone and myself
that it`s my work in case of and kind of distribution. I will try floating point when exporting to geotiff and let know .
By the way photo-scenery you see is my work as well in LOD-16 60cm/px resolution and lot of work in PS with water and blend. Photoscenery available on Rickoo is 1 or 2m/px and different worse imagery data sets. One more screen after 4 hours of sleep ( whole night with this stuff ).
FractionBits=2 in SDK Resample *.INF file with a 32-Bit Floating Point raster elevation data source file may be sufficient to minimize "terracing" for Gran Canaria.
Looks like a good scenery !
https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796680
As for as resampling and method I used, it`s slightly different as described above. The data I've download was in 5 parts so I figured that I need to merge them all together in order to enter center coordinates of island in inf file for resampling. Of course I exported merged ( one file ) to geotiff and wgs84 datum. I`m wondering if it will work in P3D as well lon and lat central coordinates .
I'm not certain that I understand what you meant by the use of "
center coordinates of island in inf file for resampling"; would you please post the INF file here ?
[
EDITED]
FYI: I asked about central Geographic coordinates of your project area to verify a UTM Zone number to be used when displayed in a GIS application.
AFAIK, for a source file specified in the
*.INF file submitted to SDK Resample, one should only use Geographic coordinates from the GIS Metadata
AFTER it is re-projected from its original distribution format (
ex:
REGCAN95 for the Canary Islands) to EPSG:4326 (aka: Geographic Lat-Lon projection / WGS84 Ellipsoid Datum) ...and
not arbitrarily the central Geographic coordinates of a GIS source data file.
IIUC, this is because EPSG:4326 (aka: Geographic Lat-Lon projection / WGS84 Ellipsoid Datum) required by FS SDK Resample, is
variable in "shape and orientation" of pixel coordinates compared to UTM or other similar 'local'
non-warped GIS cartographic projections, which are
not variable in "shape and orientation" of pixel coordinates (when sample data extents are considered in 'tiles' of no more than 1 Kilometer at at time).
Please note that Gran Canaria Island is between 48 and 52 Kilometers in diameter, thus shorelines are between 24 and 26 Kilometers from its center point.
While it is true that "warping" of GIS data is visibly greater farther North or South from the Equator when formatted in a EPSG:4326 (aka: Geographic Lat-Lon projection / WGS84 Ellipsoid Datum) GIS cartographic projection, at distances of 24 and 26 Kilometers from the center point of Gran Canaria Island, there is likely to be 'some'
variability in "shape and orientation" of pixel coordinates (aka: "warping") ...even at its location within 28 degrees North of the Equator.
Thus, IMHO, the importance of using Geo-referencing coordinates from GIS Metadata for source data files submitted to SDK Resample via a
*.INF file.
If such source data files submitted to SDK Resample have been properly re-projected to EPSG:4326 and exported as GeoTIFFs, the
*.INF file can be much less complex, and SDK Resample will automatically read the required Geo-referencing coordinates from GIS Metadata within the GeoTIFF and its
*.TFW file.
If Masks and Seasonal / Night source files are derived from the GeoTIFF and edited, provided one always keeps the original total Pixel Row and Column numbers
unchanged (and therefore the Geo-referencing) for such mapped images
unchanged), one can read and write out a *.INF for such images to be used for their entries in the *.INF file ...which
match the geo-referencing coordinates within the GeoTIFF from which they are originally derived.
To do this, one may use Ollyau's "
GeoTIFF to INF" utility to read the GeoTIFF projected in EPSG:4386, then use "
GeoTIFF to INF" to write out a INF for use with FS SDK Resample via the 'manual' compilation method.
The resulting INF includes the Geo-referencing info for the NW and SE corners derived from the [
filename].TIF 'GeoTIFF file header' and the accompanying [
filename].TFW 'world' file for that GeoTIFF image in Geographic Lat-Lon projection / WGS84 Ellipsoid Datum required by FS SDK Resample.
[
END_EDIT]
https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796680
Also I have one more question. How to optimize photo-scenery for better loading time and further visibility?
Compression 85 or maybe less or more like 100 ?
I believe that visibility from distance might be different if i out LOD=auto or 0,16. Maybe 10,16 would improve distance visibility ?
I could check myself but would like to save some time and/or know other tip for that thing....
I personally prefer the greater detail of
CompressionQuality=100.
But, it has been reported that
CompressionQuality=97 for terrain mesh still looks good, but results in Resample output of a significantly smaller BGL size.
The recent consensus is to not include
photo-real LODs
below 4, so
LOD-4,16 or
LOD-4,Auto should be a more practical range for visibility of an island.
NOTE: Data density in lower LODs requires progressively less file size, so it usually does not become a problem to extend LODs down to 4 or lower, as in some cases where one may need to increase the Geographical extent of coverage for a terrain
mesh BGL to force display on top of other loaded mesh BGLs.
Looking forward to seeing more screenies !
GaryGB
