Hallo zusammen!

Habe noch keine weiteren Tests mit Strip oder Autoasm gemacht.

Als Neuigkeit gibts zu vermelden, dass John Childs eine neue Version (3.50) von Blackart veroeffentlicht hat: http://www.terrainmap.com/

Wie ihr der Meldung entnehmen koennt, hat er meine Vergleichsbilder auf Avsim gefunden (ich hatte in diesem Thread ja auch ein paar gezeigt) und dabei festgestellt, dass eine der Interpolationsalgorithmen (LSQR) nicht sinnvollerweise auf die gesamte Datei, sondern nur die Loechers selbst angewendet werden sollte. Die neue Version tut das und ein kurzer Test von mir bestaetigt das auch - keine "verschwommenen" Ergebnisdaten mehr.

Cheers, Holger

Servus Holger und Joachim,

Die Zeit vergeht sehr rasch, ich hoffe trotzdem, dass ihr diesen Beitrag noch lest.

Joachim,
natürlich ist dies alles nicht neu. Und wie ich schon weiter oben geschrieben habe, versucht man seit Beginn von Computern Kartematerial (auch andere Pläne) zu digitalisieren.

Dein Satz:
„Du musst nur die Pixel der Kartenbitmap quasi in das LOD Raster des FS bringen so das dieses flächenmäßig alles passt.“
ist entscheidend.
Daher bin ich bei AA Tutorial Pkt 7 und 8 – reading and using bitmaps.

Vielleicht schaffe ich es diese Woche noch meine Gedanken etwas ausführlicher zu beschreiben.

Tausende Leute auf diesen Erdball versuchen auch Punkte, Linien und Polygone für GPS zu entwickeln und Kartenmaterial auch im privaten Bereich zu nutzen.

Daher nur kurz ein paar Links:

Eine von vielen guten Seiten, mit guten und kurzen Informationen (auch zu Werkzeugen):
http://www.digitalgrove.net/

Vergleich von kanadischem Datenmaterial:
http://members.shaw.ca/davepatton/mapcompare.html

deutscher Vergleich:
http://hometown.aol.de/mikeglade/TOP25BW.jpg
http://hometown.aol.de/mikeglade/GarminTop25.jpg
http://hometown.aol.de/mikeglade/GarminCS.jpg

Höhenlinien digitalisieren:
http://www.easytrace.com/work/englis...utorelief.html

ASCII – Höhenpunkte:
http://www.geocities.com/miroslavdressler/surgetut.htm

Vielleicht gibt es auch einmal eine Art POI (Points of Interest) Einbindung in den FS. Oder man kann so etwas entwickeln. Genauso wie bei GPS-Material oder anderen GIS-Material.
Damit meine ich nicht nur die Anordnung von Objekten entlang von Linien, sondern die Zuordnung von speziellen Gebäuden (z.B Wiener Stephansdom), anhand von Koordinaten. Man könnte eine Datenbank erstellen und Gebäude relativ einfach ergänzen.

Wie geschrieben, werde ich meine Ideen einmal zusammenfassen.

Wichtig wäre nur, dass dies jeder aus irgendeinem Material (Datenformate) machen kann. Damit hätte man sicher keine Probleme mit Lizenzen (man scannt die Daten ja nur) und relativ rasch eine realistische Landschaft im FS. Weltweit könnten Flusianer mit diesen Freewareprogrammen arbeiten und einfach Landschaften produzieren.
Und die Gierigen könnten es ja wieder auf CD zusammenfassen und verkaufen. Aber nur wenn sie den Autoren dieser Programme Geld geben (siehe Pete Dowson). Daher würde ich auch gerne anhand einer bgl erkennen, mit welchem Programm es erzeugt wurde.

Egal, fertig werde ich mit meinen Gedanken und deren Umsetzung nie sein, auch nicht beim FS10. Es ist auch sehr zeitaufwendig, wenn man beide Seiten - Material und Umsetzung im FS – verstehen will.

Derzeit habe ich 3 Fragen:

Holger
A)Ich habe hier
http://edcdaac.usgs.gov/glcc/tablambert_euras_eur.asp
ein img Datei schon vor etwas längerer Zeit geladen. Ich habe nur leider keine Ahnung wie ich diese Daten darstellen kann. Sind das HDF Daten?

B)Tmfdecompress funktioniert bei mir (XP) anscheinend auch nicht richtig. Mit –b, -l, -n usw. habe ich eigentlich immer dasselbe Ergebnis, und dies sieht nicht gut aus. Mache ich da etwas falsch oder gibt es eine neue Version? Bei mir funktioniert anscheinend die Bitmap-Routine nicht richtig.

Joachim
C) zu Toposcanner finde ich leider keine Informationen. Was das Programm eigentlich aus diesem Material auslesen konnte. Anscheinend wird es nicht mehr vertrieben (Lizenzgründe-Landvermessung?) Bzw. ob es jedes Datenformat kann.

Meine Download und Update Ordner ist schon sehr groß. Der muss diese Woche noch aufgearbeitet werden.
Priorität hat sicher AI-Floatplane und Ships und natürlich Glacier Bay National Park seit gestern (mit der Maule wahrscheinlich ein Genuss)
Holger, herzlichen Dank einstweilen dafür.

Horst

Zu B.

Funktioniert bei mir sehr gut. Mir reciht die nackte decompilierung aus. da ist alles drin was man benötigt. Alles andere ist meiner Meinung nach unwichtig. Bei nacktem Decompressvorgang kommt bei Landclass eine fertige Inf zum späteren Kompilieren raus. Weiterhin das RAW File. das gleiche gilt für mesh. Du musst nur ein Tool haben um die RAW Dateien zu bearbeiten bzw. auszulesen.

Dann könntest Du jedes Landclass oder Meshfile editieren.

Ich glaube deshalb hat es auch schon irgendwo Ärger gegeben. Wegen Lizenzen und so. Habe aber nur oberflächlich gelesen.

Zu D würde ich einfach mal Patrick ansprechen.

Du benötigts aber auf jeden Fall so etwas wie TOP50 neue Version mit digitalen Höhenmodell.

Nicht ganz billig der Spaß. z.B Bayern sind gleich zwei CD. Das wird so um die 100Euro liegen. Habe selbst auch nur Niedersachsen und Hessen mit Höhenmodell. Der Rest alles noch nur mit den üblichen Höhenlinien. Blackart scheint hier ja auch eine Unterstützung anzubieten. habe mir das aber noch nicht angeschaut.

Auto ASM habe ich in die Ecke gelegt. Komme trotz verschiedener Einstellungen und PCs immer zu selben Ergebnissen.

Außerdem ist es bei mir mit dem Code nicht performance freundlich. Da der FS schon genug belastet ist lasse ich die Finger davon.

Sollte ich den Code vom NAV System knacken was ich besitze werde ich wohl ein eigenes Tool machen.

Muß natürlich noch einiges lernen.

Ev. gibt es bis dahin ja schon was. Dann hat sich das erledigt.

Hallo zusammen!

Die Zeit vergeht tatsaechlich schnell; seit meinem letzten Post (Blackart 3.50 erhaeltlich) hat es 8 neue Versionen von Blackart gegeben! Scheint so aehnlich wie mit MicroDEM zu sein - vor jeder Benutzung erst mal auf der Webseite nachschauen, ob es bereits wieder eine neue Version gibt ;)

Horst, vielen Dank fuer die Sammlung der Links - als "Kartenfanatiker" (laut meiner Partnerin) finde ich solche Webresourcen immer sehr spannend.

----
"Vielleicht gibt es auch einmal eine Art POI (Points of Interest) Einbindung in den FS. Oder man kann so etwas entwickeln."

Gibts bereits fuer den FS, soviel ich weiss: http://www.abacuspub.com/catalog/s497.htm. Habe allerdings unterschiedliche Meinungen darueber gehoert - die Software laeuft wohl parallel zum FS und fuehrt oft zum Ruckeln beim fliegen.

----
"Ich habe hier [...] ein img Datei schon vor etwas längerer Zeit geladen. Ich habe nur leider keine Ahnung wie ich diese Daten darstellen kann. Sind das HDF Daten?"

Kannte diese Daten noch nicht aber laut Read-me (siehe unten) handelt es sich um 8-bit Rasterdateien. Sollte man also einfach als .raw Format mit Photoshop usw. laden koennen; die Datei fuer Eurasia hat 13000 Spalten und 12000 Zeilen.

"The data dimensions of the Lambert Azimuthal Equal Area projection for the Eurasia land cover characteristics data set optimized for Asia are 12,000 lines (rows) and 13,000 samples (columns) resulting in a data set size of approximately 156 megabytes for 8-bit (byte) images." http://edcdaac.usgs.gov/glcc/eadoc2_0.asp

Das groessere Problem duerfte hier die Projektion sein; da brauchst du wahrscheinlich ein Payware GIS um vom Lambert auf Lat/Long umzuprojektieren - falls du FS mit diesen Daten fuettern willst.

Uebrigens gibt es ein anderes, aehnliches Produkt hier:
http://www.gvm.jrc.it/glc2000/defaultGLC2000.htm. Dessen Vorteil ist, dass es sich bereits in der geographischen Projektion befindet. Jim Keir hat mich auf die Webseite aufmerksam gemacht und er bastelt bereits an einem neuen globalen Landclass-Datensatz fuer FS.

So ganz ohne Aenderungen werden die GLC2000 Daten aber auch nicht uebernommen werden koennen. Z.B. gibts nur eine Klasse fuer bebaute Gebiete und auch nur eine Klasse fuer Eis und Schnee. Fuer das gestern veroeffentlichte Glacier Bay N.P. Projekt habe ich mit den GLC2000 Daten experimentiert, sie dann aber doch nicht verwendet. Wie ihr wohl wisst, hat FS zwei Eis & Schnee Landklassen, #122 und #142. Die benutzen zwar dieselbe Textur, aber Klasse #122 wird nicht verblendet. Daher kann man Gletscher und Schneefelder im Inneren mit 122 deklarieren, muss aber an den Raendern immer eine Reihe von #142 anhaengen (das kann man auch in der default worldlc.bgl sehr gut sehen). Die Alternative, nur #142, sieht uebrigens auch nicht gut aus.

Da ich fuer das Glacier Bay Gebiet Landsat-Daten zur Verfuegung hatte, habe ich per GIS eine unueberwachte Klassifizierung der Kanaele 2, 4, und (4-3) durchgefuehrt, die 16 Ergebnisklassen auf 10 reduziert und denen dann den am besten passenden Landclass-Wert zugewiesen. Das Ergebnis ist natuerlich nicht perfekt aber sicher realitaetsnaeher als das Original.

Uebrigens wurden die Kuestenlinien vom Glacier Bay Projekt komplett mit "Strip" erstellt, inzwischen in "Slartibartfast" umbenannt (der ausserirdische Fjord-Designer vom "Hitchhikers Guide to the Galaxy"). Ihr koennt euch also im FS oder LWMViewer das Ergebnis mal kritisch betrachten.

Tmfdecompress (was ich selber noch nicht benutzt habe) ist nicht mehr frei erhaeltlich, da Jim damit moeglichen rechtlichen Schritten von Lizenzinhabern aus dem Weg gehen will. Er bitte auch darum, dass gegenwaertige Nutzer von Tmfdecompress dieses nicht weiter verteilen.

Ciao,
Holger

Na dann habe ich zu tmfdecompress doch richtig gelesen.

Übrigends Holger war Dir folgendes bekannt.

Man weis ja bei VTP2 Polys und Custom Fotosceneryzuweisung über LC252 und 253 schon recht lange das der FS hier vertikal gespiegelte Landclasstexturen liefert.

Was mir aber neu ist bzw. ich kann mich nie dran erinnern dieses jemals auch für normale Landclass gelesen zu haben das generell VTP2 Polys gekippte LC Texturen produiziert werden. Ehrlich gesagt ich habe nun so was über Ground2K gemacht und auch über SCASM Betaversionen. Mir ist es ehrlich gesagt nie aufgefallen. Sogar die Defaultpolys (Airport oder Parks stehen Kopf)

Fällt natürlich bei Wald und Rasen nicht auf. Bei VTP Polys die LCs mit Bebauung zuweisen passt natürlcih Autogen hin und vorne nicht mehr zur Textur.

Ich habe gedacht ich traue meinen Augen nicht. Anhand meiner Testtexturen konnte ich das jetzt sogar im FS2002 erkennen.

Wie gesagt bei Customtexturen findet man etliche Threads z.B AVSIM aber nie bei normalen LCs. Ob das noch niemanden aufgefallen ist. Mittlerweile gibt es ja sehr viele die Landclass über VTP2 zuweisen.

Hallo Joachim!

Das ist ja ein Ding! Mir war zwar schon oefters aufgefallen, dass die Bebauungs-Autogen eigentlich sehr schlecht zu den Texturen passen, obwohl MS eigens dafuer den Annotator entwickelt hat, aber auf die Idee mit der Spiegelung bin ich nicht gekommen. Ich werde mir das noch mal genauer anschauen und vielleicht auch mal im Avsim Scenery Design Forum nachfragen.

Uebrigens kann ich jetzt auch aus erster Hand bestaetigen, dass die "Weihnachtsgletscher" durch die "Mischung" von VTP2 Polys mit und ohne Nachttexturen entstehen. In einem der Ground2K4 Files vom Glacier Bay Projekt hatte ich neben den Gletschern auch ein Stadt-Poly (Juneau) zugefuegt und prompt leuchteten die Gletscher mit schoenster Dekoration - siehe Bild im Anhang. Habe das Stadtpoly entfernt, da das Ergebnis sowieso nicht so toll war und gleich war das Eis wieder schoen dunkel. Besten Dank nochmal fuer den Fund!!!

Cheers, Holger

Schönen Abend,

nur kurz:

Joachim
Nicht weglegen, Fehler aufzeigen und weiterhelfen. Autoren warten auf konstruktive Kritik und Meinungen. Mit dem Autor in Verbindung setzen.
Hier geht es nicht um Hacken, sondern die Suche nach Möglichkeiten für Jedermann (siehe SRTM (eine Basis auch für GPS-Karten), AFCAD)

a) Falls du Mapsource von Garmin meinst und img Files:
http://planeta.terra.com.br/informat...e_download.htm
http://karmin.sourceforge.net/
http://gps.chrisb.org/en/gps_mapper.htm
http://www.gpsinformation.net/gpsmapper/gpsmapper.htm
Zusammenfassung von Material:
http://kanadier.gps-info.de/d-map_source.htm

b) Topokarten (schon länger bekannt (ich glaube 2001):
http://home.wtal.de/noegs/top-export.htm

c) tmfdecompress:
Bitte kurzen Anhang (kleines jpg) von At2002/at2002.bgl
Übrigens noch einmal: ein gutes Freewaretool:
http://www.gadwin.com/printscreen/

Holger
a) zu meiner img-Datei
Den Link schon einige Male gelesen, und noch immer keine Ahnung wie ich es darstelle.
Vielleicht könntest du ein kleines Image runterladen und darstellen.

b) Dank deiner Anleitung bei Glacier endlich den Link zu Jim Keir Flusi-Seite gefunden:
http://www.jimkeir.co.uk/FlightSim/index.html
Küstenlinien gesehen.
AI will noch nicht richtig.
Ansonsten ein Genuss. Hatte alle Addons. Danke.

c) zu POI:
Ich meine nicht EZ-Landmark.

Sondern die Übernahme von Koordinaten und Einbindung in FS.
Keine Orientierung für bestimmte Objekte anhand von Linien (jedoch auch sinnvoll).
Z.B.: Mache eine Shell-Tankstelle und übernehme das Tankstellenetz aus andere Daten für ganz Österreich. (jede Tankstelle am richtigen Ort)
Nicht viele kleine bgl Dateien, sondern eine Datenbank und Erstellung einer bgl – siehe AI Traffic
Meine Gedanken muss ich näher erläutern.
Manchmal vergesse ich, dass der FS ein Spiel ist.

Andere Stellungnahmen muss ich erst nachvollziehen und überprüfen.

Horst

Hallo!

@ Horst

a) werd's mal im Hinterkopf behalten - versprechen kann ich aber nichts

b) bitte schoen! Lass mich wissen wenn's weiterhin Probleme mit den AI gibt

c) Aha - verstehe. Clevere Idee. Waere fuer die VFR auch gut geeignet, wenn man so z.B. Sendemasten einbinden koennte.


@ Joachim

Habe heute nachmittag deine Ergebnisse der Suche nach den beleuchteten Gletschern im Avsim Scenery Design Forum beschrieben - hoffe, dass ich das korrekt zusammengefasst habe: http://forums.avsim.net/dcboard.php?...id=18131&page=

Deutschland erwacht und ich gehe zu Bett ;-)

Cheers, Holger

Habe es gerade gelesen.

Danke

Stand heute morgen etwas unter Zeitdruck. Ich denke es ist ganz gut das ich eine Lösung für das Problem der leuchtenden Natur VTP2 Polys bieten kann. Denn mittlerweile berichten mehrere Designer von diesem Problem. Wenn man sieht das Du ihn im Prinzip jetzt bei dem Gletscher auch wieder hattest kann man erkennen das man sich den Bug sehr schnell einfangen kann.

Der Screenshot mit der Gletschergegend sieht (wenn man mal das Leuchten welches Du zwecks Demonstration des Bugs drin gelassen hast außen vor lässt) genial gut aus.

Weist Du etwas ob Jim das Tool Strip bzw. dessen Nachfolger offiziell veröffentlichen wird. Hier dürfte es keine Lizenzprobleme geben.
Reine Intereresse. Du erwähntest übrigends mal das es auch Küstenlinien beherschen wird oder bereits kann. Ist hier der Code performancefreundlicher. ( so das nur die benötigten Vectorpoints umgesetzt werden)

Ich habe übrigends eine Vermutung woher das eigentliche Problem der leuchtenden Nachtpolys rühren könnte. Denn es tritt ja wie gesagt nicht generell auf wenn VTP Polys mit LC Zuweisung von Texturen mit Nacht und ohne Nachttexturen vermischt werden.

Ob es allerdings eine effiziente Resourcen sparende Methode gibt um den Bug der vertikal gekippten Texturen bei LC Zuweisung über VTP2 Polys zu verhindern weis ich noch nicht. Schliesslich dürfen wir uns kein Speicherleck in Betracht der Auslagerungsdatei einfangen.

Wenn man aber bedenkt das fast alle User solche ADDON Scenerien betreiben (ev. ohne Wissen dieser Technik) und ihnen dieser Bug noch nicht aufgefallen ist, dürfte es nicht so tragisch sein.

Wenn ich Zeit gehabt habe wird ein Screenshot worum es geht angehangen sein. Dort wird man eine Landclasscenery eines Landclassfiles sehen mit Defaultbodentexturen wo die Texturnummer eingeblendet ist. Die Texturnummer ist ausgenordet und ist normal lesbar. Da wo sie auf dem Kopf steht wird eine Landclass nicht über ein Landclassfile sondern über ein VTP2 Poly zugewiesen.

Oben ist das VTP Landclasspoly eingebettet in eine Landclasscenery gleichen LC Types. Unten damit man es besser erkennt in einem normalen Landclassfile. Die Texturnummern sind direkt vorher in die Landclasstexturen von mir eingearbeitet worden.
Vorteil bei diesen VTP Polys ist übrigends das man theoretisch jede beliebige Form und Größe eines Ortes darstellen kann. Nachteil die Textur steht auf dem Kopf. Das ist zunächst mal nicht schlimm. Leider werden die Autogengebäude über ein zur Textur gehörendes eigenes Autogenfile zugewiesen. Dort werden quasi die Grundflächen der Häuser und Bäume definiert und positioniert. Dieses Autogenfile steht im VTP2 Fall leider nicht auf dem Kopf. Als Auswirkung davon stehen die Häuser und Bäume natürlich nicht mehr da wo sie hin gehören. Übrigends ein Problem welches auch bei FS Scene Texturen generell auftritt insofern man nicht eine Version besitzt die eigene Autogenfiles mitbringt. Bei den ersten Versionen gab es so was nicht. Kann sein das diese mittlerweile zum Lieferumfang gehören.

Diesen Bug habe ich neulich bei der Suche nach den leuchtenden VTP2 Nachtpolys entdeckt. Er gilt übrigends auch für den FS2002. (Damals kam die VTP2 Polytechnik aber noch selten zum Einsatz weil das SDK erst spät erschien) Für Fotoscenerien bei VTP2 Poly Zuweisung war der Bug schon länger bekannt. Für reine Landclass offensichtlich nicht. Bei Custom/Fotoscenery über VTP2 Polytechnik verwundert mich dieser Bug nicht da es nicht als offizielles Verfahren im SDK steht.

Bei reiner Landclasszuweisung bin ich überrascht da es ein offizielles Verfahren im FS2002 Terrain SDK ist. Auch der FS selbst hat dieses Problem bei seinen eigenen Airportpolys. Damit scheint es ein FS eigener Bug zu sein der nicht durch Designtools verursacht wird.

Da ich mir jetzt fast alle Hilfsmittel geschaffen habe um Landclass in alle Tiefen zu ergründen denke ich werde ich demnächst alle Bugs (Nachtpolys, CTD bei LC) aussortieren können. Auch ist jetzt eine Landclassdoku bis fast ins kleinste Detail möglich. Ein bischen fehlt mir noch. Im Prinzip könnte ich relativ schnell alle Steuertabellen des FS2004 aktuell für alle der sehr vielen möglichen Situationen erstellen. Also LC Nummer weist im Gebiet X die Texturserie A zu . Bei Meshsteigungen über Y Grad die Texturserie B. Bei Steigungen über Z Grad Texturserie C. Wird es mit Class Map =2 maskiert die Texturserie N usw. Dürfte mir jetzt alles schnell und effizient möglich sein.

Frage ist nur ob es noch Sinn macht. Aktuell denke ich würde es sehr viel Sinn für alle Designer machen. Nur das sind schon ein paar Stunden Arbeit. Wovor ich mich nicht scheue. Aber da gibt es eine Aussage in der aktuellen FXP Zeitschrift auf Seite 07 zum MyWorld Projekt von Burkhard Renk die mich zweifeln lässt.

"Beginnen wir bei den neuen Landklassen. Diese werden für die gesamte Welt nach neuesten Kartenmaterial und unter Verwendung von neuen Algorithmen, die die verfügbaren Daten noch besser umsetzen sollen nach den neuesten Vorgaben des FS2004 SDK erstellt......"



Nun weis ich nicht ob diese Aussage falsch gemacht wurde oder der Redakteur dieses ev. von Burkhard falsch interpretiert hat. Ev. ist mir etwas entgangen bezüglich SDKs.

Mir ist nämlich kein aktuelles SDK bekannt welches Neuigkeiten bezüglich Landclass des FS2002 bzw. gar dem FS2004 aussagt.

Nun ist es so das B.Renk offensichtlich einen sehr heissen Draht zu Microsoft haben muß. Denn er hatte damals auch schon mal eine Aussage zu dem späteren BGLCOMP.SDK gemacht. Da gab es das aber noch nicht. Entweder er hatte auch nur mal irgendwo was aufgefangen oder er ist Betatester und wird auch bei den kommenden SDKs im Vorfeld auf dem laufenden gehalten.

Jetzt ist nämlich für mich die Frage macht man sich die Arbeit wenn ev. schon nächsten Monat vieles über ein SDK aufgedeckt wird.

Da wäre die reine Fehlersuche sinnvoller.