|
Hi!
Ohne jemand schützen zu wollen,soetwas gibt es doch öffters! Z.b. bei Traffic 2005,dort wird ja auch die Freeware von AI Smooth verwendet. Oder was war mit Hamburgs City die dann irgendwann überarbeitet in der SG2 zu finden war...........?;) |
Hallo zusammen,
Zitat:
Die Beigabe der Haustexturen zu BEV war urspruenglich gar nicht geplant. Nur weil der Autor von "Koorbygen", aus welchen Gruenden auch immer, bei BEV ausgestiegen ist und seine Files jetzt als Freeware und etwas grosskotzig als "most utterly gorgeous" anpreist, heisst das noch lange nicht, dass BEV selber jetzt weniger wert ist. Allerdings stimmt das mit dem "gleich auf den Zug auspringen" schon: wenn ich mir FS-Addons kaufe, dann ist das in der Regel auch erst einige Monate nach dem Erstverkaufstag ;) Ciao, Holger |
Übrigends ich habe das auch nicht wegen der Bodentexturen gepostet.
Denn das ist ja eigentlich inkl. der Autogenpositionierung das Hauptgebiet von BEV ganz klar. Welches natürlich auch nur durch BEV erhältlich ist. Ich habe das nur gemacht, weil mir dieses Bild der Autogentexturen was Cole verlinkt hatte in Erinnerung geblieben ist. Schaut man bei BEV dann steht da halt Exclusiv. Bei AVSIM handelt es sich um die selben Screenshots. Zunächst hatte ich sogar gedacht, es handelt sich um etwas illegales bei AVSIM. Nachdem aber das Korbeygen (oder ähnlich) im Screenshot zu sehen ist, war klar das es sich um die selbe Geschichte handelt und legal ist. War also nur als Vermerk falls jemand gefallen an den Screenshots gefunden hat er dieses auch als Freeware bekommen kann. Wie Holger schon sagt Autogentexturen sind nicht viel Dateien und mit der wesentlich aufwendigeren Arbeit bzw. sehr viel höheren Anzahl an Bodentexturen nicht zu vergleichen. So finden sich z.B alle Autogenbäume einer Jahreszeit in nur einer größeren Textur untergebracht. Der FS kommt also über das Jahr gesehen mit 5 Texturen für Autogen Bewuchs aus. |
O.K., danke für eure Ausführungen. Da bin ich wohl weit übers Ziel hinaus geschossen (was ich lassen sollte, wenn ich - anders als ihr - die tieferen Zusammenhänge zwischen Bodentexturen , Autogenen usw. bislang nicht so verstanden hatte). Blödsinn ist das deshalb aber noch lange nicht.
Nun gut, "Kommmando" zurück. Aber durch dieses Forum lerne ich halt immer wieder dazu. Hamburg City oder AISmooth gab es zuerst als Freeware, dann wurde es in Payware-Produkte übernommen. Korbygen hingegen wurde erst nach der Veröffentlichung mit dem kostenpflichtigen BEV als Freeware bereit gestellt. Das ist für mich daher schon was anderes. Gruß Michael |
Hallo Miachael,
sorry fuer das Wort "Bloedsinn", das war ein Fehlgriff! Hast auch recht mit deinem letzten Absatz bezgl. der Reihenfolge. Was ich dazu sagen kann ist lediglich, dass die Freeware-Veroeffentlichung von Koorbygen das BEV Team selber voellig ueberrascht hat. Kommt ja nicht oft vor, dass jemand Software als "Stimmungsmacher" in einer internen Auseinandersetzung benutzt. Wollte mit meinen direkten Worten eigentlich nur verhindern, dass jemand auf die Koorbygenpropaganda hereinfaellt :confused: Wer sich durch dieses "Kasperltheater" (Zitat Horst) um sein Geld betrogen fuehlt, kann es entweder bei Flight1 zurueckfordern, oder sich vor Augen halten, dass, als FScene im letzten Jahr noch das Monopol hatte, man pro Jahreszeit und Region 40 Euronen zahlen musste, wenn ich mich recht erinnere. Und da gab es nur einen Textursatz (keine Auswahl wie bei BEV) und auch keine der Textur angepassten Autogenplazierung. Mal sehen wie sich das bei BEV so weiterentwickelt. Abwarten und Tee trinken :look: Ciao, Holger |
Zitat:
http://www.flightsim-bevs.com/smf_1-...hp?topic=475.0 sorry I only read German but cannot write it. Stephen deleted all posts against BEV, he must have missed this one. Every insider in the simmer community knows BEV is a team of liars and cheats. Many posts on Flight One and AvSim about this. On BEV though, threads are deleted and non-ass-kissing users being locked out. Cole (the webmaster) and koorby (the programmer/designer) already fled from those characters. Stick with FScene and/or Flight Environment. :hammer: |
Hallo,
seht ihr was ich meine? Die Koorbygen-Propagandamaschine rollt fleissig weiter :ms: Gluecklicherweise kann sich ja jeder selber denken, dass die Qualitaet von BEV (und Koorbygen) mit diesem erheiternden Schlagabtausch nichts zu tun hat. Ausserdem ist auch bereits bekannt, dass jemand vom "Flight Environment" Team (Stichwort "die Wahrheit")kraeftig gegen BEV randaliert; daher auch der Kaufhinweis auf FE :lol: Selten so gelacht. Ciao, Holger |
@ BC_Holger
Hallo Holger,
alles klar. Jetzt blicke ich ja schon ein wenig mehr durch. Ich hatte das auch ins Forum von BEV geschrieben und ganz freundliche und auch erklärende Antworten bekommen. Dazu sogar den Hinweis, den Du auch gegeben hast, dass ich über Flight1 den Kauf rückgängig machen könnte (was ich aber nicht will). Derzeit komme ich nicht auf die Forum-Seite von BEV - aber das hat wohl nichts mit meinen Beitrag zu tun sondern wohl eher mit deren Server. :confused: "Korbygen" ist ja - wie ich erst jetzt weiß bzw. verstehe - nicht das einzige Autogen, was mit BEV geliefert wird. Es gibt da noch das sog. "GENreloaded" in drei Ausführungen für verschiedene Regionen. So ganz hatte ich nämlich deren Configurator noch nicht durchschaut. Jetzt aber geht es schon. Und es stimmt, das korbygen ist da nur ein sehr kleiner Faktor im gesamten BEV-Produkt. Gruß Michael |
Hallo,
@die Wahrheit Do you have a name? Quote: ” sorry I only read German but cannot write it.” Das ist ja schön, dann kann ich dir in deutscher Sprache antworten. Aber setze auch voraus, dass du den Thread gelesen hast. Quote: "Stephen deleted all posts against BEV, he must have missed this one." Also zitiere ich mich selbst aus meinem letzten Beitrag: "Eigentlich schade für den Autor und seine Arbeit. (zumindest nach den Screenshots)" Ich meinte damit STEPHEN! Dieser Thread ist überhaupt nicht gegen BEV orientiert!! Sondern ist eine kleine Aufarbeitung von Joachims Doku (nehme ich an, da ich noch keine Zeile davon gelesen habe) Im Prinzip: Welche Voraussetzungen benötigt man, um LC Texturen korrekt darzustellen im FS9? Und die Zusammenarbeit in Nordamerika dürfte besser sein für den Konsumenten, als hier in Europa!! Wir haben diese Daten zu bezahlen!! Versprechungen gibt es viele, und fertige "Großflächen-Addons" wenige (besser: leider keine!) Quote: "Stick with FScene and/or Flight Environment." Hast du auch sachliche Kommentare hier im Forum dazu gelesen!! :lol: Also: entweder bleiben wir sachlich zu dem Produkt (Details) oder lieber "die Wahrheit" (komisher Name!) vergiss deinen Auftritt. Kind regards Horst |
Zitat:
|
Nun verstehe ich gar nichts mehr.
Ich hatte ja gerade geschrieben, dass ich hinsichtlich korbygen auch ins BEV-Forum geschrieben hatte. Und das ich freundliche, sachliche und zun Verständnis geeignete Antworten bekam. Und jetzt erscheint diese Meldung auf deren Forum-Seite, wenn ich die aufrufe: "An Error Has Occurred! Sorry Guest, you are banned from using this forum! You have breached what is fair and ethical on these boards. Please refrain from posting and visiting this site again." Ist das nun ein "Error" oder der Ausschluss vom Forum? Ich war weder unhöflich noch unsachlich noch frech noch unfair noch unethisch, was ja auch die entsprechenden Antworten vom BEV-Team (Admins, Beta-tester usw.) belegen. Also ein genereller Auschluss all derjenigen, die irgendetwas bemängelten oder kritisierten oder Fragen stellen, die so ausgelegt werden könnten? Und woher weiß deren Server, dass ich es bin, der Zugriff auf das Forum haben will? Über meine IP-Adresse? Die kommt von einem Router. Cookies habe ich nicht. Was läuft da ab? Bin ich tatsächlich ausgeschlossen worden, dann hole ich mir tatsächlich mein Geld von Flight1 zurück. Das BEV-Team kann doch nicht derart empfindlich sein. Und dann hätte "dieWAHRHEIT" diebezüglich Recht gehabt. Gruß Michael |
Hallo Michael,
sehr seltsam! Ich habe gerade mal nachgeschaut und einen User "M.C." gefunden - das bist wohl du? Der Thread ist dieser http://www.flightsim-bevs.com/smf_1-...hp?topic=545.0 und es sieht so aus, als ob dein Account auch weiterhin aktiv waere. Wenn das auch weiterhin nicht klappt, kann ich mal direkt bei der Quelle nachfragen, wieso du dich nicht mehr einloggen kannst. Dein Beitrag dort war ja nun wirklich kein Grund zur Sperrung; im Gegenteil, kommt ja eigentlich eher als Werbung fuer BEV rueber. Ciao, Holger |
Hallo Holger,
hat eben nicht geklappt mit meiner Antwort, plötzlich war die Seite weg (das nur für den Fall, dass meine Antwort doch noch verarbeitet wurde). Also noch einmal: Ich nenne mich im BEV-Forum in der Tat auch M.C., Du hattest also meinen Beitrag gefunden. Vielen Dank für dein Angebot, dort ggf. mal nachzufragen, aber seit heute geht alles wieder und ich kann auch Beiträge schreiben. Was es war, wer weiß? Gruß Michael |
Zitat:
Drum ist das jetzt auch mein wirklich letzter Post hier in diesem Forum. Dir aber viel Erfolg mit der OÖ Szenerie! :-) Marc |
Um noch mal auf das Thema Mesh (LOD12) und die bisherigen Beiträge dazu in diesem Thread zurückzukommen.
Zunächst mal in Bezug auf diese Frage von Holger: "Was mich aber besonders interessiert ist deine Aussage bzgl des Leistungseinbruchs beim Oversampling, also ein LOD12 Mesh, das als LOD11 oder LOD10 dargestellt wird. Hast du das mal quantifiziert mit deinem Testmesh?" Eines vorweg. Dieses habe ich wie oben nicht geschrieben. Ich habe geschrieben: "Also verstehe ich nicht warum es damals LOD12 Mesh gab und warum es sie heute gibt. Damals schon brach der FS2002 in der Performance extrem ein wenn man ein LOD11 Mesh mit viel differierenden Höhenpunkten hatte. Da wo man kaum Differenzen hat, bricht es nicht stark ein. Nur dort ergibt in der Regel auch kein LOD11 Mesh einen Sinn und schon garnicht ein LOD12 Mesh." Trotzdem schön, dass Holger dieses ev. anders ausgelegt hat. Wobei ich die Aussage für mich in zwei mögliche Interpretationen einteilen muss. Wobei ich nicht weis wie die Aussage wirklich gemeint war. mögliche Variante 1. Wenn man dem FS2004 LOD12 Meshfiles anbietet (die er optisch allerdings bestenfalls ähnlich LOD11 Mesh umsetzen kann), dann wird er jetzt allein dadurch stärker belastet, dass er das LOD12 Mesh ins LOD11 Raster oder niedriger berechnen muss. Dazu muss ich sagen, dass ich es so nicht gemeint habe. mögliche Variante 2. Der FS2004 wird durch das LOD 12 Mesh welches wie auch immer ins LOD11 Raster oder niedriger gebracht wird (um es optisch darstellen zu können) stärker belastet als durch ein Mesh welches im Vorfeld schon in LOD11 produziert wurde. Ich habe Variante 2 gemeint. Die stärkere Belastung aber allein dadurch, dass es sich um ein LOD12 Mesh handelt, unabhängig davon ob es der FS darstellen kann bzw. ob es durch einen TMVL in der Darstellung begrenzt wird. Zur Erklärung folgenden Text. Der Text zu diesem Sachverhalt ist allgemein und vereinfacht für jeden den es interessiert. LOD12 bedeutet bei einem Mesh Scenery File, dass ca. alle 9,5m ein Höhenpunkt definiert werden kann. LOD11 bedeutet bei einem Mesh Scenery File, dass ca. alle 19m ein Höhenpunkt definiert werden kann. LOD10 bedeutet bei einem Mesh Scenery File, dass ca. alle 38m ein Höhenpunkt definiert werden kann. LOD9 bedeutet bei einem Mesh Scenery File, dass ca. alle 76m ein Höhenpunkt definiert werden kann. Nach diesem Verfahren geht das immer weiter, die Zahlen sind allerdings nur angenähert. Wer die wirklichen Abstände genau wissen will muss es für jede Koordinate berechnen. Die Sachlage ist demnach von der Theorie, dass ein LOD12 Mesh mehr Details als ein LOD11 Mesh File darstellen kann. Wenn diese LOD12 FS Genesis Meshfiles einen Sinn ergeben sollen, dann muss der FS2002 oder ev. der FS2004 natürlich technisch in der Lage sein jeden Höhenpunkt so eines LOD12 Meshfiles auch optisch im 3D Gelände aufzulösen. Das bedeutet jeder einzelne Höhenpunkt muss im 3D Gelände (zumindest im Nahbereich) in irgendeiner Form umgesetzt und messbar bzw. mindestens irgendwie nachweisbar sein. Cole schrieb, dass diese FS Genesis Meshfiles einen Sinn ergeben, da sie ursprünglich für den FS2002 produziert wurden. Dieser soll im Gegensatz zum FS2004 noch LOD12 Meshfiles mit jedem Höhenpunkt alle ca. 9,6m dargestellt haben. Ich habe das noch mal genau mit eigenen verschiedenen Testmeshfiles ausgetestet. Der FS würde auf jeden Fall einen TERRAIN_MAX_VERTEX_LEVEL (TMVL) von 22 in der FS2002.CFG bzw. FS9.CFG benötigen damit dieses funktioniert. Fazit hier. Mein FS2002 kann es definitiv mit TMVL 22 oder höher nicht, da bin ich mir 100% sicher. Auch bei anderen Anwendern wird es nicht funktionieren. Von daher müsste mir jemand erst mal das Gegenteil beweisen, wenn er der Meinung ist der FS2002 konnte das. Ich weis auch nicht, woher die Information kommt, dass der FS2002 LOD12 Mesh Files mit jedem Höhenpunkt zumindest im Nahbereich auflösen kann. Keine Ahnung. Ich bin wie gesagt eindeutig der Meinung der FS2002 und FS2004 können definitiv kein LOD12 Mesh optisch mit jedem Höhenpunkt darstellen. Der FS2004 konnte vor dem offiziellen FS9.1 Patch noch nicht mal LOD11. Von daher bleibe ich natürlich auch bei meiner Meinung, dass wir eine extrem hohe Anzahl an überflüssigen Höhenpunkten in einem LOD12 Meshfile haben, die folglich nichts anderes als Datenmüll sind. Ist vielleicht etwas krass ausgedrückt. Sagen wir einfach es sind überflüssige Informationen mit denen der FS nichts sinnvolles anfangen kann. Mit anderen Worten der FS kann diese überflüssigen Höhenpunkte optisch nicht umsetzen. Das LOD12 Mesh funktioniert optisch nicht besser als ein LOD11 Mesh. Damit wäre aus meiner Sicht der Sinn oder ev. Werbung für ein LOD12 Supermesh welches besser als ev. andere Meshfiles die z.B nur LOD11 haben abgehakt. Auch damals zu FS2002 Zeiten hat man keinen Nutzen von LOD12 gehabt. Wer anderer Meinung ist.... bitte beweisen, ich lasse mich gerne überzeugen. Der FS2004 kann es eh nicht, da sind sich eigentlich alle einig. Schon allein mit einem LOD11 Mesh und den dann benötigten hohen TMVL=21 in der FS2002.CFG / FS9.CFG erhält man viele optische Nachteile im FS. Diese habe ich schon des öfteren aufgezählt und möchte sie auch nicht wiederholen. |
Jetzt kommt das entscheidende an Holgers Frage:
"Was mich aber besonders interessiert ist deine Aussage bzgl des Leistungseinbruchs beim Oversampling, also ein LOD12 Mesh, das als LOD11 oder LOD10 dargestellt wird. Hast du das mal quantifiziert mit deinem Testmesh?" Holgers Frage geht jetzt schon davon aus, dass der FS2004 LOD12 nicht nutzen kann. Er benutzt das Wort Oversampling, weil Daten vorliegen die eine sehr hohe Auflösung haben aber nicht nutzbar sind. Ich weise extra auf das Wort Oversampling hin, da es hier vom Sachverhalt in Bezug zu der Problematik des FS korrekt ist. Ich würde es hier aber persönlich nicht verwenden. Grund: Ich benutze es auch in meiner Doku, allerdings benutze ich es dort beim Verhältnis der Auflösung von real verfügbaren Geländerohdaten zu den produzierten FS Mesh Sceneryfiledaten. Ein fiktives Beispiel. Nehmen wir mal an man kann im Internet frei verfügbare Höhenmodelle bekommen. Diese haben eine Auflösung alle ca. 300m ein Höhenpunkt. Würde man jetzt hierraus ein LOD11 Mesh mit einer Auflösung von alle ca. 19m ein Höhenpunkt erzeugen, dann wäre das natürlich Schwachsinn. Der überwiegende Anteil der Höhenpunkte des FS LOD11 Mesh wären dann mit dem SDK Tool resample.exe erzeugte interpolierte künstliche Höhenpunkte die zwischen den realen Höhendaten alle 300m liegen. In diesem Fall spreche ich von Oversampled. Das zur Unterscheidung. Vom Prinzip ist es natürlich ein ähnlicher Sachverhalt, nur mein Oversampled bezieht sich auf die Meshproduktion und Holgers auf den reinen FS Betrieb. Für mich kommt Holgers Oversampled beim LOD12 Mesh im FS selbst natürlich nicht in Frage, weil ich davon ausgehe, dass niemand ein Mesh produziert was im Grundsatz schon durch einen FS als solches nicht darstellbar ist. Da bei FS Genesis 10m Rohdaten erwähnt wurden, dürfte man die produzierten FS Genesis LOD12 (9,6m) Meshfiles aus meiner Sichtweise noch nicht mal als oversampled bezeichnen, denn man liegt vom Raster dicht zusammen. Warum aber der Leistungseinbruch im FS wenn man ihn mit LOD 12 Meshdaten speist, die er aber optisch nicht verarbeiten kann. Nun mit LOD12 Meshdaten habe ich den Leistungseinbruch im FS noch nicht mal getestet. Sondern nur den Vergleich LOD 11 Daten zu LOD 10 Daten, LOD10 Daten zu LOD9 Daten usw.. Es ergibt sich immer der selbe Sachverhalt (auch wenn man z.B zusätzlich mit TMVL in einer Begrenzung arbeitet). Warum sollte es bei LOD 12 Daten anders sein, zumal mich der Test am Sonntag mit neuen Daten nochmals darin bestätigt hat, dass sich der Sachverhalt bei LOD12 unter TMVL=21 nicht anders verhält als bei LOD11 unter TMVL=20. Die Gründe warum das so ist, kann man genauer irgendwann in der Dok. lesen. Trotzdem ein kleiner Dokutextauszug der auch zu diesem Sachverhalt gehört. Dokuauszug ............insgesamt niedriger als bei einem LOD11 Mesh. Der Grund ist, dass unser eigentliches LOD9 Meshsceneryfile aus dem die Höhenpunkte ausgelesen werden bei vergleichbarem Gelände wesentlich weniger Daten als ein LOD11 Meshsceneryfile enthält. Dadurch belegt es bei vergleichbarem Höhenprofil weniger Speicher. Auf diese Äußerung vergleichbares Höhenprofil ist viel Wert zu legen. Vergleicht man zwei von der Fläche identische Meshfiles in LOD11 und LOD9 hinsichtlich dem Speicherplatz den sie belegen, dann definiert das LOD11 Mesh zwar extrem viel mehr Höhenpunkte als das LOD9 Mesh, dass bedeutet aber nicht automatisch, dass es dann auf der Festplatte mehr Speicherplatz benötigt. Hier hat das zur Datenreduktion angewendete Kompressionsverfahren bei der Mesh BGL Erzeugung entscheidenden Einfluss auf die Datengröße. So kann ein LOD11 Mesh in flachem Gelände sehr viel weniger Speicherplatz benötigen als ein flächenmäßig gleich großes LOD9 Mesh im Gebirge. Die wesentliche Performancebelastung des FS durch ein Mesh kann ins Verhältnis zur Speichergröße des Meshfiles pro Fläche und damit auch zum möglichen Kompressionsverhältnis gebracht werden. (natürlich nicht 1 zu 1, da andere Parameter dieses zusätzlich beeinflussen) |
Ein Beispiel:
Zwei LOD11 Meshfiles unter TMVL=21. Beide flächenmäßig gleich groß. Das eine in den Alpen, dass andere im flachen Norddeutschland. Beide arbeiten jetzt mit der selben Rasterweite beim Polygonmodell. Jeder Höhenpunkt alle ca. 19 Meter ist im Nahbereich theoretisch darstellbar. Die Grafikkarte hat also fast die selbe Polygonanzahl zu verarbeiten. (das tut sie auch) Trotzdem ist die Performancelast an der Küste erträglich, die Frames sind gut. Im Gebirge gehen sie wesentlich stärker zurück, der FS wird trotz nahezu identischer Polygonanzahl viel stärker belastet. Ich habe diese Tests im Zuge meiner Doku gemacht. Hier habe ich das flache Mesh mit einer extremen Variante, einem von mir erzeugten Kunstmesh verglichen wo sich die Höhe nahezu ständig ändert. Wir haben im Nahbereich definitiv ein identisch dichtes Polygonmodell. Beim flachen LOD11 Mesh lag meine Framerate im Mittel bei ca. 22 Frames. Bei dem LOD11 Mesh wo ständig Höhenänderungen stattfanden, lagen sie bei ca. 7 Frames. Wir sehen ein ganz extremer Unterschied trotz identischer Polygonanzahl und Fläche. Aufschluss bringt es, wenn man sich mal die zugehörigen Meshfiles anschaut. Bei identischer Flächendefinition und damit identischer Anzahl von umgesetzten Höhenpunkten belegt das flache LOD11 Mesh nur 2270Byte. Das Mesh mit sehr häufiger Höhenänderung belegt bei mir 34818Byte. Das Extremmesh belegt bei identischer Flächendefinition also 15,34 mal so viel Speicherplatz. Der Grund ist wie gesagt das Kompressionsverfahren, welches die Microsoft SDK Tools bei der Mesherstellung nutzen. Habe ich z.B ein LOD11 Meshfile, welches 257 x 257 Höhenpunkte also 66049 Höhenpunkte auf einer festen Höhe definiert, dann wäre es unsinnig jeden der Höhenpunkte mittels 16Bit also 2 Bytes im Meshfile umzusetzen. Ich habe leider noch keine Möglichkeit gefunden einen eindeutigen Beweis zu liefern, aber es würde mich nicht wundern wenn die Terrainengine in der Lage ist direkt ohne Dekompression der Meshfiles Ihr 3D Gelände aufzubauen. Die sehr unterschiedliche Performance bei den obigen LOD11 Meshfiles spricht eigentlich dafür. (nur wie gesagt ein eindeutiger Beweis ist das leider nicht) An diesem Kompressionsverfahren kommt kein Designtool herum. Bis auf eine Ausnahme sind nämlich alle Tools für Meshdesign nur vorbereitende Tools die einem etwas Arbeit speziell bei der Vordefinition abnehmen. Der eigentliche Programmierprozess läuft mit dem SDK Tool resample.exe ab. (bei älteren Versionen werden weitere SDK Tools benötigt) Dokuauszug Ende Das passt natürlich zu meiner hier im Forum gemachten Aussage. Haben wir also ein LOD12 Addon Mesh welches extrem viele Details im Gelände darstellt (nur da würde es einen Sinn ergeben), dann enthält es trotz Kompression sehr viel mehr Bytes an Information als ein LOD11 Mesh der selben Gegend. Der FS muss natürlich alle Byte Informationen eines Meshfile verarbeiten. Das allein kostet Performance wie man oben sehen kann. Nicht der LOD Level ist hier so entscheident sondern die Bytes die ein File pro Fläche mitbringt. Von daher belastet ein LOD 12 Mesh welches einen Sinn ergeben soll, zwangsweise den FS höher als ein LOD11 Mesh der selben Gegend. Es sei denn beide spielen sich in flachen oder relativ unspektakulären Gelände ab. Nur da wäre die Verwendung eines LOD 12 Mesh nur wegen dem Gelände Unsinn. Von daher würde ich die Aussage ob LOD12 oder LOD11 ist doch egal bei den heutigen riesigen Festplatten so nicht stehen lassen. Es geht hier auch um die Performance des FS2004. Ich glaube bei diesem Thema dürfte es den meisten Anwendern nicht egal sein ob LOD12 oder LOD11. Es gibt wie gesagt eh viele Nachteile durch einen hohen TMVL den wir z.B zusätzlich bei einem LOD11 Mesh in der FS9.CFG einstellen müssen um es als solches sehen zu können. Ich könnte da auf diverse Beiträge von mir verweisen. Einen Nachteil habe ich bisher selten genannt. Ev. zwei bis drei mal hier im Forum in Bezug zu LOD11. Aber ich kann mich gut daran erinnern, dass ich dieses früher zu FS2002 Zeiten schon mal gemacht habe. z.B habe ich solche Aussagen gemacht: Der FS verschiesst sein 3D Pulver bei hohem LOD Level im Vordergrund..... oder...... Vorne hui, hinten pfui. Aber siehe dazu irgendwann Doku. Das Polygonmodell selbst arbeitet nämlich auch dynamisch. Das jetzt zu erklären würde allerdings den Rahmen sprengen. Zu "Jobia: sehr interresant! Wenn also die Terrain Engine auch bei einer per TMVL erzwungenen Aufloesungs"bremse" interpoliert," Zu diesem Thema hatte ich ja bereits erwähnt, dass es sich um eine Vermutung handelte bei dieser Interpolation durch TMVL Begrenzung. Grund war eines meiner neu erstellten Testfiles im Zuge der LOD12 Diskussion letzte Woche. Dieses hatte mir einen Sachverhalt vorgekaukelt, der mich zunächst zweifeln lassen hat, ob das Verfahren der Auflösungsreduzierung welches ich in meiner Dok. beschreibe korrekt ist. Es hat sich aber glücklicherweise rausgestellt, dass der FS eine Konstellation in dieser Form wie ich es im Testfile hatte nicht umsetzen kann. Den Sachverhalt den ich letztes Jahr im Sommer ermittelt hatte ist korrekt und bleibt weiterhin gültig. Es geht hier wie gesagt um die Begrenzung durch TMVL bzw. um die Auflösungsreduzierung eines Mesh innerhalb seiner Verarbeitungsreichweite. Dort gibt es zwar auch noch eine Interpolation die tritt aber nicht überall in Erscheinung. Die möchte ich hier zunächst auch nicht erwähnen. Siehe Vorne hui, hinten pfui. |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 19:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag