![]() |
Hi!
Nun wird es interessant. Holgers und Thorstens aüßerungen liegen dicht beieinander. Somit könnte je nach Programmierungsart der "blurry texture salad" entweder sehr heftig oder eben fast gar nich auftreten. Ich werde mal ein paar Kandidaten darauf testen. Bei Simwings Scenerien kann ich aber zumindest bei mir jetzt schon verschwommene Texturen auschliessen:) :) |
Zunächst mal bin ich heute morgen fröhlich ca. 20 Minuten in Umfeld von EDDL durch die Gegend geflogen auch an den Koordinaten die man in dem Screenshot sehen konnte. Bei mir tat sich rein gar nichts.
Was diesen guten Tipp von Holger und Thorsten bezüglich DXT1 Texturformat ohne MIP Level betrifft. Da fällt mir dieser Thread ein wo ich damals den CTD bei der Hamburg Scenery von Dirk auch auf das fehlen von MIP Leveln bei einer Addon Railroad Tauschtextur im DXT1 Format zurückführen konnte. Siehe Hamburg Scenery CTD bei 53% Euer Tipp bezüglich fehlender MIP Level ist sehr gut. Ich habe nämlich ein anderweitiges Problem bei EDDL gehabt. Im Zuge einer Geschichte für die Dok hatte ich mich gewundert, warum es bei zwei verschiedenen statischen GAP Fliegern so ein unterschiedliches Verhalten bei trilinearen Filtern gab obwohl beide Texturen im DXT1 Format hatten. Ich meine es waren ATRs. Dummerweise habe ich aber damals nur mit T-View geschaut. Dort kann man aber nicht erkennen ob MIP Level fehlen. Habe eben mal nachgeschaut. Bei GAP3 gibt es leider bei den ATR Texturen einen Tagesset und zwei Nachtsets ohne MIP Level. Prinzipiell müsste man natürlich alle Texturen mal checken. Was aber trotzdem etwas kurios bleibt, dass ich im Gegensatz zu manch anderen trotz dieser Texturen nicht mit plötzlich unscharfen Texturen zu kämpfen hatte. Das hat es bei mir noch nie gegeben. Es könnte daher ev. nur in Zusammenhang mit bestimmten Grakatreibern /Hardware oder einfacher ev. mit einer bestimmten Einstellung im FS Anzeigemenü zusammenhängen. Nur wenn alles aufeinander trifft kommt es ev. zu dem Problem. Ich vermute mal Ihr werdet mit Eurem Tipp den Nagel auf den Kopf getroffen haben. Den betroffenen Anwendern die definitiv nachweislich unter dem Problem im Raum Düsseldorf leiden kann man zunächst mal ein fach empfehlen die Texturordner der GAP3 Vol 2004 einfach mal von texture nach z.B textureX umzubenennen. In den meisten Fällen läuft der FS auch ohne Texturen. Ich habe es hier bei den GAP aber noch nicht ausprobiert. Funktioniert es und das Problem ist weg, dann werden es zu 99% wohl fehlende MIP Level sein. Dann sollte man wegen der Lizenzen der Texturen das GAP Team ansprechen damit sie Ihre betroffenen Texturen ändern können. Aber warten wir mal die Ergebnisse ab. |
Zu
"Auf etwas bin ich aber gestern draufgekommen. Je näher man an das Flugzeug zoomt, desto unschärfer werden die Texturen am Boden. Das geht so weit, dass man nur mehr einen Brei unter sich hat. Zoom ich wieder weg, dann wird die Darstellung der Umgebung wieder langsam besser." Das könnte ev. je nach Sichtperspektive ein normaler Effekt sein. Ev. ist aus der Fotografie das Verhalten von unterschiedlichen Brennweiten bei Objektiven bekannt. Vereinfacht gesagt: Hat man ein Teleobjektiv bzw. ein Zoomobjektiv undzoomt sich nah ran, dann rücken Vorder und Hintergrund optisch zusammen. Es wirkt als wäre beides dicht beeinander. Ähnlich verhält sich das beim FS mit dem Zoomen. Besonders fällt dieses auf wenn man dabei z.B nicht von oben auf ein Flugzeug schaut sondern halbwegs waagerecht. Nehmen wir mal an Du hast im Vordergrund ein Flugzeug ganz weit hinten am Horizont eine Bergkette. Jetzt zoomst Du Dich nah an das Flugzeug heran. Das wirkt jetzt so als wenn die Bergkette ganz dicht beim Flugzeug ist. So weit so gut. Der FS verhält sich hier wie ein Tele/Zoomobjektiv. Das Problem dabei ist, dass der FS am entfernten Horizont nur minderwertige MIP Level der Landclassbodentexturen verwendet. Diese haben z.B anstatt 256 x 256 Pixel nur noch 32 x 32 Pixel. Sie sind also ganz grob. Durch das ranzoomen holst Du jetzt diese monströsen groben Pixel nah an das Flugzeug heran. Das wirkt unscharf. Erschwerend kommt hinzu das ein spezielles Rauschfilterungsverfahren bei Landclasstexturen in der Tiefe des Raumes nicht zur Anwendung kommt. Daher sind die monströsen Einzelpixel noch besser erkennbar. Kann sein das Du etwas anderes schlimmeres meinst. Aber dieses von mir geschilderte Phänomen gibt es beim ranzoomen. Das wäre dann normal. Es könnte theoretisch sein, dass Du dieses meinst. Ev. poste ich morgen ein Bild wenn ich dran denke. |
Habe eben noch mal eine Stunde im Umfeld EDDL getestet. Meinen PC scheinen diese DXT1 Texturen ohne MIP Level nicht zu stören. Die Texturen bleiben immer scharf.
Ich kann diesen Effekt nicht produzieren. Daher wäre es interessant ob die Anwender die der Meinung sind sie haben definitiv das Problem bei EDDL einfach mal testen ob dieses den ganzen Tag über auftritt. Nicht das es sich hier ev. um ein Problem handelt was Tageszeiten, Jahreszeiten bzw. schlimmer noch ev. AI Traffic bedingt nur zu einer ganz bestimmten Uhrzeit auftritt. Denn ausschliessen kann man so etwas bekanntlich nicht. Weiterhin hatte jemand in dem anderen früheren Thread die Meinung Kund getan, er hätte von einem Addonteam eine Aussage bezüglich eines ähnlichen Phänomens gehört. Bei denen konnte das Problem nicht nachvollzogen werden. Das Addonteam verfügte nur über ATI Grafikkarten (ich auch). Man konnte das Problem wohl grob auf NVIDIA Karten begrenzen. Von daher ein Bitte an die Betroffenen. Können auch ATI Grafikkartenbesitzer von diesem Problem berichten? Sollten trotzdem Anwender über dieses Problem klagen, so wäre (falls es wirklich von Texturen kommen sollte) die Möglichkeit gegeben die texturordner von GAP zu deaktivieren. Ich habe es bei mir getestet es kommt nicht zum Absturz. Für testzwecke also ungefährlich. Aber zumindest eine Hilfe zum Fehlereingrenzen. Man wird später halt nur feststellen, dass bis auf ganz wenige Ausnahmen die Texturen fehlen. Man sieht die Fallbackfarbe der Polygone in der Regel weiss oder grau. Fruchtet auch das nicht aktiviert man die Texturordner wieder. Wie wäre vorzugehen. Vor FS Start einfach in diesen Pfad gehen: C:\Programme\Microsoft Games\Flight Simulator 9\aerosoft\GA3_FS2004\ den dortigen texture Ordner nach textureX umbenennen. Dann in diesen Pfad gehen: C:\Programme\Microsoft Games\Flight Simulator 9\aerosoft\GAP_gmax_lib\ den dortigen texture Ordner nach textureX umbenennen. Der Pfad C:\Programme\Microsoft Games\Flight Simulator 9 hängt natürlich davon ab wo Ihr euren FS installiert habt. Der Rest z.B \aerosoft\GA3_FS2004\ sollte aber passen. Es ist der Standardinstallatiospfad. Noch etwas fällt mir ein. Ich glaube zwar nicht, dass es einen Zusammenhang gibt. Aber man weis ja nie. Bei der GAP3 Vol2004 werden ungefragt Rainers Flüsse mit installiert. Ich habe dieses manuell rückgängig gemacht. Diese wurden in den Addon Scenery Pfad des FS kopiert und müssen daher nicht im FS als eigene Scenery angemeldet werden. Sie sind qausi heimlich aktiv. Sollte alles nicht fruchten bitte einfach mal im FS Menü der Scenerybibliothek den Eintrag "Add-ON-Szenerien" abmelden. Ich glaube zwar nicht das es einen Zusammenhang gibt aber es wäre theoretisch eine Möglichkeit vorhanden. da ich das platt gemacht habe, weiss ich nicht mehr was da alles drin war. |
Was Gert betrifft. Auf die Schnelle ist mir das mit den Bildern nicht optimal gelungen.
Aber mal zwei Beispiele die ganz grob das Phänomen zeigen welches wie gesagt direkt mit Zoomfaktoren bei Tele bzw. Zoomobejktiven vergleichbar ist. Bild 1 zeigt die Cessna und umliegene Scenery. Ich bin nah dran an der Cessna die umliegende Scenery ist weit weg daher feinkörnig also scharf. Damit es besser erkennbar ist habe ich Texturfilterungen deaktiviert. |
Beim nächsten Bild war ich eigentlich weit weg von der Cessna. Durch einen hohen Zoomfaktor habe ich mich aber nah an die Cessna rangezoomt.
Sie ist optisch fast identisch groß. Trotzdem ist durch den hohen Zoomfaktor fast jedes Einzelpixel der Bodentexturen als eckige Fläche erkennbar. Ein ganz normales Phänomen wie wir es von jedem Fotoapparat bei Tele/Zoomobjektiven kennen. Das gilt auch für die Towersicht. Kann sein, dass Du etwas anders meinst. Ich wollte nur sicherstellen das es keine Fehlinterpretation ist. |
@JOBIA
HI, ich wollte noch mal was klarstellen, weil ich denke es geht etwas "durcheinander" :-)), da sich Holger Aussage und meine eigentlich widersprechen: Meiner Erkenntnis nach tritt der Fehler nur dann NICHT auf, wenn man DIE MIPMAPS UNTERDRÜCKT, also ein DXT1 Format verwendet, was einen opaken Alphakanal!!! (also alles "weiss") hat (Oder nat. eine DXT1 mit einem Alphakanla für Transparenzen) Hierdurch wird die Textur OHNE jegliche Generierung von MipMaps (sei es durch vorhandene Level im Texturfile, oder durch Eigengenerierung des FS)im FS dargestellt. Ein nachträgliches hinzufügen von MipMap leveln zu einzelnen Texturen wäre der falsche Weg (Da der FS sie ohnehin selber macht) Ich habe übrigens eine (zwei) ATI Karten. In EDDL habe ich kein Problem, aber beim Entwickeln der eigenen Szenerien sind wir auf dieses Phänomen gestoßen und konnten es wie beschrieben lösen. Wenn ca. 1 bis 2 MB der Texturen einer unserer Szenerien doch MipMaps erlauben (z.B. bei sehr kontrastreichen Texturen unumgänglich) macht es nichts, aber ab einem gewissen Punkt wird eine "imaginäre" Grenze überschritten und "patsch, alles ist blurry". Die EDDL texturen sind meines wissens hauptsächlich 8bit bmp´s. Ich habs noch nicht ausprobiert, ob sich dieses Format auch auswirkt (da ja auch hier intern im FS MipMaps generiert werden), da wir hauptsächlich DXT1 und DXT3 verwenden. Besonders anfällig für plötzliches "blurrying" scheint übrigens die Gmax Kombination von "Tile mapping" und MipMaps zu sein. (Also eine Textur, die sich auf z.B. einer Wand mehrfach wiederholt). Ein andere Designer gab mir mal den Hinweis, dass es auch daran liegen könnte, dass man in Gmax eine Textur (bzw. ein Material) mehrfach für verschiedene Objekte verwendet. Hierdurch würde aber die gleiche Textur mit verschiedenen Scale Faktoren im FS aufgerufen, was ihn durcheinanader bringen würde. Ich halte diese Aussage aber für unwahrscheinlich, da es das ganze texturing Konzept von Gmax in Frage stellen würde. (Also nur als kleiner "Denkansatz") Thorsten |
Trennen wir mal auf.
Laut Holgers Aussage "Als einfaches bmp gespeichert machte die Textur keine Probleme, aber als DXT1 (ohne Mipmaps!) gabs die schlagartige weltweite Unschaerfe." wäre dieser Sachverhalt DXT1 ohne Mips eine Möglichkeit den Fehler zu verursachen. Es fehlen offensichtlich interne Mips im Texturfile. Ok Holgers Kollege hat dann einen ganz anderes Format (DXT3) gewählt, was natürlich die Frage zunächst offen lässt, ob eine Generation von MIP Leveln bei DXT1 innerhalb der Texturdatei das Problem beheben würde. Anhand Deiner Interpretation wäre eher das Gegenteil bei DXT1 zu erwarten. Es würde eher gefährlich mit eigenen in der Textur integrierten MIP Leveln. Wie gesagt unabhängig davon, dass es damals nicht um unscharfe Texturen sondern um einen CTD ging wissen wir auf jeden Fall, dass es bei VTP Techniken bei DXT1 Texturen ohne eigene MIP Level auch Probleme geben kann. Das mit den MIP Level selber generieren ist mir übrigends auch schon bei Landclass aufgefallen. Hier geht das sogar soweit, dass dort wo bereits reguläre in einer DXT1 vorhandene MIP Level genutzt werden diese je nach Einstellungen des FS noch mal intern generiert werden. Ist aber ein andere Geschichte. Thorsten Wenn ich Dich richtig verstehe, ist es besonders wichtig, dass man nur Texturformate nutzt, die zunächst keine integrierten MIP Level besitzen, weiterhin aber auch nicht die Generation von MIP Leveln durch den FS intern erlauben. Ausnahme ev. (DXT3) denn Holger schrieb: "Also hat er sie dann in eine DXT3 mit 6 Mipmaps umgewandelt und die Probleme waren weg." Auch schrieb er "Als einfaches bmp gespeichert machte die Textur keine Probleme" Ist nur die Frage, was für ein einfaches bmp Format bei Holgers Kollegen keine Probleme machte. Denn 8Bit käme Deiner Aussage nach auch nicht in Frage, da es wiederrum die interne Generation von MIP Leveln zulässt. Bei Dir bezieht sich die Aussage definitiv nur auf Objekttechnik die mit GMAX erstellt wurde. Habe ich das richtig verstanden? Bei Holgers Kollegen wissen wir nicht über welche Technik er die Textur zugewiesen hat. Eigentlich sehr kurios das Ganze. Mal möchte der FS die Textur so haben, dann wieder so. Haben wir funktionierende Techniken wie Landclass, dann nutzt er z.B (wenn alle Regler rechts sind) die in einer Textur integrierten MIP Level und generiert keine eigenen. Auf jeden Fall denke ich das es mit diesen ATR Texturen dann bei GAP vermutlich Kandidaten geben dürfte. Denn wie gesagt drei DXT1 Texturen haben keine MIP Level. Das wäre aufgrund Deiner Aussage zunächst gut (aber nur insofern die Generation von Mip Leveln durch den FS unterdrückt werden) Das würde dann einen Alphakanal voraussetzen der alles weis definiert. Nur die drei Texturen besitzen keinerlei Aplphakanal. Damit wären es laut Deiner Aussagen potentielle Kandidaten. Auf jeden Fall werden MIP Level generiert, dass habe ich heute morgen selbst mit eigenen Augen gesehen. Trotzdem habe ich bei meinem FS keine unscharfen Texturen. Laut Holgers Aussage wiederrum dürfte vermutlich gerade das fehlen der MIP Level Probleme verursachen. Dann wären die drei Kandidaten auch nach Holgers Aussage vermutlich fehlerverursachend obwohl die Aussagen gegensätzlich sind. Dann bleibt noch die vierte ATR Textur übrig diese DXT1 Textur hat reguläre MIP Level integriert (keinen Alphakanal) Das wäre laut Holgers Aussage dann eine Textur bei der man davon ausgehen könnte das sie keine Probleme verursacht. Laut Deinen Aussagen müsste diese Textur gerade weil sie MIP Level hat ein Problemverursacher sein. Es sei denn ích habe noch etwas nach genauen lesen falsch verstanden. Alles sehr kurios und gegensätzlich. Noch kurioser weil bei mir der ganze Fehler und vermutlich auch bei vielen anderen dieses nicht auftritt. Da fällt es einem mittlerweile sehr schwierig was man überhaupt für Texturformate wählen soll. Selbst einige Leute die es vorher mal hatten, wie z.B Schubi können es jetzt nicht mehr reproduzieren. Ob da ev. doch noch etwas anderes eine Rolle spielt. Tritt das Problem ev. nur in Zusammmenhang mit anderen Geschichten auf und gaukelt uns dann etwas vor. Ich weis es nicht. Wenn man wenigstens das Problem selbst nachvollziehen könnte. |
Hallo,
um die ganze Sache noch weiter zu verwirren :) Also ich habe eine ATI 9700PRO in Betrieb und mit der lässt sich ähnliches beobachten. Im übrigen auch im Düsseldorfer Raum. Hier scheint es also tatsächlich an den GAP 3 zu liegen. Eine weitere Beobachtung ist, dass sich es bei mir schrittweise einstellt. So als ob erst einige und dann immer mehr Texturen "verwaschen" werden. Im letzten Atemzug erscheint dann nichtmal mehr die Schrift "Brakes" sondern nur noch der rote Balken ohne Inhalt. Zum Thema Landklassen und Speicher. Ich habe mir erst vor kurzem die Scenery Germany 1 installiert. Wenn ich dort drüber fliege gehen nach ca. 20 - 30 Minuten die frames in den unfliegbaren Keller. Da dieses Phänomen erst nach der Installation aufgetreten ist, scheint es dort wohl tatsächlich einen Zusammenhang zwischen Landclass und einer Art Speicherproblem zu geben. Gruß Thomas |
@Jobia
Möglicherweise liegt es tatsächlich nur am DXT1 Format und mit 32/8 bit bmp und DXT3 ist alles OK (No matter ob mit oder ohne mipmaps) Um das rauszukriegen müsste ich alle texturen von Marseille oder CDG mal von DXT1 in DXT3 oder bmp ohne alpha konvertieren und schauen wie es sich verhält. Aber das werd ich vorläufig nicht schaffen. Übrigens scheint auch die Anzahl von sichtbaren Wolken eine Rolle zu spielen, indem diese "imaginäre switch to blurry" Grenze etwas heruntergeschraubt wird und es bei vielen sichtbaren Wolken noch eher passiert als bei klarem Himmel. Meine Aussagen beziehen sich tatsächlich nur auf Gmax erstellte Objekte und scenery texturen. bei Landclass texturen ist es ja wieder ein anderes Theam. Da MUSS es ja DXT1 mit generierten MIPMaps sein, sonst: CTD. @Tom82 Mach doch mal den von Jobia vorgeschlagenen Test und nenne das GAP texturen Verzeichnis doch einfach mal um in texturesx und schaue ob der Fehler wieder auftritt. Wenn nicht, liegt es definitiv an einer textur. |
Alle Zeitangaben in WEZ +2. Es ist jetzt 10:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag