Ahoj!
Za začetek sem premaknil temo v delavnico, ker imam občutek, da zadeva čedalje bolj paše v ta forum.
Mirko napisal/-a:
Sicer pa ne vem kakšen format sploh potrebuješ za pretvorbo v BGL format, oz. s katerim orodjem to lahko narediš. Bilo bi fino, če to malo opišeš. Mogoče bi s skupnimi močmi lahko kaj naredili. To bi bilo dobrodošlo za tiste, ki imajo slabše mašine in bi zase potrebovali manjši MESH za svoj priljubljen košček deželice.
Bom probal pomagat, vedno pa velja, dajte še pogledat v
http://forums.avsim.com, v Scenery design forum in v Mesh design forum.
Začetek vsega je
Terrain SDK, kjer opozarjam na (za ta primer) Wordov dokument
Creating Terrain.doc, kjer so stvari razložene.
Če malce naredim Copy-Paste iz dokumenta:
Terrain Textures.doc napisal/-a:
Getting Digital Elevation DataA DEM provides a digital representation of a portion of the earth's elevation points over a two-dimensional surface. A DEM is generated by sampling an array of elevation values derived from topographic maps, aerial photographs, or satellite images.
There are a number of places to get digital elevation data. Most terrain data available for free over the Internet is typically stored in formats such as the USGS DEM (Digital Elevation Model) ASCII, USGS TAR, or USGS Spatial Data Transfer Standard (SDTS) formats. All source data is expected to use WGS84 projection.
...
The raw data used when creating terrain for Flight Simulator 2004 must be in a binary file format, with each elevation point (measured in meters above mean sea level) being assigned a 16-bit integer. The resampler supports both LSB (least significant byte first) and MSB (most significant byte first) 16-bit integers.
Note: The USGS DEM and SDTS formats are not compatible with the terrain tools included with this SDK, but there are converters available (free of charge) on websites that convert the data to a compatible binary form. For example, see the read_dem.exe tool that’s available for download at
http://dbwww.essc.psu.edu/notes/utilities.html.
Torej osnova za izdelavo mesha so DEM podatki. Ker pa FS razume samo BGLje, se jih s pomočjo datotek priloženih temu SDKju (včasih pridejo prav programčki tudi iz starejšega istoimenskega SDK za FS2002!!) skonvertira v BGL. Zato potrebujemo konverter imenovan RESAMPLE.EXE, ki je priložen SDKju in INF datoteko, katero RESAMPLE bere med konverzijo. Ta INF datoteka ni nič drugega kot INI datoteka. Primerček:
Koda:
[Destination]
; The [Destination] section defines the output of the resampler
; LOD = {Auto, 0..n}
LOD = Auto
DestDir = ".\scenery"
DestBaseFileName = "rainier"
UseSourceDimensions = 1
[Source]
Type = ElevS16LSB
SourceDir = "x:\dem"
SourceFile = "dem_100m_mtrainier.dat"
Lat = 46.99916666667
Lon = -121.9466666667
NumOfCellsPerLine = 457
NumOfLines = 375
CellXdimensionDeg = 0.0008333333333333
CellYdimensionDeg = 0.0008333333333332
ScaleinMeters = 1.0
Vse skupaj deluje jako enostavno, kajne? Seveda v tem INF fajlu lahko uporabimo tudi več izvornih datotek, ki jih potem RESAMPLE skupaj zloži v en BGL. Ampak tukaj bi predvsem opozoril pa na ono sekcijo Source, ki je pravzaprav najbolj pomembna.
V tej sekciji se poda izvorna točka, levi zgornji vogal (t.j. severozahodni) in velikost celice. Ravno to me pravzaprav najbolj skrbi pri izdelavi tega mesha, btw... Lahko se specificira tudi severozahodni in jugovzhodni vogal kvadranta, kamor se umešča mesh oz. obstojijo podatki. Te podatke boste verjetno dobili v onem programčku, s katerim se predeluje podatke, predvidevam.
Opozarjam tudi na ukaz LOD oz. Level of Detail. Če si preberete dokument
TMF manual avtorja Christiana Stocka (pravzaprav je to obvezno gradivo!), potem ugotovite, da je pravzaprav Zemlja razdeljena na trapeze (ne na pravokotnike, ker pač je Zemlja geoelipsoid). Manjši ko so ti trapezi, več je detajlov in s tem večji LOD.
LOD0 je pravzaprav Zemlja v enem samem trapezu. 1 trapez LOD1 je cca 1/4 trapeza LOD0, 1 LOD2 trapez je cca 1/4 LOD1 trapeza in tako dalje in tako dalje. Najfinejši LOD po MS je potemtakem LOD15, kjer je ločljivost 1.2m in ima najdaljšo stranico 306m. Tak trapez je potem ob ekvatorju praktično pravokotnik, na polih pa je pravzaprav trikotnik z kar nekaj napake. In še tabelica iz MS dokumenta:
Koda:
LOD Sample Size Lat Deg Lon Deg Span
(meters) Boundaries Boundaries Meters
0 39136.2 90 120 10018863
1 19568.1 45 60 5009431
2 9784.0 22.5 30 2504716
3 4892.0 11.25 15 1252358
4 2446.0 5.625 7.5 626179
5 1223.0 2.8125 3.75 313089
6 611.5 1.40625 1.875 156545
7 305.8 0.703125 0.9375 78272
8 152.9 0.3515625 0.46875 39136
9 76.4 0.17578125 0.234375 19568
10 38.2 0.087890625 0.1171875 9784
11 19.1 0.043945313 0.05859375 4892
12 9.6 0.021972656 0.029296875 2446
13 4.8 0.010986328 0.014648438 1223
14 2.4 0.005493164 0.007324219 612
15 1.2 0.002746582 0.003662109 306
Pretiravat z LOD ni najbolj priporočljivo, ker:
1. prevelik LOD pomeni kar zmanjšanje FPS, kar nam ni lih cilj
2. če zahtevamo prevelik LOD potem moramo zahtevati tudi od uporabnika, da instalira FS9 update:
FS2004 Update Readme napisal/-a:
Improved Digital Elevation Mesh Support -
The Flight Simulator 2004: A Century of Flight (update) increases the level of digital elevation mesh (DEM) support from 38 meters to 19 meters.
http://www.microsoft.com/games/flightsimulator/fs2004_update9.1_english.aspTMF manual napisal/-a:
Another well known problem is that FS2002 has a limitation in mesh accuracy. What this means is that very fine mesh doesn’t get displayed in FS2002. The reason is the CLOD scheme and ROAM. The detail of a quadrant in ROAM is controlled by a so called ‘error metric’ value. For example, we could say if the vertical error we get in between displaying LOD 10 and LOD 9 is less than 3 pixels, then display LOD 9 (this means we are now far enough away from that section to display a lower LOD). There seems to be a lower limit of the error metric value in FS2002. This is why you can’t ever display very highly detailed mesh in FS2002. Increasing TERRAIN_MAX_VERTEX_LEVEL from 19 to 21 in the FS2002.inf file seems to decrease the error metric value a bit, but 21 seems to be the absolute maximum. My personal opinion is that it doesn’t really bother me. I find a LOD of 10 to be very reasonably detailed already. Going up to LOD 11 and 12 you get into an area where the error starts to get bigger than the actual resolution. So you don’t win anything going to these high resolutions. On the other hand, what FS2002 should really do is still display the high detail mesh, but at a lower detail (as controlled by the error metric value). Instead, FS2002 doesn’t display high detail mesh at all, so be careful!
Vendar pa po zgornji tabelici, bi naš 25DMR ustrezal LOD11
Okej, sedaj ko smo ugotovili, kateri LOD naj bo vzeli, potem se ozrimo po dokumentu Christiana Stocka, ki nam pove, kako izračunati začetke podatkov, sicer za
LOD7, ampak vseeno se vidi kam pes taco moli:
TMF manual napisal/-a:
First of all you really need to find out where in the LOD table you want to ‘hook in’, i.e. what LOD level you want to use. The LOD level of the default scenery is 5, which means that every grid point is about 1.2 km apart (use the LOD table from the Terrain SDK to understand this section). The other LOD values smaller than 5 (coarser resolution) will get calculated dynamically, and the engine now can display LOD 5 values when you are close and LOD 4 and less the further away you are. Now let’s assume you have an elevation dataset that has elevation points every 300 metres and you want to make some scenery. What would be a good LOD value to use? If we also use LOD value 5, our grid will get resampled to a resolution of 1223 metres. This is obviously bad, because a lot of our elevation points would get dropped out, and our scenery wouldn’t look as good as it could be. So what about LOD 10? We get a grid point every 38.2 metres. Now we certainly won’t loose any detail in our scenery. But remember that the higher the LOD value, the more squares / triangles MSFS will display (which in turn will hurt frame rates). Our data only has elevation measurements every 300 metres, so a lot of ‘fake’ interpolated values get inserted into our scenery. Once our scenery gets loaded MSFS will show the very small squares (38.2 x 38.2 m2) when we are close. This is overkill, since MSFS will have to render all these little squares now, although our source data actually only has elevation points every 300m. This will slow things down unnecessarily. So we really should choose a value close to 300m, LOD 7 seems to be ideal.
TMF manual napisal/-a:
Now that we have a LOD value, we have to calculate our area that goes with the LOD value and our data (again, use the LOD table from the Terrain SDK for reference). Let’s say your area of interest where you have some data is between 37 and 41 degrees latitude. We have to use the LOD table and try to get close to 41 degrees: 45 – 2.8125 – 0.703125 = 41.484375. This is close to 41, but not within our area between 37 and 41 degrees. What would happen if we would use this value? There isn’t data defined for the whole area so the resampler wouldn’t know what to do and would just generate an empty file. Not good, so lets use 40.78125 instead. Now we can see that we actually loose some of our data. Not good either, but because MSFS is using CLOD there’s nothing we can do about it. Similarly we get 45 – 5.625 – 1.40625 - 0.703125 = 37.265625. So our latitude limits are 37.265625 and 40.78125 degrees. The longitude values get calculated similarly. If we would use a LOD value of 10, of course, we could get closer to our data limits, because we can use smaller squares.
Okej, jest upam, da je za začetek dovolj. Več pa kot omenjeno, poglejte v omenjene dokumente, pa ne pozabit snet še
Custom Terrain Textures SDK za FS2002, ki ga je za 9,7MB... FS2002 scenery SDKji so pa tukaj:
http://www.microsoft.com/games/flightsimulator/fs2002_downloads_sdk.asp#scenery
Če še kaj rabite pa sporočite!
Prijava
Registriraj se!
FAQ
Iskanje
