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

[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

[Gast]

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

[Gast]

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*

[Gast]

Demzufolge wäre es effizienter, zuerst Objekte zu rendern, die näher an der Kamera sind, oder?

[TGGC]

Effizienter wofür?

Bye, TGGC

[Gast]

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

[Gast]

rapso schrieb:

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

Schon klar. Wenn man jetzt vom folgenden Absatz absieht

wenn du also möchtest, dass es richtig ausschaut, mußt du es correct sortieren. [...] dürfte aber für ein rts das alles von oben anschaut aber ok sein.

der vielleicht nicht mehr ganz grundlagenmäßig sein könnte, hast du mir jetzt aber auch nichts neues gesagt. Ich bin bereits gegen 18 Uhr auf folgendes: http://www.sjbaker.org/steve/omniv/alpha_sorting.html gestoßen und bin danach auch selber zu dem Schluss gekommen, dass der AlphaTest jetzt die für mich wohl geeignetste Methode ist. Versteh mich nicht falsch: Ich versuche, alles was ich mache auch zu verstehen, aber es gelingt nicht immer im vornherein. Vielleicht kannst du das so nachvollziehen:

Ich befasse mich gerade mit Transformationsmatrizen (total billig, kannte ich im Grunde, habe es nur testweise angewendet), rendere mehrere Bäume und stelle auf einmal fest, dass die transparenten Bereiche den Hintergrund wegschneiden. Zu diesem Zeitpunkt muss ich dann anfangen, die Ursache dafür rauszufinden und eine Lösung zu suchen. Wenn ich vorher gewusst hätte, dass dieses Problem auf mich zukommt und ich auch noch gewusst hätte, wie es mit dem Z-Buffer zusammenhängt, hätte ich mich damit erst genauer befasst. Aber woher hätte ich im vornherein wissen sollen, dass mehrere Bäume darzustellen mir gleich so viel Ärger macht? Es hat sich ja zufällig (jetzt weiß ich warum) so ergeben, dass es bei einem Baum noch klappt.

Ich versuche nicht Morgen Pixelshader zu verwenden und das Problem jetzt gerade habe ich mir nicht ausgesucht. Harmloser als mit Transformationen kann man doch kaum anfangen.

[rapso]

gut, wuste ich nicht, dachte du fummelst gerade mit objekten und deren rendering (bzw spezialfälle wie alphablend), weil du schon in mehreren postings wegen texturestages usw. bepingt hast.
dass es nur um transforms geht, ok.

nimm dir wie jeder coder: boxen, spheres, teapot, plane und vielleicht das bunny.

wir graphikcoder wissen schon, weshalb wir für die grundlagen so primitive dinge nehmen -> jedes kleine feature verdoppelt den debugaufwand

rapso->greets();