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