Für RLUND unsichtbare Runway

[Horst LOWW]

Joachim,
Also das Demo Projekt und Terrain schaffe ich derzeit nicht.
Ich muss jedoch noch die verwendeten Bitmaps (die beigelegt sind) abändern, vielleicht funktioniert dies dann fehlerfrei.
Vielleicht verursachen solche Bitmaps Fehler.
Auch das TerraScene Bitmap muss ich noch probieren.

Wollte eigentlich nur hinweisen, dass die beigelegten Inc Dateien veraltet sind. Hier gibt es einen neue Version von TDFMacros:
http://library.avsim.net/search.php?...zip&CatID=Root

Horst

[Horst LOWW]

@Holger
Bezüglich verschiedenen Mesh, habe ich Joachims Foto wieder gefunden auf meinem PC.
Ich hoffe er hat nichts dagegen, wenn ich dies noch einmal anhänge.
Dies ist schon ein Problem auf engen Raum.

Horst

[BC_Holger]

Tachchen!

Habe gerade meine Jungfernfahrt mit Autoasm (v1.00, December 20, 2003 6:33:32 PM) hinter mich gebracht.

Also, wenn ich die obigen Texte richtig verstanden habe, geht es um:

1. ungewuenschte LWM Polys beim kompilieren der Beispiele
2. die hohe Anzahl der Punkte bei den VTP2-Linien

Zunaechst habe ich erst mal Autoasm eigestellt mit den Ordnern:
F:\AutoAsm
F:\Program Files\FS2004\Addon Scenery\aaa Autoasm test scenery\scenery
F:\AutoAsm\terrain
F:\Program Files\FS2004

Diese Einstellung habe ich in autoasm.ini uebertragen und gespeichert, damit ich nicht fuer jedes Projekt neu Ordner einstellen muss.

Ansonsten hatte ich nur Schwierigkeiten mit der VTP Generierung von ts_demo, wo mir zunaechst ein Speicherfehler (#7) in die Quere kam. Habe dann aber in einer Avsim-Diskussion den Tip gelesen, die Memory-Einstellung zu erhoehen; bei mir musste ich von 100,000 auf 5,000,000 erhoehen, um ts_demo erfolgreich abzuschliessen: http://forums.avsim.net/dcboard.php?...6520&mode=full


Meine Ergebnisse:

Die 'circle' Demo fuehrt zu zwei zusaetzlichen kleinen LWMs am unteren Rand der LOD8 Zellen rechts unten und links oben.

Die 'ts_demo' Demo generiert keine (!) zusaetzlichen LWMs, allerdings fehlt eine LOD13 Area im westlichen Arm des grossen Sees.

Zu den VTP-Linien von 'ts_demo' kann ich nur sagen, dass zum einen die Strassendichte schon ganz nett ist, die Strassen selber aber eher wie eine Studie von Dali aussehen (siehe angehaengtes Bild) - oops, war das jetzt genoergelt?

Wenn das Eingabe .bmp so genau ist, frage ich mich, wieso so viele Strassen unverbunden bleiben? Und dass die so krakelig aussehen, haengt wohl mit der 1:1-Umsetzung der Punktdichte zusammen? Na ja, vielleicht laesst sich da mit verschiedenen Einstellungen oder Linientypen mehr herauskitzeln. Ist also nur eine vorlauefige Beobachtung.

Die Seeufer-VTPs scheinen etwas konsistenter generiert als in "Strip" (habe allerdings Strip noch nicht mit ts_demo.bmp getestet), sind aber recht schmal und oft zu weit im Wasser oder landeinwaerts (die Breite kann man aber vor der VTP-Generierung aendern).

Soviel fuers Erste.

Horst, besten Dank fuer das angehaengte Bild des Mesh-Mosaiks. Sehr interessant; jedenfalls muesste man sich beim Einsatz von Strip auf einen Rohdatensatz festlegen, es sei denn man nutzt Jim's tmfdecompress.exe, um sich da (illegal) selber eine Kombi-Mesh zurechtzubasteln.

Habt ihr uebrigens schon die Meshdarstellung der neuen LWMViewer-Version gesehen? Sehr nett! Ich habe Jim noch ein paar typische DEM-Farbskalen zur Auswahl geschickt, da die gegenwaertige zu wenig Farbabstufungen durchlaeuft (meiner Meinung nach): http://www.jimkeir.co.uk/FlightSim/LWMViewer.html

Und dann gibt's auch noch Edgars neuen Childpoint Converter V1.0, der angeblich das Problem mit den wildgewordenen VTP2-Autogen von Ground2K loest: http://forums.avsim.net/dcboard.php?...id=17057&page=

Tools, tools, tools.

Ciao, Holger

[BC_Holger]

... und hier noch das Ergebnis von ts_demo. Beachtet die fehlende Wasserzelle im westlichen Seearm.

Huch! Interessant - diese (erste) Version hat gar keine fehlende Zelle, die zweite Version aber doch. Hmmm...

[BC_Holger]

... also hier dann noch die gegenwaertige LWM Version mit Loch.

Ciao, Holger

[JOBIA]

Zu Holger

"Habe gerade meine Jungfernfahrt mit Autoasm (v1.00, December 20, 2003 6:33:32 PM) hinter mich gebracht".

Das verwundert mich. Der Chris hat ja nirgends direkt seine Versionsnummer abgelegt. Als Gymmick hat er in meiner Version eine Bitmap die über die Info Schaltfläche ausgelesen wird (ähnlich der Sceneryauslesung). Da wird bei mir Version 0.6 vom 22.12.03 gemeldet. Auch die Word Doc spricht bei mir von der Version 0.6

Du hast eine Version 1.00 die aber vom Datum her älter als meine Version ist. Deine Versionsnummer ist wiederrum höher. Sehr seltsam.

Kannst Du mir den Link nennen wo Du die her hast.

Ich hatte sie wie gesagt über den Link geladen den er selbst im AVSIM Forum genannt hatte.

Lässt man das Zip File aus der Adresse aus landet man direkt auf seiner Homepage. Dort ist allerdings überhaupt kein Bezug zum FS erkennbar. Er hat die Page offensichtlich nur zum ablegen des Tools genutzt.

Hier mal der Link den er genannt hatte.


http://www.kline.demon.co.uk/autoasm.zip


Komischerweise habe ich es bei AVSIM auch nicht gefunden.

Auf jeden Fall bin ich beruhigt das Du bei einem Gebiet zusätzliche LWMs hast. Komischerweise hatte ich wiederrum beim Circle keine zusätzlichen LWMs. Ich denke das ist eine eindeutige Aussage das da etwas faul ist. Das Du es nicht bei TS_Demo hast könnte jetzt auch an einer anderen Version liegen.

Mit den Speichereinstellungen hatte ich auch schon rumgespielt, hat nichts gebracht hinsichtlich der Probleme.

Horst hat zwar nicht das LWM Problem aber er sagt ja selbst das Die Ergebnisse unterschiedlich sind wenn man andere Koordinaten angibt der Rest aber unverändert bleibt.

Zu deinem Satz
"Wenn das Eingabe .bmp so genau ist, frage ich mich, wieso so viele Strassen unverbunden bleiben?"

Ich denke mal da wird man den Search Radius hochsetzen müssen.



"Und dass die so krakelig aussehen, haengt wohl mit der 1:1-Umsetzung der Punktdichte zusammen?"

Denke ich auch. Denn das war bei mir immer dann der Fall wenn Die Information in der Bitmap dichter als der mögliche Vectorpointsabstand des FS war. Dann versucht er auch hier jeden Punkt umzusetzen. Erreichen tut er dieses dadurch das er den Vectorpoint wiederholt bzw. mal um einen Punkt nach rechts, links, oben oder unten ausweicht.


"Na ja, vielleicht laesst sich da mit verschiedenen Einstellungen oder Linientypen mehr herauskitzeln. Ist also nur eine vorlauefige Beobachtung"

Ich vermute mal fast nicht. In meiner Version gibt es keinen Steuerparameter der dieses zulässt.

Ev. ist das in Deiner oder Horst seiner Version anders.

Momentan sehe ich nur bei den Vectorpoints die Chance einen Bitmapmasstab zu wählen das die Pixel der Bitmap koordinatenmäßig gesehen einen größeren Abstand als die Vectorpoints des FS haben.

Ist natürlich auch nicht optimal.

Bei den LWMs keine Ahnung was da bei der Umwandlung in den ASM Code passiert.

[Horst LOWW]

Wahnsinn, habe gerade mit dem neuen LWMViewer herumgespielt. Toll jetzt sehe ich nicht nur die genau Abdeckung der einzelnen Meshdaten, sondern auch die Löcher. Ich hänge einmal ein Bild an.
Dies sollten Löcher im Mesh (Allegmane) sein. Sieht so aus wie beim Mauszeiger. Auch in der Umgebung relativ viele Stellen. Aber vielleicht interpretiere ich dies falsch. Meine Mesh- Kenntnisse sind noch zu gering.

Aber Jim Keir ein fähiger Mann, herzlichen Dank für seine Arbeit.

Das Fehlen von Lod 13 Area kann ich bestätigen. Ist mir auch aufgefallen, nur bei der Area daneben (westlich). Die Ursache dafür habe ich noch nicht gefunden, da es meiner Meinung mit der Erzeugung (also Ablauf, mit und ohne LWM, bzw Auto, Load, Save) zusammenhängt. Sehr selten auftritt. Sollte man beachten, vielleicht finden wir den Grund oder den Zusammenhang.

Zum Vergleich habe ich auf Seite 4 Ts_demo angehängt (test.jpg). Also muss ich da noch Fehler machen, da ich die Straßen gar nicht sehe. Ich denke auch, dass dieses TS_Demo Bitmap auch nicht geeignet ist.
Das TS1 Bitmap muss ich noch probieren.

Auch der Hinweis von Wright in der Anleitung, für Load, Save und anschließend wieder Read data, sollten wir beachten.
Ich für meinen Teil, muss diese Anleitung noch einmal Zeile für Zeile durchlesen und ausprobieren.

Verbindet man die Daten mit Höhendaten (in AA noch nicht möglich), muss jeder Anwender dieselben Daten haben (vielleicht deshalb auch Srtm, da sich dies jeder derzeit selbst erzeugen kann). Ansonsten kann man nur das geeignete Bitmap anhängen und der Anwender muss es selbst erzeugen. Wie bei AFCAD damals mit der Textdatei.

Joachim, unter Datei-Eigenschaften findest du wahrscheinlich auch bei dir die Information. Wie ich dir weiter oben beschrieben habe.
Bei FS2004 Geländedetails habe ich gestern zu einem alten Beitrag verlinkt. In diesem Beitrag erwähnst du ein Werkzeug: Toposcan von Bernhard. Kann ich dies im WWW finden, bzw. wo? Falls deine Antwort nicht für ein öffentliches Forum geeignet ist, würde ich um eine kurze Antwort per Mail bitten.

Da ich mich wieder in meine heimatliche Bergwelt zum Schifahren zurückziehe, ist dies mein letzter Beitrag. Internet und Computer bleiben, zum Wohle meiner Familie und mir, zu Hause.
Weiter testen werde ich erst wieder in der zweiten Februarwoche.

Ich würde aber bitten den Beitrag hier aufrecht zu erhalten. Nachdem wir uns auf einen sachlichen Austausch geeinigt haben, mischt sich auch keiner mehr ein, der sich nicht ernsthaft mit diesen Programmen beschäftigt. Und durchlesen von A-Z wird ihn so und so kein Neuer mehr.
Auch die Verlinkung zu neuen Werkzeugen und interessanten Beiträgen finde ich toll.

Ich denke, dies sind Werkzeuge, die mir noch viel Freude bereiten werden. Vielleicht auch wenn man sie verbindet und daraus ein tolles Tool macht. Wir sollten weitertesten und den richtigen Input bzw. Bitmap, für Jedermann erzeugbar, suchen. Und auch beachten, warum dies mit bglcomp derzeit noch nicht funktioniert. Bzw. ob sich hier Fehlerquellen ergeben können, für die Zukunft.

Horst

[Horst LOWW]

Da ich jetzt doch noch Zeit für einen kurzen Beitrag finde (große Familie = viel Gepäck), bevor ich meine „Kiste“ für eine Woche abdrehe.

Dient nur zur Fantasieanregung:

Strip kenne ich nicht. Aber mit AA sollte es möglich sein, auch Terrain zu erzeugen. Zumindest laut Anleitung. Ich füttere dieses Programm derzeit noch nicht mit eigenen Bitmaps.
Aber hänge hier ganz einfach ein jpg aus Höhendaten an (ein Knopfdruck). In diesem Format (jpg) ist dies nicht zu gebrauchen, aber ich kann es sonst nicht hier anhängen. Man kann aber aus anderen Daten, andere Formate erzeugen. Bzw. die Höhenschichten auch anders darstellen. Oder auch mit tmfdecompress raw Daten erzeugen.

[Horst LOWW]

Man kann diese Daten auch in farbigen Formaten darstellen. Laut Anleitung kann ich diesen Daten auch noch die Botanik richtig zuordnen.
Wenn ich diesen Colour-Index (derzeit denke ich nicht) richtig darstelle, habe ich die richtige Texture/Autogen auch noch am richtigen Platz.
Wenn ich dieses angehängte Bitmap auch noch mit realen Vegetationen-Bitmaps verbinde ( z.B Waldgrenzen, Weinberge), wird die Eingabe, das richtige Bitmap, sehr interessant.
Wenn ich über die terrain.cfg noch die richtigen Bitmaps zuordne, kann ich theoretisch auch noch verschiedene Texturen zuweisen (Vegetation sieht auf jeder Höhenstufe anders aus – bzw der Mensch greift hier sehr stark ein – siehe Waldbau - Kahlschlagflächen).

Ich bin ein sehr fantasievoller Mensch – verbinden wir vorhandene Daten auch für den Flusi.

Daher die Bitte: Füttern wir fähige Leute wie Jim Keir und Chris Wright mit unseren Ideen, die wir vorher überprüfen. Damit wir diese fähigen Programmierer nicht quälen. Damit sie Spaß auch an ihrer Arbeit haben.

Dies braucht jedoch Zeit.

Genug.

Horst

[JOBIA]

Horst das ist im Prinzip aber alles seit langem bekannt. Mesh wurde schon immer über RAW/BIN Dateien programmiert. Jedes Tool welches ev. komfortabel arbeitet muß letzendlich zu BGL Erzeugung den Weg über die SDK resample.exe gehen. Das ist bei Autoasm nicht anders.

Ich habe z.B alle meine Testmeshfiles und Landclassfiles in Adope Photoshop programmiert. Hier kannst Du auch aus einer Karte die Farbinformation auslesen und automatisch Landclass programmieren. Das habe ich schon im Sommer 2002 so realisiert.

Im Prinzip ist Autoasm für Mesh bzw. Landclass jetzt eine etwas komfortablere Möglichkeit. Wie gesagt geht alles mit einem Fotoprogramm. Du musst nur die Pixel der Kartenbitmap quasi in das LOD Raster des FS bringen so das dieses flächenmäßig alles passt.


Eine statistische LC Zuweisung abhängig von der Höhe hatte auch schon FS Landclass von B.Renk. Das Prog. gab es im Frühjahr 2002 schon.

Das Problem in unserem lieben Lande ist aber in der Regel die Verfügbarkeit von Daten die hier 100% geeignet wären. Wie so oft der Liebe Input. Super wäre morphologisches Kartenwerk. Das hatte ich schon mal vor langer Zeit geschrieben. Dieses wurde unter anderem auch in der Mobilfunkplanung genutzt.

Da konnte man sehen wo Wälder sind, welche Waldarten, Ackerbau, Sumpf, Wiesen, Städte mit jeweiliger Bevölkerungsdichte des Stadtteiles usw. Alles schön farblich abgesetzt.

Ich hatte damals versucht über TOP50 auszuwerten. Leider wird da zu oft die selbe Farbe verwendet. Orte/Städte immer schwarz. Die Straßen leider auch. Da kann man dann schlecht sagen hier ist Industriegebiet dort ist Wohngebiet usw.

Morphologisches Material bekommst Du nicht umsonst. Ist unbezahlbar.

Gut kann sein das man vieles auch über die verschiedensten Aufnahmetechniken von Satelitten rausziehen kann. Holger hat da ja ein paar gute Tipps gegeben. Setzt natürlich den Zugriff auf eine schnelle Datenverbindung vorraus.