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