Transparente Texturen löschen an den transparenten Stellen andere Meshes aus



  • @YASC: Ich sollte es vielleicht dazu sagen, die Baumkronen bestehen aus ein paar wenigen Polygonen und sind mit einer Textur überzogen die an manchen Stellen durchsichtig ist. Es gibt also keine ganzen transparenten und nicht-transparenten Polygone.



  • Dann mach mal für die die wenigstens ein bisschen transparent sind



  • Hmm, aber dann kanns doch passieren, dass die Blaetter der hinteren Baeume vor denen der vorderen Baeume liegen, so trivial wie ein Partikelsystem mit gleichen Partikeln ist das ja nicht (oder?..)

    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 🙂



  • Screenshot
    Es könnte sein, dass speziell dieses Problem damit gelöst ist. Genau kann ich es allerdings nicht sagen, wenn die meiste Zeit Objekte, die im Hintergrund sein sollten, Objekte im Vordergrund überlagern. Als Lösung kommt das leider so noch nicht in Frage. Oder wolltest du damit nur was herausfinden?



  • 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 🙂

    Wenn sie als letztes gerendert werden, können sie doch auch wieder vor Objekten erscheinen, hinter denen sie eigentlich sein sollten oder? Oder hast du es anders gemeint. Amsonsten sehe ich das Problem genauso wie du. Eigentlich gäbe es ja überhaupt kein Problem, wenn der transparente Bereich wirklich transparent wäre und nicht einfach andere Meshes auslöschen würde. Wieso ist das überhaupt so? 😕



  • 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 🤡



  • Optimizer 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 🙂

    Wenn sie als letztes gerendert werden, können sie doch auch wieder vor Objekten erscheinen, hinter denen sie eigentlich sein sollten oder? Oder hast du es anders gemeint. Amsonsten sehe ich das Problem genauso wie du. Eigentlich gäbe es ja überhaupt kein Problem, wenn der transparente Bereich wirklich transparent wäre und nicht einfach andere Meshes auslöschen würde. Wieso ist das überhaupt so? 😕

    Das "ausloeschen" liegt daran, dass wenn das transparente Dreieck zuerst gerendert wird und nix im Hintergrund ist, der transparente Teil des Dreieckes grau (Hintergrund) wird. Spaeter wird der hintere Baum gezeichnet, allerdings verhindert der Z-Test, dass der Baum vor dem (ganzen) "transparenten" Dreieck liegt, d.h. das "Transparente" ist nach wie vor vorne mit seinem grauen Hintergrund. (Z-Test ist auf das Dreieck bezogen, nicht nur auf die sichtbaren Teile)
    -->
    Transparente Teile muessen gerendert werden, nachdem der Hintergrund bereits besteht, damit der transparente Teil auf den bereits existierenden Hintergrund (Baum) addiert werden kann.

    Uhm, verstaendlich?..

    Jedenfalls sollte die nicht-transparente Szene erst mal gerendert sein, damit anschliessen die transparenten Elemente dazuaddiert werden koennen. Auch dabei gilt wieder, dass das hintere Teil bereits existieren muss wenn das vordere kommt... (Es sei denn die transparenten Teile sehen alle gleich aus, dann kannst Du Z-Write deaktivieren, sieht man ja nicht welches von denen vorne liegt. Bei Baeumen weiss ich aber auch nicht, wie das gehen soll, ausser wirklich mit sortieren.. mal rapso fragen 🙂 )



  • 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



  • @durito:

    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:

    @durito:

    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 rauskommt

    Geht 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...


Anmelden zum Antworten