Hallo Horst:

das einzige Tool (soweit mir bekannt) das derzeit FS Mesh grafisch darstellen kann ist TMFViewer, das ja Teil der Scenery SDK Dokumentation ist.

Aber... Jim hat mir noch ein anderes Tool mit Strip mitgeschickt, einen Mesh-Decompiler, der existierende FS mesh .bgl (und auch Land/Waterclass) Dateien wieder in bearbeitbare .raw Formate umsetzt. Ausserdem wird es wohl demnaechst einen Update fuer LWMViewer geben, der auch Meshdarstellung erlaubt.

In der Zwischenzeit kann ich nur Christian Stock's TMF Manual (Englisch!) empfehlen (bei avsim usw), dass meiner Meinung nach immer noch die am verstaendlichsten geschriebene Zusammenfassung der FS-Prinzipien der Mesh, LC, Texture, usw. Darstellung ist.


Schubi: danke fuer das Lob; nette Auswahl an smileys ;)

Ciao, Holger

Christina Stock habe ich gelesen, TmfViewer kenne ich und benutze ich.
Ja, es gibt diese Werkzeuge.
Verbinden wir sie doch? Ob dies nützlich, und vorallem einfach ist, keine Ahnung.
Sicher unverschämt, dies auch grafisch darzustellen (aber denken wir darüber nach, wenn es einfach ist). Wie geschrieben, keine Ahnung. Aber großartig wäre es.
Nur eine Idee, und auch nicht unbedingt notwendig, und keine Antwort nötig.

Horst

@Holger
Was ich hier etwas spät angedeutet habe könnte uns allen, also Konsumenten und Entwicklern, helfen.
Daher will ich meine Gedanken etwas ausführlicher darstellen, und dich bitten dies Jim Keir darzulegen, und „schmackhaft“ zu machen.

Kann man aus dem LWMViewer eine Art Diagnosetool machen?

Natürlich würde ich mir dies lieber von MS wünschen, und für sie wäre es leichter. Aber bekommen werde ich es wahrscheinlich nie.

Warum?

Wir tauschen zumeist, bei angeblichen Fehlern, nur und immer wieder Vermutungen aus.
Wir können es nicht auf den Punkt bringen. Wir sind halt oberflächlich und überprüfen selbst nicht genug. Es ist eben sehr zeitaufwendig und mit Wissen verbunden.
Nicht nur hier im Forum, sondern auch in vielen Foren auf der Welt.

Deshalb hat MS wahrscheinlich auch die Funktion Problemberichterstattung eingeführt. Da es wirklich keinen Sinn macht, Programmfehler durch Kundenangaben zu finden. Man muss Mittel haben dies genauer und schnell zu analysieren. Dies funktioniert elektronisch und ergibt eine Statistik. Eigentlich eine sehr gute Idee. Ob dies MS auswertet und umsetzt - keine Ahnung.

Was haben wir im Flugsimulator (FS)?

Für unsere Hardware und andere Software, gibt es Diagnosetools und auch Protokolle und Dienste, wo man eventuelle Schwächen und Fehler erkennen kann. (Hier sollte mancher Anwender halt manchmal zuerst sein System überprüfen bzw. kennen lernen, oder diese Werte)

Auch den Problembericht, der uns relativ wenig sagt, außer welche dll betroffen ist.

Und bei dem CTD in Sion eigentlich nichts.
Zum Glück hat Joachim relativ rasch, die richtige Vermutung gehabt. Simpel und richtig abgeschaltet. Sonst hätten wir sehr lange Zeit vermutet, woher dies kommt.
Klären kann man es später.

Was haben wir?

LWMViewer, tmf viewer,Tcalc, DefArea, Blackart, usw. usw.

Was brauchen wir?

Ein Freewaretool, dass dies alles verbindet und das jeder installiert haben soll.
Man stellt sein Flugzeug auf einen Punkt im FS und hat alle relevanten Daten.

Der Laie braucht anfangs nicht zu verstehen, was er da sieht, aber der helfende Experte hat sehr schnell die richtigen Daten für die Frage.

Ich denke wir würden uns sachlicher unterhalten, und nicht so viele Vermutungen anstellen.

Wer soll dies tun?

Hier die Unverschämtheit, da ich hier Arbeit umsonst von jemand einfordere, da ich es selbst nicht kann. Und auch nicht notwendig finde, dass dies jetzt ein Neuer macht.

Es soll jeder Entwickler dieser tollen Werkzeuge sagen, wo er es ausliest und wie. Er gibt die Informationen einem, der ein simples und einfach zu bedienendes Werkzeug erstellt. Das eigentlich nur Daten richtig ausliest, und diese Daten event. in einer txt zu speichern sind.
Soviel wie möglich grafisch, der Rest mit nackten Zahlen.

Einfach und simpel, als Freeware, und soviel Daten wie möglich.

Zeitaufwand für die Entwicklung – ich habe leider keine Ahnung.

Vorteil?

Der Betroffene liefert für den Fehler entscheidende Daten, bzw findet sie selber leicht und vor allem richtig.
Der Zeitaufwand für den Anwender ist gering.
Der FS9 würde nicht zu schnell als Absturzsimulator bezeichnet.
Der Betroffene hätte relativ schnell die Werte richtig erzeugt, ohne es zu verstehen.
Es werden weniger Vermutungen ausgesprochen, die Diskussionen werden sachlicher.

Holger, hättest du nicht auch gleich lieber die Seasonslinie richtig gesehen?

Vorschlag für die Einbindung von Daten?

Hier erfindet man das Rad ja nicht wieder, sondern trägt nur Wissen zusammen und kombiniert es in EIN Werkzeug, das Freeware angeboten wird. Und Standart für jeden FS-Freund sein soll.

- relevante FS9.cfg Daten (z.B vertex –level und andere)
- Mesh. Wir reden zwar viel von diesen Daten, Löchern, Interpolieren (für Mitlesende: http://www.geoinformatik.uni-rostock...zel.asp?ID=991). Aber niemand macht sich Gedanken, was dies bedeutet und wie dies umgesetzt wird im FS9.
Daher auch hier Daten für den Anwender, damit er dies zumindest sieht, bzw weiß welche bgl jetzt aktiv ist. Eben z.B bei sehr vielen Meshdaten und deren Überlappung. Er braucht ja nicht das System verstehen aber sehen, muss er die Fehlerquelle. Man kann es leichter erklären.
-Gerade aktive Texturen für einen bestimmten Radius als Momentaufnahme, nicht für Addon (Joachim?)
-?

Man nörgelt, weil man vermutet. Weil man es nicht überprüft hat, bzw. es nicht kann
Auch bei Flugzeugen:
Siehe hier: http://www.wcm.at/forum/showthread.p...ight=pss+merge
Wenn ich die Situation nicht exakt darstellen kann, kann ich sie auch nicht richtig testen. Wenn der Entwickler dies kann, warum gibt er mir nicht diese Möglichkeit?

Holger du hast Recht, es ist wirklich sehr schwer in einem deutschsprachigen Forum mitzulesen (aber auch in anderen).
Aber wir brauchen auch Werkzeuge, die es den Anwender leicht machen dies nachzuvollziehen, ohne Fachwissen.

Viel Text, aber man kann es ja zweimal lesen, und ein wenig darüber nachdenken. Man erspart sich dadurch sehr viel Zeit. Sich selbst und beim Schreiben von Beiträgen.

Horst

@Joachim

Ich bin da leider etwas langsamer in der Aufarbeitung (auch Zeitmangel). Da ich selbst auch öfter Laufzeitfehler verursache, die ich mir bis jetzt erklären konnte.

Kommentar zu deinem Bild:
a) Dies wird bei mir nicht erzeugt, ich finde nur Projektdaten (siehe angehängtes Bild).

Ts_Demo geöffnet, Centre Position N10 E50, LWM only deaktiviert. Auto cull und fill aktiv, search radius 16.
Read data (40 Sekunden)
Write LWM (6 sek).
Write VTP (5 sek)

Probier dies vielleicht noch einmal.

b) Eigene Bitmaps erzeuge ich bis jetzt nicht, da ich zuerst die Funktionen des Programmes verstehen möchte und als Vergleich nur die Demofiles angeben will.
Zu der Geraden:
Ich gebe dir Recht 98 Punkte zuviel. Aber hier durchläuft sie mit 100 Punkten 7 LOD 13 Zellen. Dies ist doch eine lange Gerade, oder?
Natürlich sollten so viele Points wie möglich vermieden werden.
Performance für das gesamte Projekt?
Wie?
Hier sehe ich die Möglichkeit eventuell die Anzahl der Punkte im Projekt zu reduzieren. Also nachdem sie eingelesen wurden. Ich denke dabei an die Möglichkeit, beim unterschiedlichen Kurvenradius von Autobahnen oder eben Forststraßen.
Oder eine zweite Möglichkeit über read data, extra Daten nur für Bitmaps mit vielen Geraden anders einzulesen.
Ob wir dies brauchen, muss man sich ansehen, bzw den Einfluss auf die Performance messen.

Daher wäre es vielleicht gut, wenn Rainer mitspielt. Er könnte event. sein Projekt mit AutoAsm erzeugen. Wir hätten einen Vergleich zu den Points mit Ground2K. Wenn er die selben Vorlagen nimmt.

Mein weiteres Vorgehen:
1)Lernen der Funktionen und deren Auswirkung anhand der Demos
2)Inputmöglichkeiten und deren Auswirkungen, also erstellen von Bitmaps, bzw suchen nach geeigneten Informationen.

Die bglcomp funktioniert nicht, aber dies schreibt Chris Wright im Link.

Horst

Erst kommt jetzt das OWL2003-Update für den FS2004. Kann also leider momentan bei Euren Versuchen nicht helfen.

Ciao,
Rainer.

Zu Horst

"Kommentar zu deinem Bild:
a) Dies wird bei mir nicht erzeugt, ich finde nur Projektdaten (siehe angehängtes Bild)".

Schau noch mal nach Horst. dein Screenshot stellt die Problembereiche nicht dar sie sind einmal weiter nordwestlich und einmal z.B weiter südwestlich. Das was man auf deinem Bild sieht ist bei mir auch OK.

Ansonsten ich habe es jetzt auch auf meinem Notebook gecheckt. das selbe Problem bei mir.

Dann zu:

"Zu der Geraden:
Ich gebe dir Recht 98 Punkte zuviel. Aber hier durchläuft sie mit 100 Punkten 7 LOD 13 Zellen. Dies ist doch eine lange Gerade, oder?
Natürlich sollten so viele Points wie möglich vermieden werden".

Korrekt wenn sich die Points über mehrere Zellen ziehen wäre das akzeptabel. Aber wie ich oben schrieb ist der Maßstab egal es werden bei mir immer alle umgesetzt. Auch wenn die 100 Punkte innerhalb von 10 Metern liegen würden. dann würden hallt mehrere Punkte den selben x/Y Wert haben.

Daher meine Hoffnung das mein Download ev. fehlerhaft war und irgendetwas nicht stimmt.


Zu Autoasm allgemein also auch für die anderen. Man darf sich das nicht so vorstellen das man hier einfach einen Kartensreenshot nehmen kann. Das ganze muß schon bereinigt und vorbereitet werden.

Zu Schubi.
Ja es hört sich am Anfang komplex an. Ist es aber eigentlcih nicht.

Wenn man wie gesagt wie Rainer TOP200 oder gar TOP50 besitzt (kostet natürlich Geld) dann hat man aber schon optimales Material für Gewässer usw. TOP50 ein Bundesland ca. 50 Euro.

Es gibt aber auch Alternativen. Wenn ich mir z.B Dirk seine Hamburgscenery und einige Elemente anschaue dann kann ich schon sehr stark davon ausgehen das hier vermutlich D-SAT als Basis diente.

Preis ca 49 Euro ganz Deutschland. Eine alte version z.B 5.0 die bestimmt nicht viel schlechter ist (ein paar Luftbilder von Städten weniger) lässt sich bestimmt um 20 Euro ergattern.

Was mir sehr positiv aufgefallen ist und durchaus für eine Polygonscenery reichen würde (auch fürs Straßensystem tauglich) wenn man mit Ground2k arbeiten würde ist halt Daten von Autonavigationssystemen. Hier z.B die Software Navigon. Übrigends angespeckt findet man dieses system auch im Aldi Nav System da natürlich als Medion Naviagtor. Da diverse Routenplaner mittlerweile auch auf Navi Material beruhen zum Teil kaum ein Unterschied feststellbar taugt ev. dieses auch.

Das oben geschilderte bezieht sich aber immmer darauf das man ein Bild aus so einer Software hat. Dieses Bild muß wie gesagt in der Regel entzerrt werden.

Wie gesagt wenn man diesen Code der NAV Daten bei Navisystemen selbst knacken könnte (leider gibt es hier von version zu Version schon Abweichungen) und dann in FS Vectorcode konvertieren könnte, hätte man zumindest für Europa den Stein der Weisen gefunden.

Zu Rainer

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


"Sehe ich das richtig, dass dieser Automatismus nicht die Phasen 2 und 3 genauso benötigt?

Nein siehst Du leider falsch.

bei Ground2K hat man ja bisher immer den linken oberen und den rechten unteren Eckpunkt angegeben zwecks Kartenbitmapeinbindung.

Ist bei der neuen Version beim überfliegen der Anleitung wohl noch erweitert worden ähnlich Autoasm.

Nun wie ist es bei Autoasm.

Hier wird der Mittelpunkt der Karte definiert. Weiterhin die Spreizung in der Vertikalen und Horizontalen in Grad. Es ist auch hier nicht möglich jeden Eckpunkt vorzudefinieren. Damit muß auch hier eine Karte vorher entzerrt werden. Wenn man es genau nimmt muß man ja nicht nur trapezförmig entzerren sondern auch noch bogenförmig.

Bei kleinen Bereichen muß man das aber nicht so pingelig sehen.

Die Bitmap ist bei Autoasm übrigends schon sehr pingelig vorzubereiten.

Kommt halt drauf an was man vorliegen hat.

Achso... danke!

Exakt dies macht die Arbeit so zeitaufwändig.

;) Und dies aus Deinem Mund. ;) :D

Ciao,
Rainer.

Gleiten wir jetzt auch schon hier ab, in die „normale“ Aufarbeitung in diesem Forum?
Ist Lesen und Denken auch hier Pflicht?
Sonst brauche ich nichts mehr schreiben, oder schreibe meinen letzten Beitrag.

Horst

Zu Horst

"Gleiten wir jetzt auch schon hier ab, in die „normale“ Aufarbeitung in diesem Forum?
Ist Lesen und Denken auch hier Pflicht?
Sonst brauche ich nichts mehr schreiben, oder schreibe meinen letzten Beitrag."

Wie darf ich denn das verstehen. Ich glaube ich verstehe es nämlich nicht.


Sollte es sich auf mich beziehen musst Du mir das genauer erklären?

Teilweise war es Aufarbeitung von Fragen. Frage ergibt Antwort. Wie so oft im Forum eingefordert also ohne viel drum herum.
Ist also nichts gegen einzuwenden. Dann steht auch neues mit drin.

Für mehr habe ich am Wochenende keine Zeit gehabt.

Daher wäre mir dran gelegen ob ich damit gemeint war.

Derzeit habe ich ja noch Geduld.

Wir unterhalten uns sehr kompliziert, lesen nicht – und verbringen unsere Freizeit mit dem Verfassen von langwierigen Texten über Vermutungen. Wir erzeugen dadurch Vorurteile.

Über Fragen darf man vorher Nachdenken, und in Antworten soll man sehr wenige Vermutungen einfliesen lassen.
Über Antworten soll man Nachdenken, bevor man wieder eine Frage formuliert.

Joachim, du hättest, wahrscheinlich dieses Bild nicht gezeigt, wenn du über diese Points richtig nachdenkst. Bei seinen Fragen zuerst selbst überprüfen, wie dies im Programm dargestellt werden soll, bzw auch wird.
Vielleicht kann man hier wissenschaftlicher vorgehen, als etwas zu „zerlegen“.

Ein postives Beispiel hier im Beitrag:
Frage: verursacht die Funktion x in Blackart einen Fehler?
Antwort: ja
Erklärung: derzeit nicht möglich = Nachdenken

Horst

Zu Deinem Text

Joachim, du hättest, wahrscheinlich dieses Bild nicht gezeigt, wenn du über diese Points richtig nachdenkst. Bei seinen Fragen zuerst selbst überprüfen, wie dies im Programm dargestellt werden soll, bzw auch wird.
Vielleicht kann man hier wissenschaftlicher vorgehen, als etwas zu „zerlegen“.


Wenn Du dabei auf Autoasm anspielst.

Es war unter anderem die Frage ob jemand mit Autoasm schon mal was gemacht hat und probiert hat. Nun das war mein Ergebnis bei den Demodateien. Bei meinen persönlichen Bitmaps sah das genau so aus. Da wie gesagt im Code immer alle Points umgesetzt werden ist das aus meiner Sicht nicht unbedingt positiv. Das Programm als solches ist gut. Ich hatte auch zurückgefragt ob sich dieses bei Dir oder jemand anderen bestätigt. Das sind also keine Vermutungen sondern das was bei mir Tatsache ist.

Das Bild diente dazu den Sachverhalt zu verdeutlichen.

Was hier offensichtlich fehlt sei es das es bei mir ev. aus irgendwelchen Gründen nicht funktioniert habe ich geschrieben. Du kannst mir glauben ich habe bei Autoasm genau nachgedacht. Warum es dieses Problem gibt also den eigentlichen Grund ergründen kann ich nicht, weil es bei mir eben immer so hinten raus kommt egal was ich einstelle.

Deshalb wäre es ja interessant gewesen was bei Dir hinten rauskommt.

Zu diesem Problem mit den LWMs. Bei deinen Screenshot ist der Bereich der bei mir fehlerhaft ist nicht dargestellt, deshalb bin ich hier auch nicht schlauer.


Ich denke aber ich habe auch anderweitig schon oft bei Fehlern irgendwelcher Art weitergeholfen, das beruht ja nun nicht alles auf Vermutungen.

Man muß das ganze auch mal so sehen Du sagst das Du manchmal wenig Zeit hast. Ich kenne Deine Gründe nicht. Man spricht zwar nicht unbedingt drüber im Forum. Ich habe Frau und 4 jährige Tochter zu Hause. Meine Frau ist von meinem Hobby nicht gerade begeistert.

Es gibt daher wegen des FS des öfteren Streß. Ich denke das geht einigen so. Daher ist es bei mir immer eine Gratwanderung. Ich möchte nicht eines Tages vor der Frage stehen FS oder Familie. Daher muß auch ich mir meine Zeit einteilen. Ich hinke eigentlich immer dem hinterher was ich eigentlich machen möchte.

Auch wenn mal Vermutungen dabei sind so tragen die oft zu Lösungen bei. Ev. kann so ein Gedankengang bei jemand anderen das Licht aufgehen lassen.

Bei Autoasm sind es aber bei mir keine Vermutungen sondern fakt. So ist es bei mir.


Ich glaube Holger hatte vermutlich recht mit der Aussage das man das nicht unbedingt als Arbeit sehen sollte.

Joachim reduzieren wir bitte unsere Texte auf wesentliche Information, die der Andere überprüfen soll. Und suchen später Erklärungen.

Wir überlesen damit weniger.

Ich habe dir mitgeteilt, dass dein Input falsch ist, bzw. auf meinem System anders dargestellt wird. Wenn ich dies schreibe, habe ich dies überprüft.
(auch die anderen Punkte gibt es nicht, und rechts unten ist leicht verschoben)
Also braucht man den Output nicht zu analysieren und erklären.

Szenerien werden und sollen automatisch durch meinen Rechner erstellt werden, genauer kann ich es nicht machen, bzw. im FS darstellen.
Ich bin kein Landvermesser, aber meine Heimatstadt ist bis auf den letzten Zentimeter vermessen worden.

Also suchen wir Daten, Pläne und Möglichkeiten unseren Rechner damit zu füttern. Er soll es zeichnen und ausrechnen. Dies ist Sinn und Zweck eines Rechners, bzw elektronische Datenverarbeitung.

Beginnen wir bei unserer Heimat, wo wir diese Daten haben. Tauschen sie aus und haben jeder sicher eine Freude. Genauer kann man es nicht machen.

Wenn ich deine Frage nicht verstehe, oder eine Erklärung benötige, werde ich es dir mitteilen.
Versuchen wir bei Fragen nicht gleich Erklärungen anzuhängen.

Und bitte, lese den Beitrag noch einmal.

Horst

PS: Es ist nicht nur meine, auch Chris Wrights Freizeit. Der mir seine Arbeit umsonst anbietet. Daher will ich auch Respekt davor haben.

Gut dann schicke mir bitte mal Deine LWM und VTP Files aus TS_demo sowohl ASM als auch BGL. Dann kann ich e.v Rückschlüsse ziehen was bei mir falsch sein könnte. An jobia@t-online.de

Die Arbeit von Chris akzeptiere ich auch, ich habe das bei mir so festgestellt das war meine Erfharung deshalb die Rückfragen und ich möchte halt wissen was bei mir anders sein soll als bei Dir ich habe nichts an den Daten verändert und habe das Problem auf zwei Rechnern. Beide haben die geforderten VB Files drauf.

Ev. probiert das noch mal jemand anders aus der sich für das Programm interessiert.

So haben wir ev. einen dritten Sachverhalt.

Ich verwende nur die Originalfiles, sonst wäre kein Vergleich sinnvoll.
Ich kopiere sie noch einmal aus dem download um Fehler auszuschließen.
Und generiere es neu.
Damals habe ich dies 3 Mal erstellt, da es mich interessiert hat, ob er die Daten jedes Mal anders ausliest. Jedoch nur im LWMViever und konnte deine Punkte (Pfeile) nicht erkennen, bzw leicht verschoben.
Der Fehler kann ja auch bei mir liegen, bzw diese Art von Bitmap ist nicht geeignet, oder fehlerhaft.
Mein Anhang sollte Ansporn für andere sein.
Übrigens:
http://forums.avsim.net/dcboard.php?...7272&mode=full

Mache dies heute noch.

Horst

Ich habe dies etliche Male (Vorgang wie oben) mit Ersetzen der Originaldatei und LWM only vorher oder nacher probiert, es wird immer anschließend mit LWMViewer die selbe Datei erzeugt.
Hänge ich an. Wenn zu unscharf, mache ich es noch mal.
Geforderte VB Files? Habe ich in keiner Anleitung gefunden.
Also bitte Dateiangaben und Version – vielleicht eine Ursache.

Horst

Hallo zusammen:

kaum ist man mal ein Wochenende skifahren und schon muss man maechtig blaettern, um den Faden wieder aufzunehmen...

Ich werde hier nur noch mal zu Horsts Ideen was schreiben, habe aber auch gerade ein paar neue Versuche mit "Strip" und Gewaessermasken von Schleswig-Holstein abgeschlossen; die Ergebnisse stelle ich aber besser in ein neues Thread.

---
"
Kann man aus dem LWMViewer eine Art Diagnosetool machen?
"

Es waere schon nicht schlecht, ein all-in-one Diagnosetool zu haben, das all relevanten FS-Daten zusammenfasst und vielleicht sogar bewerten kann. Und ich trage diese Idee auch gerne an Jim Keir weiter, zumal der ja gerade nett frischen Wind in die Tools-Szene bringt.

Die Frage ist allerdings, wie man von Darstellung zur Analyse kommt. Ehrlich gesagt glaube ich, dass unsere Forenexperten mir ihren jeweiligen "Fachgebieten" da doch schneller und zuverlaessiger sind. Es ist vieleicht so aehnlich wie mit den Computern in KFZ-Werkstaetten: selbst wenn alle AutobesitzerInnen ihren eigenen Wartungscomputer mitgeliefert bekommen wuerden und selbst wenn diese ihnen zuverlaessig die Probleme anzeigen wuerden, dann waere da immer noch das Problem der "Reparatur". Mit anderen Worten, selbst wenn ich die Saisonlinie von Anfang an gesehen haette (danke nochmals fuer die geduldige Nachhilfe, Joachim!) ist noch nicht gesagt, dass ich sie als CTD-Faktor erkannt haette.

Was ich mir auch fuer FS-"Normalverbraucher" als sinnvoll vorstellen koennte (aehnlich wie deine Idee mit den "aktiven Texturen", Horst), ist eine tabellenartige Zusammenfassung der an einem bestimmten Ort (d.h., LOD13 Zelle) aktiven Dateien und Texturen. So ein Tool muesste also den FS Ordner (plus eventuell ausgelagerte Add-on-Dateien) durchforsten, alle Header lesen, die Prioritaeten verarbeiten und dann daraufhin eine Liste erstellen, die Dateinamen, Erstellungsdatum/Version, Texturtyp, usw. enthaelt.

Fuer "Normalverbraucher" waere so eine Liste ein schneller Check, ob die installierten Add-ons auch tatsaechlich genutzt werden (an diesem Ort) und fuer Experten ein "Sprungtuch" zur detaillierten Fehlersuche. Ich wuerde Tabellen einer grafischen Darstellung vorziehen, weil wir ja bereits schon ein paar grafische Tools haben, die aber eben raeumlich arbeiten und daher in mancher Hinsicht schwierig zu ueberblicken sind.

Voraussetzung fuer so ein Tool ist natuerlich, dass die Header gelesen werden koennen, ebenso wie die Texturauswahl (problematisch wegen der "leidigen" Verblendung) und dass die Prioritaetensetzung vollstaendig bekannt ist.

... und eine Programmierer, der das gesammelte Wissen zusammentraegt und in brauchbaren Code umwandelt. Freiwillige? :)

---

Ich verfolge die Diskussion zu autoasm mit Interesse und werde sicher auch bald ans testen gehen. Wie gesagt, meine weiteren Erfahrungen mit der Erstellung von bitmaps via Landsat (und deren Umsetzung in "Strip") stelle ich in einem eigenen Thread zur Diskussion.

Gruesse, Holger

Horst

Mir würde es wie gesagt sehr weiter helfen wenn Du mir Deine ASM und BGL Files an meine obige Mail Adresse schicken würdest. Nur so kann ich bei mir den Fehler finden. Das Bild bringt mich leider nicht weiter. Habe mir jetzt den Download noch mal gezogen. Mit Cleansweep geputzt damit alle Programmteile auch wirklich weg sind. Alles neu installiert. Es bleibt bei dem Problem.

Du fragst nach VB Files die Du in der Anleitung nicht findest.

Hier der Textauszug aus der Dok:
2. WHAT YOU NEED

1. A paint program that can handle high resolution .bmp image files. Paint Shop Professional (PSP) is perfect for this - and quite cheap! For all painting operations I’ll refer to PSP, but other paint programs should have similar or better capabilities.
2. The Microsoft compiler (bglc.exe). Most scenery designers will already have this, but it comes with the FS2002 BGLC compiler SDK (http://zone.msn.com/flightsim/FS02DevDeskSDK15.asp). Do not use any bglc versions that predate the scenery SDK. If you want to create terrain mesh you’ll also need the following SDK tools: resample, tmfmerge and tmf2bgl from the scenery SDK.
3. The two include files: TDFHeaders.inc and TDFMacros. Many thanks to Dick for the use of these.
4. This is a Visual Basic 5 program, so you'll need the VB runtime module. Most PC’s will have this installed but if not you should be able to download it from www.microsoft.com


Wie gesagt das mit den VB Runtime module ist das einzigste was mir noch in den Sinn kommt. Aber wie gesagt die sind drauf. Ich denke ohne diese würde auch eine Fehlermeldung kommen. Wie gesagt 2 PCs mit neuinstalliertem Autoasm. Bei unverändertem TS_demo File diese Probleme.

Das einzigste was mir sonst noch in den Sinn kommt sind die Pfade. Ich habe bei mir alles in Laufwerk E installiert bei dem anderen PC in D

Diese Pfade habe ich bei beiden natürlich angepasst. Aber das kann oder sollte den Bug nicht auslösen.

Wie gesagt ich benötige die Files sonst kann ich nicht weiterkommen.

Werde noch mal einen Bekannten bitten das auszuprobieren. Rainer hat ja keine Zeit gehabt und wer anders der das mal schnell ausprobieren möchte hat sich ja noch nicht gefunden.

@Holger
Die Analyse sind die Forenbeiträge, sie werden sachlicher. Die Anwender lesen die Daten richtig aus. Sie können vergleichen, und dann event. in die richtige Richtung Vermutungen anstellen. Die Daten werden eben nur richtig ausgelesen, ohne dass der Anwender dafür Verständnis haben muss.

Ein Beispiel, wegen tmfdecompress, für Überlappung bei mesh bgl Daten, wenn man auch die fs9.cfg (sie muss ja auch auf einen bestimmten Platz sein) mit einfliesen lässt.
Ich habe jetzt 2 Möglichkeiten:

a) ich erkläre ihm einen Vorgang, welche Daten ich benötige. Er kann es, und sagt mir die richtigen Daten, oder er hat einen Fehler gemacht. Oder will es gar nicht herausfinden.
Bis dahin haben wir sehr viel Text mit Erklärungen produziert.

Oder b) Ich bitte den Anwender irgendwo ein Freeware Tool herunter zuladen. Sich zur Problemstelle mit dem Flugzeug zu bewegen. Das Programm öffnen und mir folgende Werte mitteilen: aktive mesh bgl Daten und deren Lod Level und den Vertex Level.

Ich habe für beide Teile in kurzer Zeit die Information. Und dies vor allem richtig ausgelesen.
Ob es weiterhilft bei dem Problem ist eine andere Frage.
Auch Peter Dowson, Lee Swordy lesen die Daten richtig aus.

Das Problem in vielen Beiträgen, die Anwender sind zu faul, sich das Wissen anzueignen. Bzw. wollen dafür keine Zeit opfern.
Das Gute an der Sache der Anwender braucht nichts zu verstehen, teilt aber die richtigen Daten mit.
Und Leute, die sich damit beschäftigen, brauchen weniger Zeit diese Daten ebenfalls richtig und schnell darzustellen.

Vielleicht werden wir damit sachlicher. Helfen würde es bestimmt jeden. Und wahrscheinlicher weniger unnötigen Text produzieren.
Welche Daten wichtig sind?
Soviel wie möglich.

Herzlichen Dank, dass du eine Testreihe für die Problematik in diesem Beitrag herangezogen hast und dir die Mühe machst, dies ihm anderen Beitrag auch darzustellen.

@Joachim
Mail habe ich dir geschickt.
Module muss ich noch suchen, welche Dateien bzw. Versionen auf meinem System aktiv sind.

Horst

Horst unabhängig von den VB Files. Ich habe Autoasm über den Link von der Ankündigung con Chris im AVSIM Forum geladen.

Name: Autoasm.zip
Größe genau: 944.979Bytes
Datum:22.12.03 06:16:55

stimmt das bei Dir überein?

Dann bleiben im Prinzip nur noch irgendwelche VB Files übrig.

@Joachim
Dies ist die Zahl unter Eigenschaften zip file Größe, der Klammerwert.
Lade es vielleicht noch einmal herunter. Überprüfe hier Datumsveränderungen oder Versionen. Ich habe es noch einmal anscheinend am 14.01 heruntergeladen. (Datum des zip files).
Finde leider die zuständigen dll, bzw. keine Ahnung, für Vb module auf meinen System nicht, zwecks Vergleich.

@Holger
Kannst du auch AutAsm unter die Lupe nehmen.
Füttere ihn mit Daten deiner Umgebung, die relativ einfach zu haben sind.

Dann würdest du dies für Jim Keirs nächstes Meisterwerk verstehen, was ich unter Austauschen weiter oben gemeint habe. Chris Wright Beitrag hier:
http://forums.avsim.net/dcboard.php?...7272&mode=full

Beginnen wir bei den kleinen Einheiten vor der Haustür(z.B ganz Deutschland)

„Small is beautiful“ (Karl Popper, Philosoph)
wieder ein gebürtiger Wiener :), der zum Thema passt.

Ich bin sehr zuversichtlich, dass wir ein "Knofdruckprogramm" haben. Nur müssen wir, es so gestalten, dass dies für jedermann ganz einfach ist.

Ich habe auch keine Flughafenpläne, aber dank AFCAD und vielen fleißigen Bastlern rund um die Welt, auch richtige Af_2 files bekommen. Ich denke dies sind die Werkzeuge, die uns weiterhelfen.

Ich würde dann nicht den Begriff "kleinflächig" eines "Experten" in deinem Beitrag lesen, sondern mich über andere Dinge unterhalten.
z.B Können wir die Höhendifferenz von sage und schreibe z.B 20-30 cm zu Deutschland, aufgrund der Nivellementnetze und Pegelstationen, auch im FS darstellen, bzw sehen?

Horst

Hallo!

Horst: ja ich werde auch mal Autoasm antesten, sobald ich ein paar andere Projekte vom Tisch habe.


Muss mich uebrigens fuer eine fehlerhafte "Anleitung" entschuldigen. Die Interpolationen in Blackart laufen eine wenig anders ab, als ich das beschrieben habe. Ich war kurz zuvor, John eine Mail bezgl der Fehlermeldung zu schicken, habe mir dann aber doch nochmals die Anleitung komplett durchgelesen - nur gut, sonsts waers peinlich geworden ;-)

Also, so gehts richtig:

1. Blackart starten und die SRTM .hgt Datei laden

2. Im Grafikfenster (Blackart hat zwei offene Fenster) die fehlenden Pixel (-32768) auf Null setzen mit Image > Array Operations > Clip Negative Elevations.

3. Im Grafikfenster ueber File > Input Data die Anzahl der Iterationen auswaehlen. LSQR ist der bessere aber auch langsamere Algorithmus, Laplacian schneller. Fuer beide empfiehlt John Werte von 1000 - 10000 (http://www.terrainmap.com/rm33.html#FAQ , im unteren Drittel), aber Vorsicht bei den LSQR Werten: fuer 1000 LSQRs braucht mein Computer eine Stunde!

4. Grafikfenster minimieren und im Hauptfenster Run > Run Blackart auswaehlen.

5. Nach Abschluss der Interpolationen die modifizierte Datei als SRTM .hgt abspeichern.


Ich bin gerade dabei, eine kleine Versuchsreihe laufen zu lassen und das sieht doch ganz vielversprechend aus. Mir ist noch nicht ganz klar, wie die beiden Interpolationstypen vereint werden. Die LSQR-Interpolationen sehen in den grossen Loechern etwas besser aus, haben aber den Nebeneffekt, dass sie die gesamte Datei re-interpolieren und dabei etwas an Detail reduzieren.

Jedenfalls handelt es sich hier immer noch um Interpolationen, also je groesser die Loecher, desto weniger realistisch das Lochinnere. Aber: wenn Blackart auch kein Matterhorn herzaubern kann, so scheint es doch zumindest die bei MicroDEM und SRTM2BGL ueblichen "Schlieren" und "Loecher" zu vermeiden.

Vorlaeufiges Fazit: Wenn man nichts Besseres zum Fuellen der Loecher hat, sollte man zumindest die Rohdaten vor der Uebergabe an SRTM2BGL mit Blackart interpolieren.

Als Beispiel hier Ausschnitte von "gestopften" SRTM Dateien von Patagonia, im Original mit massiven Loechern. Zunaechst MicroDEMs lineare Interpolation, mit Suchdistanz von 2000:

... dann zum Vergleich Blackart's Interpolation mit 1000 Laplace-Iterationen (angeblich der schwaechere Algorithmus).

... und schliesslich Blackart's Interpolation mit 1000 LSQR-Iterationen. Dass das Bild etwas unschaerfer erscheint liegt an der allgemeinen Generalisierung dieses Algorithmus'. Wenn ich das recht verstehe, kann dieser Effekt durch eine hoehere Anzahl von Iterationen verhindert werden (oder eine Kombination von den Laplace-Interpolationen); das wuerde dann aber sehr lange dauern.

Cheers, Holger

Ich würde sagen wenn es irgend geht sollte man doch versuchen zumindest mit ev. etwas schlechteren Daten zu füllen insofern man da dran kommt. Ev. ist es ja dann eine alternative das füllen mit Defaultdaten des FS zu machen. Die könnten ev. besser für das Loch sein als die Interpolation.

Holger ich muss mich erst in Blackart und Microdem einlesen. Aber Danke für deine neue Anleitung.

Joachim genau, dies habe ich versucht auf Seite 2 anzudenken.
Wir können uns im FS ja auch mit dem LOD Level helfen, auf engeren Raum, wenn Löcher vorhanden sind.
Diese eventuell auch mit besseren Daten „stopfen“.
Vielleicht im FS9.
Höhenlinien werden auch in Vektorgrafiken oder Daten dargestellt.

Joachim
Ich habe sehr viele deiner Beiträge gelesen und verfolgt. Und habe den Eindruck bekommen, dass sehr viele Anwender dich eigentlich nur ausnutzen bzw. benutzen.
Man darf ruhig seine Freizeit für seine eigene Weiterbildung, für das Erweitern seines Wissens, und das Sammeln von Ideen nutzen.

Man muss sich nicht Jedermann verpflichtet fühlen.

Vielleicht helfen meine Texte dir und deiner Familie, und deiner eigenen Weiterentwicklung. Sie stellen keine Kritik an deiner Person dar.
Man kann und soll seine Freizeit in Ruhe und sinnvoll verbringen.

Mir und meiner Familie hilft es.

Horst

PS:
Joachim kannst du, wenn du Zeit findest, den Gedanken bezüglich Diagnosetool noch einmal nachlesen. Bzw. Holgers Gedanken dazu, versuchen nachzuvollziehen.
Wäre es eventuell möglich, diese Texturdaten theoretisch für einen bestimmten Radius darzustellen?

@An alle Mitleser

Gibt sicher Leute, die ungern Suchmaschinen benutzen.
Jetzt habe ich dies gemacht, um etwas Verständnis für die Beziehung zu Popper, den ich gestern erwähnt habe, herzustellen.

Ich habe hier
http://www.raumplanung.uni-dortmund....schmals5.htm#9
(braucht man nicht alles lesen)
eine deutsche Textstelle gefunden, die meine Gedanken darstellen.

Zitat von dieser Seite:

Die Gesellschaft ist nach Popper zu komplex, um sie "ganzheitlich" zu erfassen, planen zu können. Popper meint nur solche gesellschaftlichen Veränderungen planend vornehmen zu können bzw. verantworten zu können, bei denen er "Ursache und Wirkung" genau bestimmen kann, bei denen also Planungsabläufe genau - bis ins Detail - kontrollierbar sind. D.h., auch die Ziele, die Grade der Bedürfnisbefriedigung, die Effizienz der Mittel, die Zielgruppen, die sozialen Folgen müssen in einer Planungssituation jeweils beherrschbar sein. Nach Popper's Erfahrungen ist es - aufgrund gesellschaftlicher Komplexität und der Unübersichtlichkeit sozialer Beziehungsgeflechte - falsch bzw. fahrläßig, vermeintliche Ganzheitskonzepte in planendes Handeln umzusetzen.

Zitatende

Horst

Hallo!

@ Joachim

"
Ich würde sagen wenn es irgend geht sollte man doch versuchen zumindest mit ev. etwas schlechteren Daten zu füllen insofern man da dran kommt. Ev. ist es ja dann eine alternative das füllen mit Defaultdaten des FS zu machen. Die könnten ev. besser für das Loch sein als die Interpolation.
"

Ja, dass habe ich auch mal gedacht, erscheint ja auch zuerst logisch. Wenn man dann aber mal selber das Fuellen probiert, wird man schnell ueber die unbefriedigenden Ergebnisse frustriert sein.

Siehe das angehaengte Bild, wieder von Patagonien. Hier habe ich die Loecher in den SRTM3-Daten mit den neuen SRTM30-Daten gestopft, die dasselbe Format haben wie GTOPO30/DTED0-Daten (welche MS fuer das FS LOD5 Default-Mesh genommen hat) aber angeblich etwas bessere Genauigkeit.

Und, ist das Ergebnis genauer als Interpolation mit Blackart? Nein! Sieht es zumindest besser aus? Auch nicht! Und warum nicht? Weil der Generalisierungseffekt der 900-m Aufloesung das Relief vertikal staucht, also Bergruecken niedriger und Talboeden hoeher sind als in der Realitaet. Daher kommt es beim Fuellen an den Lochraendern zu Steilkanten und der gefuellte Teil sieht auch sehr merkwuerdig aus (was auch nicht verwunderlich ist: selbst ein 5km breites Loch wird ja nur von 15-20 900m Hoehenpunkten modelliert).

Also, fuellen der Loecher kommt nur in Frage, wenn man entweder einen Datensatz mit aehnlicher Aufloesung findet (z.B. ASTER) oder die low-res Daten vorher mit aufwendigen Algorithmen an die high-res Daten anpasst. Ich habe da vor ein paar Monaten mal so einen Algorithmus angedacht http://forums.avsim.net/dcboard.php?...1267&mode=full und Blackart bietet auch eine Methode der Vorverarbeitung, die ich aber noch nicht getestet habe.

---

Horst, besten Dank fuer das interessante Popper-Zitat; das erinnerte mich an lange Vorlesungsstunden im geographischen Institut der Uni Marburg ;-)

Cheers, Holger

Schönen Abend!

Jetzt muss ich mich doch noch genauer mit den Höhepunkten und deren Umsetzung im FS befassen bzw. einlesen :). Bzw. dieses Thema etwas vorziehen.

Holger, ich denke ich habe Joachim etwas anders verstanden.

Vielleicht habe ich deshalb auch die Stelle für Popper gesucht.
Wir denken in verschiedenen Welten.
Deine Umsetzung ist sicher richtig.
Kanada ist groß, Österreich ist klein. Wie soll ich diese Welt „genau“ darstellen?

Hier in Europa werden anscheinend viele verschiedene Daten angeboten, bzw die verschiedenen Arten der Umsetzung im FS. Damit „kämpfen“ wir, bzw. erkennen es nicht.

Joachim hat einmal ein Bild mit deren Abdeckung im FS hier in das Forum gestellt (ich finde es derzeit leider nicht).
Und er hat mir aufgrund der LOD level – Erklärung (zumindest habe ich dies mitlesend erkannt), den schönsten Überflug über Österreich verschafft.
Ich habe Daten auf CD gekauft, die ich gar nicht sehen konnte! Dafür bin ich ihm noch heute sehr dankbar.
So wie in Sion. Ich habe bis jetzt für mich nicht geklärt, welche Daten bei mir aktiv sind. Eben wegen der Überlappung.

Vielleicht kann man eben bessere Daten einfach darüber legen, für einen kleinen Raum? (Zugspitze, Großglockner usw.), eben durch den Lod level. Viele Flusi Freunde können dies sicher machen, wenn sie wissen, wie sie es machen.

Joachim kann dies sicher besser erklären.

Übrigens der Beitrag von Jim Keir bei Avsim mit: „nothing that LWMViewer will read :) (Yet, anyway...).", freut mich.

Dein Beitrag wäre die Therapie für die Diagnose :)

Horst

Wahrscheinlich muß man das mit den Füllen (wenn man keine anderen Daten als die des FS bekommt) mit beiden Versionen ausprobieren. Einmal Interpolation. Einmal Befüllung mit FS Daten. Ev. kann man aus den FS Daten wichtige markante Höhen erkennen die hier existieren. Dann könnten diese mit eingearbeitet werden. In der Regel wird es natürlich so sein, das das Material was Microsoft in den SDKs erwähnt uns auch zur Verfügung steht. Da ist das Rohmaterial natürlich dem bereits durch den resampler gelaufenen Material vorzuziehen.

Als letzte Alternative sähe ich aber noch das Übernehmen aus normalen Höhenlinien von Kartenmaterial.

Da gab es ja auch schon Versuche dieses zu Automatisieren.

Notfalls könnte man markante Punkte z.B über Hand einfügen. Wenn das Resultat dann zwar nicht der Hammer wäre. Es wäre dann aber immer noch besser als wenn ein Berg ganz fehlt.

Holger hast Du deine Ergebnisse mal angeschaut wie sie hinterher im FS aussehen bei den verschiedenen Interpolationen.

Es war dumm von mir nach dem Datum des ZIP Files zu fragen. Horst welches Datum hat z.B die Autoasm_1280.exe auch 20 Dezember 18 Uhr 33

Weiterhin welche Version wird bei Dir über die Info Fläche angezeigt.

Bei mir Version 0.6 22 Dezember 2003

Die Info hat er gleich als Bitmap gemacht die er auswertet. Lustig

Gar nicht lustig das ich jetzt den dritten Fremdrechner durch habe. Zwei XP einer 98.

Auch habe ich heute morgen noch mals frisch das ZIP File gezogen.

Auch bei dem letzten Rechner eines Bekannten den ich besucht habe das selbe Problem. Es entstehen kleine Gewässerflächen die dort nicht hingehören.

Sowohl bei dem dem als auch dem TS_demo Projekt. Das mit den vielen Vectorpoints übrigends auch wenn die Bitmap bzw. deren Pixel einen Masstab kleiner der Vectorpoints hat. Auch hier wurden alle Pixel herangezogen. Sicherheitshalber habe ich diesen Test erst zum Schluß gemacht nicht das ich ev. irgendetwas verändere.

Holger hast Du schon Autoasm getestet?

Was mich bei dem ZIP File wundert das ein eigentlich überflüssiger Programm Files Ordner erzeugt wird. Dort ist alles leer. Diese existieren eh im Autoasm Ordner. Bei dem Bekannten mußt ich im Gegensatz zu mir sogar noch nicht mal die Pfade für den FS usw. ändern. Das macht mir die Sache noch unverständlicher.

Hallo zusammen!

Joachim, sehr gute Zusammenfassung zum Thema Interpolation vs. Fuellen - stimme ganz mit dir ueberein!

Ich habe vor laengerer Zeit mal ausprobiert, in MicroDEM grosse Loecher mit ein paar Stuetz-Hoehenpunkten vor dem interpolieren zu verbessern. Das hat aber das Ergebnis eher verschlechert, da der Algorithmus mit den einzelnen Punkten umringt von -32768 nix anfangen konnte. Allerdings meint John Childs, dass Blackart mit solchen Stuetzpunkten besser umgehen kann. Ausserdem wurde Blackart ja speziell zur Erstellung von DEMs von eingescannten Karten erstellt, wer also Topo-Karten vom Matterhorn hat, koennte da mal ein Versuch starten. Und nicht die "benachbarte" Dent Blanche, 4375m, vergessen (siehe Bild, habe ich 1991 beim Winterzelten aufgenommen) ;-)

Habe Autoasm immer noch nicht angefasst, da ich gerade beim verpacken und uploaden von ein paar AI-Paketen bin. AI Schiffe gibts bereits bei AVSIM und heute sollen noch die AI Wasserflugzeuge folgen. Meine AFCAD2 und FDE Tricks sind zwar ganz nett aber besonders stolz bin ich auf die speziellen Effekte und deren automatisierte Schaltung ;-)

Sobald ich die AI Sachen vom Tisch habe gehts zurueck zu Strip und Autoasm.

Cheers, Holger

Hallo,

Joachim, dies war ja keine dumme Frage. Ich bedenke auch viele Dinge nicht. Deshalb tauscht man sich aus, wenn man selbst nicht weiterkommt.

Autoasm_1280.exe hat das selbe Datum. Und unter Eigenschaften Datei finde ich unter Allgemein das selbe Datum bei Geändert am:.
Unter Eigenschaften/ Version: Dateiversion 1.00

Bei der Info Fläche im Programm erzeuge ich einen Laufzeitfehler 76.
In der Anleitung:
INFO: do not press this button.
FS2002/CFS2: AutoAsm can create water polygons for CFS2 (but not VTP lines). Select the flight simulator as required. (auch beachten)

Die Info findest du ja im Prinzip bei jedem Programm (meistens unter ?). Wright erzeugt es, indem er ein bitmap (liegt im bitmaps Ordner) zuweist. Mehr Informationen sind nicht notwendig, bzw. diese Funktion derzeit unwichtig. Die Zuweisung dürfte aber nicht auf jedem System funktionieren, daher der Hinweis in der Anleitung.
Egal, die Benutzeroberfläche ist derzeit ja nicht unbedingt wichtig. Der Ablauf des Programms sollte fehlerfrei funktionieren.

Zu Visual basic, musst du bei MS nachsehen
http://msdn.microsoft.com/vbasic/pre...vb5/downloads/
Da gibt es bereits andere Versionen, bzw. habe ich keine Ahnung was man als Awender überhaupt haben muss. Hier könnte ich höchstens eine dll Datei bei meinem System suchen.

Da ich annehme, dass du bei den Daten die ich dir geschickt habe, keinen Fehler findest, hilft dir (oder auch Mitlesenden) vielleicht eine kurze Anleitung:

A)Herunterladen von autoasm

B) Zip Datei öffnen

C) zweiten Arbeitsplatz öffnen und einfach den Ordner AutoAsm an eine beliebige Stelle (in meinem Fall in den Ordner C:\Tools\ ) ganz einfach von einem Fenster in das andere verschieben (also kopieren) . Den Ordner Program Files ignorieren.

D) Damit habe ich einen Arbeitsordner erzeugt mit dem Namen c:\Tools\autoasm

E) Anschließend die bglc aus FS2002 SDK in diesen Arbeitsordner kopieren.

Hinweis in Anleitung:
3. Copy bglc.exe into the main AutoAsm directory (it is included in the Microsoft bglc SDK).
4. If you want to create terrain mesh, copy these Microsoft SDK tools into the terrain sub-directory: resample.exe, tmfmerge.exe and tmf2bgl.exe.
When you compile an asm file it is essential that the two .inc files are in the same directory as bglc.exe.
(hier also tdfheaders und tdfmacros)

F) Autoasm_1280.exe öffnen, es erscheinen 3 Fenster

G) Wichtig ist das MAIN Window, wo die einzelnen Ordner festgelegt werden. Das Programm arbeitet nicht über die Registrierung, sondern legt die Informationen in den Projektdaten ab.
Bei mir : c:\Tools\autoasm\settings

Folgender Vorgang:
Bei Project Name : TS_demo eingeben und LOAD drücken. Dann die Ordner oberhalb richtig zuordnen.

Bei mir:
c:\Tools\autoasm
C:\Programme\Microsoft Games\flight simulator 9\addon scenery\scenery (dort habe ich normalerweise nie Daten, außer jetzt durch AA)
C:\Programme\Microsoft Games\flight simulator 9

Dann SAVE drücken.
Damit habe ich für dieses Projekt die richtigen Ordner zugewiesen. (Ansonsten sehr viele Laufzeitfehler)

H) Anschließend sollte bei Eingabe von ProjectName TS_demo und LOAD-drücken die Ordner jetzt richtig angezeigt werden.

I) weiter wie schon weiter oben beschrieben.

Die Ordner von AA (AutoAsm), wie bitmaps, settings, terrain darf man natürlich nicht umbenennen.
Die Erzeugung einer bgl erfolgt nicht, wenn der FS geöffnet ist = Laufzeitfehler.

Vielleicht hilft dir dies einstweilen.
Wenn etwas nicht stimmt, überprüfe ich es noch einmal.

Horst

Ein paar Gedanken zu AA und wahrscheinlich auch zu Strip:

Im Prinzip ist dies alles ja nicht neu. Es ist nur der erstmalige Versuch, die bereits erzeugten Daten bzw. vorhandenen Daten, in den FS zu integrieren.
Mit Beginn des PC hat man versucht Bücher, Pläne, Bilder, Gemälde, Listen usw. eben elektronisch zu archivieren. Man kann diese Archive besser nutzen, und auch verbinden. Man kann die Daten leichter tauschen und darauf über das Internet, oder andere Systeme der Vernetzung, zugreifen.
Und dies natürlich auch mit Geodaten:
ein paar Links zum Weiterlesen:
http://www.ifag.de/
http://www.bev.gv.at/
http://www.geographie.uni-mannheim.d...warearchiv.htm
http://www.dds.ptv.de/html/geo.frame.html
http://www.goldensoftware.com/products/products.shtml
http://www.microimages.com/index.htm

Derzeit zu AA, da ich erst bei dem sinnvollen Input angelangt bin.

a) Zu Terrain-Anpassung:

http://forums.avsim.net/dcboard.php?...id=17350&page=

Dies wäre sehr wichtig. Damit könnte man seine Daten relativ leicht automatisch auf die Höhepunkte drauflegen. Also auf bereits vorhandenes Material.
Die Erzeugung von eigenem Terrain, habe ich noch nicht probiert.

Aber wie ist dies dann bei Straßen oder Bahnlinien?
Hier könnte eventuell eine Möglichkeit bestehen, wenn man für Autobahnen event. die max. Steigung der Straße definieren kann.
Was meine ich damit?
Die Radien bzw. den Verlauf wird man erzeugen können. Die richtige Anpassung an die Höhendaten wird etwas schwieriger. Denn dies sieht nicht sehr schön aus, wenn dies ganz einfach darauf gelegt wird.
Im Flachland fällt es nicht sehr stark auf. Im Bergland jedoch sehr stark.
Wir in Österreich haben eben viele Tunnels; Lawinen- und Steinschlagverbauungen für Straßen.
Bei einem Tunnel kann ich die Straßenlinie nur unterbrechen, damit sie nicht über den Berg darüber läuft im FS9. Dies muss ich exakt an der Stelle tun, die mit meinen Höhendaten zusammenpasst.
Oder ich erzeuge eine Linie ohne Unterbrechung, die optisch durch den Berg durchgeht im FS9, und daher nicht wahrgenommen wird. D.h hier muss ein Tunnel sein.

Bei Bundes- oder Landesstraßen, bzw Forststraßen braucht man dies ja nicht unbedingt, da diese ja eher der Natur angepasst werden.

Oder eine andere Methode wäre, Daten für Straßen mit Höhendaten zu suchen, und diese zu integrieren (??). Also unabhängige von den Höhendaten des FS9. Höhendaten nur für Straßen.

b) Performance und Points

Hier wäre vielleicht eine Möglichkeit der Reduzierung der Points wichtig. Aber erst, nachdem man sie erzeugt hat.
Hier muss man eben den richtigen Kompromiss für sein Projekt finden. Bzw der Input muss stimmen.
Man wird derzeit die Bitmaps so genau machen, wie möglich (dies muss man eben herausfinden). Kann es aber an die derzeit vorhandene Rechnerleistung anpassen, indem man einfach nur jeden z.B 10 Point nimmt.
Später kann man seine Arbeit einfach ändern, wenn man jeden Point nimmt. Wenn die Voraussetzungen der Hardware gegeben sind.

Horst

Zu Holger

Mit der Füllung eines Mesh Loches durch eine Karte mit Höhenlinien usw. habe ich jetzt weniger in Richtung Microdem oder Blackart gedacht
(letzteres kenne ich nicht außer deinen Berichten) sondern mehr in Richtung Fotoprogramm.

Ich mache meine Testmeshfiles auch nur mit Fotoprogramm. Zum Teil auch mit Hexeditor.

Denn bei testfiles muß ich stabile bekannte Verhältnisse haben. (im Vorfeld schon nicht nur hinterher in der BGL) Ich arbeite dann auch unter idealen Verhältnissen so das beim resampeln keinerlei Interpolytion auftritt.

Wenn ich also z.B das MeshRohdatenfile (mit entsprechender Palette) im Fotoprogramm vorliegen habe, ist es im wesentlichen nur noch eine Bitmap die ich brauche um das Loch zu füllen.

Diese Füllbitmap müßte maßstabsgerecht von der LandKarte mit Höhenlinien abgenommen werden und in das Loch eingefügt werden.

Allerdings nicht so wie es in der Karte vorkommt sondern entsrechend der Meshpalette vorbereitet. Also im Prizip eine Graustufenbitmap.


Die Vorbarbeitung stelle ich mir so vor. Topografische Karte. Erstmal eine Maske die das Gebiet grob begrenzt. Dann fängt man bei der Höchsten Stelle an und setzt die Graustufe die als höchste Bergstelle vorkommt. Selektieren als Objekt und eigenständig abspeichern oder in der Priorität weg schieben. Maske nach nächsten Höhenring, Line suchen bzw. wachsen lassen. Fläche wieder entsprechend Höhe in Graustufe definieren.
Immer so weiter bis man mindestens das Loch flächenmäßig gefüllt
hat. Jetzt werden diese einzelnen Objekte in umgekehrter Reihenfolge wieder zusammengefügt. Das ergäbe jetzt mehrere überlagerte Flächen in unterschiedlichen Graustufen. Ev. kann man diese etwas härteren Übergänge weichzeichnen ohne aber dabei die fest ermittelten Graustufen zu verändern. Das ganze jetzt in die SRTM Graustufenbitmam/RAW Datei eingearbeitet und fertig ist ein halbwegs vernünftiges gefülltes Loch. Das ganze über den resampler gejagt und fertig.

Wenn ich mehr zeit habe werde ich das mal ausprobieren. Ev. hat ja ein Bekannter eine Karte vom Matterhorn.

Übrigends Horst als ich das befüllen mit FS Defaultdaten erwähnt habe, habe ich auch tmfdecompress gemeint.

Zu Autoasm kann ich nur sagen Sch..... ich habe es nicht anders gemacht als Du. Nur das bei mir alles auf E: lag. Bei dem Bekannten auf C:

Da brauchte ich überhaupt nichts zu ändern. Trotzdem ist bei allen der selbe BUG. Deine Files sind wie gesagt fehlerfrei das ist ja das was ich mir nicht erklären kann.


Schön für Dich schlecht für mich und die anderen.

Hat man falsche Pfade oder die BGLC vergessen bekommt man eine Fehlermeldung daher kommt das eigentlich auch nicht in Betracht.

Es gibt im Prinzip den selben Fehler bei dem Demoprojekt. Das Projekt kann es daher auch nicht sein.

VB Files weise ich nicht. Bei dem XP mußte ich sie nachinstallieren. Bei den XP PCs war vorher Ground2K drauf. Ich meine ich hatte sie damalas bei mir mit Coastline Maker eingespielt.

Werde jetzt noch mal bei Microsoft schauen.

Das einzigste was mir jetzt noch bleibt.

Es ist zwar eine üble Aussage von mir aber ich hoffe fast Holger bekommt das selbe Problem. Mir bleiben jetzt nur noch die VB Files.

Ansonsten weis ich nicht weiter.

Wie gesagt die Versauung ist im Tool selbst wenn alle Polys gezeichnet und ausgelesen werden noch nicht zu sehen. Erst wenn der asm Code erzeugt wird.

Da der Code im ASM Code schon schlecht ist fällt die BGLC.EXE auch raus. Es muß nachdem Autoasm das wesentliche gemacht hat in der Erzeugungsphase des ASM Codes passieren.

Bei Staßen , Tunneln usw. bezüglich Mesh sehe ich keine Probleme.

Ist das Mesh gut die Straßen richtig positioniert wird alles harmonisieren. Dann kommt ja noch die neue Flattenfunktion des FS2004 dazu dann passt das schon. Beim Tunnel kurze Unterbrechung des Liniencodes schon dominiert hier das Mesh und die Straße verschwindet optisch halbwegs vernünftig. Ev. noch ein kleines Minipoly oder ein kurzes Stück Liniencode mit ganz schwarzer Textur dann sieht das ev. auch aus wie ein Tunnelloch.

Joachim zu VB ein Link:
http://www.vbarchiv.net/home/willkommen.php
Vielleicht findest du Informationen.

Mit TmfViewer erzeugt man eine Art Höhenrelief (mit Informationen).
Bitmaps, wie Holger sie weiter oben darstellt.
Dies sind Höhenreliefe.

Im Gegensatz zu Höhenschichten Bitmaps.(also zweidimensional)
Hier werden Höhendaten in farbig abgestuften Höhenschichten dargestellt. Wobei jede Farbe eine bestimmte Höhe darstellt.

z.B in Blackart erzeugt man dies
http://www.terrainmap.com/rm38.html#srtm_repair

Habe ich jetzt bessere Daten, für z.B Matterhorn, würde ich mir ein Höhenschicht Bitmap aus den Höhendaten erzeugen und AA damit füttern. Ich erzeuge eine eigene bgl für dieses Loch, bzw. mache eine bessere Darstellung, aus besseren Höhendaten.

Joachim, dein Weg wäre mir etwas zu umständlich. Bzw. dies erledigt der Rechner. Dies wären dann nur zweimal Knopfdruck bis zur bgl (Abgesehen von den richtigen Einstellungen vor dem Knopfdruck, damit die richtige Darstellung im FS9 funktioniert). Bitmap und Erzeugung.

Ich bin kein Katograph, aber dies ist sicherlich einfach darzustellen, aus vorhandenem Material.

Dies sollte AA ja können, er braucht nur das richtige Bitmap.

Der Vorteil bei AA: Es ist egal, wie ich dieses Bitmap erzeuge.

Daher suche ich noch immer nach Input-Möglichkeiten bzw. deren Darstellung. Bzw. einfache Erzeugung für Jedermann.
Anschließend muss man dies mit AA ausprobieren.

Horst

"Mit TmfViewer erzeugt man eine Art Höhenrelief (mit Informationen).
Bitmaps, wie Holger sie weiter oben darstellt.
Dies sind Höhenreliefe".

TMFViewer ist bekannt nutze ich schon seit dem FS2002 SDK.

"Im Gegensatz zu Höhenschichten Bitmaps.(also zweidimensional)
Hier werden Höhendaten in farbig abgestuften Höhenschichten dargestellt. Wobei jede Farbe eine bestimmte Höhe darstellt"

Das stimmt nicht. Er stellt es zwar farbig dar aber Du kannst mit dieser Bitmap rein gar nichts anfangen, weil eine ganzes Packet von Höhen in einer Farbe abgelegt ist.

Geh mal auf ein und die selbe farbe grün und fahr mal Deine Punkte ab. Da wirst Du sehen das die Farbe nicht als Höheninformation zu gebrauchen ist.

der TMF Viewer hat auch insofern Bugs das er ein und die selbe Höhe zum Teil mit etwas anderer Farbe darstellt.


Kenne ich alles aus meinen Versuchen.

Das einzigste was man brauchbar nutzen kann ist das RAW File aus tmfdecommpress.

Diese bunten Bilder aus Blackart sind auch nur visualisierte Bilder von Rohdaten die unterschiedlichste Datenformen haben. AA kann mit diesen wenn man Mesh erzeugen möchte aber nichts anfangen. Es benötigt (da das Mesh über den MS SDK resampler erzuegt wird) einen Code der über 16Bit die Höhe pro Meshpunkt definiert.

Das geht idealer Weise mit einer Graustufenbitmap bzw. RAW File.

Blackart kenne ich nicht. Aber auch bei Microdem gibt es das mit der Farbabstufung. Aber auch hier wäre es nicht direkt für den FS zu gebrauchen. Das einzigste was man direkt weiter verwenden kann sind die Graubitmaps um später ein Mesh erzeugen zu können.

Mein Beispiel oben bezog sich aber nicht darauf das man etwas besseres hat sondern gar kein digitales Höhenmodel. Also nichts wo man direkt eine Höhe raus erkennen kann. Sondern nur eine farbige topografische Karte (Wanderkarte wie sie jeder kennt) die zusätzlich einfarbige (meist schwarze oder braune) Höhenringe also nur dünne Linien an denen die Höhe z.B 300m steht hat.

Hier muß man nach Tricks suchen um jetzt daraus ein Höhenmodel in Graustufen die der jeweiligen Höhe entsprechen aufzubauen.

Da gab es auf der Seite wo man Blackart laden kann auch Beispiele dieses zu automatisieren. Nur das ist extrem aufwendig und war damals eigentlich auch noch nicht so richtig zu gebrauchen.

Zu den VB Files.

Danke für den Link. Da sehe ich momantan die einzige Hoffnung drin.

Wenn den Bug mehrere hätten würde es sich lohnen den Chris anzuschreiben, so denke ich werde ich das Tool bei Seite legen.

Servus Joachim,
Das man mit TmfViewer keine zweidimensionalen Höhenbitmaps erzeugt, habe ich eigentlich gemeint.
Aber bevor ich dies aus einer eingescannten Karte erzeuge, würde ich jemand bitten dies aus einer digitalen Karte zu erstellen, welche Höhendaten enthält.
Vielleicht kommt mir einmal etwas unter, wo man dies einfach aus Karten, mit Höhenlinien und ohne Höhendaten, erzeugen kann.
Egal.

Zu AA:
Mit TS_Demo schaffe ich immer das gleiche Ergebnis.

Aber mit Demo kann ich Fehler produzieren, bzw. habe ich unterschiedliche Ergebnisse.
Da ich mit Höhenschichtenbitmaps herumgespielt habe, wollte ich Terrain ausprobieren.

Also nimm bitte das Projekt DEMO (bei Terrain ändere nichts). Also das Demo – Bitmap.
Dann erzeuge es mit Write LWM und VTP, auch mit Auto Run und ändere auch Centre Position (z.B N10 E40). Also verschiedenste Variationen.

Ich komme hier auf zwei verschiedene Erzeugungen, jedoch beide nicht richtig.
Ich habe sie nur mit LWMViewer betrachtet, und hänge dir beide Varianten an, die ich bis jetzt erzeugen kann.

Wright schreibt zwar bei Punkt 2 bei Using Bitmaps von Grau, aber vielleicht verursachen die Bitmaps die Fehler und nicht VB (siehe die Nadel links oben im Bitmap)

Horst

Nr.2

Bin in den nächsten zwei Tagen unterwegs komme daher vermutlich erst am Donnerstag dazu. Ev. schaue ich mal kurz ins Forum.

Eigenartig ist nur, dass man anscheinend mit unterschiedlichen Koordinaten, andere Ergebnisse erzielen kann. Aber diese, immer den selben Fehler aufweisen.
Gut Ding braucht Weile. Also tasten wir uns langsam an diese Sache ran, vielleicht produzieren wir die Fehler selbst.

Horst