Transparente Texturen löschen an den transparenten Stellen andere Meshes aus
-
YASC schrieb:
durito schrieb:
IMHO muessen die transparenten Teile zum Schluss gerendert werden und zwar nach Tiefe sortiert. Kann mir irgendwie nicht vorstellen, dass es anders funktionieren sollte, lasse mir aber gerne erklaeren wie's einfacher geht
Ja stimmt, dann die als letztes und ZENABLE auf false, vielleicht gehts ja dann.
Probieren macht Spass
Dann koennen aber immernoch hintere Blaetter ueber vorderen zu liegen kommen.
-
durito schrieb:
YASC schrieb:
durito schrieb:
IMHO muessen die transparenten Teile zum Schluss gerendert werden und zwar nach Tiefe sortiert. Kann mir irgendwie nicht vorstellen, dass es anders funktionieren sollte, lasse mir aber gerne erklaeren wie's einfacher geht
Ja stimmt, dann die als letztes und ZENABLE auf false, vielleicht gehts ja dann.
Probieren macht Spass
Dann koennen aber immernoch hintere Blaetter ueber vorderen zu liegen kommen.
Deswegen ja nach der Tiefe sortiert, die tiefsten zuerst
-
Also ich verstehe schon, was du meinst. Ich dachte, D3D sortiert nach Tiefe und rendert dann einfach die vorderen über die hinteren rüber. So gibt das natürlich Sinn.
Wenn man am Ende die teilweisen transparenten Elemente dazurendert, werden die dann noch korrekt von davor liegenenden Objekten verdeckt, d.h. werden nur die wirklich sichtbaren Teile dazugemalt? Wenn nicht -> böse.
Kann man den Z-Test nicht auch einfach deaktivieren? Ist natürlich performance-mäßig nicht unbedingt eine gute Überlegung, aber wenn ich einen fetten Wald abbilde, habe ich mit der manuellen Methode doch wahrscheinlich insgesamt noch mehr Aufwand, als wenn ich einfach alles rendere? Zumindest für Testzwecke würde ich das gerne probieren, habe aber kein entsprechendes RenderState gefunden.
-
ZENABLE auf false, schon is der Z-Buffer aus
-
@YASC: Ok, anscheinend war das so auch deine Überlegung, sorry hab ich nicht gleich kapiert.
YASC schrieb:
ZENABLE auf false, schon is der Z-Buffer aus
Ähm klar, aber die Sortierung auch.
-
YASC schrieb:
durito schrieb:
YASC schrieb:
durito schrieb:
IMHO muessen die transparenten Teile zum Schluss gerendert werden und zwar nach Tiefe sortiert. Kann mir irgendwie nicht vorstellen, dass es anders funktionieren sollte, lasse mir aber gerne erklaeren wie's einfacher geht
Ja stimmt, dann die als letztes und ZENABLE auf false, vielleicht gehts ja dann.
Probieren macht Spass
Dann koennen aber immernoch hintere Blaetter ueber vorderen zu liegen kommen.
Deswegen ja nach der Tiefe sortiert, die tiefsten zuerst
Ok ja, so stell ich mir das auch vor, aber eben, ziemlich aufwaendig..
Und den ZENABLE brauchst Du dann auch nicht mehr zu deaktivieren
-
Ich sehe noch ein Problem. Ich habe ja für die Baumkronen so ein Mesh-Subset, wenn ich die einfach von Hand sortiere ohne Z-Buffer dann kann es wieder zu Grafikfehler kommen, wenn sie sich in einzelnen Polygonen überlappen. Kann ja sein, dass ein vorderer Zweig von einem hinteren Subset vor dem hinteren Zweig eines vorderen Subset gehört. Soll ich Polygonweise sortieren? Langsam wird's krass.
-
Probier mal nur aus Interesse:
Die transparenten zuletzt und das mit ZWRITEENABLE
würd mich mal interessieren was dann rauskommt
-
Optimizer schrieb:
Also ich verstehe schon, was du meinst. Ich dachte, D3D sortiert nach Tiefe und rendert dann einfach die vorderen über die hinteren rüber. So gibt das natürlich Sinn.
Wenn man am Ende die teilweisen transparenten Elemente dazurendert, werden die dann noch korrekt von davor liegenenden Objekten verdeckt, d.h. werden nur die wirklich sichtbaren Teile dazugemalt? Wenn nicht -> böse.Jau. (natuerlich nur falls Z-Buffer aktiviert ist)
Kann man den Z-Test nicht auch einfach deaktivieren? Ist natürlich performance-mäßig nicht unbedingt eine gute Überlegung, aber wenn ich einen fetten Wald abbilde, habe ich mit der manuellen Methode doch wahrscheinlich insgesamt noch mehr Aufwand, als wenn ich einfach alles rendere? Zumindest für Testzwecke würde ich das gerne probieren, habe aber kein entsprechendes RenderState gefunden.
Warum den Z-Buffer deaktivieren? Das "wegschneiden" faellt dann zwar weg, aber Du hast dann das Problem, dass wenn die hintersten Blaetter zuletzt gerendert werden, dann werden sie ohne Z-Test einfach ueber die vorderen Blaetter gepappt, sieht auch nicht schoen aus.
Z.B. partikelsystem, hier ginge das schon:
-Alles nicht-transparente rendern
-Z-Writing ausschalten
-Partikel (ohne sortierung)Liegt nun ein hinteres Partikel ueber einem vorderen ist das ja egal. wenn aber Deine Blaetter vorne statt hinten liegen sieht das nicht gut aus.
-
YASC schrieb:
Probier mal nur aus Interesse:
Die transparenten zuletzt und das mit ZWRITEENABLE
würd mich mal interessieren was dann rauskommtGeht auch ned, dann entsteht wieder dieser "wegschneide"-Effekt zwischen den transparenten Elementen, wenn das vordere zeitlich vor dem hinteren gerendert wird.
Ach, blending ist ne komplizierte Sache. Ich sag ja, ich seh wirklich keinen Weg, ausser der Tiefensortierung der transparenten Teilchen. Was aber unendlich muehsam werden kann. Rapso, sag mal was
-
Tja, dann seh ich auch nix mehr außer Tiefensortierung
-
Also von Hand sortieren muss man vielleicht nicht. Ich render die Baumstämme (nicht transparent), EndScene(), BeginScene() und render die Blätter, EndScene().
Das Ergebnis sieht schon wesentlich besser aus: Screenshot
So richtig frei von Grafikfehlern ist es noch nicht. Es ist nicht ganz leicht, das als unbewegtes Bild rüberzubringen, aber die Rückseiten (Unterseiten) der Blätter werden von den transparenten Oberseiten immer noch eliminiert. Culling ist aus.
-
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...
-
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
