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

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.

durito

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

durito

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.

0x00000001

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

TGGC

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?

TGGC

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.

TGGC

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.

durito

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

TGGC

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?

TGGC

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?

0x00000001

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

rapso

optimizer, wenn du dir ein bisschen grundlagen wissen anlesen würdest, würdest du mit deiner arbeit vermutlich sehr viel schneller vorrankommen. eigentlich steht in jedem tutorial zu alphablending (egal ob oGl oder Dx) wie das richtig zu machen ist. DirectX sortiert erstmal garnichts, es weiß ja nicht ob du das mit absicht oder zufällig so zeichnest wie du es zeichnest, bei z.b. additiv geblendeten sachen dürfte die sortierung absolut egal sein (weil bei + in beliebiger ordnung die variablen vertauscht werden können). wenn du jedoch blendest muss sortiert werden, nicht nur damit die verdeckung richtig ist, sondern auch damit das blenden korrekt abläuft.
die formel fürs blenden ist ja, primitiv gesehen

color = hintergrundfarbe*(1.f-alpha)+Pixelfarbe*alpha

wenn du nun zweimal auf dem selbem pixel zeichnest, kommst du auf

color = (hintergrundfarbe*(1.f-alpha)+Pixelfarbe1*alpha)*(1.f-alpha)+Pixelfarbe2*alpha

bzw

color = hintergrundfarbe*(1.f-alpha)^2+Pixelfarbe1*alpha*(1.f-alpha)+Pixelfarbe2*alpha

wie du siehst, fließt in die endfarbe von Pixelfarbe1 und Pixelfarbe2 unterschiedlich viel rein, falls alpha!=0 && alpha!=1 ist. wenn du also die reichenfolge der beiden pixelfarben vertauschenwürdest, würde der pixel anders aussehen, obwohl du trotz disabled z-write eventuell alle polys/pixel sichtbar hast.

wenn du also möchtest, dass es richtig ausschaut, mußt du es correct sortieren. der aufwand dafür ist nicht unerheblich. die einzig immer richtig laufende methode ist meines wissens nach ein BSP-tree. dabei hast du natürlich den nachteil dass du die objekte kaum bewegen kannst. eine mischung davon wird öfters benutzt, dass die objekte untereinander normal sortiert werden z.b. anhand ihres pivots oder schwerpunktes und dann das objekt für sich mittels bsp-trees aufgebaut wird.
es gibt auch suboptimale methoden, z.b. sixside-indices, dabei mußt du vorher (eventuell beim laden) ein objekt möglichst gut für 6 ausrichtungen sortieren (kann man mittels bsp-trees oder guten überlappngstest der polys machen). hat den nachteil, dass sobald du an einer position bist, die zu nah am objekt ist (z.b. mitten im objekt), keine der sixsides der sortierung mehr richtig ist. dürfte aber für ein rts das alles von oben anschaut aber ok sein.

wenn du also nicht noch mehr kopfzerbrechen haben möchtest (was du bei alpha-particlen aber trotzdem haben wirst ), zeichne die sachen mit alphatest.

was TGGC behauptet, dass es pixelig wird, stimmt so nicht. es kann pixelig werden, aber schau dir spiele wie z.b. farcry an, wenn die interpolation vom alphachannel eingeschaltet ist und deine modeller sich ein wenig mühe geben, hast du einfach nur saubere scharfe kanten als ob es ausgemodellt wäre. siehe http://www.fabian-gander.ch/links/games/farcry/38.jpg

rapso->greets();

btw. das ist kein flame, aber pardón, du solltest dir wirklich manchmal wissen besorgen bevor du etwas versuchst anzuwenden. die idee von learning by doing ist nicht, dass man wissenslos durch die gegend irrt und es klappt dann irgendwann mal