Transparente Texturen löschen an den transparenten Stellen andere Meshes aus
-
Achso, Moment Fehlalarm. Die Baumkronen eliminieren sich natürlich immer noch gegenseitig. Also doch wieder von Hand sortieren und Z-Buffer aus. Kann man den nicht nur den Z-Test ausschalten und die Sortierung behalten?
-
durito schrieb:
Optimizer, mach sonst doch mal ein Screenshot mit:
-Staemme rendern
-Z-Writing disablen
-Blaetter rendern (nicht sortiert)Das ist eben die Loesung mit dem Fehler, dass hintere Blaetter vor den vorderen liegen koennten, aber evt. siehts ja doch nicht so schlimm aus. Wenn es nicht allzusehr stoert, dann koenntest Du Dir die Muehe mit dem sortieren sparen...
Das stört, Screenshot gab's dazu auf Seite 2 schon. Wenn dann muss ich es auf jeden Fall sortieren.
-
Optimizer schrieb:
Achso, Moment Fehlalarm. Die Baumkronen eliminieren sich natürlich immer noch gegenseitig. Also doch wieder von Hand sortieren und Z-Buffer aus. Kann man den nicht nur den Z-Test ausschalten und die Sortierung behalten?
ja genau
Geht auch ned, dann entsteht wieder dieser "wegschneide"-Effekt zwischen den transparenten Elementen, wenn das vordere zeitlich vor dem hinteren gerendert wird.
Eben, probier mal das Z-Writing auszuschalten beim Blaetter rendern.. Evt. schauts ein wenig besser aus...
-
Optimizer schrieb:
durito schrieb:
Optimizer, mach sonst doch mal ein Screenshot mit:
-Staemme rendern
-Z-Writing disablen
-Blaetter rendern (nicht sortiert)Das ist eben die Loesung mit dem Fehler, dass hintere Blaetter vor den vorderen liegen koennten, aber evt. siehts ja doch nicht so schlimm aus. Wenn es nicht allzusehr stoert, dann koenntest Du Dir die Muehe mit dem sortieren sparen...
Das stört, Screenshot gab's dazu auf Seite 2 schon. Wenn dann muss ich es auf jeden Fall sortieren.
Ne, auf dem screenshot wurden die Blaetter nicht erst nach den Staemmen gerendert.
-
Ich muss jetzt erstmal ne Pause machen.
Danach wird's wohl länger dauern, wenn ich erstmal von Hand sortieren einbauen muss... falls das denn nötig ist. Kann man nicht nur das eliminieren ausschalten, dann hätte ich die Sortierung schon? Dann würde ich nur für die transparenten das Eliminieren ausschalten und der Rest wäre dadurch nicht langsamer. Ich könnte mir amsonsten vorstellen, dass diese Methode jetzt was bringen wird. Hoffentlich ist sie nicht komplett ineffizient...
-
Faul wie ich bin, habe ich das jetzt natürlich nicht gecodet.
Stattdessen bin ich auf was interessantes gestoßen: Man kann über das AlphaTestEnable-Renderstate verhindern, dass transparente Pixel auf den Z-Buffer geschrieben werden. Damit kann man sich letztlich die ganze Sortierung von Hand sparen.Meine persönliche Theorie ist, dass dieses Ding Laufzeit kostet und es am besten ist, trotzdem erstmal alle nicht-transparenten Objekte ohne dieses State zu rendern. Der Screenshot hier macht das gerade so, alles einfach auf blöd zu rendern werde ich auch noch ausprobieren. Außerdem scheint das auch noch nicht perfekt mit halbtransparenten Texturen zu funktionieren (man sieht den Rand der Blätter, bei dem so ein Alpha-Übergang von 0 nach 1 ist). Aber für scharfe Unterschiede zwischen "transparent" und "nicht transparent" ist das anscheinend schon mal brauchbar.
Ich bin also noch ziemlich am experimentieren, wollte mich aber schon mal für die nette 4-Seiten-Diskussion bedanken und hoffe, dass euch diese Information auch noch interessiert hat. Ich jedenfalls habe heute viel gelernt.
-
Das mit dem AlphaTestEnable ist schon interessant, habe mit Transparentz noch keine Probleme gehabt weil kaum genutzt, aber das kann ja noch kommen. Gleich mal irgendwo notieren...
Ganz einfach ist das Problem auf jeden Fall nicht. Ich bin schon in Farcry vor einem Zaun gestanden und die Sträucher HINTER dem Zaun haben den Zaun irgendwie überdeckt. Am nervigsten ist das aber wohl für die Programmierer, denn die meisten Leute interessiert sowas nicht sonderlich
-
Ohh wehh, so viel Gequatsche zu diesem simplen Thema. Wie schon gesagt, Alpha Zeug selbst sortieren und am Ende von hinten nach vorn zeichen. Hat den Nachteil, das selbst auf Polygonebene manchmal keine eindeutige Sortierung möglich ist. Oder eben Alphatest. Das hat wiederum den Nachteil, das es für einen Pixel nur an und aus kennt, d.h. Fehler bei Halbtransparenz und pixelige Ränder.
Bye, TGGC
-
Gibt's auch eine logische Erklärung dafür, dass das eigene Mesh nicht ausgelöscht wird? Wird Mesh-weise von hinten nach vorne gerendert oder was geht da ab?
-
Das eigene Mesh wird gelöscht.
Bye, TGGC
-
Meinst du, es wird auch ausgelöscht? Dem ist aber anscheinend nicht so, wenn du dir mal den ersten Screenshot ansiehst. Der Baumstamm oder die Äste vom eigenen Baum werden dort nicht eliminiert.
-
Gelöscht ist das falsche Wort. Es wird ja nur verhindert, das etwas neues gezeichnet wird, wenn etwas da ist, bleibt es auch da.
Also: Alle später gezeichneten Polys des eigenen Mesches werden verdeckt.
Bye, TGGC
-
Wie erklärst du dir dann den ersten Screenshot? Man sieht ja deutlich, dass der Baumstamm durch die transparente Textur hindurch sichtbar ist.
-
Optimizer schrieb:
Faul wie ich bin, habe ich das jetzt natürlich nicht gecodet.
Stattdessen bin ich auf was interessantes gestoßen: Man kann über das AlphaTestEnable-Renderstate verhindern, dass transparente Pixel auf den Z-Buffer geschrieben werden. Damit kann man sich letztlich die ganze Sortierung von Hand sparen.Meine persönliche Theorie ist, dass dieses Ding Laufzeit kostet und es am besten ist, trotzdem erstmal alle nicht-transparenten Objekte ohne dieses State zu rendern. Der Screenshot hier macht das gerade so, alles einfach auf blöd zu rendern werde ich auch noch ausprobieren. Außerdem scheint das auch noch nicht perfekt mit halbtransparenten Texturen zu funktionieren (man sieht den Rand der Blätter, bei dem so ein Alpha-Übergang von 0 nach 1 ist). Aber für scharfe Unterschiede zwischen "transparent" und "nicht transparent" ist das anscheinend schon mal brauchbar.
Ich bin also noch ziemlich am experimentieren, wollte mich aber schon mal für die nette 4-Seiten-Diskussion bedanken und hoffe, dass euch diese Information auch noch interessiert hat. Ich jedenfalls habe heute viel gelernt.
Huh, tönt ja interessant. Muss mal suchen, obs sowas bei OpenGL auch gibt..
-
Er wurde vorher gezeichet. Machs doch mal andersrum.
Bye, TGGC
-
durito schrieb:
Huh, tönt ja interessant. Muss mal suchen, obs sowas bei OpenGL auch gibt..
Ja, gibt es.
TGGC schrieb:
Er wurde vorher gezeichet. Machs doch mal andersrum.
Ähm stimmt. *an den Kopf schlag*
-
Demzufolge wäre es effizienter, zuerst Objekte zu rendern, die näher an der Kamera sind, oder?
-
Effizienter wofür?
Bye, TGGC
-
Angenommen, ich render als allererstes 'ne fette Wand direkt vor der Kamera. Dann werden die dahinter liegenden Objekte doch gar nicht erst gezeichnet, oder? Es wird halt noch geprüft, ob sie zu zeichnen sind, aber ich stelle mir das als weniger Arbeit vor, als sie auch noch darzustellen.
Wenn ich dagegen die Wand als letztes rendere, habe ich die ganze Arbeit unnötigerweise schon gemacht. Kann sein, dass ich da ne falsche Vorstellung habe.Lohnt es sich da, zu sortieren?
-
Optimizer schrieb:
Lohnt es sich da, zu sortieren?
Absolut, moderne Grakas speichern zusätzlich zum z-buffer noch eine art suchbaum der den inhalt des buffers beschreibt. Damit können sehr große Flächen dann sofort weggelassen werden (wenn zB eine große Wand direkt vor einem ist)
In irgendeinam ATI Paper hab ich mal gelesen dass man die Technik gut unterstützen kann indem man die Nearplane möglichst weit weg setzt und die Farplane möglichst nahe.
ah da ist ja zufällig ein link:
www.ati.com/developer/dx9/ATI-DX9_Optimization.pdf
