Doom 3 Grafikengine

[MeLLe]

Originally posted by Monger
Wieviel Speicher wird dieser Stencil-Buffer denn in Anspruch nehmen (wenn man mal von einer normalen Auflösung ausgeht?)?
Stencil-Depth * vertikale Auflösung * horizontale Auflösung.

also z.B. 8bit * 768 * 1024

[Demirug]

Originally posted by Monger
Aaaahhhhh! Jetzt kommt langsam die Erleuchtung!

Der Stencil-Buffer funktioniert wie eine Light-Map, die zwischengespeichert wird?


Ja und nein. Zwischengespeichert werden beide. Lightmaps gehören aber zu den Texturen und der Stencilbuffer gehört zum Backbuffer.

Und dann wird jeder Pixel um einen bestimmten Wert zusätzlich aufgehellt?

Ja und dieser Wert (RGB) wird in der Fragmentpipline für jeden Pixel berechnet.

Okay, dann geht es tatsächlich hundertprozentig linear, außer dass sich der Stencil-Buffer mehr Helligkeitsabstufungen merken muss.

Der Stencilbuffer speichert aber nur beleuchtet oder nicht beleuchtet. Einer der Schwachpunkte bei der Stencilschatten technik.

Das ist in der Tat genial. Wieviel Speicher wird dieser Stencil-Buffer denn in Anspruch nehmen (wenn man mal von einer normalen Auflösung ausgeht?) ?

Der Stencilbuffer speicher pro AA-Sample einen Wert. Dieser ist im Normalfall 8 Bit gross. Also Auflösung * AA-Modus. Da dieser Buffer aber bei der verwendung von 24 bit Z in der Regel sowieso mit angelegt wird fällt der speicher nicht zusätzlich ins gewicht.

Edit: Woher weiß Doom3 denn, wieviel Lichtquellen auf ein Objekt leuchten?

Die Engine muss umgekehrt vorgehen. Also es müssen alle Objekte die von einer Lichtquelle beleuchtet werden gesucht werden. Das ist aber relative einfach. Analytische Geometrie 101.

[Monger]

quote:
--------------------------------------------------------------------------------
Okay, dann geht es tatsächlich hundertprozentig linear, außer dass sich der Stencil-Buffer mehr Helligkeitsabstufungen merken muss.
--------------------------------------------------------------------------------



Der Stencilbuffer speichert aber nur beleuchtet oder nicht beleuchtet. Einer der Schwachpunkte bei der Stencilschatten technik.


Wie werden dann Grautöne erzeugt? Und das müssen sie ja offensichtlich, denn angenommen wir haben einen Helligkeitswert von 50%, dann kann man das auch mit viel Fantasie weder als Schwarz noch als Weiß betrachten. Wird anderweitig ein Helligkeitswert gespeichert?

Edit: Ich hab mich etwas mißverständlich ausgedrückt: Wenn der Stencil Buffer nur beleuchtet oder nicht beleuchtet ausgibt, was berechnet denn letztendlich, wie der Pixel wirklich aussieht? Und wie kommt man von Schwarz-Weiß auf Grau?

PS: Was ist "analytische Geometrie 101"? Bist du etwa auch einer dieser Binärcode-Fanatiker?

[Demirug]

Originally posted by Monger
Wie werden dann Grautöne erzeugt? Und das müssen sie ja offensichtlich, denn angenommen wir haben einen Helligkeitswert von 50%, dann kann man das auch mit viel Fantasie weder als Schwarz noch als Weiß betrachten. Wird anderweitig ein Helligkeitswert gespeichert?

Edit: Ich hab mich etwas mißverständlich ausgedrückt: Wenn der Stencil Buffer nur beleuchtet oder nicht beleuchtet ausgibt, was berechnet denn letztendlich, wie der Pixel wirklich aussieht? Und wie kommt man von Schwarz-Weiß auf Grau?

Die Farbe des Punktes wird über den "Pixel Shader" (ja DOOM III ist OpenGL aber mit den Begriff Pixel Shader können die meisten mehr anfangen) berechnet. Dort sind dann die Formeln die man für dir verschiedehnen Lichttypen (Punkt, spot, usw.) braucht entsprechend hinterlegt.

PS: Was ist "analytische Geometrie 101"? Bist du etwa auch einer dieser Binärcode-Fanatiker?

Nein die 101 habe ich aus dem Kurssystem der Amerikanischen Unis entliehen. Dort wird der Schwirigkeitsgrad eines Kurse mit einer 3 stelligen nummer angegeben. 101 ist dabei immer der Anfängerkurs.

[zeckensack]

Originally posted by Monger
Wie werden dann Grautöne erzeugt? Und das müssen sie ja offensichtlich, denn angenommen wir haben einen Helligkeitswert von 50%, dann kann man das auch mit viel Fantasie weder als Schwarz noch als Weiß betrachten. Wird anderweitig ein Helligkeitswert gespeichert?Das für eine einzelne Lichtquelle und ein einzelnes Objekt gültige Schattenvolumen gibt tatsächlich nur an, ob beleuchtet wird oder nicht. Zwischenstufen gibt es keine.

Bei der Berechnung der Beleuchtungsintensität (die nur da stattfindet wo kein Schatten ist) können sich aber sehr wohl Helligkeits- und Farbverläufe ergeben. Es ist zB allgemein übliche Praxis, das Licht in Abhängigkeit des Abstandes der Lichtquelle zur beleuchteten Oberfläche abzuschwächen. Auch Farben (bunte Lichter) äußern sich nicht an den Schatten, sondern nur da wo das Licht auftrifft.

Das ist auch korrekt so, es ist überhaupt nicht der Schatten selbst, der einen Farbverlauf aufweisen muß. Kein Licht = schwarz, ist auch im echten Leben nicht anders :)

Und den ganzen Rest mit den Halbschatten, mehrfarbigen Schatten usw erhält man ganz automatisch, indem man die Beiträge mehrerer Lichter (nicht mehrerer Schatten! der Lichtbeitrag innerhalb einer schattierten Fläche ist immer gleich null!) nacheinander durchgeht und im Framebuffer aufsummiert.

[Kai]

Interessanter Denkanstoss für euch: Im finalen D3 können auch farbige Schatten dargestellt werden, z.B. wenn eine grüne und eine rote Lampe ein Objekt beleuchten. Dann mischen sich die Schatten und es entsteht ein dunkelgrüner Schatten, mit rotem Rand. :)

[ow]

??

Was soll denn ein farbiger Schatten sein?

[Demirug]

Kai, der war gut :D

Schatten ist die Abwesenheit von Licht. Was du beschreibst ist ganz einfach der Effekt der Auftritt wenn zwei verschieden farbige Lichter ein Objekt bestrahlen welches beide Farbe reflektiert.

Für irgendwas müssen die Lektionen in Farbenlehre ja gut gewessen sein.

[ow]

Naja, jetzt brauch ich wohl nicht mehr auf eine Antwort auf meine Frage zu hoffen....:D;)

[Kai]

Originally posted by Demirug
Kai, der war gut :D

Schatten ist die Abwesenheit von Licht. Was du beschreibst ist ganz einfach der Effekt der Auftritt wenn zwei verschieden farbige Lichter ein Objekt bestrahlen welches beide Farbe reflektiert.

Für irgendwas müssen die Lektionen in Farbenlehre ja gut gewessen sein.

Ja, meine ich. So wie in der Disco halt. Ich konnt's nur nich so schlau beschreiben :D Was mich aber viel mehr interessiert, ist die Technik die dahintersteckt. Ergibt sich der "farbige Schatten" zwangsläufig aus der Erklärung die Du gebracht hast, oder steckt da innerhalb der Engine mehr dahinter?

[Quasar]

Denk' ich da jetzt zu einfach, oder sind die Stencils nur für die korrekte Projektion der Schatten zuständig? Die Farbe kann danach ja beliebig gewählt (oder auch errechnet mittels additiver Farbmischung) werden.
*aufmschlauchsteh*

[Demirug]

Kai, das ergibt sich automatisch aufgrund der Arbeitsweise der Engine. Wobei Einfarbiges Licht ja eher langweilig ist. Mit Lichtmasken kann man richtig hübsche Sachen machen. Diese benötigen aber entsprechende Support in der Engine ich bin mir zwar nicht ganz sicher aber ich denke mal das die DOOM III Engine diese technik auch beherscht.

[zeckensack]

So, ich hab mal ein Schema gemacht :D

Links der Beitrag eines roten Lichts
In der Mitte der Beitrag eines grünen Lichts
Rechts dann das, was sich durch Summation beider Lichter ergibt.

Schwarz=überhaupt kein Licht, logisch.

Anm: die farbigen Flächen in meinem Schema kann man natürlich im echten Leben nicht sehen. Man sieht das Licht nur da, wo es auf Objekte trifft. Das war mir jetzt einfach zu kompliziert zu zeichnen und zu wenig anschaulich.

*edit*
da fällt mir ein,
Die farbigen Flächen kann man in 3D sehr wohl sehen, wenn man es mit einem ebenen Fußboden zu tun hat. Der wird dann exakt so gefärbt wie in meinem Schema.

[Demirug]

ja quasar die stencils werden nur benutzt um zu bestimmen welches AA-Sample beleutet wird und welches nicht. Da dies bei jeder Lichtquelle natürlich anders ist muss auch für jede Lichtquelle der Stencilbuffer gelöscht und neu gerendert werden. Die Farbe der AA-Samples wird durch das Object und die Lichtquelle bestimmt. Im Backbuffer werden dann für alle Lichtquellen die das Sample beleuten die Farben hochsummiert.

[Quasar]

Ist es, rein theoretisch, möglich, dass eine Karte mehrere Stencil-Buffer zugleich verwalten und bearbeiten kann, sprich, bei Doom3 mehrere Lichtquellen singlepass berechnen kann?

[zeckensack]

Originally posted by Quasar
Ist es, rein theoretisch, möglich, dass eine Karte mehrere Stencil-Buffer zugleich verwalten und bearbeiten kann, sprich, bei Doom3 mehrere Lichtquellen singlepass berechnen kann? Da der Stencilbuffer pro Licht nur an/aus speichern muß, kann man schon jetzt und hier auf gängigen Karten die Masken für 8 Lichter gleichzeitig speichern (wg 8 Bit Stencil; Kyro: 4).

Nur bringt das überhaupt garnichts, wenn man pro Licht und pro Objekt einen Pass machen muß :bäh:
(naja, man spart sich das Löschen des Stencil-Buffers, IMO ist das aber nur ein kleiner Gewinn, kein bahnbrechender Performance-Vorteil; außerdem ist durchaus möglich daß der gute JohnC das schon längst so handhabt).

[Demirug]

Quasar, den stencilbuffer zu spliten um von mehr als einen Lichtquelle die Schattenvolumen zu hinterlegen liesse sich noch einigermassen realieren. Das Problem entsteht aber dann beim beim bestimmen der Farbwerte. Der Stenciltest mit dem bestimmt wird ob ein Farbwert nun geschrieben wird oder nicht kann nur einmal pro AA-Sample durchgeführt werden. Zudem ist dieser Test immer noch ein Teil der Fixed Functions eines Chips man hat im Pixelshader also keinen Einfluss darauf. Zumdem kommen da auch noch erhebliche organisatorische Probleme dazu. Für jede mögliche Kombination von Lichtquellen die ein Object beleuchten könnten müsste ein eigener Shader geschrieben werden.

[Quasar]

Aha, ok, vielen Dank ihr Beiden. :)

[[LOG]Skar]

meint ihr D3 nutzt Displacement Maps? Oder andere features von einer
Dx 9 Karte?

[Demirug]

Originally posted by [LOG]Skar
meint ihr D3 nutzt Displacement Maps? Oder andere features von einer
Dx 9 Karte?

DM genau wie jede andere Art von HOS (Higher Order Surfaces) definitiv nicht weil es sich nicht mit der Art wie die DOOM III Engine Schatten erzeugt verträgt.

Das Two-Side Stencil Feature, was jetzt einige Karten haben, wird sicherlich genutzt um bei den Schatten die Geometriebelastung zu verringern.

Wir werden aber sicherlich keine neue Effekte sehen weil dafür ja von der Seite der Designer gar keine Grunddaten verfügbar sind.

[KiBa]

Originally posted by zeckensack
Da der Stencilbuffer pro Licht nur an/aus speichern muß, kann man schon jetzt und hier auf gängigen Karten die Masken für 8 Lichter gleichzeitig speichern (wg 8 Bit Stencil; Kyro: 4).

ne, es muss mehr gespeichert werden pro pixel. nennt sich stencil-count. dieser wird um 1 erhöht, wenn ein front-face des schattenvolumens gerendert wird und um eins verringert bei einem back-face. ist der count ungleich 0, wird der entsprechende pixel gerendert.
man kann also maximal aus der sicht der kamera 256 front-faces rendern, mehr geht nicht, da der stencil-buffer nur 8-bit hat.
(viele karten beherrschen aber den korrekten über- und unterlauf des stencil-counts, so dass nur noch der unterschied zwischen front- und back-faces 256 nicht überschreiten darf)

[KiBa]

mpf, das war ich eben...
kann es sein, das der login nicht funktioniert, wenn man sich beim reply erst anmeldet?

[ow]

Ja, das kann sein und ist leider schon länger so.
Einloggen funzt nur auf der Startseite richtig.

[Chris Lux]

Originally posted by KiBa
(viele karten beherrschen aber den korrekten über- und unterlauf des stencil-counts, so dass nur noch der unterschied zwischen front- und back-faces 256 nicht überschreiten darf)

hi KiBa ;)
eigentlich ist der letzte satz doch ueberfluessig. denn schattenvolumen sind geschlossene koerper. dh der unterschied zwischen font und back faces kann fuer einen strahl, den man durch (oder in) so ein volumen schickt nie groesser sein als 1. es sei denn man haette zwei volumen, die sich schneiden (weiss nicht ob sowas auftreten kann bei den siluetten algorithmen).

cu und frohe weihnachten

[zeckensack]

Originally posted by Hans Ohlo


hi KiBa ;)
eigentlich ist der letzte satz doch ueberfluessig. denn schattenvolumen sind geschlossene koerper. dh der unterschied zwischen font und back faces kann fuer einen strahl, den man durch (oder in) so ein volumen schickt nie groesser sein als 1. es sei denn man haette zwei volumen, die sich schneiden (weiss nicht ob sowas auftreten kann bei den siluetten algorithmen).

cu und frohe weihnachten Nein, KiBa hat schon recht, meine Aussage oben ist deswegen auch falsch.

Ein Schattenvolumen ist zwar ein geschlossener Körper, aber nicht zwingend Konvex. Dh wenn ich mir einen Strahl von der Kamera durch das Schattenvolumen eines einzigen Körpers vorstelle, kann es sein, daß dieser Strahl
rein,
raus,
nochmal rein,
nochmal raus
geht.

Der Stencilbuffer sammelt diese Schritte quasi unterwegs ein.

Da die Dreiecke des Volumens aber nicht zwingend front-to-back gerendert werden (je nach Modelltopologie kommt das in den besten Familien vor!), und außerdem die Backfaces und Frontfaces sowieso getrennt voneinander auf die Karte geschickt werden, kann aus diesem Beispielfall auch das hier werden:
rein,
nochmal rein,
raus,
nochmal raus.

Und dafür braucht man dann 'unterwegs' zwei Bits. Das Endresultat ist nur ein Bit, aber um es zu erzeugen braucht man mehr Platz.

[KiBa]

moin, hans... ;)
zs hat ja schon was dazu geschrieben.
hinzu kommt, das der sichtstrahl nur bis zu der nächsten fläche im z-buffer "zurückverfolgt" wird. es ist z.b. möglich, dass alle frontfaces einer silouette in den stencil-buffer gerendert werden, alle backfaces sich aber hinter einem polygon befinden. die silouetten-optimierung macht deinem beispiel nen strich durch die rechnung. aber selbst mit konvexen schattenvolumen hätte man immer noch das problem der sich überlagernden volumen, was einen stencil-count wie beschrieben unbedingt erforderlich macht.
cu

[Chris Lux]

Originally posted by KiBa
hinzu kommt, das der sichtstrahl nur bis zu der nächsten fläche im z-buffer "zurückverfolgt" wird. es ist z.b. möglich, dass alle frontfaces einer silouette in den stencil-buffer gerendert werden, alle backfaces sich aber hinter einem polygon befinden.


imo geht das nich, auch, wenn das volumen nicht konvex ist. das meinte ich ja mit dem fall, das der count dann nur einen unterschied von 1 haben kann... aber was zs meinte leuchtet ein, das nicht f2b gerendert wird.

ueber den rest unterhalten wir uns mal bei gelegenheit, ich mach jetzt ferien bis 7.1. also nochmal frohe weihnachten und nen guten rutsch ;)

[Rampage 2]

Originally posted by Kai


Das tät ich gerne tun, aber so ganz legal ist die Sache nicht, daher lasse ich's ;)

Aber ich kann nochwas dazu sagen. Schatten ausfransen zu lassen (ob normale Emulation, oder per Pixelshader oder nicht) kostet heute noch viel zu viel Performance. Ich bin ja schon froh, das wir mal so weit sind das alle Objekte von der gleichen Lichtquelle in Echtzeit beleuchtet werden können.

Wenn ich ne Kiste in die Mitte eines Raumes stelle und auf jede der vier Seiten ne Lichtquelle ausrichte, wirft die Kiste auch genau vier Schatten, mehr oder weniger sichtbar (kommt ja auf die Stärke des Lichtes an).

Hat nicht gerade was mit dem Thema zu tun, aber was viele wohl generell verwechseln: Es sind definitiv nicht die Objekte in der Spielwelt, die Doom3 performancemässig in die Knie zwingen, es sind die Lichtquellen (wg. der tausend Schatten die sich bei überlagernden Quellen ergeben). Du kannst nen Raum vollknatschen mit zig Zombies, und einer Lichtquelle - da klappen deine FPS kaum ein. Aber wenn Du ne zweite Quelle dazu nimmst, oder gar eine dritte oder vierte ... adieu Performance.

Daher wird Doom3 (und die auf der Technik basierenden Projekte) eher düster gehalten werden, weil die Power für mehrere (sagen wir mal 30 Lichtquellen pro Raum einfach noch nicht da ist. Wenn man heute mit der Technik 6 Lichtquellen pro "portalisiertem" Raum einsetzt, muss die Graka schon ganz schön schwitzen um die Sache am rollen zu halten.

Aber wie schon erwähnt, so dolle schlimm ist das nicht. Schon gar nicht für Outdoor-Szenarien wo es gar keine dynamischen Lichtquellen braucht. Da wird id (falls die Outdoor-Maps es in die Final schaffen) und auch die anderen Hersteller auf andere Techniken zurückgreifen. Ich sag mal soviel dazu: Drauf gekommen das so zu machen ist noch keiner ;) Und es benötigt nichtmal nen Kompiliervorgang, wobei der Übergang aber wirklich und hundertprozentig "seamless" verlaufen kann. Also net "Tür raus, LOADING, outdoor, Tür rein, LOADING, indoor" etc.

Edit: An diejenigen die noch immer zweifeln ob dieses realtime-lightning in einer starren Umgebung wie Doom3 sie in der Alpha zeigt überhaupt sinn macht: Jo, macht es. Wartet auf die Final -> und wundert euch nicht, warum ihr jedes noch so kleine Regal umschmeissen könnt ;)

Das liegt doch daran, dass jede Lichtquelle (bzw. Lichtweg) einzeln
berechnet werden muss - denn bei EINER Lichtquelle sich die Engine
nur bei dieser einen Lichtquelle "orientieren" um den Weg der Schat-
tenwürfe zu rekonstruieren, richtig? Aber bei MEHREREN Licht-
quellen müssen 1.) mehrere Lichtquellen BERÜCKSICHTIGT werden
um die Schattenwege zu berechnen - also höhere Komplexität und
2.) es entstehen pro Objekt mehr Schatten ( bei 4 Lichtquellen
machen das 4 Schatten pro Objekt) - und das verbraucht sehr
viel Füllrate. Ich glaube auch warum die GFFX in D3 deutlich
schneller war als die R9700Pro: Die GFFX hat eine 50% höhere
(theoretische) Füllrate als die R300. Und die GFFX hatte
exakt 40% höhere avg-Framerates als die R300 - klingt für
mich einleuchtend, da die Schatten sehr viel Füllrate fressen
Daher glaube ich auch nicht dass eine R9700Pro in D3 viel
schneller sein wird als eine R9500Pro - weil beide die selbe
Füllrate bieten.

Habe ich das so richtig interpretiert?

Edit: Bei 2 Lichtquellen müsste ein Spiel dann halb so schnell laufen
wie mit einer, oder?

[Kai]

Originally posted by Rampage 2

Edit: Bei 2 Lichtquellen müsste ein Spiel dann halb so schnell laufen
wie mit einer, oder?

Theoretisch richtig. Soweit hast Du alles ziemlich gut nachinterpretiert, aber in der Praxis sieht das wieder ein wenig anders aus mit der halbierung der Performance. Mit dem neuesten Build jedenfalls.

Übrigens: Die GeForceFX ist genau das, was ich mir für Doom3 wünschen würde ;)

[Demirug]

Originally posted by Kai


Theoretisch richtig. Soweit hast Du alles ziemlich gut nachinterpretiert, aber in der Praxis sieht das wieder ein wenig anders aus mit der halbierung der Performance. Mit dem neuesten Build jedenfalls.

Übrigens: Die GeForceFX ist genau das, was ich mir für Doom3 wünschen würde ;)

Theoretisch nicht ganz richtig. Eine Halbierung tritt nur dann ein wenn die zweite Lichtquelle genau die gleichen Objekte beleuchtet und der benötigte Shader genauso aufwendig ist. In der Praxsis kann man also nicht sagen das die Engine mit der Anzahl der Lichtquellen skaliert. 5 Lichtquellen die nur wenige Objekte beleuchten können schneller sein als eine Lichtquelle die sehr viele Objekte beleuchtet. Voraussetzung dafür ist aber das das Lightsetup der Engine richtig optimiert wurde. Aber davon gehe ich jetzt einfach mal aus.

[Kai]

@ Demirug: Ging ja sowieso vom Worstcase aus. Also 1 Raum, 10 Hindernisse. Mehrere sich überschneidende Lichtquellen, die die Hindernisse beleuchten.

Aber hast Recht, wenn die zweite Lichtquelle natürlich von den 10 Objekten WEG leuchtet kackt die Performance nicht, oder nicht allzusehr ein. In der Praxis sieht das daher natürlich anders aus, aber mehr als 15 - 20 Quellen pro Raum und Portal sind selbst mit der kommenden Hardware selbstmord.