Für RLUND unsichtbare Runway

[JOBIA]

Antwort auf ein paar Punkte

- Zur Landclass-Zusammenfassung finde ich toll, dass du anscheinend auf die Sdk wartest. Gut so.

nein da warte ich nicht drauf. Grund ist ich habe einfach momentan für so etwas keine Zeit. Ansonsten wird da bestimmt kein SDK zu kommen. Denn meiner Meinung gibt es hier aus Microsoftsicht kein Handlunsbedarf weil die Änderung nicht die Programmierung betreffen. Es sind einmal Fehler die bisher begangen wurden und es ist die Art wie die Grafikengine damit umgeht. Würde mich überraschen wenn da etwas kommen sollte.


- Zu Finkenwerder oder deiner simflyer Frage damals :Area16N schummelt sich anscheinend in der Priorität immer vor. Warum? Keine Ahnung.

Das hast Du bei Finkenwerder falsch interpretiert. Area16N Flatten muß die höchste Priorität über andere Flattentechniken wie z.B LWM2 und LWM3 Flatten haben. Wäre das nicht der Fall würden alle Airport ADDONS die von Default FS2002/2004 Flughäfen abweichen fehlerhaft dargestellt. Versinkende Flugzeuge usw.

Es war ein Klimmzug zwecks abwärts Kompatibilität zu Scenerien .

Den Bug den ich meine ist der, dass es bei zwei deckungsgleichen Scenerien die beide die alte Area16N Flattentechnik verwenden diesen Vertauschungsbug gibt.

Beispiel mal angenommen Finkenwerder wo das vermutlich zutrifft.

Nehmen wir mal an EDDH von GAP würde in der Bibliothek oben stehen und vom GAP Team auf 16m Höhe mittels alten Area16N Flattenbefehl positioniert. Finkenwerder würde auch als Schmankerl eine EDDH Scenery zusätzlich enthalten. Sei es das man nur zusätzlich etwas angepasst hat bei EDDH. Würde vom Finkenwerderteam jetzt für EDDH eine Flattenhöhe von 17m ebenfalls mit dem alten Area16N Flattenbefehl gesetzt hätten wir folgendes Problem.

In der Priorität würde EDDH GAP oben stehen. Wir sehen also otpisch die GAP Scenery. Die EDDH Scenery von Finkenwerder wird durch ein Exclude der GAP unterdrückt. Wenn der FS jetzt keinen Prioritätsfehler hätte würde auch der Flattenbefehl von GAP aktiv sein. Da der FS hier aber einen Vertauschungsfehler hat arbeitet die GAP jetzt nicht mit Ihrer Flattenhöhe von 16m sondern mit der von Finkenwerder EDDH also 17m. Folglich würden bei diesem Beispiel die Gebäude um einen Meter einsinken da diese in der Regel Ihre eigene Höhe mitbringen. Wären die Höhenangaben umgekehrt würden sie schweben.


Das es so ist habe ich Anfang letztes Jahr rausgefunden als ich mich mit der damaligen Bodenpolyflackerproblematik im FS2002 beschäftigt habe. Das es so ist habe ich anhand eines Testfiles welches man damals in der Doku downloaden konnte demonstrieren können. Hier waren es gar 3 sich überlappende Area16N Flattenpolys da konnte man sehen das immer die niedrigste Scenery Ihre Höhe durchsetzt dann kommt die mittlere Scenery und dann die höchste. Also alles genau verkehrt.



Weiterhin gibt es natürlich noch die Priorität der verschiedenen Flattentechniken untereinander.

Sie lautet niedrigste Priorität LWM2 Flatten des FS2002, dann LWM3 Flatten des FS2004, dann Area16N Flatten (welches wir bisher in fast allen Airportscenerien bisher noch vorfinden).

[Horst LOWW]

- Landclass Zusammenfassung.

Ich habe dies eigentlich nur so interpretiert, da der FS9 etwas anfälliger ist (CTD), und nach Veröffentlichung der verschiedenen SDK s, hier vielleicht eine Erklärung zu finden ist.

- Area16N

Da ich eben zuletzt auf Greenwoods Seite dies gelesen habe:
http://www.fs-traveler.com/flatten.shtml
wollte ich eigentlich nur sein Tool ausprobieren. Bei mir habe ich leider immer einen Laufzeitfehler. Er findet anscheinend den Flusi Ordner nicht. Egal einstweilen, man kann es ja auch anders machen

Und da kam mir deine ältere Erklärung wieder in den Sinn.
Hat man eben verschiedene Szenerien von verschiedenen Autoren auf engen Raum, führt dies zu Konflikten. Man kann die Priorität ja nicht in der scenery.cfg festlegen.
Area16N schwindelt sich ja dann auch vor. Vorteil und Nachteil, je nach Anwender.

Genauso Greenwoods-Erklärung hier:
http://www.fs-traveler.com/priority.shtml
für mesh-Daten.
Hier habe ich leider auch keine Möglichkeit die Priorität über die scenery.cfg festzulegen. Und es kann eben zu Konflikten kommen, mit der Auswirkung das ich Daten eben nicht sehe, bei Überschneidungen von verschieden meshdaten bzw. auf kleinem Raum.

In beiden Fällen ist es für Autoren ja wirklich schwer oder unmöglich, einen Update anzubieten, der dies alles berücksichtigt und jeden Anwender hilft.
Daher ist es für mich wichtig, dass diese Daten, wenn möglich, eine eigene bgl haben, die ich auch leicht identifizieren kann, und anschließend für meinen Flusi richtig verschiebe.

Es gibt ja auch bei den Szenerien, gute Daten oder Gebäude, wo der Autor bereits aufgehört hat. Bzw. wegen mancher idiotischen Anwender aufgegeben hat. Und diese Daten muss man ja auch nicht immer wegwerfen.

Daher finde ich deine Antwort für die sinnvolle Frage von Martin Georg bezüglich LC Daten gut.

- AutoAsm

Werde ich wie geschrieben, in den nächsten Tagen ausprobieren.
Da es vielleicht auch das Werkzeug ist, mit dem man in Verbindung mit LWMViewer die Originaldaten bezüglich Mesh ändern kann.
Daher hoffe ich, dass es irgendein Tool geben wird, mit dem man diesen Code entfernen kann, und eine eigene excl.bgl erstellen kann. Sonst wird es nämlich abenteuerlich zu gehen in Zukunft.

Ansonsten derzeit kein Aufklärungsbedarf, außer ich habe etwas falsch dargestellt.

Horst

Übrigens der Verweis auf Greenwoods Seite soll keine Werbung für sein Produkt sein, ich kenne es weder, noch kann ich es beurteilen. Aber ich bin ihm äußerst dankbar, dass er Erklärungen auch öffentlich zugänglich macht.

[JOBIA]

Hat man eben verschiedene Szenerien von verschiedenen Autoren auf engen Raum, führt dies zu Konflikten. Man kann die Priorität ja nicht in der scenery.cfg festlegen.


Area16N schwindelt sich ja dann auch vor. Vorteil und Nachteil, je nach Anwender.

Ja eben das ist genau das Problem bei Area16N Flatten. Man muß dann die Area16N Flattenpolys der niedrigeren Scenerien die den gleichen Airport betreffen deaktivieren oder in eine andere Priorität schieben. Kein Problem könnte man jedem noch halbwegs erklären. Aber damals im FS2002 beim Flackerproblem in LOWS war das nicht möglich da bei der ATP Scenery alle Area16n Flattenpolys aller Airports in einem File waren. Da hat man dann keine Chance. Man kann ja schlecht irgendjemand ein File anbieten wo man selbst keine Rechte dran hat. War halt unglücklich das alle in einem File waren. ich möchte nicht wissen wieviele Designer diesen Bug überhaupt nicht kennen. Er tritt ja nur auf wenn zwei ADDONs unterschiedliche Höhen haben und beide auf Area16N Flatten beruhen.

Genauso Greenwoods-Erklärung hier:
http://www.fs-traveler.com/priority.shtml
für mesh-Daten.
Hier habe ich leider auch keine Möglichkeit die Priorität über die scenery.cfg festzulegen. Und es kann eben zu Konflikten kommen, mit der Auswirkung das ich Daten eben nicht sehe, bei Überschneidungen von verschieden meshdaten bzw. auf kleinem Raum.

Ja genau ist das Problem z.B beim alten Lago Mesh es ist oversampled hat im Prinzip überhaupt nicht so eine hohe Dichte der Höhenpunkte drängelt sich aber trotzdem immer vor. Vor das Genesis Mesh aber bestimmt nicht denn wenn da TMVL22 empfohlen wird dann muß das ja in Teilbereichen mindestens LOD 11 oder mehr haben.

[Horst LOWW]

- Mesh

Die Daten und deren Auflösung (und natürlich auch die Überlappung) wird leider, auch in den nächsten Versionen des FS bleiben. MS kann und wird sie wahrscheinlich aufgrund der Datenmenge weltweit nie anbieten. Daher sind hier die Erzeugung und die Möglichkeit des Downloads für Jedermann sehr wichtig. So wie bei SRTM, daher hat man einen gewissen Standart oder Fehler. Man muss eben nach Möglichkeiten suchen, wie man diese Löcher stopft.
Wenn dies weltweit geschieht, finden sich sicherlich, eben wie bei AFCAD, Bastler die ihre Heimat vielleicht relativ einfach ergänzen, und dies geschieht dann relativ rasch. Und andere stört dies vielleicht nicht. So erhält man relativ einfach eine schöne, vielleicht realitätsnahe Mesh-Welt.
Siehe auch die Arbeit von Joe hier:
http://forums.avsim.net/dcboard.php?...7146&mode=full
Er bastelt, findet derzeit einen guten Ansatz, und dann kommt die oben genannte Problematik

- AutoAsm

Dazu hätte ich jetzt eine Bitte.

Kannst du eventuell eine kleine bmp (oder mehrere) anhängen, die deine Bedenken darstellt? Dann würden wir einstweilen die selben bmp verwenden.

LA habe ich bereits überflutet, und bin darin herum „gekurvt“ (und ein wenig mit Werkzeugen verglichen). Die anderen werde ich in nächster Zeit machen.
Dies geht bei mir nur Schritt für Schritt, da ich zum Großteil die Fehler des Programms, und natürlich vorallem meine, und deren Auswirkungen, zum Teil selbst herausfinden möchte. Dadurch lerne ich am meisten, und vielleicht ist es besser so.
Außer dir sind Fehler bekannt.

Falls ein Mitlesender Interesse hat, was man mit einem Knopfdruck machen kann, hänge ich die notwendigen Dateien an. (32kb für Los Angeles). Derzeit nur ein Beispiel: Küstenlinien und Wasser in LA-Stadtgebiet. Hat aber mit der Realität nichts zu tun.

Horst

[BC_Holger]

Hallo zusammen:

eigentlich wollte ich ja auch autoasm ausprobieren, aber dann hat mir gestern jemand ein alternatives Tool in der Betaversion zugeschickt, dass mich heute beim Testen total umgehauen hat.

Es ist etwas "engstirniger" als autoasm, da es "nur" Mesh, Kuestenlinien und LWM Wasser erstellen kann (dazu noch ein hoehenabhaengiges Landclassmodell), aber die Rohdaten (Mesh) sind frei verfuegbar und koennen direkt verwendet werden oder nach gewuenschtem editieren. Ein paar Parameter in einer .inf Datei auswaehlen und dann das Tool laden und zuruecklehnen. Das Ergebnis ist nicht ueberall 100% perfekt, aber wenn das Mesh stimmt, sieht das Ergebnis extrem gut aus und der Rest kann von Hand nachgarbeitet werden.

Habe ein Alaska-Bild im folgenden Post angehaengt; weitere Einzelheiten folgen, sobald ich naeheres vom Autor hoere.

Ciao, Holger

http://forums.avsim.net/dcboard.php?...id=18770&page=

P.S. Besten Dank, Joachim, fuer den ausfuehrlichen Testbericht zu autoasm.

[JOBIA]

Zu Holger

Mit dem Mesh ist es immer so eine Sache. Also SRTM Rohdaten in den Alpen hauen mich überhaupt nicht um. Wenn ich da SRTM höre kommt mir immer das Grauen.

Aber lassen wir Mesh außen vor. Woran erstellt das Tool die LWM Gewässer und Küsten?

Höhenanhängiges Mesh Modell. Wie darf ich denn das verstehen. Vermutlich so das anhand der höhe typische Bewaldung, Gebirge oder Schnee positioniert wird?

Das konnte übrigends auch schon Burkhard Renk sein FS Landclass.

Aber wie gesagt diese Geschichte mit Gewässern ist interessant.

[JOBIA]

Hallo Horst und andere (User/Designer) die ev. mal mit Autoasm rumgespielt haben.

Ist ev. interessant da mit diesem Tool ev. die Möglichkeit besteht halbwegs effizient zu einem Straßensystem oder ähnlichem für Deutschland und andere Länder zu kommen.

Zunächst mal zum Problem das bei mir Autoasm Fehler im LWM Poly Code erzeugt. Ich habe z.B immer bei dem mitgelieferten Demoprojekt TS_demo zusätzliche LWM Gewässer in Area 4, 22 der Cells in denen Autoasm regulär richtiges Gewässer aus der TS_demo.bmp ausliest.

Die dazugehörigen VTP2 Uferlinien werden jedoch korrekt erzeugt. Ich gehe daher davon aus das Autoasm selbst zunächst richtig ausliest. Denn sonst müsste es bei VTP2 auch fehlerhaft sein. Irgendwie stimmt hier die Routine für LWM nicht. Fakt ist an den Macros von Richard Ludowise kann es nicht liegen. Denn der Fehler ist in der ASM Datei bereits vor der Kompilierung in die BGL erkennbar. Bei diesem Demofile sind diese zusätzlichen falschen LWM Flächen immer identisch hinsichtlich Vectorpoints. Der Rasterabstand also der Abstand zwischen den Vectorpoints bei VTP2 und LWM ist identisch, nur die Zählweise ist anders, das dürfte für Chris demnach eigentlich dann kein Problem sein. Den wesentlichen Unterschied sehe ich aber bei LWM das man immer die zusätzlichen Eckpunkte der Areaflächen berechnen/definieren muß insofern das LWM Poly Area übergreifend ist. Weiterhin das man um den Crash to Desktop bei Area Fill 1x1 Befehlen zu verhindern, anstatt des Area Fill Ersatzpolys berechen muß. Ich vermute daher das bei diesen oben genannten zusätzlichen Berechnungen etwas in die Hose geht.


Das Projekt selbst ist in Autoasm wie gesagt mitgeliefert. Die Daten sind von Chris voreingestellt so das man hier eigene Fehler quasi ausschliessen kann. Hätte ich was neues gemacht wäre ich zunächst davon ausgegangen das der Fehler bei mir liegt. So vermute ich eher am Programm. Daher würde es mich interessieren wie es bei Dir Horst bzw. bei anderen aussieht die das mal probiert haben.

Ich denke der Rainer hat doch bestimmt auch schon mal mit Autoasm rumgespielt.

Damit Ihr seht was ich meine siehe das Bild im Anhang. Hier habe ich aber aus Platzgründen gleich mehrere Sachen untergebracht. Für das geschilderte Problem zählt der Bereich oben links. Fehlerhafte Flächen bei TS_demo die eigentlich nicht existieren dürften siehe roter Pfeil. Selbstverständlich findet man diese fehlerhaften Gewässer dann auch im FS2004 wieder.

Könnt ja mal checken wie es bei euch aussieht. Wie gesagt ich habe es so wie es der Chris als Demoprojekt angelegt hat laufen lassen. Ich habe an dem Projekt auch schon alles mögliche geändert leider bleibt das Problem unverändert bei diesem TS_demo Projekt inkl. TS_demo.bmp von ihm. Wobei die TS_demo Bitmap von ihm bis auf das wo er drauf hinweist sauber ist. Man kann im Fenster auch erkennen das diese problematischen Bereiche nach dem auslesen noch nicht existieren. Erst wenn er mittels der ausgelesenen Points den ASM Code erzeugt entstehen diese Fehler. Was auch kurios ist, dass diese zusätzlichen Polys außerhalb des Bereiches erzeugt werden den seine Bitmap laut Definition koordinatenmäßig nicht abdeckt.

Irgendwie wird das dazu gemauschelt. So ein Fremdobjekt (dann allerdings in anderer Form) entsteht bei mir auch bei eigenen Projekten. Hier war die Bitmap allerdings absolut sauber. Auch meldete das Diagnose Tool keine Fehler. Alles was aus einer Sicht Probleme bereiten könnte habe ich in der Bitmap verhindert. Trotzdem taucht bei mir wieder eine zusätzliches falsches LWM Poly auf. Erst hatte ich gedacht es ist irgend eine LWM Fläche die im Projekt an anderer Stelle irgendwo ev. auch als Teil einer großen Fläche vorkommt. Dem ist aber nicht so. Auch wenn man es als Negativform auslegen würde passt es nirgends dran. Sehr seltsam das ganze.

Sollte das ein Trick eine Art Signatur von ihm sein, das erkenntlich wird die Scenery ist mit Autoasm erzeugt worden? Da es Freeware ist denke ich nicht das dieses der Fall ist.

Diese Problematik wäre aber zu verkraften. Wenn man sein Projekt kennt, könnte man dieses aus dem ASM Code entfernen und neu kompilieren.

Wie gesagt ev. stimmt an meinem PC mit dem ich getestet habe etwas nicht. Ev. ist auch ein Fehler im ZIP File gewesen. Deshalb würde es mich interessieren ob es bei euch bei dem mitgelieferten Demoprojekt TS_demo auch auftritt.

Kommen wir zum nächsten Problem.

Lassen wir dabei die Problematik der aufwendigen Bitmap Vorbereitung außen vor. (ein weiterer Grund der das schnelle automatische erstellen von Bodenscenery etwas behindert. Es sei denn man hat geeignetes Rohmaterial)

Kommen wir zu der anderen Geschichte wo ich momentan sagen würde: "Das was bei mir hinten aus Autoasm rauskommt ist nicht tauglich da es performance verschwendender Code ist".

Da brauche ich auch keine Bitmap zu liefern Horst. Erzeuge Dir eine Bitmap 8Bit Farbtiefe mit einem nackten 1 Pixel breiten geraden Strich der 100 Pixel lang ist.

Wie gesagt da reichen für den FS hinterher von der Theorie her zwei reine Vectorpoints für aus um so eine Linie darstellen zu können. Die Thematik Cell übergreifend, Anfangspunkt usw. außen vor.

Ich habe schwarz als Hintergrund und rot als Strich in der Bitmap. Es liegt damit im Vorgaberahmen von Autoasm. Was dabei rauskommt sieht man im Bild im Anhang. Hier die untere Hälfte des Bildes.

[JOBIA]

Erkennbar das Fenster von Autoasm. Unten die rote Linie die aus der Bitmap ausgelesen wurde. Das die Punkte nicht ganz auf der Linie liegen hängt mit dem Masstab zusammen weiterhin mit den Paramatern die man bei der Liniendefinition vorgeben kann. (Interpolation durch Autoasm usw.) Egal was ich hier noch manipuliere es werden immer die 100 Pixel ausgelesen. Deckt die Bitmap hinsichtlich Koordinaten nur eine kleine geografische Fläche ab sind die Vectorpoints förmlich aneinander gequetscht. Man findet dann auch identische X/Y Werte vor. Irgendwie versucht das Programm zwingend alle Pixel der Bitmap im BGL Code unterzubringen.

Ein Beweis das man da 100 Punkte sieht bzw. das Autoasm diese aus der Bitmap ausgelesen hat sieht man durch das geöffnete Diagnosefenster. Hier steht drin das 1 Polygon erkannt wurde welches aus 100 Points besteht. Eine Fehlermeldung steht hier nicht, also ist die Bitmap OK. Kann man ja auch nicht viel falsch machen bei einem geraden Strich.

Bis hierhin ist noch alles OK würde ich mal sagen. Jetzt lässt man den VTP2 Linien Code für diese Straße erzeugen. Sinnvoll wäre wie gesagt wenn jetzt eine Routine Richtungsänderungen der Points der Linie überwacht. Erkennt es das hier keine großen Änderungen vorhanden sind könnte es jetzt anhand des Masstabes der Kartenbitmap entscheiden ob sie Vectorpunkte aus dem Code rausschmeisst da es sich eh um eine gerade Strecke handelt.

So wäre das Tool in der Lage bei einer langen geraden Strecke wie das bei mir der Fall war den Code auf den wesentlichen Anfangs und Endpunkt abzumagern. Aus 100 Points würden dann zwei. Man stelle sich das vor bei 1000 Points. 1000 zu 2 wäre schon gigantisch.

Allerdings muß ich zugeben das mit der Überwachung ist nicht so einfach. Ist die Linie vertikal oder waagerecht ist es einfach hier muß man zwischen den Punkten nur überwachen ob entweder der X oder der Y Wert konstant bleibt. Ist das der Fall handelt es sich um einen Vectorpoint der ev. ausgelassen werden kann. Ob das so ist kann man aber nur wissen wenn man den nächsten auch schon mit überwacht und in die Berechnung mit einbezieht bevor man entscheidet raus damit.

Schwierig wird es aber wenn die Linie nicht vertikal oder horizontal läuft sonder diagonal oder gar in beliebigen Winkel. Ja dann wird es richtig schwierig eine gerade Linie zu erkennen. Zum einen weil es bei beliebigen Winkeln einer geraden Strecke technisch gar nicht möglich ist das diese immer eine konstante Änderung der X/Y Werte zur Folge hat. Das sieht man sehr schön wenn man sich eine 1 Pixel breite Linie in einem Fotoprogramm malt. Fazit man muß hier dann vermutlich zusätzlich noch mit Winkelfunktionen rumdoktern.

Dieses bedeutet auch das hier Autoasm gewisse Toleranzen zu lassen müsste um einen performancefreundlichen Code zu erzeugen. Das ganze ev. abhängig vom Masstab.

Um dieses alles realisieren zu können wird eigentlich eine Art Matrix benötigt so das man auf alle Pixel einer Bitmap direkten Zugriff hat um Berechnungen durchzuführen.

Da Autoasm sehr große Bitmaps zulässt denke ich könnte diese Auswertung vermutlich zum scheitern verurteilt sein. Ev. ist das auch der Grund warum es diese Routine nicht gibt.

Ev. habe ich auch Autoasm nur falsch bedient. Daher würde es mich interessieren ob hier jemand Erfahrung mit gemacht hat. Übrigends der Beweis das zumindest bei mir so eine Routine (die in der Dokumentation auch nicht erwähnt wird) bei Autoasm nicht arbeitet sieht man oben rechts.

Ein Screenshot aus dem HEX Editor. Hier habe ich nach Vectorpoints im ASM File gesucht. Bei Liniencode nennt sich der Befehl für einen Vectorpoint

VTPWidePoint mit den entsprechenden Vectorkoordinaten also z.B VTPWidePoint 10235, 0, 11136, 0

Nach diesem Befehl habe ich mit dem HexEditor im entsprechenden ASM File gesucht und ihn zählen lassen. Das Zählergebniss kann man im Informationfenster sehen. 100 mal hat er den Befehl gefunden. Wir erinnern uns meine Linie in der Bitmap hatte 100 Pixel.

In der BGL ist das auch der Fall. Auch hier sind die 100 Vectorpoints enthalten. Zwei Vectorpoints hätten gereicht um diese Linie/Straße zu beschreiben.

Sollte mir kein Fehler unterlaufen sein (ich hoffe das ich einen gemacht habe) dann ist die Funktion von Autoasm gewährleistet. Nur der Code ist halt nicht so prall.

Die Frage ist was passiert dann bei einer großflächigen Scenery.

Da der FS ja selbst versucht die Performance dynamisch durch abschalten bzw. runterfahren von Details zu beeinflussen ist eine Beurteilung gar nicht mal so einfach. Der User bemerkt ev. gar nicht das ein Mesh im Hintergrund in der Tiefe des Raumes an Auflösung verliert. Ev. sieht er auch nicht das Texturen im Hintergrund eher in einen niedrigen Mip Level geschaltet werden.

Im Prinzip merkt man alles erst wenn der FS in seine Grenzbereiche kommt.

Ein vernünftiger aussagekräftiger Test wäre eigentlich nur bei einem längeren sich wiederholenden Flug unter identischen Vorraussetzungen möglich.

Dabei müste dann nicht nur auf Frames geachtet werden sondern auch ob Details sich verändern. Der Test selbst müßte mit einer reinen Autoasm Scenery erfolgen die einmal original ist und einmal in einer Version bei der Polys und Linien auf das nötigste abgemagert wurden.

War mal wieder etwas länger. Ich denke aber das hier auch immer Designer mitlesen das weis man ja. Ich glaube es kann nur im Interesse aller sein wenn es ein Tool gäbe mit dem man halbwegs schnell komplette Straßensysteme oder ähnliches für z.B Deutschland erstellen könnte.

[JOBIA]

Noch mal kurz zur Bitmap im Anhang:

1) Oben links der Bildausschnitt. Hier bei den roten Pfeilen sieht man die LWM Gewässerpolys die bei mir zusätzlich entstehen bei dem mitgelieferten TS_demo Projekt.

2) Untere Hälfte. Das allgemeine Autoasm Fenster in dem man die ausgelesenen Points meiner Bitmap ( mit einer 100 Pixel langen geraden Linie) sehen kann. Als Beweis das eingeblendete Diagnosefenster welches diese 100 Points bestätigt.

3) Oben rechts der Bildausschnitt vom Hex Editor mit geöffneter ASM Datei. Dieser bringt den Beweis das bei dem von Autoasm erzeugten ASM Code diese Points auch später mit in die BGL kompiliert werden.

Wie gesagt bei den Polys verhält sich das im Prinzip genauso wie bei den Linien.

[BC_Holger]

Hallo:

ja, die SRTM-Rohdaten in alpinen und ansonsten stark reliefierten Gebieten sind schon nicht einfach zu bearbeiten. Fakt ist aber, dass sie fuer die meisten Gebiete ausserhalb Nordamerikas das Beste sind, was derzeit zu haben ist.

Die vielen kleineren Loecher von ein paar hundert Metern Durchmesser kann man problemlos interpolieren; digitale Gelaendemodelle sind ja generell nix anderes als von regulaer oder sonstwie angeordneten Hoehenpunkten interpolierte Rasterdateien. Zum stopfen der groesseren Loecher gibt es durchaus sinvolle Alternativen, die allerdings ein brauchbares GIS benoetigen. Eingige der Methoden haben wir schon im Avsim Mesh Design Forum besprochen - und dieser Thread ist ja auch gar nicht ueber SRTM.

Das mit der 1:1 Umsetzung von Bitmap-Linien in autoasm ist ja schon etwas unguenstig; hoffe mal, dass Chris dazu kommt, eine Generalisierungsmethode einzubauen (Douglas-Peucker laesst gruessen?).

Das von mir angesprochene Tool benutzt direkt ein Roh-mesh in .tif oder FS Resample Format und extrahiert die Kuestenlinien entlang der 0-m Linie, uebrigens mit frei einstellbarer Generalisierung. Ab und zu "verschluckt" sich der Algorithmus noch und produziert Inseln oder Meer wo es nicht sein sollte, aber das Tool (Codename "Strip") ist ja auch erst im Beta-Zustand.

Seen und Fluesse werden ueber frei waehlbare Startpunkte automatisch erzeugt. Seen "fuellen" das Gelaendemodell bis zur vorgegebenen Hoehe und Fluesse suchen sich ihren Weg selber entlang der Tiefenlinie. Offensichtlich sind diese beiden Optionen etwas aufwendiger als die Kuestenerstellung und auch sehr stark von der Qualitaet des Gelaendemodells abhaengig. Wahrscheinlich ist hier eine Kombination von Strip, autoasm und Ground2K4 eleganter.

Die automatische Erstellung der Land- und Wasserklassen erschien mir zunaechst als Gag, ist aber doch ganz clever. Man erstellt eine einfache Hoehentabelle mit Klassenzuwahl und Strip tut den Rest. Fuer stark bebaute Gebiete ist das Ergebnis wenig sinnvoll aber in Wildnisarealen, wie mein Beispiel von der Kueste Alaska, ist die so erschaffene Landclass-Datei, abgesehen von den fehlenden Kuestengletschern, ein deutlich besserer Startpunkt als die Default Landclass. Ausserdem erzeugt Strip automatisch die .raw und .ezl Dateien zur weiteren Bearbeitung in EZ-Landclass oder Ground2K4.

Waterclass ist aehnlich, hier koennen z.B. verschiedene Texturen fuer Gebirgsbaeche, Mittelgebirgsfluesse, und Tieflandgewaesser erzeugt werden. Grob, aber sinnvoll.

Zurueck zum testen. Heute ist Patagonia an der Reihe; mal sehen, wie sich Strip bei SRTM-Daten verhaelt...

Cheers, Holger