|
Für RLUND unsichtbare Runway
Hier ein Beispiel von mir. Die unsichtbar programmierte Runway ETSM Memmingen. Nur die Anflugbefeuerung habe ich als Beweis für die Existenz der Runway sichtbar gelassen. Aber auch dieses könnte deaktiviert werden. Es ist alles neue Airporttechnik über AFCAD2. Allerdings noch die erste AFCAD2 Version. AFCAD2 selbst unterstützt die Technik unsichtbar nicht. Ich meine ich habe das damals mit dem Hex Editor gemacht. Ev. ist das bei der neuen Version implementiert. Ich vermute aber nicht da es keine offizilelle Geschichte ist. Muß mal schauen ob ich mir was aufgeschrieben habe wo das entsrechende Byte im Code sitzt. Werde das wenn ich Zeit habe mal mit der aktuellen AFCDAD2 Version von letzter Woche testen.
Im Prinzip könnte man auf diese Weise Bodenscenery komplett mit ILS, Anflugbefeuerung jeglicher Art, Taxilines , AI Traffic machen ohne die FS2004 Texturen als sichtbare Oberfläche zu nutzen. Bei geflattetem Airportboden könnte man jetzt Fotoscenery mit extrem hoher Auflösung als Bodenscenery verwenden. Bei unebenen Boden eben nur mit ca. 4,7m pro Pixel. Der neue Runwaybefehl des FS2004 hat ein paar Vorteile gegenüber dem des FS2002. Er hat zum Teil das Verhalten des FS2000 Befehles darüber möchte ich aber noch nicht plaudern mir fallen da ein paar schöne Zaubereien ein. Hier das Bild im Anhang: |
Hallo Joachim:
bin wieder im Lande... Habe mich gestern und heute mit dem Transfer meiner FS2002 AI Helikopter und Wasserflugzeug Files befasst, da es in letzter Zeit vermehrt "geht nicht" Kommentare gegeben hat. Klappt aber doch alles wunderbar und das neue AFCAD 2.21 ermoeglicht das Unsichtbarmachen von allen Szenerieteilen - man braucht also keinen Hex-Editor mehr. Daher sind unsichtbare Heliport- oder Wasser-Overlays ohne Probleme zu erstellen. Mein "Test-Bericht" findet sich hier: http://www.flightsimmer.com/forums/s...&threadid=7939 und ein paar Screenshots hier: http://www.flightsimnetwork.com/dcfo...D21/11325.html Ab morgen dann aber wieder zurueck zur Ground2K4-Arbeit. Ich werde meine Projektdateien nochmals mit der neuesten Version kompilieren; mal sehen, ob sich was am "Weihnachtsgletscher" aendert. Ciao, Holger |
Nachdem ich eine computer- und internetlose Zeit hinter mir habe (eigentlich auch sehr angenehm), darf ich jetzt wieder sehr, sehr viel nachlesen und aufarbeiten (bis mein Hirn raucht) und manchmal meinen „Senf“ dazugeben.
Als die BGLcomp_SDK erschienen ist, habe ich damit etwas „herumgespielt“, und für mich einige Ungereimtheiten gefunden (in der SDK selbst). Deshalb habe ich dies auch versucht mit diesem Artikel auszudrücken: http://www.wcm.at/forum/showthread.p...t=Auswirkungen ohne vorher damit weiter zu forschen. Ich dachte halt, etliche Antworten werde ich später finden. Und etliche Antworten auf meine Fragen, habe ich jetzt im Avsim Scenery Design Forum nachlesen können. Danke an alle Bastler, man erspart sich manchmal viel Arbeit, wenn man das „Kastl“ eine zeitlang nicht aufdreht. Ich finde es nämlich sehr wichtig, wie eben Daten kompiliert werden (natürlich!), und habe damals den Zusammenhang zu verschiedenen Werkzeugen gesucht. Es gibt eben neue Parameter z.B in der terrain.cfg, die richtig interpretiert werden wollen. Abgesehen von den Fehlern, die jeder Anwender durch Unkenntnis selbst erzeugt. Auch den Hinweis in der SDK auf die makemdl (wird auch sicher bald erscheinen), eben über das Mdl Format, finde ich sehr wichtig. (erklärt vielleicht auch den CTD bei Flugzeugwechsel). Zu dem Thema hier: Heißt dies, dass ich sozusagen auf jedem Terrain eine Landebahn erzeugen kann? Oder braucht diese unbedingt einen Flattencode? Und noch ein paar Fragen: - Gibt es Kenntnis, ob in der neuen Version von AFCAD 2.21 auch die Kompilierung anders ist? (obwohl ich mit Lee Swordys bisheriger, großartiger Arbeit bei mir noch keinen Fehler finden konnte) - „spielt“ jemand mit Chris Wrights AutoAsm herum? Und ist dies eventuell ein Werkzeug mit dem man sich ein „Gesamtpaket“ für ein größeres Gebiet (Wasser, Straßen, Eisenbahn usw.) erzeugen kann? - Gibt es neue wichtige Erkenntnisse seit Weihnachten, die ich vielleicht überlesen habe? Horst |
Zu Holger
Ja das Du mit der aktuellen Ground2K Version noch mal Deine Projekte neu kompilierst hätte ich auch vorgeschlagen. Ich hatte hier im Forum diesbezüglich vermutet das die Routine die bei Ground2K die gezeichneten Flächen in Polys zerlegt Fehler verursacht und meiner Meinung nach zu aufwendige Polys erzeugt. Würde man das von Hand im Kopf machen käme da etwas besseres bei raus. Leider ist das über eine mathematische Routine doch recht komplex umzusetzen das gebe ich zu. Rainer Duda antwortete aber darauf das eben diese Routine bei Ground2K jetzt geändert wurde. Deshalb habe ich mir bevor es mit der neuen Version nicht gecheckt ist keine weiteren Gedanken über das Problem gemacht. Kannst ja mal hören lassen ob es mit dieser Version ohne Fehler klappt. Zu AFCAD2. Das man unsichtbare Taxiways erzeugen kann im Prinzip nur mit der Mittellinie usw. ist klar. Aber eine Runway direkt in AFCAD2 ohne jeglichen Oberflächenbelag wie Asphalt, Beton oder Dreck das wäre mir neu. Ich habe nichts dergleichen bei AFCAD2.21 gesehen. Es sei denn ich habe etwas übersehen. Welche Runwayoberfläche soll denn als Platzhalter dafür stehen, das man praktisch nur die Landclasscenery sieht. Ich habe es wie gesagt damals doch mit dem HexEditor gemacht. Es geht wie gesagt darum das man z.B Anflugbefeuerung in FS2004 Technik nutzen möchte (das erfordert zwingend eine Runwaydefinition)die Runway selbst aber optisch vom Belag her nicht vorhanden sein darf. Es geht hier nicht um Löschfunktionen für Runways oder ähnlichen. zu Horst im Prinzip benötigt sie kein Flatten. Man kann sie auf jedem Terrain einsetzen. Sie hat keine feste Oberfläche mehr wie der FS2002 Befehl. Sie verhält sich ähnlich wie der erste alte Runwaybefehl. Der Boden müßte natürlich smooth gemacht werden so das es nicht staubt wenn man Asphalt VTP2 Polys drunter legt. Das wäre ideal für schräge Runways da man die Anflugbefeuerung trotzdem definieren kann. Bisher hat man ja darauf verzichtet und bei schrägen Runways in der Regel auf VTP2 Polys allein zurückgegriffen. Man könnte auf beiden Seiten Anflugbefeuerung einsetzen auch wenn diese unterschiedlich hoch sind. Man müßte dann einfach zwei kurze Runways definieren. Probleme hätte man dann aber wenn die seitliche Beleuchtung über die ganze Länge der Runway gehen sollte. Ev. könnte man das dann abfangen indem man die Runway aus mehreren Runwaysegmenten aufbaut. Aber man bedenke folgendes. Es ist bisher nur Theorie die ich nur in Teilen getestet habe. Ich denke es wird auf jeden Fall Probleme geben wenn man auf diesem Airport AI Traffic einsetzen möchte. Ich weis nicht was der macht mit unterschiedlichen Höhenangaben. Ev. Hopserei. Ich denke zu viele Segmente sind performance störend. Zu Auto ASM. Habe mir das neulich mal durchgelesen. Planen tue ich zumindest momentan nichts. Einfach zu wenig Zeit. Problematisch sehe ich bei diesem Tool das man eigentlich dafür sorgen muß das ein Straßensystem im Prinzip so vorbearbeitet werden muß das die einzelnen Linienenden keine Verbindung zu einander haben dürfen. Auch das eine Linie auch an Kurvenradien/Ecken immer nur ein Pixel breit sein darf wenn ich das richtig verstehe. Gut ist eigentlich auch logisch. Ich hatte als das FS2002SDK rauskam auch mal eine Routine geschrieben die automatisch Vectoren aus einer Bitmap ausliest. Hier ging es aber um geschlossene Formen wie Polys. Bei Linien in einer Bitmap weis man ja nie welcher Pixel mit welchem verbunden werden muß. Ich denke das wird bei Autoasm der Grund sein das man sie auftrennen muß. Das bedeutet viel Vorarbeit bei der Rohdatenbitmap die ausgewertet werden soll. Ich denke viel kann man da mit einem guten Photoprogramm abfangen. Als ich damals mal Landclass über Photopaint automatisch programmiert habe, nutze ich dort auch die Funktion von wachsenden und schwindenden Masken usw. Da kann man schon einiges machen. |
@ Joachim
Verstehe. Muss mit beiden Sachen etwas mehr herumspielen und ausprobieren. Bei Afcad mit Phototexturen und bei AutoAsm mit dem Rohdatenbitmap. Vielleicht kommen ja Ideen, die von Designern in ihren Scenerien umgesetzt werden können. Auch ich habe leider immer chronischen Zeitmangel für meine Freizeitbeschäftigung, daher werde ich fertig sein, wenn der FS10 erscheint. Horst |
Nur zur Info. Zu meinem Text und Bild mit dem unsichtbar machen von Runways bei Erhaltung von Anflugbefeuerung usw.
Hier schrieb Holger: "Habe mich gestern und heute mit dem Transfer meiner FS2002 AI Helikopter und Wasserflugzeug Files befasst, da es in letzter Zeit vermehrt "geht nicht" Kommentare gegeben hat. Klappt aber doch alles wunderbar und das neue AFCAD 2.21 ermoeglicht das Unsichtbarmachen von allen Szenerieteilen - man braucht also keinen Hex-Editor mehr. Daher sind unsichtbare Heliport- oder Wasser-Overlays ohne Probleme zu erstellen." Habe mich über Mail mit Holger unterhalten, da er diesen Thread nicht weiter verfolgt hatte. Er hatte es wohl falsch interpretiert. AFCAD2 beherscht diese Technik für Runways nicht. Damit sind diese Tricks auch weiterhin nur über HEX Editor möglich. Früher konnte man den Trick im SCASM Code direkt anwenden. Bei AFCAD2 kommt man aber an nichts dran. Nur über das neue BGLCOMP SDK sehe ich da Möglichkeiten. Wenn man das Lee Swordy mitteilen würde wäre es aber ein leichtes für ihn das einzubauen. |
Horst Du hast das Tool Autoasm angesprochen und ob jemand damit schon Erfahrung hat. Wir könnten uns da ev. austauschen. Ist ev. auch für andere z.B Rolf bzw. das Team interessant. Daher zunächst das was ich dazu sagen kann. Daher hier die ganze Geschichte mal umrissen. Nun an dem Tool selbst arbeitet der Chris Wright seit dem das FS2002 Terrain SDK rausgekommen ist. Die erste Beta konnte man sich im Zeitraum Dezember 2002 downloaden wenn ich mich recht zurückerinnere. Ich hatte damals auch damit rumgespielt nutzbar war es aber eigentlich noch nicht.
Die Grundsatzidee selbst was er da vor hat ist eigentlich genial. Mal ausgeholt was wir momentan haben zum programmieren von Straßen, Gewässern usw. sprich Bodenscenery nach Vector Terrian SDK. Ich nenne hier die bekanntesten wie sie grob arbeiten. Zunächts mal Ground2K von Christian Fumey. Geniales Tool. Nachteil es muss im Prinzip alles von Hand gemalt werden. Sprich man muß sich eine Karte oder ähnliches als Bitmap in Ground2K hinterlegen und alle Elemente von Hand zeichnen. Oder wie Rainer es neulich mal ähnlich gesagt hat, alles von Hand abklicken. Das ist sehr viel Handarbeit die leider sehr monoton. Das Straßennetz von Deutschland ist schon sehr verzweigt. Wenn es nicht nur genauer sondern auch optisch besser mit z.B allen Autobahnabfahrten sein soll dann ist das eine Arbeit für ein paar Monate. Daran sieht man vermutlich auch das sich noch niemand bereit dazu erklärt hat dieses großflächig freiwillig zu machen. Bei dem Handwerkszeug Ground2k kann man eigentlich nicht viel falsch machen. Wenn doch wäre das in der Regel nicht so tragisch wenn man sich schön seine Projekte aufhebt, so kann man das wesentliche nachträglich auch noch mal korrigieren. Ich habe da neulich wohl richtig gelegen mit meiner Vermutung das die Polys aus Ground2k zu komplex sind. Offensichtlich behebt die neue Routine von Ground2K dadurch diverse Probleme wie unerklärliche Nachtpolys die eigentlich dunkel sein sollten. Zumindest bringt es wohl Linderung bei dem Problem. Ausschließen kann man das Problem trotzdem noch nicht ganz. Vorteil bei Ground2K. Man klickt nur die Punkte an, wo eine Straße z.B eine Richtungsänderung macht. Denn wir wissen die kürzeste Verbindung zwischen zwei Punkten ist eine Gerade. Logisch reicht es uns dann aus, wenn wir hier nur die zwei nötigen Punkte definieren wenn wir eine schnurgerade Autobahn haben. Haben wir Kurven nehmen wir mehr Punkte. Im Prinzip macht es Ground2K so. Das was wir anklicken wird später als Vector Point im BGL Code genutzt. Das was da zwischen liegt in der Regel nicht, es sei denn es wird benötigt. Spezielle Besonderheiten bezüglich Code mal außen vor. Sprich wir haben eigentlich einen Framerate freundlichen Code. Selbstverständlich muß Ground2K auch darauf achten das alle Vectorpoints im LOD Raster liegen. Das macht Ground2K im Hintergrund alles allein, da braucht man sich nicht drum kümmern. Will man z.B Flächen zeichnen müssen diese gezeichneten Eckpunkte der Flächen auch in Vectorpoints umgesetzt werden. Bei Flächen ist zu beachten das auch im Fs2004 für VTP2 Polys es immer noch gültig ist, dass Flächen nicht nach innen gewölbt sein sollten (gilt zumindest noch für VTP2 Polys nach FS2002 SDK). Der FS lässt hier gewisse Toleranzen zu. Übertreibt man es aber, kommt es zwar nicht zu einer Fehlermeldung, man wird aber hinterher wenn man genau hinschaut feststellen das die Flächen dann nicht so dargestellt werden wie man sie gezeichnet hat. Der Vectorpoint in einer Wölbung wird ausgelassen, dass Poly springt dann in der Regel zum nächsten Vectorpoint so das erst gar keine nach innen gewölbte Fläche entsteht. Kann man sehr schön sehen wenn man mit einem Designtool programmiert welches voraussetzt das der Anwender mitdenkt und die Polygone selbst in mehrere nicht nach innen gewölbte Polys aufbricht. Abhilfe wie gesagt, die Flächen müssen in Einzelpolygone aufgebrochen werden damit es zu keiner Fehldarstellung kommt. Auch über dieses müssen wir uns keine Gedanken machen. Ground2k erledigt das über interne mathematische Routinen automatisch. Diese sind übrigends vor kurzem geändert worden. Vorher waren die Polys mathematisch korrekt aber extrem aufwendig und verschwenderisch hinsichtlich Vectorpoints. Das führte wie gesagt nicht nur zu Problemen sondern knabbert auch an der Performance. Jetzt ist die neue Routine denen wie die Default FS Polys aufgebaut sind sehr ähnlich. Ob bei der neuen Ground2K Version die neuen Routinen zur Fehldarstellung führen können habe ich bisher nicht geprüft. Darum geht es hier auch nicht. Es geht mir nur um die Erklärung der Problematik von Autoasm. Als nächste Möglichkeit gibt es z.B Konvertierungstools wie E00VTP von Falko Dienstbach. Diese lesen bestehende Topografie Daten (hier E00 Daten) aus und konvertieren sie. Diese E00 Daten sind im Prinzip schon so eine Art Vectorpoints. Falkos Tool rechnet diese um bringt sie dann ins passende FS LOD Raster der Vectorpoints und erzeugt den Code so das sie in eine BGL kompiliert werden können. Zweifelsohne die eleganteste Lösung. Nachteil diese E00 Daten kosten meines Wissens etwas. Zweitens sind sie doch arg grob. Es sieht im Fs hinterher nicht unbedingt viel besser aus als jetzt. Einen Testbericht über Railwaystrecken in Italien die auf E00 Daten basieren konnte man damals auch in einer FXP lesen. Vorteil sie sind wesentlich genauer als das die Microsoftdaten. Das Highlight wäre meiner Meinung aber ein Tool welches Daten von GPS Autonavigationssystem ausliest. Das schwebt mir momentan vor, da ich persönlich festgestellt habe das diese Daten durch nichts zu toppen sind. Bei mir ist sogar jeder kleine Popelfluss in den Navigationsdaten enthalten. Auch als Basis einer Vectorpolygonscenery wären sie mit Abstrichen nahezu ideal. |
Leider haben Polgonscenerien die Eigenschaft das sie optisch doch recht hart an den Rändern ausfallen. Reines Landclass löst das wesentlich eleganter, hat dafür allerdings speziell im Fs2004 den Nachteil das es mit der genauen Positionierung optisch nicht so richtig passt.
Auch kann man an der Formgebung einer kleinen Ortschaft oder Waldes mit Landclass nicht viel drehen. Um auf die Navigationssystemdaten zurückzukommen. Leider sind diese Daten komprimiert und so wie ich mit bekommen habe reinrassig vektorisiert also keine X/Y Punkte. Ich habe bisher leider keine vernünftigen Erkenntnisse aus den Daten ziehen können. Die Firmen selbst hüllen sich leider in Schweigen. Im Prinzip kommt vermutlich nur jemand mit Beziehungen an den Code dran. Die dritte Möglichkeit wäre halt das Tool Autoasm. Hier arbeitet man mit einem anderen Prinzip. Es soll nichts von Hand gezeichnet werden müssen es werden auch keine Vektordaten oder was auch immer konvertiert sondern es wird quasi eine Bildanalyse durchgeführt. Sprich man hat eine Bitmap einer Karte. Diese Bitmap wird ausgelesen und daraus dann der Code von Straßen, Flüssen, Seen usw. automatisch erzeugt. Geniale Idee. Nur leider nicht ganz so einfach. Zum einen stellt das Tool gewisse Ansprüche wie es diese Informationen in der Bitmap haben möchte. Diese zu erfüllen bedeutet eine nicht unwesentliche Vorarbeit sonst wird das nichts. Leider nimmt diese Vorarbeit auch schon viel Zeit ein. Eine einfache Karte geht nicht. Für Straßen sollte es nach Möglichkeit auch nur eine 1 Pixel breite Linie sein wo nach Möglichkeit nicht 3Pixel im rechten Winkel aneinanderliegen sollten. Dieses hat man sehr schnell wenn man eine Straße hat die in einem schärferen Winkel abbiegt. Da empfiehlt es sich das Eckpixel zu löschen wenn man Fehler möglichst verhindern möchte. (Kommt vieles aber auch auf das Rohdatenmaterial an) Ist man schlampig bei der Bitmap muß man mit Fehlern rechnen die bei komplexen Gebieten zunächst nicht auffallen. Auch ist Autoasm so intelligent das es Unterbrechungen einer Linie erkennt. Man kann hier sogar den Suchradius eingeben wo nach einer ev. zugehörigen Linie gesucht werden soll. Insofern ist das Stadium schon ganz schön fortgeschritten. Diese ganze Geschichte mit der Bitmap und dem auslesen sehe ich aber nicht unbedingt als das Problem. Ich habe jetzt in den letzten Tagen ein paar Stunden mit Autoasm rumprobiert. Die Bitmaps waren immer ideal vorbereitet so das keine Fehler hätten entstehen dürfen. Trotzdem kam es auch bei den mitgelieferten Demofiles/Bitmaps bei mir immer wieder zu Fehlern wobei hier von Chris selbst alle Parameter schon vorgegeben waren und ich ein Fehler meinerseits eigentlich ausschliessen kann. Bei der TS_demo habe ich bei den LWMs immer ein zusätzliches kleines LWM Poly in Area 4,22 der entsprechenden Cell wo regulär korrekt LWMs umgesetzt wurden. Da es immer die selben Vectorpoints sind tippe ich auf einen Fehler in der Routine. Habe da aber noch nicht weiter nachgeschaut. Wer Autoasm bisher schon mal benutzt hat kann ja mal kontrollieren ob es bei dem mitgelieferten TS_demo File bei ihm zu dem selben Problem kommt. Ich hatte alle Tests nicht auf dem eigenen PC gemacht. Ev. waren auf dem Test PC nicht die aktuellen VB Runtime Module installiert, die Installation dieser lag schon etwas zurück. Ich denke aber nicht das das der Grund für das Problem ist. Auf jeden Fall kann man so etwas mit diesem falschen Poly auf die Schnelle beheben wenn man sich im Code auskennt. Ein Hauptproblem sehe ich aber momentan wo anders. Beispiel ich habe in meiner Bitmap/Karte mit 1024x1024 Pixeln eine gerade Autobahn/Linie von 600 Pixeln Länge woraus mal im FS eine gerade Autobahn werden soll. Wenn ich die Bitmap nun einlese werden exakt diese 600 Pixel erkannt. Schön! Egal mit welchen Parametern ich rumspiele es werden diese 600 Pixel auch als Vectorpoints im ASM Code umgesetzt. Weniger schön! Dabei muß natürlich auch Autoasm zum Teil interpolieren. Selbst wenn meine Linie in der Realität nur einer kurzen Entfernung entspricht (der Maßstab meiner Bitmap anders ist) , sind diese 600 Vectorpoints im Code zu finden. Da der Abstand der Vectorpoints im FS fest steht, fängt Autoasm jetzt an gleiche Vectorpoints im Code zu wiederholen um diese 600 unterzubringen. Egal was ich an möglichen Beeinflussungen (und Maßstäben) ausprobiert habe. Es waren die 600 Pixel immer als Vectorpoints umgesetzt. Was bedeutet dieses? Autoasm funktioniert bis auf kleinere Probleme einwandfrei. Es lassen sich im Prinzip wenn die Bitmap den Vorgaben entsprechend vorbereitet wurde komplette Scenerien automatisch erstellen. Das können auch sehr große Flächen sein. Nur der PC sollte mitspielen. Super Sache wenn da nicht das Problem wäre, dass jedes Pixel z.B dieser 600Pixel langen geraden Straße umgesetzt werden würde. Wenn ich jetzt mal Besonderheiten die beim Code erfüllt sein müssen außen vor lasse dann würden theoretisch zwei Punkte ausreichen um diese Straße mit Vectorpoints zu beschreiben. Im Code stehen aber mindestens die 600 Vectorpoints. Das ist nicht gerade sehr gut für die Performance im FS. Da sehe ich momentan das Hauptproblem. Egal was ich programmiere VTP2 Polys, VTP2 Linien, LWMs immer wird jeder Pixel der Bitmap umgesetzt. Jeder Vectorpoint im FS ist eine Information die verarbeitet werden muß. Das gilt generell für alles weniger Polys, Vectorpoints, Verticies bedeutet immer eine bessere Performance. Nicht umsonst wurden Mip Level z.B bei Texturen und dynamisches Verhalten in Form von LOD beim Mesh oder Aircrafts eingeführt. |
Sollte jemand bei Autoasm irgendeine Stellschraube gesehen haben die definitiv zu weniger Vectorpoints führt würde mich das brennend interessieren. Ist es bei euch genau so, würde ich sagen kann man Autoasm mit guten Gewissen noch nicht für großflächige Scenerien verwenden, schon gar nicht wenn man große Scenerien aus flächenmäßig kleinen Gebieten und hoher Kartenauflösung zusammen setzt.
Was dem Tool momentan aus meiner Sicht fehlt ist eine Routine die bei einer Linie z.B vom aktuellen zu den folgenden Vectorpoints Richtungsänderungen der X,Y Werte beobachtet. Abhängig vom Maßstab müßte das Tool dann entscheiden ob man diesen Vectorpoint nutzt oder erst spätere zur Beobachtung heranzieht. So müsste das Spiel immer weitergehen bis eine ausreichende Änderung erfolgt bzw. bis man sich einer Area oder Cellgrenze nähert. Erst dann dürfte der Vectorpoint genutzt werden. Ev. Zwischenpunkte könnte man einfügen wenn der Code optisch hängt. Das ist da was mir bisher aufgefallen ist. Sollte sich das bei Dir Horst oder jemand anders bestätigen wäre mir das als Scenery noch zu gefährlich. |
Viel Stoff zum durcharbeiten und mitdenken
Meine Annäherung zu AutoAsm von Chris Wright: http://forums.avsim.net/dcboard.php?...&mesg_id=16520 war eigentlich nur folgende: a) Ich habe damals den FS9 installiert und schade, im Eurw-Ordner passt leider wieder nichts. Und nachdem sich im Scenery Design das Meiste geändert hat, habe ich begonnen, meinen bereits vorhandenen Daten selbst einen kleinen Update zu verpassen. Bis eben neue Daten vorhanden sind. b) Warum man bei MS nicht grundsätzlich Daten verwendet die zusammenpassen? keine Ahnung c) Die größte Sorge derzeit für mich im FS9: hoffentlich pfuscht kein Designer an diesen Originaldaten herum. Und hoffentlich liefert MS Informationen in der nächsten SDK, wie dies zu umgehen ist. Ich will damit nur an Af-Daten im FS2002 erinnern, und Lee Swordy einen Orden verleihen, dass er dies (warum auch immer?, oder zufällig, obwohl es wieder viel Bastelarbeit ist) geändert hat. Man pfuscht an Originaldaten, nur mit Zustimmung des Anwenders herum. Oder sucht Wege dies zu umgehen. d) Bei Flugwerk finde ich leider derzeit keine Bilder, bei Stefan Rausch schaut dies ja schon sehr gut aus. Also bei beiden Produkten kein unmittelbarerer Bedarf noch mehr zu ändern. Also für Österreich habe ich Geduld, und die Geduld sollten auch die Autoren haben. Und derzeit bin ich überzeugt, ich werde belohnt. e) Aber für den Rest Europas (und die ganze Welt)? Und hier, muss die Genauigkeit nicht unbedingt stimmen, zumindest für mich. Vielleicht kann man in den Srtm Daten Löcher einfach bearbeiten (siehe AF_2: Toll wie die Flusigemeinschaft dies relativ rasch wieder bastelt) für den kleineren Raum? Aber halbwegs zusammenpassen soll es. Joachim, ich habe ehrlich gesagt noch nicht mit AutoAsm „herumgespielt“, da ich mich zu den Konsumenten zähle. Aber vielleicht ist dies ein Werkzeug der Annäherung an dieses Problem. Und vielleicht wartet Chris Wright auf Benutzer, um es weiterzuentwickeln. Wir werden ihm vielleicht helfen, seine Probleme zu lösen, bzw. helfen sein Werkzeug zu entwickeln. Ich habe eigentlich nur abgewartet, ob Szenerien erstellt werden, die damit entwickelt wurden, oder welche Fehler sich daraus ergibt. Aber Recht hast du, man soll Ideen versuchen und ausprobieren. Indem man ganz einfach und simpel Dinge ändert. Ich glaube Chris Wright wartet auch nur auf Fragen und Erfahrungen. Meiner Zeit entsprechend werde ich natürlich versuchen mich einzudenken und einzuarbeiten, und anschließend oder zwischendurch hier in diesem Beitrag berichten. Derzeit: - Ich hoffe, du hasst ein System, deine oft aussagekräftigen Texte zu sammeln, und diese als Zusammenfassung auf deine Homepage zu stellen. Ich muss leider öfters nachlesen, und dies ist mit viel Zeitaufwand verbunden. - Zur Landclass-Zusammenfassung finde ich toll, dass du anscheinend auf die Sdk wartest. Gut so. - Zu Areafill – keine Ahnung (bzw. Verständnis für die Zusammenhänge) was ich da gemacht habe (ich habe nur das Bild noch gehabt bei diesem Beitrag) - Zu Finkenwerder oder deiner simflyer Frage damals :Area16N schummelt sich anscheinend in der Priorität immer vor. Warum? Keine Ahnung. - Hast du ein paar Links in deinem „Hirn-Google“, zu dem angesprochenen GPS-Daten und deren Umsetzung? Und noch eine Bitte, da ich zu keinem Designer oder Produzenten und nicht mal zu einem Flusikollegen Kontakt habe, auch nicht per Mail, (schützt zum Glück meine Zeiteinteilung und ist auch gewollt): Kann sich nicht manchmal, eine deiner Kollegen oder Freunde, bei gewissen Beiträgen auch öffentlich einbringen? Siehe auch deine derzeitige Abänderung der terrain.cfg. Dies sind für mich die Vorteile des WWW. Nicht nur um Wissen zusammenzutragen. Horst |
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). |
- 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. |
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. |
- 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 |
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. |
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. |
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. |
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. |
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. |
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 |
Hallo Holger,
das klingt ja richtig gut, mit dem Tool was die Flußläufe entlang der Tiefenlinien laufen läßt. Als Horst (LOWW) vor einiger Zeit mal theoretisch in diese Richtung spekuliert hat, ist das unter den Fachleuten hier nicht ganz so ernst genommen worden. Mich hat sein Gedankengang gleich fasziniert, war das für mich doch logisch nachvollziehbar. Würdest Du nochmals präzise sagen, was das für ein Tool ist und ob es für Otto- Normaldesigner nutzbar/verfügbar ist. Vielen Dank und Gruß ( und erfriere nicht bei Euch ) Rolf |
Ich habe die Texte jetzt nur überflogen (muss ich genauer aufarbeiten), daher nur kurz.
- zu AutoAsm Soweit ich dies bis jetzt verstehe, gibt es für den Input nur 2 wichtige: a) die Bitmap-Größe b) die Größe für den Bereich, denn man damit im FS abdecken will (read in Box und search radius, noch nicht probiert) Anschließend read data. Dies sollte nach meiner Meinung die Durchquerung einer Lod 13 in N-S Richtung auch für eine Gerade, glaube ich nicht mehr als 10-13 Points sein. Bei 13 Points für eine Gerade, natürlich 11 zuviel.(Wieviel „gerade“ Punkte gibt es – zwecks Performance?) Abändern kann man dies im Programm, glaube ich derzeit, nicht. D.h Löschen von Points, bzw Halbierung oder Reduzierung aller Points, oder Ausgleich von Geraden. Für die Erzeugung von LA braucht er ca 5000 Points, soweit ich dies im Kopf habe. Eigene Bitmaps habe ich noch nicht erstellt. Joachim, natürlich werde ich dies überprüfen und wahrscheinlich morgen oder übermorgen antworten. - mesh Holger, ein Standart für mesh sollte sich etablieren, aber wie Joachim schreibt sollte man Löcher beachten. Also nicht interpolieren, sonder versuchen zu „stopfen“ mit richtigen Daten, bzw. auch einfach Löcher zu schaffen, um besseren Daten, oder anderen Daten, den Vortritt zu lassen, auf engeren Raum. Für jedermann zugänglich ist sehr wichtig. Douglas-Peucker? Rolf, meine Idee, und dies würde höchstens für Flüsse funktionieren, sich diesem Problem zu nähern, habe ich nur Joachim, etwas umständlich, hier erzählt. Und ob dies überhaupt möglich ist, habe ich nie versucht. D.h. wir haben eigentlich nicht darüber nachgedacht. Horst |
Zu den Löchern in SRTM Mesh bin ich etwas skeptischer wie Holger. Siehe auch neulich meinen Screenshot das sind ín den Alpen eben nicht nur hundert Meter sondern sehr viel mehr. Da klaffen echt riesige Lücken. Das schlimme daran ist das dieses oft genau an den Stellen anzufinden ist wo ganz markante steilflankige oder extrem hohe Berge stehen. Diese kann man auch nicht interpolieren das kann mir keiner weis machen. Klar in halbwegs flachen Land ist das möglich.
Da mag das realistisch sein. Aber nicht im Extremgebirge. Wenn halbwegs realistische Daten nur mal angenommen alle 200m existieren ist das selbst mit Interpolation genauer als ein Loch von 500 Metern oder mehr. In diesem Loch kann sonst was sein. Zu diesem Tool. Auch da bin ich etwas skeptisch. Sicherlich sind die Ergebnisse schnell da bezüglich Seen. Nur es hängt hier auch wieder sehr stark von der Genauigkeit des Mesh ab. Logisch ist das SRTM Mesh da wo es keine Löcher gibt schon nicht schlecht. Da es hier realistisch ist sind die Gewässer dann mit diesem Tool vermutlich schon sehr genau (und was toll daran sein dürfte sie passen optisch durch diese Technik vermutlich 100%) Wenn ich das richtig interpretiere kann man das ja im Prinzip mit realer Flüssigkeit vergleichen. Man definiert die Höhe, dass Gewässer nimmt durch die Routine den Geländeriss an der auf dieser Höhe im Mesh liegt. Wie Wasser halt. Also äußerst real. Aber wie gesagt abhängig vom Mesh. Das kann bei SRTM wie gesagt auch schon mal sehr ungenau sein. Ich gebe zu vermutlich nicht ungenau in dem Bereich wo Gewässer liegen. Obwohl damals hatte jemand ja beim Bodensee (SRTM Mesh) auf der Waseroberfläche mehr als 5M glaube ich an Höhenschwankungen festgestellt. Das auf einer flachen Fläche in flachem Gebiet kann schon ganz schön die Flächen von Seen oder Flüssen versauen. Bei mir in der Gegend sind Werra, Fulda, Weser. Wenn da Hochwasser ist und diese Flüsse nur um einen Meter ansteigen sieht es flächenmäßig gewaltig anders aus. Wenn man dann die 5 bis 6 Meter Höhenfehler hat die bei SRTM schon von der Nasa angegeben werden (in der Regel wird es übertroffen) dann kann man sich vorstellen das man schon mit extremen Fehlern rechnen muß. In Fjorden usw. dürfte es aber nahezu perfekt sein. (Geteilte Meinung von mir zu em kompletten Thema) na ja auf jeden Fall dürfte es besser sein als die Defaultgewässer. Ohne das Tool zu kennen würde ich vom Gedankengang schon mal sagen es wird uns nur in bergigem Gelände was nutzen. Bei Flüssen in Nord/Ost/Mitteldeutschland wird es zu ungenau sein aufgrund von Meshfehlern und zu flachen Gelände. Hier sind die Höhenunterschiede einfach zu gering. ich bin zwar kein Flusskenner. Schwiegervater kommt aber gebürtig von der Mosel (Schweich kommt da nicht auch der Rainer her). Auf jeden Fall ist es da schon ganz hügelig drum herum. Nur ob das ausreicht bei den typischen Meshfehlern um auch flächenmäßig genaue Flüsse zu produzieren wage ich zu bezweifeln. In Friesland halte ich das gar fast für unmöglich. Ich denke Rolf, Deiner und meiner kritischen Einstellung wird das nicht ganz standhalten. Lssen wir uns überraschen. Optisch wird es gut sein. Flächenmäßig? |
Howdy:
beim Lesen der letzten Beitraege hier ist mir wieder mal klar geworden, warum ich mich nicht viel in deutschsprachigen Foren aufhalte: nichts fuer ungut, aber hier wird einfach zu viel genoergelt :mad: Wenn das ein Aussenstehender lesen wuerde, wuerde der wohl annehmen, dass einige Leute hier zur Arbeit mit dem Flugsimulator und seinen Add-ons gezwungen werden. :D Dazu kommt dann noch das mit dem (Ueber-)Lesen: z.B. habe ich eindeutig gesagt, dass es einen Unterschied geben muss bei der Bearbeitung von kleinen vs. grossen Loechern im SRTM. Generell vermisse ich den Lob fuer diejenigen, die sich bemuehen, den derzeitigen FS Standard zu verbessern, auch wenn es nur in kleinen Schritten ist. Stattdessen wird ohne Umschweife ein Tool oder Datensatz nach dem anderen "zerlegt". Dabei kann es durchaus sein, dass die Kritik im einzelnen angemessen ist; mir gehts um den Stil und den (meiner Meinung nach) Mangel an Ausgewogenheit. Also, vielleicht etwas mehr "Hurrahs" und ein wenig Leichtigkeit... --- Rolf, Danke fuer dein Interesse (die Kaeltewelle ist uebrigens mehr im Osten; hier im Westen Kanadas haben wir momentan "normales" Winterwetter). Der Autor von "Strip" ist Jim Keir, der uns vor kurzem den genialen LWMViewer beschert hat. Er hat bereits einen kurzen Abriss seines Programms auf seiner Internetseite, der allerdings bereits etwas veraltet ist und, zumindest der Eleganz der Kuestenlinienerstellung betreffend, auch etwas untertreibt. Hier ist der Link: http://www.jimkeir.co.uk/AutoGen/index.html Ich habe bisher drei verschiedene Datentypen ausgetestet und das ist alles sehr vielversprechend. Insbesondere die Fjorde der nordamerikanischen Westkueste kommen beeindruckend dabei weg: tausende von Kilometern in wenigen Minuten. Die (halb-) automatische Erstellung von Fluessen und Seen ist noch nicht ganz ausgereift, aber Jim scheint sehr am Erfolg seines Projektes interessiert zu sein. Jim hat noch keine Entscheidung getroffen bezueglich der Veroeffentlichungsmethode des Tools. Da ihr euch vorstellen koennt, dass die Kombination von akuratem Mesh plus Kuestenlinie kommerziell erfolgreich seien koennte, wird er vermutlich fuer Freeware-Entwickler (d.h. kleine Projekte) "Strip" frei verfuegbar machen und von Payware-Entwicklern Lizenzgebuehren verlangen. Ist aber, wie gesagt, noch nicht entschieden. Wie LWMViewer zeigt, ist Jim auf alle Faelle im Freeware-Lager. Werde mich bei weiteren Neuigkeiten und Testergebnissen wieder melden. Ciao, Holger |
Hallo Horst:
habe noch vergessen, deine Frage zu beantworten: Douglas-Peucker ist der Name eines der wichtigsten Algorithmen zur Gerealisierung von Vektordaten. Eine Google-Suche wird dir tausende von Internetseiten bescheren, viele davon ohne Porn ;) Interessanterweise war Prof. Peucker (gebuertiger Wiener, wenn mich nicht alles taeuscht) am Fachbereich Geographie an der Simon Fraser University in Vancouver angestellt, wo ich meine Doktorarbeit begonnen habe. Er ist zwar nicht mein Doktorvater (habe nach einem Jahr den Fachbereich gewechselt), aber wir hatten einige interessante Gespraeche. Viele Gruesse, Holger |
Hallo,
huch... sollte ruhig mal in Threads reinschauen, die erst mal einen nichtssagenden Titel haben... ;) Zitat:
Zitat:
Warum hat noch kaum jemand sich großflächig an Flüssen versucht? Je mehr man damit macht, um so klarer die Antwort: es kann (mit frei erhältlichen Daten) keinen Automatismus geben, der auch nur annähernd genau einen Flusslauf generieren könnte. Flüsse fliessen noch nicht mal auf gleicher Ebene, z.T. sogar einfach mal kurzzeitig vielleicht sogar bergauf. Es existieren Staustufen etc... Nur... vielleicht muß man sich die Arbeit eigentlich gar nicht machen, wenn man tatsächlich etwas weniger Realität fordern würde und mit strikt oder annähernd gleich verlaufenden Polygonen arbeitet. Wäre mal auszutesten, ob überhaupt jemand - der nicht aus einer gewissen Gegend dann stammt - den Unterschied merkt. Warum hab ich das nicht gemacht? Ich möchte, dass jemand in Karlsruhe hingehen kann und seine Heimat relativ genau wiederfindet, genauso wie ich meine Mosel in Schweich oder Trier exakt wiederfinde. Habe ich in Karlsruhe dort aber automatisch generiert und dies entspricht nicht der Realität wird der dort beheimatete User doch denken, dass auch sonstwo der Fluss nicht der Realität entspricht. Dann kann er auch gleich beim Microsoft-Original bleiben und wird es auch so tun. Strassen wären (zumindest wenn man sich auf den Verlauf beschränken würde und Ein- und Ausfahrten "vereinfacht") automatisiert vielleicht tatsächlich möglich. VTP-Linien sind leichter auf gewisse GPS-Koordinaten zu setzen, die Breite ist ziemlich festgelegt. Eisenbahnstrecken wären auch möglich, nur dass dort z.T. durch Tunnel und Gleisdamm-Aufschüttungen die Gleise anders verlaufen als Strassen und auch damit sich der Charakter einer Gegend ändert. Warum setze ich bisher keinen solchen Automatismus ein, weder bei OWL noch bei den Flüssen: Eine Szenerie lebt von dem vermittelten Charakter. Eine Gegend wird nur dann wiedererkannt, wenn dieser Charakter der Umgebung irgendwie getroffen wird. Hat man Berge und Flüsse im Umfeld, muss vielleicht der Rest nicht so 100%-ig genau sein, wenn Mesh und die Rivers schon mal passen. Fehlt dies aber, so erkennt man erst die Gegend wieder, wenn Strassen oder Eisenbahnen korrekt mit Ortsrändern und markanten Gebäuden dargestellt werden... So was ist für mich (noch) nicht zu automatisieren und macht momentan den Reiz aus. Wenn wir nur noch Automatismen irgendwo drüberjagen, wird das Design nicht mehr interessant sein. Ciao, Rainer. |
Hallo Miteinander,
@ Holger: Mensch, da hast Du wirklich einen guten Gedankenanstoß gegeben. Vielleicht ist unser Perfektionismus, unsere Verbissenheit eine Eigenschaft, die uns wenig Freunde beschert. Anderenseits, das bringt uns natürlich auch voran. Aber bei einem Hobby? Auf jedenfall, man sollte sich wirklich mal zu Herzen nehmen, was uns einer sagt, der 2 Kulturkreise kennt. Ich dank Dir für Deine Mühe und den Link. @ Rainer : Du hast sicher nicht unrecht,was Automatismus beim Design anbetrifft. Aber wenn es darum geht, weltweit mal auf einfache Weise relative Genauigkeit mit einem Automatismus zu erzielen, da würd ich das gerne in Anspruch nehmen. Mich hat schon immer tierisch gestört, wenn ein Fluß am oder über einen Berghang fließt. Das wäre dann erst mal weg. Dann bliebe uns noch so viel zu tun, was absehbar in den nächsten 10 Jahren noch kein Automatismus kann. Ich zum Beispiel würde mal gerne wieder einen Flugplatz von Rainer Duda sehen - noch kenne ich erst EDLI und EDLO :). Hat der " Jester" da nicht Bedarf angemeldet? Gruß Rolf |
Strassen wären (zumindest wenn man sich auf den Verlauf beschränken würde und Ein- und Ausfahrten "vereinfacht") automatisiert vielleicht tatsächlich möglich. VTP-Linien sind leichter auf gewisse GPS-Koordinaten zu setzen, die Breite ist ziemlich festgelegt
Die Frage ist nur kennt jemand ev, den Code z.B von Autonavigationssystemen. Denn wenn Automatismus dann muß man ja diese irgendwie auslesen. Holger als Nörgelei würde ich das nicht auffassen. Ich mache mir nur Gedanken wo man so eine Gewässererzeugung realistisch einsetzen kann. Im flachen Land sehe ich da halt Probleme in hügeligen bzw. bergigen weniger wenn das Mesh passt. |
Hallo Rolf,
Zitat:
Aber dann setz' ich mich wieder dran und es kommt irgendwann was neues... Ciao, Rainer. |
Hallo Rainer:
"Warum hat noch kaum jemand sich großflächig an Flüssen versucht? Je mehr man damit macht, um so klarer die Antwort: es kann (mit frei erhältlichen Daten) keinen Automatismus geben, der auch nur annähernd genau einen Flusslauf generieren könnte. " Wie waers denn damit: sich eine der frei verfuegbaren Landsat7 30-m Szenen runterladen und aus dem Kanal 4 (nahes Infrarot) eine Gewaessermaske erstellen, die dann, in ein Bitmap umgewandelt, an autoasm oder aehnliches Tool "gefuettert" wird. Ich habe fuer meine Diplomarbeit (1985) solche Gewaessermasken erstellt und die sind wirklich gut. Nicht perfekt, da breite Bruecken die Fluesse unterbrechen koennen und schmalere Fluesse wahrscheinlich nur streckenweise sichtbar sind (die Flussbreite brauch aber nicht 30m zu sein, der Wasseranteil in dem Signal eines 30x30m Pixel muss lediglich ueberwiegen). Ein Problem wird sein, die 2D-Daten Landsat Daten ueber das 3D Gelaende zu legen, aber das ist sicher machbar (LWM-Polys koennen ja "mesh-clinging" sein, aber das sieht nut gut aus, wenn das Gelaendemodell auch einigermasses "sauber" ist). Mein Argument ist, dass es viele Moeglichkeiten der Datenbearbeitung gibt, die wir in der FS-Welt ueberhaupt noch nicht angefasst haben. Wir vergessen vielleicht zu oft, dass diese Daten ja nicht nur fuer uns Simmers da sind. Waehrend ich das hier tippe, sitzten weltweit dutzende wenn nicht hunderte GIS-SpezialistInnen daran, fuer neue Rohdaten intelligente und brauchbare Bearbeitungsmethoden zu entwickeln. Vorsicht also mit "geht nicht" und "kann nicht" oder "ist nicht gut". Das Gleiche gilt auch ganz besonders fuer SRTM-Daten, welche ein grosses Geschenk (na ja, abgesehen von den SteuerzahlerInnen der Projektfinanzierungslaender :) ) fuer alle moeglichen Anwendungen in Naturwissenschaft, Raumplanung etc. sind. Ihr koennt sicher sein, dass weltweit fieberhaft Loecher gestopft werden und dass da ueber lineare Interpolation und fuellen mit GTOPO30 nur muede geschmunzelt wird. Also: alle mal umsehen und in der weiten Welt nachschauen, was andere so mit e-Daten machen! Gruesse, Holger P.S.: Rainer, uebrigens hat mir deine Beschreibung bezueglich sorgfaeltig ausgewaehlter Designelemente for FS-Landschaften sehr gut gefallen! |
@ Holger
Google oder Suchamschine? Holger richtig, aber da siehst du in welchem Stadium, meiner Aufarbeitung zu AutoAsm ich bin. Diese wäre der Schluß. Wie wird dies erzeugt? Also der Anfang der Arbeit von Chris Wright. Danke für den Hinweis. Da ich mich erst seit September mir der Erstellung von Szenerien und Techniken dazu befasse, bin ich leider etwas langsam. Da ich ständig nach Fachbegriffen nachsehe, und diese richtig interpredieren muss. Aber der Zeitaufwand dafür wird kürzer. Auch das Mitlesen und Suchen in Beiträgen im Avsim Forum und anderen, bedarf sehr viel Zeit. Im FS8 waren es die Flugzeuge, im FS9 soll es eben Szenerie sein. Und die Werkzeuge die mir dies erklären, werden immer toller. Also, als ich den LWM Viewer das erste Mal benützt habe. WOW! Ich sehe endlich diese Daten auch während des Fluges am anderer Schirm. Deinen Verweis kannte ich natürlich vom Download, denn dies wäre meine Frage an dich gewesen. Da ich den LWMViewer auch bei AutoAsm finde, stimmt mich zuversichtlich. Man wird sich sicher austauschen. Ich glaube an alle, die sich hier bemühen Werkzeuge zu erstellen, kann man nur ein herzliches Dankeschön sagen. Zu SRTM gebe ich dir recht – große Abdeckung und für jedermann verfügbar. Auf John Childs Seite: Blackart – WOW! Jetzt sehe ich diese Löcher auch grafisch. Da ich nicht alles geleichzeitig ausprobieren, (bei Mesh auch nur Matthew Styles Programm benutzt und Greenwoods maui-Beispiel für die Auswirkungen im FS9) kann, zwei Fragen: a)Kann man mit Blackart die Daten einfach reparieren? Da ich leider nicht so viele Rohdaten habe, wollte ich dies erst später versuchen. b)Kann man diese Daten auch im FS während des Fluges sehen? (glaube ich nicht, sonst hätte ich wahrscheinlich schon etwas gefunden) An beiden Programmen sehe ich Potential, mir eine „Knopfdruckerzeugung“ zu geben. Warum sollen sehr fähige Leute an einem Programm arbeiten, wenn es nicht funktioniert? Es beschäftigen sich eben derzeit zu wenige damit, bzw nehmen das Angebot an. Leider aber auch eventuell die Möglichkeit meine Originaldaten (siehe weiter oben) zu manipulieren. Hier hoffe ich noch immer, das eine einfache Möglichkeit gefunden oder von MS mitgeteilt wird, wie diese Flatteneinträge im Mesh nicht geladen werden. Sonst ensteht bei meiner Datenmenge ein unübesichtliches Chaos. @Rainer AutoAsm orientiert sich nicht anhand von Meshpunkten. Der Ansatz ist folgender: Du hast ein bitmap – du ladest es in das Programm – kannst ein paar Einstellungen machen – und in ein paar Sekunden hast du es erzeugt. Zitat aus Readme AutoAsm V.06 Chris Wright: The following scenery objects can be created: 1. LWM polygons for water or land. 2. VTP lines for roads, streams, railways etc. 3. VTP areas. 4. Terrain mesh together with user-defined generic textures. 5. Objects such as trees or buildings linked to VTP lines (similar to vector autogen). An installation of Airport 2.60 or 3.0 is required for this. Für Österreich werde ich sicher gute Daten kaufen können (war zumindest bis jetzt so), wo mir Genauigkeit wichtig ist. Mit Flughäfen also ein Gesamtpaket. Aber z.B für Straßennetz Großstadt (Stadtplan) mit richtig angeordneten Gebäuden entlang der Straßen in Verbindung mit Phototexturen (meine Bitmapvorlage, die ich leider nicht habe), oder Forststraßen österreichweit, wäre sicher noch Platz. Und dies sehr genau eruopaweit? Dies auf Knopfdruck? Nur anhand von Plänen? Der Ansatz ist genial. @Joachim Bin leider noch nicht dazu gekommen, für dein Bild da oben (morgen), aber beurteilen kann und will ich das Programm einstweilen nicht. Dies dauert bei mir halt länger. Horst |
Hallo Horst:
Danke, dass du mich daran erinnerst; ich wollte naemlich eine aehnliche Frage zu Blackart stellen. "Da ich nicht alles geleichzeitig ausprobieren, (bei Mesh auch nur Matthew Styles Programm benutzt und Greenwoods maui-Beispiel für die Auswirkungen im FS9) kann, zwei Fragen: a)Kann man mit Blackart die Daten einfach reparieren? Da ich leider nicht so viele Rohdaten habe, wollte ich dies erst später versuchen. b)Kann man diese Daten auch im FS während des Fluges sehen? (glaube ich nicht, sonst hätte ich wahrscheinlich schon etwas gefunden)" Zu b) kann ich nein sagen, da Blackart keine Verbindung zu FS ueber FDSConnect oder FSUIPC hat. Zu a) hatte ich eigentlich gehofft, diese Frage mit ja beantworten zu koennen. John's Interpolationsalgorithmen und Fuellmechanismen hoeren sich ganz vielversprechend an, als ich das aber anhand einer SRTM-Szene ausprobieren wollte, habe ich nur eine Windows-Fehlermeldung bekommen. Hat das schon mal jemand anderes ausprobiert? Im Prinzip ganz einfach: eine SRTM .hgt-Datei in Blackart laden, dann Image>Array Operations>Clip Negative Elevations und dann Image>Array Operations>Assigning Interpolated Elevations. Ich bekomme da immer einen "Access Violation" Fehler. http://www.terrainmap.com/index.html#top Dann habe ich noch die neue Version von 3DEM ausprobiert http://www.visualizationsoftware.com/3dem.html und dessen Umsetzung der Loecher-Fuellung von SRTM-Daten ist auch ganz interessant. Die Methode ist zwar nur einfache lineare Interpolation (gaehn!), aber man kann den gewuenschten Bereich (als Rechteck) frei waehlen. Das kann in bestimmten Gebieten sehr nuetzlich sein. Ciao, Holger P.S.: habe gerade nochmals auf einer der Landsat Seiten - http://glcfapp.umiacs.umd.edu:8080/esdi/index.jsp - nachgeschaut. Bei einer Path/Row Suche von Path 192-196, Row 19-27, mit ETM+ und TM links oben ausgewaehlt, finden sich da muntere 42 frei verfuegbare Datensaetze von Deutschland und dem Alpenraum. (Kann allerdings sein, dass nicht alle 100% wolkenfrei sind). Der Unterschied zwischen TM und ETM+ ist das letzterer einen zusaetzlichen 15-m Kanal hat, der aber fuer meine oben skizzierte Erstellung von Gewaessermasken unnoetig ist. Allerdings ist der 15-m Kanal fuer diejenigen interessant, die photoreale Texturen erzeugen wollen. Ich habe das mal in den Rockies ausprobiert und fuer Regionen ohne hochdetaillierte menschliche Bebauung sieht das ganz nett aus. Hier finden sich ein paar Screenshots dazu: http://portal.fsgenesis.net/modules....view_album.php |
Den Fehler bekomme ich auch. XP = mein Betriebssystem
b) Habe ich eigentlich nicht Blackart gemeint. Horst |
@Holger:
Zitat:
Zitat:
@Horst: Zitat:
Ist eine interessante Diskussion und ich würde es absolut begrüssen, wenn mal ein anderer ebenfalls was innerhalb Deutschlands an Strassen oder so machen würde. Dann würden nämlich endlich meine Flüsse und anderer Leute Mesh besser aussehen, ohne durch Microsoft-Berg- und Talstrassen behindert zu werden. Vielleicht mal ein kleines Beispiel, welche Arbeit ich mir ungefähr mit so einem Automatismus schenken würde (in meinem Beispiel mit meinen verfügbaren TOPO200-Karten) Der Automatismus benötigt doch - wenn ich es richtig verstanden habe - ein Hintergrundbild in gewissen Farbabstufungen und kann daraus das von Euch erzeugte LWM-Polygon oder ähnliches erzeugen. Dieses Erzeugen geht dann in Sekundenschnelle. Wie sieht denn real bei mir die Arbeit an den Flüssen aus: 1. Ich erzeuge mir aus den TOP200-Karten Teilbereiche, nehme mir also immer Teile aus den digitalen TOP200-Karten heraus und übernehme sie in mein Bildverarbeitungsprogramm. 2. Hier drehe und strecke ich sie so, bis Breiten- und Längengrade relativ gerade verlaufen 3. Dieses erzeugte bmp lade ich in ground2k in den Hintergrund und ermittle die Eckkoordinaten 4. Ich vergleiche Schritt für Schritt gewisse Höhenpunkte bei den Gewässern und stufe so meine zu zeichnenden Polygone "sanft" ab. Meist ergibt dies eine Anzahl x an Polygonen pro Bereich. 5. Ich excludiere die Microsoft-Bäche 6. Schlußendlich zeichne ich die Polygone nach und gebe Ihnen die Höhen mit Welche Arbeit dauert daran am längsten und beeinflußt die Qualität immens: Phase 2 und Phase 3 Das wirkliche Zeichnen geht (mittlerweile) sehr schnell, beim Excludieren kann ein kleiner Algorithmus hilfreich sein. Sehe ich das richtig, dass dieser Automatismus nicht die Phasen 2 und 3 genauso benötigt? Er braucht doch auch eine aufzubereitende Datengrundlage? Ausserdem habe ich dann das Problem, aufgrund der von Holger erläuterten Fehler (wegen Brücken etc...) trotzdem von Hand stark kontrollieren zu müssen. Ciao, Rainer. |
@Rainer
Vielleicht noch einmal der Link zu AutoAsm: http://forums.avsim.net/dcboard.php?...ng_type=search ein 923 kb download und kostenlos. Versuch es einmal. Readme lesen bzw. überfliegen und LA Fluten. Am Anfang mit den richtigen Ordnern aufpassen. Besser man probiert es selbst. Horst |
Hallo Rainer:
" Sehe ich das richtig, dass dieser Automatismus nicht die Phasen 2 und 3 genauso benötigt? Er braucht doch auch eine aufzubereitende Datengrundlage? " Ich beschraenke mich hier mal auf die Landsat-Daten, zunaechst mal ohne den Versuch, eine Gewaessermaske zu erzeugen. Fuer meine Ground2K4-Projekte ist der Ablauf der Folgende: 1. herunterladen eines geeigneten Datensatzes; jede Landsat Szene deckt etwa 180x180km ab. 2. laden und kombinieren der drei sichtbaren Spektralkanaele in ein GIS (GlobalMapper, Idrisi, usw.) 3. ausschneiden eines Teilbereiches (optional) 4. Transformierung von UTM nach lat/long 5. Uebertragung der Eckkoordinaten (ich benutze ein eigenes Excel-Spreadsheet, dass mir beim rechnen hilft; ist aber nicht unbedingt noetig) 6. speichern als .bmp und laden in Ground2K4 Das dauert etwa 30-45 Minuten und ich habe ein Hintegrundbild, das mir nicht nur Gewaesser und Infrastruktur gibt, sondern auch die reale Landnutzung, so dass ich Landklassen komplett oder partiell erneuern kann. Ich habe so vorbereitete Szenen bereits mehrfach an Leute verschickt, die selber kein GIS zur Transformation zur Verfuegung haben. Bin auch weiterhin dazu bereit, diesen Service fuer ernsthaft Interessierte zu leisten. Man kann das Ganze noch abkuerzen, indem man nur den 15-m panchromatischen Kanal nimmt. Dabei gewinnt man sogar noch an Aufloesung, verliert aber die hilfreiche Information der Farbgebung. (Es gibt die Moeglichkeit, die 30-m Spektralbaender in den 15-m Kanal einzuspleissen; das habe ich fuer meine Versuche der photorealen Texturen gemacht, ist aber etwas zeitaufwendiger). Wie gesagt, das war jetzt nur eine Beschreibung zur Erstellung von Hintergrundbildern fuer Ground2K4. Derselbe Ansatz kann dann erweitert werden, um Gewaessermasken zu erstellen. Im Kanal 4 bedarf dass nur eines einfachen Schwellenwertes, also keiner aufwendigen Klassifizierung. Die Frage ist aber natuerlich, ob autoasm sauber genug arbeitet, dass man nicht muehselig von Hand die .asm Datei nacharbeiten muss. In dem Falle denke ich auch, dass das Nachzeichnen direkt in Ground2K4 schneller ist. Da faellt mir gerade etwas ein: wie waere es, wenn man "Strip", was ja recht sauber auch feine Kuestenlinien erfasst, durch einen Trick dazu verleiten wuerde, eine Gewaessermaske als Kueste anzusehen. Die von Strip auf 0m gesetzten Hoehen muesste man dann in der .asm Datei entweder mit -9999 oder abgestuften Hoehen ersetzen. Muesste ich direkt mal ausprobieren, ich habe naemlich noch ein paar Gewaessermasken irgenwo in den Tiefen meiner HD ;-) Ciao, Holger |
Hi!
Höchst interessante Beiträge zu Ground2K und auch den neueren Tools. Verstehe zwar t.w. nur Bahnof ;)doch das,was ich verstehe,lässt uns alle auf eine Entwicklungsreiche Zukunft blicken:) Genau wie Rainer seine Top200 Karten in Ground2K einfügt,mache ich es auch,allerdings mit Top50 Karten. So wie es Holger angeht, ist es mir mind.eine Nr. zu hoch:rolleyes: Da fehlt mir der Dipl.ing.;) Gruß::) |
Hallo nochmals:
nach dem vielen Text vielleicht mal ein Bild von meinem G2K4 "Arbeitsplatz" mit Landsat ETM Hintergrund. Cheers, Holger |
Also die Seite http://glcfapp.umiacs.umd.edu:8080/esdi/index.jsp
ist ja auf den ersten kurzen Blick eine wahre Fundgrube. Auch Deine I-Net präsents wirkt sehr gepflegt. Tja und Bilder sagen eben mehr als 1000 Worte. Gruß: :) |
Die Annäherung an Mesh und deren Umsetzung im FS9 ist bei mir gering. Bzw nicht vorhanden.
Meine Frage dazu ist ja vielleicht unverschämt: Kann man diese Daten auch im LWMViewer darstellen? Derzeit nicht, aber gibt es eine Möglichkeit? Man könnte damit, vielleicht auch ein FS-Analyse Tool erstellen (?). D.h das Wissen aller Werkzeuge vereinigen. (Fehler leichter zu erkennen). Mein Ansatz deshalb: Ich möchte diese Daten derzeit sehen, ob und wo diese Löcher auch im FS dargestellt werden. Wie geschrieben, ich habe keine Ahnung, wie viel Punkte ich überhaupt im FS brauche, damit interpolieren überhaupt Sinn macht. Horst |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 14:04 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag