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.
|