|
HI,
One of the MS guys told me today that we should expect "news of" the next version in 6 to 10 months. He also hinted that some of the older planes would get a (much needed) makeover and that there "might" be some new ones. Beyond that all he would say is that we can expect more of the same sort of improvements we saw going from FS02 to FS04. IMO those were significant improvements indeed! That part about the bridges in the update is good news. I just hope they put the Tacoma Narrows Bridge where it belongs. Later, Tom Wunder (Moderator: AVSIM ~ Flight Unlimited Series Forum) (Co-Moderator: AVSIM ~ Racing Fools Forum) Na dann warten wir doch lieber noch 6/10 Monate und haben dann den FS2006. Vielleicht sogar mit einen AIRBUS ! Der FS2004 ist inzwischen in meinem Regal eh eingestaubt. Gruss Fox |
War dieser Thread unten. Also der FS2002 konnte das definitiv ohne Manipulation des Terrain_Max_Vertex_Level in der FS2002.cfg auch nicht. In diesem Thread hatte ich auch Bilder von einem LOD11 Testmesh welches ein Kunstprodukt von mir war. Es sollte dazu dienen diesen Effekt vorne hui hinten pfui zu untermauern. Aufgefallen war es mir bei einem regulären LOD11 Mesh nur da hätte man das schlecht rüberbringen können.
Hier der Thread. http://www.wcm.at/vb2/showthread.php...highlight=mesh Dieses Testmesh spricht auch gegen die Zahlen die bezüglich der Sichtbarkeitsreichweite von verschiedenen LOD Level Mesh veröffentlicht wurden. Es scheint davon abzuhängen wieviel Höhenabwechslung in so einem Mesh enthalten ist. Ein LOD11 Mesh kann auch ganz flache Gegenden haben, dann belastet es nicht und diese Zahlen könnten stimmen. Man beachte bei der Problematik auch die Komprimierung bei Meshdaten. Ein flaches LOD11 Mesh enthält im extrem Fall weniger Bytes als ein zerklüftetes LOD9 Mesh gleicher Fläche obwohl das LOD11 Mesh vermeintlich viel mehr Höhenpunkte enthält. Ich denke nämlich ganz ehrlich das die Terrainengine im Hintergrund gleich mit den komprimierten Daten arbeitet. Da wird bestimmt nicht erst dekomprimiert um wirklich jeden Höhenpunkt zu haben nur um dann hinterher z.B in Nordeutschland dann doch eine mehr oder weniger flache Gegend ohne große Höhenunterschiede daraus aufzubauen. Der Holger weis wie ich das meine. Ok der Test war damals im FS2002 das habe ich im FS2004 nicht getestet. Beim FS2002 war es aber so wenn der FS eine gewissenAnzahl von extrem vielen Höhenänderungen (was bei einem zerklüfteten LOD 11 Mesh der Fall sein kann) darstellen muß dann brach er ein und die Detailiertheit im hinteren Bereich nahm radikal ab. Jetzt ist die Frage was macht Microsoft um angeblich 19m Daten zu unterstützen. Drehen sie selbst nur in der FS9.CFG des Patches den TMVL auf z.B 21 hoch dann würde offiziell LOD11 unterstützt allerdings auch mit allen negativen Effekten. Da die Seen usw. recht falsch positioniert sind dürfte das ein optischer Rückschritt werden. Daher vermute ich mal das hier etwas passieren könnte von dem wir noch nichts ahnen. Ev. wird hier etwas eingebaut (ev. ein Faktor in der FS9.CFG der gesteuert werden kann )was zwar LOD11 zulässt aber auf der anderen Seite extrem steile Winkel zu LWM oder anderen Flattenbefehlen verhindert. So hätte wir die Möglichkeit zu LOD11 ohne groß negative Auswirkungen an Gewässern bzw. Airports. Das man über Manipulation des TMVL LOD11 Mesh zur Anzeige bringen kann das dürften eigentlicht alle Designer wissen das kann ich mir als Neuheit nicht vorstellen. Warten wir es ab. |
That's good news ....
allerdings wär mir ein update in Sache AI Flieger lieber gewesen. wie schön wäre das wenn die Flieger tatsächlich die definierten SIDs und STARs der Flughäfen nutzen würden und dabei beim Anflug einen vom Flugzeugtyp abhängigen Abstand zum Vordermann einhalten könnten ...... (sollte doch eigentlich nicht allzuschwer zu programmieren sein, oder?!) in diesem Sinne "taxi into position and hold" .... xaver |
@ Schubi
Ja, der Patch ist die angekündigte Überraschung... @ Alle ...und er hätte, da wir bei Drucklegung noch kein O.K. zur Veröffentlichung hatten, im Editorial als "Gerücht" erwähnt werden sollen. Allerdings wird das Editorial wegen eines Fehlers der Druckerei nicht im Heft sein... Das ist das Problem mit Printmedien. Da werden wir mehr oder weniger gezwunden, das Maul zu halten und dann kommen die Onlinemedien mit den News... na gut. Das Positive an dem Patch: All die Patches, die für Austrian Airports geliefert werden mussten, weil der verdammte Flusi bei Einhaltung der Angaben im SDK einfach abschmierte, sollten jetzt überflüssig sein. CTDs sollten ausgemerzt sein. Und es soll ein Fehler in der Terrain.dll behoben sein, der die Darstellung von hochauflösendem Mesh ermöglicht. Ja, da steht in diesem Thread schon einiges von 19m-Mesh... Soviel uns bekannt ist, war es durch den Fehler bislang aber nicht möglich ein höherauflösendes Mesh als 76m darzustellen. Dass aber heisst, dass die ganzen 38,5m Meshes nur bewirkt haben, dass der PC mehr zu rechnen hat... Und niemandem fiel wirklich auf, dass sein 38m-Mesh keine optische Verbesserung bringt. Eigentlich schon erstaunlich... @ Streithähne Das MS ein gelegentlich ein wenig arrogant zu agieren scheint, ist sicherlich nicht von der Hand zu weisen. Dass die Burschen aber für solches Vorgehen meist Gründe haben (wenn diese auch oft nur pekuniärer Natür sind), muss man auch erwähnen. Wie man auch einsehen muss, dass ein Designer, der (zumindest zum Teil) davon lebt für ein Produkt von MS Add-ons zu fabrizieren, sich über solche Attacken auf den Hersteller seiner Arbeitsbasis - sagen wir: gelangweilt fühlt. Dass Hans Hartmann nicht gerade bekannt dafür ist grosszügig über Kommentare, die ihm nicht passen hinweg zu sehen wissen wir hier ebenso, wie wir wissen, dass seine Reaktionen auf solche Kommentare schon einmal bissig ausfallen können. Verbalinjurien, auch wenn sie durch Pünktchen "unkenntlich" gemacht werden, sollten bitte dennoch unterbleiben. |
Zitat:
:D |
Zitat:
Würde auch erklären warum in der Switzerland Prof. die Leute auch mit der niedrigen Einstellung ganz zufrieden waren. (Mal abgesehen von den Meshfehlern die dann leider auftreten.) Was mich dann aber wirklich wundert warum die Jungs, die die Meshs berechnen das nicht merken. Wird da nicht getestet? Und nochmal die Bitte an die FXP: Macht doch endlich mal einen Vergleichstest der Meshs. Nicht von den Quellen, sondern davon wie es schließlich im Sim aussieht. (Habe ich an anderer Stelle schon angefragt.) |
Zitat:
Aber das ist ja echt der Hammer :eek: Das Wort ist für mich DAS bisherige Highlight des jahres in diesem Forum und sollte dem entsprechend gewürdigt werden! http://www.my-smileys.de/smileys1/xyxthumbs.gif !!!!R-E-S-P-E-K-T!!!! |
Zitat:
Jedenfalls wäre ein ausführlicher Vergleichstest wirklich absolut klasse! Gruß Roland |
Zu
Und es soll ein Fehler in der Terrain.dll behoben sein, der die Darstellung von hochauflösendem Mesh ermöglicht. Ja, da steht in diesem Thread schon einiges von 19m-Mesh... Soviel uns bekannt ist, war es durch den Fehler bislang aber nicht möglich ein höherauflösendes Mesh als 76m darzustellen. Dass aber heisst, dass die ganzen 38,5m Meshes nur bewirkt haben, dass der PC mehr zu rechnen hat... Na das werde ich doch mal testen das kann ich mir beim besten Willen nicht vorstellen das der FS2004 keine 19 Mesh darstellen kann. Da spricht nämlich alles dagegen was ich bisher gesehen habe. Außerdem dürfte dann der Terrain_Max_Vertex_Level nicht so gravierende Auswirkungen haben. Den Test kann ich ganz schnell machen z.B mit dem alten Testmesh welches ich da in dem FS2002 Link benutzt habe. |
Da bin ich mal gespannt:cool:
|
Für alle die evtl. Probleme mit dem Patch u. diverser Add-On's (Mesh, Landclass, Flüsse-Updates) befürchten.
Zur Sicherheit werde ich erstmal ein paar Sachen deinstallieren bzw. als Backup sichern, bevor ich den Patch einspiele. http://forums.avsim.net/dcboard.php?...d=211043&page= Was mein Ihr dazu...:rolleyes: Gruss;) |
Zitat:
Des wird scho alles guat geh!;) Ich mache keine Sicherung, da bei mir eh alle wie in Kraut und Rüben installiert ist, wenn´s schief geht hätte ich dann mal wenigstens einen Grund "auszumisten";) :D Gruß Lukas:) |
Zitat:
...The only issues that the MS team could imagine at this date is any 3rd party software that repairs bridges, lakes, rivers or coastlines could conflict with the patch.... Gruss |
Zitat:
Bliebe noch abzuwarten, was "conflict" genau heißt: Sieht mal bescheiden aus - oder crasht. Was weiß ich, wo ich überall Brücken habe :confused: (Belgien, NL2000, Norway, France VFR ....). Dann müßte der Patch schon enormes leisten, bis ich den installiere und dann die oben genannten Sceneries abschalte ;). |
Brücken währen harmlos. Da würde man eben mal die BGL Datei löschen der Verlust wäre nicht groß. Auch vom Addon Produzent ein Patch wäre schnell gemacht.
Seen, Flüsse, Küstenlinien das wäre sehr kritisch da dieses von fast jedem Addon mitgebracht wird. Davon sind bestimmt 70% der Addons betroffen. ATP2004, SG1, Simwings um mal einige zu nennen die Gewässercode mitbringen. Das wäre übel wenn es wirklich Probleme gibt. Zu Guidos Aussage bezüglich Mesh. Habe zwar mein File von damals nicht mehr. Daher habe ich ein neues LOD11 Mesh erstellt. Abwechselnd jeder Höhenpunkt 500m zu 1000m. Unten das Bild im FS2002 |
Hier im FS2004 bei beiden der TMVL manipuliert. Fakt der FS2004 stellt es wirklich nicht dar siehe Bild unten er bildet nur jeden zweiten Meshpunkt dar. da das Mesh bei 500m beginnt liegt die Fläche auf 500m
|
das oben gibt noch keine 100% Sicherheit denn das Mesh von mir ist extrem. Könnte sein das der FS2004 so etwas abblockt. Das kann ich mir allerdings nicht vorstellen. Auf jeden Fall kann man sehen das der FS2002 die abwechselnden Höhensprünge des LOD 11 Mesh von 500 auf 1000m darstellt. Der FS2004 siehe Bild eben nicht pendelt sich wie gesagt bei jeden zweiten Höhenpunkt mit 500m ein. Beide FS versionen werden wie gesagt mit manipulierten Terrain_Max_Vertex_Level in der FS...CFG gefahren ohne dieses wäre LOD11 eh nicht möglich.
Damit hat Guido und Microsoft recht. LOD11 wird nicht als LOD11 Mesh mit Höhenpunkten alle 19Meter im FS2004 umgesetzt es kommt allenfalls jeder zweite Höhenpunkt zur Anzeige also alle 38m ein Höhenpunkt das wäre LOD10. Jetzt müsste man noch mal ein Test mit einem LOD10 Mesh machen. |
Interessant Joachims schnelltest:)
Zitat:
Zu den Küstenlinien etc.,daß wäre ja nicht so prall! Durch soetwas würde die ohnehin schon knappe kostbare Zeit der Desighner draufgehen. |
Hallo,
zu der Aussage: „Und niemandem fiel wirklich auf, dass sein 38m-Mesh keine optische Verbesserung bringt. Eigentlich schon erstaunlich...“ Die meisten angebotenen Daten stammen so und so von den 3arcsec SRTM Daten (90m Auflösung), die neben den vielen kleinen und großen „Löchern“ bzw. Fehlern, mittels des von MS zur Verfügung gestellten Programms, in eine höhere Auflösung (ca 76m) „gezwungen“ wird. Für diese Daten ist die Änderung von MS so und so eine rein akademische Frage. Denn man kann aus schlechter Auflösung, keine bessere machen! Für diese Daten wird sich nichts ändern (ich wüsste nur als Käufer gerne, wie man die „Löcher“ stopft) 1arcsec SRTM (30m) gibt es nur für USA, und hier verwendet man besser NED. Also optisch wird es auch angezeigt siehe: http://www.wcm.at/forum/showthread.php?threadid=145644 (abgesehen von dem Einfluss für Landklassen bzw. der Einfluss der Vektoren). Mit Terrain_Max_Vertex_Level (vertex=Koordinatenpunkt). Wert 20 stellt eben ca 38m dar (LOD 10) Nur macht es keinen Sinn, da ich ja keine besseren (wegen LOD9 Mesh), sondern nur mehr Punkte erhalte. Ich kaschiere damit nur einen anderen Effekt. Denn Terrain radius hat Joachim erwähnt. Also ist die Auskunft, welche Höhendaten in welchen LOD „gezwungen“ werden, sehr wichtig! Man kann aus niedriger Auflösung (z.B. 90m) kein besseres Mesh erzeugen (z.B. LOD10) Man gibt die passenden Daten in das passende LOD! z.B. gibt man 25 m Höhengitter in LOD10 (38m) und nicht 50m, die gehören in LOD9 (76m), Dies sieht man auch im FS9, beide Levels (bzw. deren Koordinatenpunkte). LOD 11 in Beziehung zu TMVL=21 ist ein anderes Kapitel (und dies ist sicher damit gemeint) Höhendaten (oder das benutzte Mesh) haben einen sehr, sehr großen Einfluss auf die „Simulatorwelt“. Horst |
Eigentlich ist es letztendlich egal was jetzt noch zum Thema Mesh kommt. Ich gebe zu ich habe mich im FS2004 mit der Thematik Meshumsetzung nicht weiter beschäftigt. meine Testmesh für die LC Dok sind alle LOD9 die werden 100%tig umgesetzt. Einige Wissen das ich eh Verfechter für LOD9 Mesh bin. Meiner meinung nach reicht das eindeutig aus. Alles was darüber ist bringt durch die zwangsweise Erhöhung des Terrain_Max_Vertex_Level in der FS9.CFG meiner Meinung nach nur Nachteile.
Ich habe trotzdem noch mal einen Test mit LOD10 gemacht. Was man aber auch bedenken sollte das wir im FS2004 die zwei neuen Paramter TERRAIN_MIN_DEM_AREA=10.000000 TERRAIN_MAX_DEM_AREA=100.000000 haben. Kann sein das hier irgendwer mal was zu erwähnt hat. Ich habe diese Paramter nie manipuliert oder getestet. Ich schliesse nicht aus das man hiermit auch noch Veränderungen wie auch immer erreichen kann. Bisher hat meines Wissens an diesen beiden Parametern noch kein Addon dran herumgeschraubt. Meine Tests waren mit jungfräulicher FS...CFG. Ich habe dann alle Meshregler nach rechts geschoben und den TMVL auf 21 gesetzt was heimlich viele Addons machen um Ihr LOD11 Mesh zur Anzeige zu bringen. Wie wir gesehen haben funktioniert LOD11 nur im FS2002 nicht aber im FS2004. Ich denke mit dem Patch beginnt die Zeitrechnung von vorn vorher braucht man sich keine Gedanken mehr drüber machen was jeder Parameter wirklich für Einflüsse hat. Zum LOD10 Mesh. Es wird im FS2002 wieder 1 zu 1 umgesetzt. Jede meiner 1000M Nadeln ist zu sehen. |
So und jetzt kommt es. Wie sieht das selbe Testmesh im FS2004 aus. Bild siehe Anhang. Fakt ist ein LOD10 mesh wird im FS2004 angezeigt. leider aber nicht korrekt. Es müssten 1000m hohe Nadeln sein. Sind es aber nicht. Es gibt hier irgendwelche Störungen. Auch verhält sich das etwas anders wenn ich den TMVL von 21 auf 20 runtersetze. Dann sieht es anders aus ist aber immer noch nicht 1 zu 1 umgesetzt.
Gehe ich auf den Defaultwert TMVL 19 wird auch das LOD10 Mesh nicht dargestellt ich habe wieder ein flache Fläche mit 500 Meter also den Basisbodenwert meines Testmesh. Mein Fazit aus der Sache. Nur LOD9 funktionierte bisher im FS2004 einwandfrei. LOD11 funktionierte garnicht es wurde nur als LOD10 dargestellt. Da aber LOD10 auch nicht fehlerfrei dargestellt wurde haben wir wohl alle mehr oder weniger Schrott gesehen. Guidos Aussage das es niemand aufgefallen ist lässt sich aber erklären. Dadurch das ich bei Änderung des TMVL von 19 zu 20 und 21 eine Änderung an einem Mesh größer LOD9 feststelle gaukelt das uns ein Verhalten vor welches wir vom FS2002 kennen. Und schon fällt man drauf rein. Wie gesagt meine Testmesh geben den Beweis das es nicht 100%tig umgesetzt wird. was aber nicht ausschliesst das der FS2004 im Gegensatz zum FS2002 etwas eingebaut hat was eigentlich unrealistische Meshwerte nicht zulässt. denn auch der TERRAIN_ERROR_FACTOR=75.000000 hat jetzt andere Dimensionen. Im FS2004 Prozent, vorher im FS2002 ein Faktor (keine Ahnung) Aber wenn der FS2004 unrealistische Werte ev. halbwegs abfängt wo fängt dann unrealistisch an und wo hört es auf. Tafelberge an Gewässern oder Airports lies er zu (unrealistisch) , so das man wohl doch definitiv von einem Bug ausgehen kann. Im Prinzip müsste man jetzt Tests ähnlich denen machen wie ich es damals bei dem Faitman Mesh gemacht habe. Nur das man hier die reale Welt außen vor lässt sondern erst mal Meshhöhenpunkt der MeshBGL mit dem umgesetzten Wert im FS2004 vergleicht. Unten das im Gegensatz zum LOD11 Mesh im FS2004 zwar umgesetzte LOD10 Mesh welches allerdings wie gesagt nicht korrekt umgesetzt wird. Es sind eindeutig nicht überall 1000m Nadeln zu erkennen. |
Hallo Joachim,
Herzlichen Dank für den ausführlichen Test! Dies bedeutet, das die wenigen LOD 10 mesh files von Micrsoft (Hoover Dam, Mount Rainier..), nicht richtig dargestellt werden, oder? Horst |
Ich würde nich sagen das sie extreme Fehler durch dieses oben genannte Phänomen haben. Bei einem realen Mesh wird sich das etwas verlaufen. Aber man kann eindeutig sagen das der FS2004 nicht jeden Höhenpunkt der BGL 1 zu 1 auch in der Grafik umsetzt von daher sind definitiv Fehler drin die uns als Betrachter aber ev. nicht auffallen.
|
Diese Woche habe ich nur noch wenig Zeit für den FS nächste Woche bin ich nicht da. Ich werde ev. daher den Patch verpassen. ich kann aber jedem nur empfehlen ev. vorsichtig zu sein sich Sicherungen anzulegen. Sinnvoll wäre auch eine Aufzeichnung was beim Patch abläuft.
Ev. ist es sinnvoller sich aus dem Patch nur diverse Verbesserungen rauszuziehen falls es doch größere Probleme mit Addons geben sollte. |
EDIT: Versehentlicher Doppelpost. Irgendwie bleibt bei mir dauernd die Verbindung beim Posten hängen, und wenn ich dann abbreche, taucht der Beitrag manchmal trotzdem auf, manchmal aber auch nicht. Sorry.
|
EDIT: Versehentlicher Doppelpost.
|
@Joachim: Guter Test! :ja:
Ich finde es toll, dass MS endlich wieder die Produkte kostenlos patched anstatt immer die Patches zu verkaufen! :) Schön, dass sie sich den katastrophalen Memory-Leaks angenommen haben -- der gute Wille ist immerhin da. Ging ja auch nicht an, dass manchmal jeder zweite Mittelstreckenflug an einem CTD scheitert -- trotz Jobias Patch! In dem Thread verbirgt sich weiter unten noch eine Aussage, die ich hier noch nicht gesehen habe: Da sagt jemand, der auch auf der Pressekonferenz gewesen sein will, dass MS nicht nur schon die nächste Version plant (wurde oben schon zitiert), sondern dass man ab jetzt auch die SDKs VOR dem Release der neuen Version des FS veröffentlichen möchte! Das wäre geradezu revolutionär und würde bedeuten, dass der update-Zyklus von MS von 1,5 bis 2 Jahren wieder mehr Sinn macht. Man hätte eher neue Addons und Kompatibilitätspatches für die alten! Hier der Beitrag aus dem AVSIM-Thread: Zitat:
Für den AI Verkehr würde ich gerne sehen, dass ATC staffelt und Holdings vergibt, um eine Staffelung einzuhalten. Das würde völlig reichen. SIDs / STARs kann man heute schon selbst fliegen ohne dass ATC meckert, wenn man die Wegpunkte in den IFR-Flugplan gibt. Die AI Flieger müssen das meiner Meinung nach nicht können. Wenn man SIDs und STARs umsetzt ist das ein riesen Aufwand, und Nachher regen sich alle auf, dass es eh veraltete Daten sind. Was sonst noch fehlt: Man sollte wieder wie im FS2002 Landebahnen wirksam schließen können. Und die Beschränkung von 8° Unterschied zwischen zwei Bahnen für Parallelbahnbetrieb muß wieder weg. Dann kann das ATC auch besser arbeiten, wenn man den Verkehrsfluß wieder besser lenken kann. Aber das kommt wohl alles erst mit dem FS2006... :heul: Und wie gut, dass ich mir gerade eine neue Festplatte besorgt habe, so dass ich jetzt endlich ordentlich backups machen kann! Alles Gute und feste Daumen drücken! |
Hier nun ein paar erste Shots zum Update...
Sorry, ich wollte ein Link posten aber leider funzt der irgendwie nicht... Dann müsst ihr eben ein wenig scrollen. http://forums.avsim.net/dcboard.php?...1348&mode=full Gruss ;) |
Hallo,
Kurz zurück zu 76m und 19m – Patch (??) und 38m Darstellung! Zwei Bilder, Bild1: Matterhorn (Schweiz) (mit normalen FS Texturen) Wir befinden uns in Zermatt: http://www.zermatt.ch/ Die Perspektive soll dieses „Seilbahnbild“ darstellen. Mesh: LOD 9, TMVL:19 Bild2: Erhöhung des TMVL auf 20. Für diese Daten (LOD9 )eine Katastrophe, für andere Daten jedoch nicht!! Wäre dies genauso bei LOD10 Mesh für die gleichen Source Daten? Warum klatscht man (oder frau), für diesen Schritt von MS? Vielleicht kann man dies ja irgendwo einmal nachlesen (in deutscher Sprache). Diese Problematik sollte Designern, die mit Installationsprogrammen dies manipulieren (besser ihre Fehler ausbessern), bewusst sein. Bzw. ist eine Aufklärung der Kunden über Zusammenhänge sehr notwendig! Man sollte bei Produkten nicht nur den optischen Eindruck berücksichtigen, sondern auch die Änderung von globalen Auswirkungen betrachten! Bzw. Installationsprogramme durchleuchten. Vorteil und Nachteil :) Horst PS: der Patch hat sicher keine Auswirkungen auf dies, bzw. werde ich auch keine neuen Meshfiles, Küstenlinien, Straßen usw. bekommen. Es ist ein kleiner, notwendiger Patch, und bei MS nicht selbsrverständlich. |
Bild2
|
@ Horst LOWW
Stimm schon, dass die meisten Mesh-Terrains auf den 3arcsec 76m Daten beruhen. Für die USA sind jedoch 1 arcsec Daten verfügbar und die werden auch vermarktet und umgesetzt... Und ein bekannter Mesh-Bauer mit einer großen Website schreibt bein einem seiner Freeware-Probemeshs "it's made as a 19m Mesh - the queen of all meshes"... Zumindest diesen Leuten hätte es auffallen müssen... @ Michael Garbers Nein, es wird in FXP keinen Vergleichtest der Meshs geben. Im neuen Heft auf Seite 39 steht unter anderem auch, warum nicht... |
@ Horst LOWW
Stimm schon, dass die meisten Mesh-Terrains auf den 3arcsec 76m Daten beruhen. Für die USA sind jedoch 1 arcsec Daten verfügbar und die werden auch vermarktet und umgesetzt... Und ein bekannter Mesh-Bauer mit einer großen Website schreibt bein einem seiner Freeware-Probemeshs "it's made as a 19m Mesh - the queen of all meshes"... Zumindest diesen Leuten hätte es auffallen müssen... @ Michael Garbers Nein, es wird in FXP keinen Vergleichtest der Meshs geben. Im neuen Heft auf Seite 39 steht unter anderem auch, warum nicht... |
Hallo zusammen,
interessante Diskussion zum Thema Mesh: besten Dank fuer die Tests, Joachim und Horst! Horst, meine Frage bzgl deines Matterhorns: wo kommt denn das her? Keines der SRTM-basierenden Mesh Files kann so ein LOD9 Matterhorn enthalten, weil die Originaldaten dort naemlich ein grosses Loch haben. Also muss dein Mesh (Hersteller?) entweder das Matterhorn aufgesetzt haben (als LOD10 oder LOD11 Mesh) oder Ersatzdaten eingebaut haben. Beides wuerde aber deinen Vergleich beeinflussen, oder nicht? Ciao, Holger |
@Guido: Schade. Für mich persönlich ist es eh zu spät, ich habe mich blind festgelegt. Für andere wäre es eine Entscheidungshilfe gewesen. Wie ich schon an anderer Stelle sagte, sicher hat jedes Mesh seine Vor- und Nachteile und jeder User hat andere Präferenzen.
Es wäre also kein "Niedermachen" und "Pushen" des anderen. |
Man müsste jetzt mal die Mesh Höhendaten der BGL auswerten.
Wie gesagt der FS2002 hat 1 zu 1 sauber umgesetzt. Nur ich erwähnte ja schon zu FS2002 Zeiten TMVL höher 19 vorne Hui hinten Pfui. Denn bei meinen LOD11 Mesh kann man etwas nicht sehen. Das LOD11 Mesh geht wesentlich weiter in die Tiefe des Raumes. Nur der FS schaltet an der Grenze wo man die Nadeln gerade noch sieht in eine niedrigeren LOD Level. Fliegt man weiter würden sich neue Meshnadeln aufbauen was korrekt für mein Testmesh wäre. Mir ist aber aufgefallen umso mehr der FS2002 grafisch an Höhenpunkten 3D mäßig wirklich darstellen muss umso eher baut er in die Tiefe des Raumes ab. Belässt man aber den TMVL bei 19 oder aber maximal 20 verschiebt sich die Grenze nach hinten. Macht natürlich nur Sinn bis LOD10. Das Mesh ist auch in der Tiefe des Raumes besser. Wie gesagt das waren Erfahrungen aus dem FS2002. Von daher zweifele ich auch an einigen Aussagen bezüglich Sichtbarkeitsgrenze von verschiedenen Mesh LOD Level. Ev. muss man hier auch den Informationsinhalt des Mesh mit einbeziehen. Prinzipiell beim FS2004 ähnlich, wenn man hiermal außer Betracht lässt das er überhaupt nicht 1 zu 1 sauber umsetzt bei Manipulation. Bei LOD9 Mesh und TMVL 19 hat der FS2004 bei meinen Testmesh bisher aber immer 1 zu 1 sauber umgesetzt. Ich denke Horst es sind einfach Aussetzer bei Deinem zweiten Foto. Du siehst bei meinem LOD10 Mesh auch das nicht jede Meshnadel vorhanden ist. Wenn bei manipulierten TMVL also über 19 beim Matterhorn ein paar Höhenpunkte fehlen dann bleibt ev. halt nur noch so eine Spitze wie in Deinem Bild vom Matterhorn übrig. Aber ich denke die Masse der Anwender hat solche Effekte nicht gehabt, das hätte auf jeden Fall keine positiven Effekte ausgelöst. Das Matterhorn ist doch recht bekannt so etwas wäre negativ aufgefallen. Wie Du selbst schreibst treten diese Effekte nicht bei jedem Mesh auf. Das deckt sich ja auch mit dem was ich erwähnt habe. Ev. gibt es einen Faktor im FS der gewisse unrealistische Werte abfängt oder mildert. Deshalb könnte es einigen Meshdesignern nicht aufgefallen sein. Man muß aber auch mal eins bedenken. Meshprogrammierung gehört zu den Techniken die im wesentlichen auf Automatismen beruhen (es sei denn man beschäftigt sich mit Löcherstopfen oder Airportanpassungen beim Mesh) von daher fallen hier Fehler im Gegensatz zum Airportdesign nicht so schnell auf. Die Fehler endeckt dann in der Regel erst der Anwender. Ich vermute auch ganz stark das die meisten Meshdesigner Ihre Daten hinterher im FS überhaupt nicht mehr stichprobenweise kontrollieren. Da es Tools gibt die aus SRTM Daten fast automatisch Meshfiles erzeugen gibt es einige Designer (nicht alle) die es damit nicht so genau nehmen. Das haben wir ja nun schon oft von gehört. Dann kommen da ev. spektakuläre Meshfiles bei raus die mit der Realität nicht viel gemein haben. Zum Thema TMVL und dessen neagtive Auswirkungen im FS2004. Es sind ja auch nur ein paar Addons bekannt die am TMVL Änderungen vornehmen. Persönlich weis ich das nur von der Switzerland Prof. denn da wurde es hier im Forum vom Entwickler bestätigt. Die anderen Addons da kenne ich das nur von Äußerungen einiger Anwender. Letztendlich denke ich sollten wir abwarten was der FS2004 Patch bringt. Setzt der FS2004 dann 1 zu 1 um kann man sich ja ev. mal intensiver mit diversen Parametern in der FS9.CFG beschäftigen wie man Parameter am besten einstellt. |
Man müsste jetzt mal die Mesh Höhendaten der BGL auswerten.
Wie gesagt der FS2002 hat 1 zu 1 sauber umgesetzt. Nur ich erwähnte ja schon zu FS2002 Zeiten TMVL höher 19 vorne Hui hinten Pfui. Denn bei meinen LOD11 Mesh kann man etwas nicht sehen. Das LOD11 Mesh geht wesentlich weiter in die Tiefe des Raumes. Nur der FS schaltet an der Grenze wo man die Nadeln gerade noch sieht in eine niedrigeren LOD Level. Fliegt man weiter würden sich neue Meshnadeln aufbauen was korrekt für mein Testmesh wäre. Mir ist aber aufgefallen umso mehr der FS2002 grafisch an Höhenpunkten 3D mäßig wirklich darstellen muss umso eher baut er in die Tiefe des Raumes ab. Belässt man aber den TMVL bei 19 oder aber maximal 20 verschiebt sich die Grenze nach hinten. Macht natürlich nur Sinn bis LOD10. Das Mesh ist auch in der Tiefe des Raumes besser. Wie gesagt das waren Erfahrungen aus dem FS2002. Von daher zweifele ich auch an einigen Aussagen bezüglich Sichtbarkeitsgrenze von verschiedenen Mesh LOD Level. Ev. muss man hier auch den Informationsinhalt des Mesh mit einbeziehen. Prinzipiell beim FS2004 ähnlich, wenn man hiermal außer Betracht lässt das er überhaupt nicht 1 zu 1 sauber umsetzt bei Manipulation. Bei LOD9 Mesh und TMVL 19 hat der FS2004 bei meinen Testmesh bisher aber immer 1 zu 1 sauber umgesetzt. Ich denke Horst es sind einfach Aussetzer bei Deinem zweiten Foto. Du siehst bei meinem LOD10 Mesh auch das nicht jede Meshnadel vorhanden ist. Wenn bei manipulierten TMVL also über 19 beim Matterhorn ein paar Höhenpunkte fehlen dann bleibt ev. halt nur noch so eine Spitze wie in Deinem Bild vom Matterhorn übrig. Aber ich denke die Masse der Anwender hat solche Effekte nicht gehabt, das hätte auf jeden Fall keine positiven Effekte ausgelöst. Das Matterhorn ist doch recht bekannt so etwas wäre negativ aufgefallen. Wie Du selbst schreibst treten diese Effekte nicht bei jedem Mesh auf. Das deckt sich ja auch mit dem was ich erwähnt habe. Ev. gibt es einen Faktor im FS der gewisse unrealistische Werte abfängt oder mildert. Deshalb könnte es einigen Meshdesignern nicht aufgefallen sein. Man muß aber auch mal eins bedenken. Meshprogrammierung gehört zu den Techniken die im wesentlichen auf Automatismen beruhen (es sei denn man beschäftigt sich mit Löcherstopfen oder Airportanpassungen beim Mesh) von daher fallen hier Fehler im Gegensatz zum Airportdesign nicht so schnell auf. Die Fehler endeckt dann in der Regel erst der Anwender. Ich vermute auch ganz stark das die meisten Meshdesigner Ihre Daten hinterher im FS überhaupt nicht mehr stichprobenweise kontrollieren. Da es Tools gibt die aus SRTM Daten fast automatisch Meshfiles erzeugen gibt es einige Designer (nicht alle) die es damit nicht so genau nehmen. Das haben wir ja nun schon oft von gehört. Dann kommen da ev. spektakuläre Meshfiles bei raus die mit der Realität nicht viel gemein haben. Zum Thema TMVL und dessen neagtive Auswirkungen im FS2004. Es sind ja auch nur ein paar Addons bekannt die am TMVL Änderungen vornehmen. Persönlich weis ich das nur von der Switzerland Prof. denn da wurde es hier im Forum vom Entwickler bestätigt. Die anderen Addons da kenne ich das nur von Äußerungen einiger Anwender. Letztendlich denke ich sollten wir abwarten was der FS2004 Patch bringt. Setzt der FS2004 dann 1 zu 1 um kann man sich ja ev. mal intensiver mit diversen Parametern in der FS9.CFG beschäftigen wie man Parameter am besten einstellt. |
mein Gott ist es jetzt mal gut mit den Doppelpostings, allein in diesem Thread schon an die 10 stück.
|
Horst, Ist es nicht vielleicht noch ein bißchen zu früh nur davon auszugehen, dass MS einfach den TMVL-Wert in der cfg-Datei ändert? Vielleicht ändern sich ja auch einige von den grundlegenden Dingen, die Joachim ansprach durch den Patch, so wie:
- Abhängigkeit der Sichtweite eines LODs von der Komplexität des Meshes - Interne Korrekturmechanismen - "Aussetzer" in der Darstellung -- nicht jeder Datenpunkt wird umgesetzt, obwohl es vom LOD her passen müßte (hab ich soweit alles richtig verstanden?) Der erste Punkt zielt ja ganz klar auf die Performance ab. (Mehr Details vorne -- weniger Details hinten -- Summe bleibt etwa konstant.) Wenn MS die terrain.dll in Details ändert, könnten sie nicht dann auch diese Balance angepasst haben? Wir werden wohl abwarten müssen -- ich bin jedenfalls gespannt! Kurz Off Topic zu den Doppelposts -- das hat irgendwas mit Serverproblemen oder -Belastung zu tun, denke ich. Ich weiß nicht, wie es bei Jobia war, aber bei mir lieg es so: Ich drückte auf "Antworten", der Ladebalken bleibt dann in der Mitte hängen. Dann bin ich zurück gegangen, hab geguckt, ob mein Post dar war (Refresh nicht vergessen!), war es nicht. Also wieder das selbe gepostet. Abgeschickt -- es blieb nicht hängen. Aber: Beide Beiträge waren da! Hab ich was falsch gemacht? Liegt wohl daran, dass das Forum neue Beiträge vielleicht nicht gleich sofort anzeigt? |
Hallo,
nur kurze Anmerkungen, da ich kein "Insider" bin, und die Zusammenhänge und Auswirkungen betrachtet werden sollen. @Guido Auch 1 arcsec SRTM Daten in 19m zu "zwingen", wäre für mich sinnlos! Solche Daten (bzw Umsetzungen) zu verkaufen = völliger Blödsinn. Deinen Satz finde ich leider nicht "it`s made…". (Ehrlich gesagt, ich habe jetzt auch keine Ahnung wo ich "googeln" soll!). Die Problematik ist aber schon länger bekannt (siehe Steve Greenwood) Was die Darstellung von LOD11 Daten (Mesh) derzeit überhaupt für einen Sinn hat, bei unserer Rechnerleistung, verstehe ich überhaupt nicht! Es macht, wie du schreibst (oder wie ich es interpretiere), im Prinzip keinen Sinn! Ich mache dies meistens selbst, daher kenne ich die meisten Produkte nicht. @Holger Dies sind keine SRTM Daten. Der Hersteller (:)) versucht lediglich die Beziehungen und Auswirkungen zu verstehen! LOD 10 und LOD 11 kann ich aus der Entfernung derzeit im FS nicht sehen. Wenn man das Matterhorn alleine macht in einem andern LOD Level, muss ich ausprobieren (nehme aber an, dass ich keinen merkbaren Einfluss habe) Ich wollte eigentlich nur den Einfluss von TMVL darstellen. @Joachim Keine Aussetzer! (Resample to LOD13 (oder LOD12), hier kann man die "Einblendung" (bzw. den Zeitpunkt des Erscheinens sehr gut nachvollziehen)) @Felix Man ändert sicher nicht diesen Wert in der cfg Datei! Das könnte ich derzeit selber auch. Es geht nur um den "inneren" Ablauf. Horst |
Microsoft
Hallo,
ihr wißt alle mehr als die Leute von Microsoft. Habe heute mit einem Mitarbeiter von Microsoft gesprochen , er sagt , es wäre was im Busch , aber was , wann irgendetwas von Microsoft als Update rauskommt , weiß niemand. Solange nichts in der Seite von Microsoft steht sind das hier alles sogenannte Schei...hausparolen. |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 17:17 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag