X-Ray Engine: das Maß aller Dinge?

[Kladderadatsch]

Oles Shishkovtsov, chefprogrammierer von stalker, hat ein imo äußerst interessantes interview zur grafik-engine gegeben. die wird von ihm als absolut revolutionär dargestellt:
Es ist sehr gut, etwas zu sehen, das jemand bereits getan hat und das schon irgendwo beschrieben wurde. Das ist einfach. Aber wenn etwas noch nie von jemandem probiert worden ist, dann muss man ordentlich nach allen Möglichkeiten forschen und die besten herauswählen.

In der letzten Zeit gingen 50 Prozent meiner Zeit für Experimente drauf. Der zweite Renderer ist das Resultat von Unmengen an Experimenten. S.T.A.L.K.E.R. wird der erste Titel sein, der auf dem Spielemarkt Deferred Shading verwenden wird. Der Vorteil dieser Methode liegt darin, dass es irrelevant ist, wie viele Polygone wir auf dem Monitor zeichnen. Sie wird nur das Generieren von Schatten etwas verlangsamen, jedoch macht es keinen Unterschied, ob wir eine Lichtquelle oder tausend verwenden und es macht auch nichts aus, in welche Richtungen die Lichtquellen zeigen. Statisch oder dynamisch – die Beleuchtung wird dennoch in Echtzeit durchgeführt. Wir arbeiten vollständig mit einem Vektorraum. Das bedeutet: Ist die Auslage richtig kalibriert, können wir ein Foto eins zu eins reproduzieren. In anderen Worten heißt dies nichts anderes, als dass kein anderes Spiel, das heute exisitiert, ein Foto einfach repetieren kann, wie sehr man auch versucht, die Textur zu beleuchten, wenn der Raum, in dem das Licht kalkuliert wird, nicht mit dem Raum, in dem sich die Textur befindet, übereinstimmt.

Unser Ansatz des Bump Mapping ist auch nicht traditionell. Vom Anfang an versucht jeder, die Oberfläche detaillierter erscheinen zu lassen. In anderen Worten: Es wird intendiert, sehr viele Details auf einem flachen Polygon zu zeigen, als sei es tesseliert in Billionen von Polygonen – Mikrodetails. Bump Mapping hilft teilweise, dieses Ziel zu erreichen. Zum Beispiel würde aber eine Erhebung nie das, was hinter ihr ist, überdecken. Wenn eines Tages die realistiche Möglichkeit da ist, wäre Displacement Mapping ideal für so etwas. Zurzeit ist dies jedoch unerreichbar – zumindest für Echtzeitanwendungen. Wir haben einen ganz anderen Ansatz gewählt. Man könnte durchaus sagen, dass wir echtes Displacement Mapping verwenden – nur an den Kanten nicht. Dort kann man immer noch eine flache Oberfläche erkennen.

Basierend auf den selben Daten, die der erste Renderer verwendet, wird der zweite ein viel detailliertes Bild präsentieren, was auch eine zehnmal höhere Qualität der Beleuchtung beinhaltet. Um es simpler zu fassen: Die Grafik wird um ein Vielfaches besser aussehen. Das ist die Idee, die hinter all unserem Vorgehen steckt.
quelle (http://stalker.myexp.de/ger/index.php?site=newscomment2.php&id=1777)

was sagen da die gurus dazu? sind das schlichtweg falsche behauptungen, oder steckt da doch etwas dahinter, was eine releaseverzögerung ins jahr 2006 rechtfertigt?

[Spasstiger]

Ich halte die Aussagen eher für Rechtfertigungsversuche, wobei ich technisch nicht so versiert bin, um die Aussage mit dem "Deferred Shading" richtig beurteilen zu können.

[Coda]

Das was er erzählt ist schon richtig. Deffered Shading hat aber andere Problem, unter anderem braucht es für wenige Lichtquellen mehr Leistung.

Wenn man allerdings viele dynamische Lichtquellen hat ist das O(1) verhalten natürlich extrem gut.

Allerdings ist das eigentlich nur auf GeForce 6+ und Radeon 9500+ möglich weil man für gescheite Performance MRT braucht.

[TheCounter]

Allerdings ist das eigentlich nur auf GeForce 6+ und Radeon 9500+ möglich weil man für gescheite Performance MRT braucht.

Deswegen wohl auch die 2 Renderer. Bin aber wirklich gespannt wie das ganze im DX9 Modus läuft und vor allem wieviel SM3.0 hier ausmacht.

[Xmas]

Der "ganz andere" Ansatz für Bumpmapping ist wohl auch nur eine Variante des Parallax Mappings.

Dass es keinen Unterschied macht ob eine oder tausend Lichtquellen verwendet werden ist ganz großer Unsinn. Da hilft auch noch so viel deferred Shading nichts.

Und was soll bitte "zehnmal höhere Qualität der Beleuchtung" sein? Als ob man das quantifizieren könnte...

[Demirug]

Das sie "Deferred Shading" benutzen haben sie nun ja schon länger angekündigt.

Die Idee dabei ist einfach die Beleuchtung so lange zu verzögern bis feststeht was beleuchtet werden muss. Dafür müssen aber alle Informationen die man dafür dann braucht in einem Zwischenbuffer gespeichert werden.

Die Überlegung dabei ist das man die Aufwendigen Lichtberechnungen nur noch für die Pixel durchführt die man am Ende auch zu gesicht bekommt. Da desweiteren die Objekt texturen im gefilterten Zustand in dem Speicher geschrieben werden entfällt das Filtern für jede neue Lichtquelle. Da man bei Füllen der Zwischenspeicher auch den Z-Buffer füllt braucht man Z-Pass den man normalerweise für sie Stencilschatten benötigt nicht.

Ich persönlich mag diese Methode allerdings nicht sonderlich, weil:

- Im Vorbereitungspass sehr viele Informationen in den Speicher schreiben muss. Gleichzeitig die Bandbreite durch das Auslesen der Texturen belastet und Verhältnismässig wenig rechnet.

- Bei den Lichtpasses für jede Lichtquelle die ganzen Daten wieder eingelesen werden müssen.

- Das Verfahren ist nicht kompatibel mit MSAA

- Teiltransparente Objekte können damit nicht gerendert werden. Das muss man dann noch zusätzlich mit einem anderen Verfahren machen.


Die Aussage das die Anzahl der Polygone wie auch der Lichtquellen irreleavant ist kann nur ein schlechter Scherz sein. Was dargestellt werden soll kostet Leistung darum kommt man nun nicht mal herum.

[Coda]

Wahrscheinlich meint er die Lichtberechnung am Ende damit.

[Kladderadatsch]

hier (http://stalker.myexp.de/ger/index.php?site=newscomment2.php&id=1772) gibts übrigens die probe aus exempel- dx9 screenshots und trailer des ausenareals. (unbedingt anschauen- jede menge details in sachen grafik und ki)


und hier habe ich noch ein paar (populärwissenschaftliche;)) informationen gefunden:
Folgende Features bietet die X-Ray-Engine:

Allgemein
• Darstellung von großen Landschaften, als auch von kleinen geschlossenen Räumen
• "On Demand Loading" ermöglicht die Darstellung einer gigantischen Welt ohne störende Ladepausen
• Simulierung der Spielzeit, fließender Tag/Nacht-Wechsel
• weiche und realistische Bewegungen durch ein Skelett-Animationssystem, basierend auf Motion-Capturing

Grafik
• unterstützt alle Direct3D-kompatiblen Grafikkarten der zweiten Generation (TNT2, Voodoo2); empfohlen ist allerdings mindestens eine GeForce 2
• optimierte Darstellung für Hardware T&L (Transform & Lighting -> zwei separate Engines des Grafikchips sind für Transformation- und Lichteffekte zuständig)
• fortlaufende Level of Detail (LoD) Technik für die gesamte Level-Geometrie
• rund 300.000 Polygone pro dargestelltem Bild mit 60 fps auf durchschnittlicher Hardware
• hochdetaillierte Charakter-Modelle (500 bis 10.000 Polygone)
• schnelles Animationssystem mit einer theoretisch unendlichen Anzahl an virtuellen Knochen
• SSE/3Dnow! werden zur Darstellung der Gesichtsmimik und der generellen Fortbewegung verwendet
• Objekte wirken aus der Entfernung recht "einfach" gebaut, sobald ihr aber näher rankommt, werden immer neue Details sichtbar
• adaptive Hardware Caching-Technik
• dynamische, farbige Licht-Effekte
• realistischer, weicher Schattenwurf
• Charaktere werfen echte Schatten
• animierte Lichtquellen, welche die Umgebung perfekt und schnell ausleuchten
• zerstörbare Lichter
• verschmelzen von mehreren Lichteffekten ohne Clipping
• Wassereffekte mit Spiegelungen auf der Oberfläche
• Flares, Flammen und Lichtkoronas
• aufwändiges Partikel-System basierend auf echter Physik
• komplexe Shader-Modelle (besonders bei DirectX9)
• Multi-pass Rendering (Fallback Shaders)
• Bump Mapping (Shading-Technik bei der strukturierte Oberflächen simuliert werden können und zwar mit mehreren Texturen und Lichteffekten. Dadurch entstehen sehr plastische Texturen.)
• photorealistische Texturen
• Pixel-Shader wird genutzt (besonders bei DirectX9) - Der Pixel Shader verändert Beleuchtungs-, Materialien- und Oberflächeneffekte, so dass realere Oberflächen zum Vorschein kommen.
• Vertex-Shader wird eingesetzt, um Charaktere und Umgebungen lebendig zu gestalten (beispielsweise Falten in Gesichtern)
• Charaktere werden durch umgebende Shader beleuchtet
• DirectX9-Shader fügen weitere Details zu den Charakter-Modellen hinzu

Physik-Engine
• basiert auf der ODE-Engine
• schnelle Darstellung der berechneten Physik
• Kollisions-Berechnung ist optimiert für eine große Anzahl an Aufgaben
• Kollisions-Datenbank mit wenig Speicher-Nutzung
• realistische Berechnung der Flugbahn von Projektilen
• Fahrzeuge steuern sich real / gehen schnell zu Bruch
• korrekte Simulation der Schwerkraft
• Ragdoll-Effekte bei den Leichen

[Demirug]

Wahrscheinlich meint er die Lichtberechnung am Ende damit.

Ja, dabei spielt die Anzahl der Polys keine Rolle mehr aber für jede Lichtquelle hat man einen Pass und summiert auf. Sowas neigt zum Banding. Noch ein Grund das ganze nicht zu mögen.

Wenn man keine Stencilschatten nutzt könnte man natürlich auch mehrer Lichtquellen in einem Pass berechnen. Aner warum dann überhaupt noch "Deferred Shading"?

Vielleicht bin ich ja auch nicht ganz opjektiv weil ich persönlich schon immer ein Anhänger der "Möglichst alles in einem Pass" Methode war.

[Coda]

Vielleicht haben sich die Fehler ja auch bei der Übersetzung ergeben oder der Interviewer hat es falsch verstanden.

Ich versteh auch nicht ganz was sie mit defered shading wollen, mich hat da bisher kein Demo so richtig überzeugt. Und das MSAA nicht funktioniert ist ja eigentlich schon fast ein Totschlagargument dagegen.

[Labberlippe]

Das sie "Deferred Shading" benutzen haben sie nun ja schon länger angekündigt.

Die Idee dabei ist einfach die Beleuchtung so lange zu verzögern bis feststeht was beleuchtet werden muss. Dafür müssen aber alle Informationen die man dafür dann braucht in einem Zwischenbuffer gespeichert werden.

Die Überlegung dabei ist das man die Aufwendigen Lichtberechnungen nur noch für die Pixel durchführt die man am Ende auch zu gesicht bekommt. Da desweiteren die Objekt texturen im gefilterten Zustand in dem Speicher geschrieben werden entfällt das Filtern für jede neue Lichtquelle. Da man bei Füllen der Zwischenspeicher auch den Z-Buffer füllt braucht man Z-Pass den man normalerweise für sie Stencilschatten benötigt nicht.

Ich persönlich mag diese Methode allerdings nicht sonderlich, weil:

- Im Vorbereitungspass sehr viele Informationen in den Speicher schreiben muss. Gleichzeitig die Bandbreite durch das Auslesen der Texturen belastet und Verhältnismässig wenig rechnet.

- Bei den Lichtpasses für jede Lichtquelle die ganzen Daten wieder eingelesen werden müssen.

- Das Verfahren ist nicht kompatibel mit MSAA

- Teiltransparente Objekte können damit nicht gerendert werden. Das muss man dann noch zusätzlich mit einem anderen Verfahren machen.


Die Aussage das die Anzahl der Polygone wie auch der Lichtquellen irreleavant ist kann nur ein schlechter Scherz sein. Was dargestellt werden soll kostet Leistung darum kommt man nun nicht mal herum.

Hi

Dumme Frage..

Was wäre wenn man das in einen extra "zwischenpuffer" gibt?

Gruss Labberlippe

[Kladderadatsch]

Ist die Auslage richtig kalibriert, können wir ein Foto eins zu eins reproduzieren.
bedeutet das, dass es in stalker sprichwörtlich photorealistische texturen geben wird?


und ersetzt dieses deferred shading einfach nur das stencil shadowing?

unter diesem link (http://www.internet-magazin.de/praxis/programmierung/cm/page/page.php?table=pg&id=1962) ist deffered shading übrigens ausführlich behandelt. (9 seiten)

so auch probleme:
Prinzipiell sollten Sie die Datenmenge aber so gering wie möglich halten, wie das folgende Beispiel zeigt. Nehmen Sie an, Sie speichern die Position in einem A32R32G32B32 Rendertarget (32 Bit IEEE Float für alle vier Komponenten), die Normale, diffuse Farbe und zusätzliche Materialparameter jeweils als A8R8G8B8-Rendertarget. Somit würden Sie pro Pixel bereits 224 Bits speichern, was sich bei einer Auflösung von 1024x768 auf 21 Megabyte summieren würde, ohne das Sie Anti- Aliasing verwenden könnten. Ein dabei verschwiegenes Problem ist, dass die momentane Grafikhardware es gar nicht erlaubt, unterschiedliche Bit-Tiefen bei multiplen Rendertargets zu verwenden.

wie soll man den letzten satz verstehen?

[Demirug]

Hi

Dumme Frage..

Was wäre wenn man das in einen extra "zwischenpuffer" gibt?

Gruss Labberlippe

Ich verstehe die Frage nicht so ganz.

Was willst du in diesen Zwischenbuffer packen?

[Demirug]

bedeutet das, dass es in stalker sprichwörtlich photorealistische texturen geben wird?


und ersetzt dieses deferred shading einfach nur das stencil shadowing?

unter diesem link (http://www.internet-magazin.de/praxis/programmierung/cm/page/page.php?table=pg&id=1962) ist deffered shading übrigens ausführlich behandelt. (9 seiten)

so auch probleme:
Prinzipiell sollten Sie die Datenmenge aber so gering wie möglich halten, wie das folgende Beispiel zeigt. Nehmen Sie an, Sie speichern die Position in einem A32R32G32B32 Rendertarget (32 Bit IEEE Float für alle vier Komponenten), die Normale, diffuse Farbe und zusätzliche Materialparameter jeweils als A8R8G8B8-Rendertarget. Somit würden Sie pro Pixel bereits 224 Bits speichern, was sich bei einer Auflösung von 1024x768 auf 21 Megabyte summieren würde, ohne das Sie Anti- Aliasing verwenden könnten. Ein dabei verschwiegenes Problem ist, dass die momentane Grafikhardware es gar nicht erlaubt, unterschiedliche Bit-Tiefen bei multiplen Rendertargets zu verwenden.

wie soll man den letzten satz verstehen?

Bei DX geht es da um das D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS Capsbit. Das ganze steht in Verbindung mit MRT. Wenn man in mehr als einen Buffer gleichzeitig schreiben will so gilt die Begrenzung (wenn diese Bit nicht gesetzt ist) das alle Buffer ein Format mit der gleichen Bitgröße pro Pixel benutzen müssen. Man kann also nicht eine 4 kanal FP16 texture gleichzeitig mit einer gewöhnlichen 32 Bit RGBA Texture verwenden. Den die FP16 Texture hätte ja 64 Bit.

[micki]

- Im Vorbereitungspass sehr viele Informationen in den Speicher schreiben muss. Gleichzeitig die Bandbreite durch das Auslesen der Texturen belastet und Verhältnismässig wenig rechnet.
wenn man offsetmapping(bzw virtual displacement mapping) durchführt, muss man das schon in diesem durchgang machen, was, sofern man versucht mit conditional jumps zu optimieren, die pixelshader genug unterhalten sollte...



- Bei den Lichtpasses für jede Lichtquelle die ganzen Daten wieder eingelesen werden müssen.
aber dafür keine eigentlichen texturen mehr und zudem durch aufteilung auf ein paar mehr polygone kann man der gpu beim cachen helfen, das sollte doch nicht wirklich ein problem sein (wenn es auch natürlich nicht umsonst ist... there's no free lunch..)


- Teiltransparente Objekte können damit nicht gerendert werden. Das muss man dann noch zusätzlich mit einem anderen Verfahren machen.

klappt doch bei keinem multipass verfahren, auch nicht bei Doom3, oder?


Die Aussage das die Anzahl der Polygone wie auch der Lichtquellen irreleavant ist kann nur ein schlechter Scherz sein. Was dargestellt werden soll kostet Leistung darum kommt man nun nicht mal herum.
er meint wohl relativ gesehen. die engine kann sicherlich 20 lichtquellen pro pixel aus einer textur lesen und verwirft die meisten davon ganz schnell, die meisten Pixelshading engines geben bei 4lichtquellen / pixel auf.

MfG
micki

[Demirug]

wenn man offsetmapping(bzw virtual displacement mapping) durchführt, muss man das schon in diesem durchgang machen, was, sofern man versucht mit conditional jumps zu optimieren, die pixelshader genug unterhalten sollte...

Dafür muss man aber auch wieder zusätzlich sampeln was den Rechenaufwand kompensiert.

aber dafür keine eigentlichen texturen mehr und zudem durch aufteilung auf ein paar mehr polygone kann man der gpu beim cachen helfen, das sollte doch nicht wirklich ein problem sein (wenn es auch natürlich nicht umsonst ist... there's no free lunch..)

Aufteilen muss man da nichts und Cachen bringt da eh nicht viel weil jeder Wert aus dem Zwischenspeicher ja sowieso höchstens einmal pro Lichtquelle gebraucht wird. Natürlich muss man die Texturen nicht mehr samplen das hat man ja schon in dem Vorbereitspass erledigt. Bei vielen Lichtquellen im Multipassverfahren in Verbindung mit hohem AF kann das ja dann entsprechend auch was bringen. Ich führte ja darum ein Singelpass Verfahren mit vielen Lichtquellen pro Pass als die IMHO bessere Alternative auf. Dafür hätte ich dann gerne schon Integerverarbeitung in den Pixelshadern sowie topologie funktionen.

klappt doch bei keinem multipass verfahren, auch nicht bei Doom3, oder?

Ist mit Multipass immer problematisch das besondere Problem beim DS ist aber das man in den Zwischenbuffern ja nur eine Schicht speichern kann. Alles was Teiltransparent ist stellt eine weitere Schicht da. Ergo muss man das wieder getrennt nach dem alten Verfahren ergänzen nachdem mandem das DS abgeschlossen hat.

er meint wohl relativ gesehen. die engine kann sicherlich 20 lichtquellen pro pixel aus einer textur lesen und verwirft die meisten davon ganz schnell, die meisten Pixelshading engines geben bei 4lichtquellen / pixel auf.

MfG
micki

Lichtquellen sind bei DS doch nicht in einer Texture.

[micki]

Dafür muss man aber auch wieder zusätzlich sampeln was den Rechenaufwand kompensiert.
andere idee: unified shader architecture, da könnte man für den ersten pass alle power in die VS stecken und im zweiten durchgang in den PS, wenn dann das gemunkelte edram in den ATI chips drinne wäre... *unrealistischwerd*



Aufteilen muss man da nichts und Cachen bringt da eh nicht viel weil jeder Wert aus dem Zwischenspeicher ja sowieso höchstens einmal pro Lichtquelle gebraucht wird.
afaik wird aber immer eine kachel aus dem speicher in den cache geladen, wenn man also in "quadraten" vorgeht, könnte man mehr cachehits haben also mit einem großen quad das wohl zeilenweise mit 2x2 pixel. als ich sowas mal auf einer gf4TI getestet hatte, war es ein wenig fixer. mag sein dass es heutzutage anders ist :)




Lichtquellen sind bei DS doch nicht in einer Texture.
da es bei ps2_x nicht genug const-register gibt um alle möglichen daten für die lichtquellen zu speichern, hatte NV in einem seiner paper mal gesagt, man kann in kleinen dafür dedizierten textures indizieren, dort hat man platz für pos,dir,attenuation,specularpower,specularintensity,color... pro lichtquelle.

MfG
micki

[Demirug]

andere idee: unified shader architecture, da könnte man für den ersten pass alle power in die VS stecken und im zweiten durchgang in den PS, wenn dann das gemunkelte edram in den ATI chips drinne wäre... *unrealistischwerd*

Ich sehe das Limit im ersten Schritt aber eher an der Bandbreite. Da bringen auch unified shader nichts.

afaik wird aber immer eine kachel aus dem speicher in den cache geladen, wenn man also in "quadraten" vorgeht, könnte man mehr cachehits haben also mit einem großen quad das wohl zeilenweise mit 2x2 pixel. als ich sowas mal auf einer gf4TI getestet hatte, war es ein wenig fixer. mag sein dass es heutzutage anders ist :)

Das Problem entsteht nur wenn man als Rasterisiere noch auf einen Linewalker setzt. nVidia hat sich davon aber schon lange getrennt da wird Cachefreundlich gearbeitet egal wie gross die Dreiecke sind. Bei ATI bin ich mir nicht sicher.

da es bei ps2_x nicht genug const-register gibt um alle möglichen daten für die lichtquellen zu speichern, hatte NV in einem seiner paper mal gesagt, man kann in kleinen dafür dedizierten textures indizieren, dort hat man platz für pos,dir,attenuation,specularpower,specularintensity,color... pro lichtquelle.

MfG
micki

Das Problem gibt es bei DS ja erst gar nicht weil man jede Lichtquelle getrennt rendert.

[micki]

Ich sehe das Limit im ersten Schritt aber eher an der Bandbreite. Da bringen auch unified shader nichts.
dein argument war, dass sich die PS langweilen beim ersten "pass", das würde ja nicht mehr so sein, wenn man alle recheneinheiten fürs VertexTransform benutzen würde. und naja, bandbreite... edram wäre schön, aber unmachbar für 1600*1200 mit AA.


Das Problem entsteht nur wenn man als Rasterisiere noch auf einen Linewalker setzt. nVidia hat sich davon aber schon lange getrennt da wird Cachefreundlich gearbeitet egal wie gross die Dreiecke sind. Bei ATI bin ich mir nicht sicher.
kannst du dazu mal mehr sagen? ich dachte die laufen mit 2x2 blöcken durch.



Das Problem gibt es bei DS ja erst gar nicht weil man jede Lichtquelle getrennt rendert.
wieso sollte man nicht alle lichtquellen auf einmal rendern? ich hatte das bisher immer so gemacht in meinen kleinen tests (natürlich ist das nicht mit VolumeShadows möglich, aber shadowmaps)

MfG
micki

[Demirug]

dein argument war, dass sich die PS langweilen beim ersten "pass", das würde ja nicht mehr so sein, wenn man alle recheneinheiten fürs VertexTransform benutzen würde. und naja, bandbreite... edram wäre schön, aber unmachbar für 1600*1200 mit AA.

Der Vertexshader langweilt sich ja noch mehr.


kannst du dazu mal mehr sagen? ich dachte die laufen mit 2x2 blöcken durch.

Tun sie ja auch. Es geht dabei um die Reihenfolge in welcher die Blöcke in die Pipeline eingespeist werden. Bei einem klasischen Linewalker wird da einfach zeilenweise das Dreieck abgelaufen. nVidia läuft das Dreieck in einem besonderen Muster ab das Cachefreundlich sein soll.

wieso sollte man nicht alle lichtquellen auf einmal rendern? ich hatte das bisher immer so gemacht in meinen kleinen tests (natürlich ist das nicht mit VolumeShadows möglich, aber shadowmaps)

MfG
micki

Wenn du alle Lichtquellen auf einen Schlag renderst ist der Vorteil von DS ja wieder dahin. Dann kann man auch gleich alles in einem Pass machen und spart das Zwischenspeichern. Die Überlegung beim DS ist ja das man den Licht Shader nur auf die Pixel anwendet die davon beleuchtet werden können. Unabhängig davon zu welchem Objekt sie gehöhren. Gerade bei vielen kleinen Lichtquellen kann das durchaus schneller sein. Allerdings sehe ich diesen Vorteil schwinden je besser das Branching im Pixelshader wird.

[micki]

Wenn du alle Lichtquellen auf einen Schlag renderst ist der Vorteil von DS ja wieder dahin. Dann kann man auch gleich alles in einem Pass machen und spart das Zwischenspeichern. Die Überlegung beim DS ist ja das man den Licht Shader nur auf die Pixel anwendet die davon beleuchtet werden können. Unabhängig davon zu welchem Objekt sie gehöhren. Gerade bei vielen kleinen Lichtquellen kann das durchaus schneller sein. Allerdings sehe ich diesen Vorteil schwinden je besser das Branching im Pixelshader wird.
ich sah den vorteil darin, dass jeder pixel nur einmal beleuchtet werden muss, egal wie hoch der overdraw eigentlich wäre und per branching (natürlich erst ab 3.0) ist das pro pixel fix möglich.


aber was man noch machen könnte: im beleuchtungspass das ganze bild in kleinere kacheln aufteilen und ins vertexformat reinschreiben welche lichtquellen benutzt werden (deren daten man aus contans oder textures im pixelshader rausließt/rausindiziert), so würde man nicht pro lichtquelle einmal zeichnen müssen, hätte aber auch kaum verschleiss, weil das culling pro kachel auf der cpu gemacht werden könnte.

MfG
micki

[Demirug]

ich sah den vorteil darin, dass jeder pixel nur einmal beleuchtet werden muss, egal wie hoch der overdraw eigentlich wäre und per branching (natürlich erst ab 3.0) ist das pro pixel fix möglich.

Das kann man einfacher habe. Einfach einen Z-Pass vorschieben.

aber was man noch machen könnte: im beleuchtungspass das ganze bild in kleinere kacheln aufteilen und ins vertexformat reinschreiben welche lichtquellen benutzt werden (deren daten man aus contans oder textures im pixelshader rausließt/rausindiziert), so würde man nicht pro lichtquelle einmal zeichnen müssen, hätte aber auch kaum verschleiss, weil das culling pro kachel auf der cpu gemacht werden könnte.

MfG
micki

Die Idee hat durchaus was für sich aber im Prinzip berechnet man dann mit jedem Shaderdurchlauf immer noch nur eine Lichtquelle. Lediglich die Anzahl der Drawcalls wird reduziert. Dafür muss man dann aber bei dynamischen Lichtquellen die texture mit den Infos in jedem Frame aktualisieren.

Oder habe ich da jetzt was falsch verstanden?

[micki]

Die Idee hat durchaus was für sich aber im Prinzip berechnet man dann mit jedem Shaderdurchlauf immer noch nur eine Lichtquelle. Lediglich die Anzahl der Drawcalls wird reduziert. Dafür muss man dann aber bei dynamischen Lichtquellen die texture mit den Infos in jedem Frame aktualisieren.

Oder habe ich da jetzt was falsch verstanden?
ich denke das hängt vom shader ab, wenn der VShader alle indicies weiterleitet an die pixelshader, können die pixelshader mit diesen indicies durch eine textur iterieren aus der sie lichtquelle für lichtquelle für die beleuchtung eines pixels entnehmen.
wäre an sich nur ein pass für alle lichtquellen (sofern man genug platz in den contantenregistern hat).
alternativ wäre es auch möglich eine textur zu haben, die pro kachel die lichtquellen(informationen) hällt, jede kachel müßte dann nur einen index haben, dabei würde man sich einen lock vom VB sparen, müßte dafür aber die textur pro frame neu locken.

MfG
micki

[deekey777]

Ich geb mal weiter an, dass ich die PCGH 02/07 gekauft habe. X-D
In dieser ist ein Interview mit Dimitry Iassenev, in der steht:
Deren Renderer unterstützt FP16-HDRR bereits seit 2004,
Softshadows, Parallax Mapping und das SM 3.0 wurden erst im Herbst 2006 integriert, "das SM 3.0 wird hauptsächlich zur Verbesserung der Performance genutzt. Das FP32-Rendering und das Vertex-Texturing haben sich als sehr nützlich beim Deferred-Shading erwiesen."
Da war mal ein Artikel in der PCG oder PCGH vor einigen Jahren, in dem stand, dass die Entwickler von STALKER mit SM 2.0 nicht zufrieden wären, da es sie zu stark einschränkt, da seien die Möglichkeiten der FX-Serie besser.
Wäre es vollstellbar, dass der DX9-Renderer mindestens eine Grafikkarte voraussetzt, die SM 2.X beherrscht?
Vertex-Texturing? Da war doch was...
Inwieweit kann VTF bei DS helfen?

Und wenn sich jemand über das fehlende MSAA beschwert, dann liegt es an FP16-HDRR.

[Sonyfreak]

Und wenn sich jemand über das fehlende MSAA beschwert, dann liegt es an FP16-HDRR.Das gilt aber nur für Besitzer von NV40 und G7x Karten oder? Alle anderen Grafikkarten die HDR-R unterstützen, können ja MSAA gleichzeitig einsetzen.

mfg.

Sonyfreak

[Coda]

Deferred Shading hat andere Probleme mit MSAA. Das geht nur unter D3D10 dann.

[Sonyfreak]

Dann würde ich mal meinen, dass mir Stalker erstmal gestohlen bleiben kann. Weil auf ein Spiel ohne AA hab ich ehrlich gesagt keine Lust mehr.

mfg.

Sonyfreak

[Coda]

Die Unreal Engine 3 hat das gleiche Problem btw.

[Sonyfreak]

Das habe ich auch schon gelesen. Ich frage mich nur in wie weit die Entwickler mitdenken. Sowohl Stalker als auch Spiele auf der U3 Engine sind ja eher Titel, die auf High-End Maschinen laufen sollen. Glauben die denn, dass die User die solche Rechner haben gerne auf AA verzichten?

mfg.

Sonyfreak

[LovesuckZ]

Sowohl Stalker als auch Spiele auf der U3 Engine sind ja eher Titel, die auf High-End Maschinen laufen sollen.

Die U3 Engine kommt auch bei Spielen für die Konsolen zum Einsatz. AA spielt hier eine untergeordnete Rolle. Und da wir PC - User nur Portierungen erhalten, müssen wir mit den Fakt leben.

[ShadowXX]

Das habe ich auch schon gelesen. Ich frage mich nur in wie weit die Entwickler mitdenken. Sowohl Stalker als auch Spiele auf der U3 Engine sind ja eher Titel, die auf High-End Maschinen laufen sollen. Glauben die denn, dass die User die solche Rechner haben gerne auf AA verzichten?

mfg.

Sonyfreak
Coda erwähnte die Lösung des Problems bereits: D3D10......zumindest UT3 soll mit D3D10-Pfad AA können.

[deekey777]

Auch wenn in diesem Thread der Eindruck entsteht, das Deferred Rendering sei das pure Böse, so kann man davon ausgehen, dass es Gründe dafür gab, dieses Verfahren in STALKER bzw. für die Engine zu nutzen.
http://www.beyond3d.com/forum/showthread.php?p=921137#post921137
http://gdconf.com/conference/2004.htm

[tokugawa]

Lest einfach die GPU Gems 2. Da wurde das Deferred Lighting/Shading in Stalker schon vor Jahren erklärt.


Das habe ich auch schon gelesen. Ich frage mich nur in wie weit die Entwickler mitdenken. Sowohl Stalker als auch Spiele auf der U3 Engine sind ja eher Titel, die auf High-End Maschinen laufen sollen. Glauben die denn, dass die User die solche Rechner haben gerne auf AA verzichten?


Klar denken die mit. Für MRTs sprechen viele Dinge, und das mit FSAA ist ein Trade-off, der dem einem schmecken kann und dem anderen nicht. Mir sind die Vorteile die über MRTs möglich sind jedenfalls ein (vorerst) fehlendes MSAA wert.

Theoretisch ginge ja immer noch SSAA.

[Sonyfreak]

Klar denken die mit. Für MRTs sprechen viele Dinge, und das mit FSAA ist ein Trade-off, der dem einem schmecken kann und dem anderen nicht. Mir sind die Vorteile die über MRTs möglich sind jedenfalls ein (vorerst) fehlendes MSAA wert.Ich nehme für ein paar möglicherweise nützliche Zusatzfeatures ein im Endeffekt weit schlechteres Bild in Kauf? :confused:

Das ist natürlich Ansichtssache, aber mir wäre AA weit lieber.

Theoretisch ginge ja immer noch SSAA.Ich befürchte nur, dass die Leistung aktueller Grafikkarten in diesen Spielen nicht für Supersampling AA ausreicht.

Ich hoffe, dass man dieses Problem mit einem DX10-Patch beheben kann, weil ich eigentlich nur ungern auf diese beiden Spiele verzichten will. :(

mfg.

Sonyfreak

[ShadowXX]

Ich hoffe, dass man dieses Problem mit einem DX10-Patch beheben kann, weil ich eigentlich nur ungern auf diese beiden Spiele verzichten will. :(

mfg.

Sonyfreak
Wie schon erwähnt....für UT3 ist dies schon zu 100% vorgesehen (aber man benötigt eben DX10)

[Sonyfreak]

Wie schon erwähnt....für UT3 ist dies schon zu 100% vorgesehen (aber man benötigt eben DX10)Es war auch ein 64bit Patch für UT2003 geplant, und der ist auch nie erschienen. Erst für UT2004 kam dann ein solcher Patch heraus. Ich hoffe wie gesagt auch darauf, aber vertrauen kann man darauf nicht.

mfg.

Sonyfreak

[deekey777]

Lest einfach die GPU Gems 2. Da wurde das Deferred Lighting/Shading in Stalker schon vor Jahren erklärt.

Und wenn man keine Lust hat, dieses Taschenbuch zu kaufen: Gibt es diese Präsentation von der GDC auch irgendwo zum Herunterladen?

[Kladderadatsch]

warum ist aa erst ab dx10 möglich?

[Gast]

warum ist aa erst ab dx10 möglich?

Weil DX9-HW und SW nicht in der Lage ist MSAA bei MRTs anzuwenden.

[Gast]

Ich hab da mal ne Dumme Frage: Wie bekommt man bei X-Ray (oder auch beim parallax occlusion mapping) aus einer stinknormalen 2d-Textur einen 3d-Tiefeneffekt? Oder genauer gesagt: wie erkennt das System, dass z.B. SchwarzA Schrift (also einfach 2d-Farbe) ist und SchwarzB einen Schatten/Vertiefung darstellen soll, was natürlich brechnet werden muß. Legt man einfach eine unsichtbare Textur mit Höhenwerten drüber? Oder gibt es codierte Farben, die die Engine erkennt?

[Mr.Magic]

Ich hab da mal ne Dumme Frage: Wie bekommt man bei X-Ray (oder auch beim parallax occlusion mapping) aus einer stinknormalen 2d-Textur einen 3d-Tiefeneffekt? Oder genauer gesagt: wie erkennt das System, dass z.B. SchwarzA Schrift (also einfach 2d-Farbe) ist und SchwarzB einen Schatten/Vertiefung darstellen soll, was natürlich brechnet werden muß. Legt man einfach eine unsichtbare Textur mit Höhenwerten drüber? Oder gibt es codierte Farben, die die Engine erkennt?

Das ist wie es schon beim Bumpmapping war. Für die Höhen und Tiefen ist eine zweite (Graustufen-)Textur zuständig.

[Gast]

Legt man einfach eine unsichtbare Textur mit Höhenwerten drüber?
Ja so könnte man es ausdrücken.
Texturen sind heutzutage nur noch Speicherbereiche, die beliebige Informationen enthalten können, die Shader dann nutzen.

[Gast]

Theoretisch ginge ja immer noch SSAA.

Geht leider nicht, zumindest nicht mit einer 880GTS @ Vista mit FW101.41 + nHancer und 2x2 Supersampling im Stalker Profil aktiviert.
Da bleibt das Bild, im höchsten Beleuchtungsmodus leer (wie wenn man MSAA forciert).

[Gast]

Thx für die Erklärung Mr.Magic und Gast!

[Gast]

Weil DX9-HW und SW nicht in der Lage ist MSAA bei MRTs anzuwenden.
wofür steht mrt?

[Spasstiger]

wofür steht mrt?
Multiple Render Targets.

Siehe hierzu auch:
http://msdn2.microsoft.com/en-us/library/ms791834.aspx
No antialiasing of a multiple render target group is supported.

[RaumKraehe]

Beim Spielen von Stalker ist mir aufgefallen das die Engine irgend wie ohne zu murren mit multiplen dynamischen Lichtquellen umgehen kann und die erste Engine auf meinem Rechner ist die in absolut erstaunlicher Geschwindigkeit weiche Schatten rendert. Dabei ist es wiederum scheinbar vollkommen egal wieviele Lichtquelle mit im Spiel sind.

Besonders gut kommen diese Effekte in Morgengrauen oder in der Abenddämmerung + Gewitter und Helmlampe rüber. Das ist ja der Hammer. Lichtquellen werden sogar in echtzeit multipliziert. Also wenn 3 Lampen auf einen Punkt leuchten wird der heller als wenn nur eine Lampe auf denselben Punkt leuchtet. Schatten die durch das Sonnenlicht generiert werden können mit einer Lampe auch wieder "aufgehoben" werden.

Ich finde das recht faszinierend. Kann mir jemand irgend wie Laienhaft erklären wie die das hinbekommen haben?

thx.

[Coda]

Also wenn 3 Lampen auf einen Punkt leuchten wird der heller als wenn nur eine Lampe auf denselben Punkt leuchtet.
Das ist in allen Spielen die dynamisches Licht benützen auch so.

Schatten die durch das Sonnenlicht generiert werden können mit einer Lampe auch wieder "aufgehoben" werden.
Dito.

Ich finde das recht faszinierend. Kann mir jemand irgend wie Laienhaft erklären wie die das hinbekommen haben?
Was ist daran so faszinierend? Das war schon in Doom 3 so ;)

[RaumKraehe]

Das ist in allen Spielen die dynamisches Licht benützen auch so.


Dito.


Was ist daran so faszinierend? Das war schon in Doom 3 so ;)

Doom 3 habe ich nicht intensiv gespielt und dort ist mir das def. auch nicht so aufgefallen. Zumindest nicht so gut wie in Stalker. :( Wobei ich die Aussage "das ist bei allen Spielen so" stark anzweifle. Was ist wenn nur eine dynamische Lichtquelle pro Szene unterstützt wird. Dann können die sich ja auch nicht wirklich multiplizieren.

Da wäre auch die Frage wie Doom 3 mit mehr als 4-5 dynamischen Lichtern performt und warum dann Doom diese abartig harten und unrealistischen Schatten hat. Wobei auch hier noch zu überlegen gilt in wie weit es doch schon einen Unterschied macht ob ich einem kleinem Schlauchlevel mit einer Handvoll Objekte dynamisch Lichter erzeuge oder ob das in einer doch deutlich komplexeren Umgebung mache.

Faszinierend finde ich halt die Performance mit der das ganze geboten wird, besonders wenn man noch die realtiv weichen Schatten dazu nimmt. Jedes andere Game mit alternativen Engines schafft das auf meinem Rechner nicht.

In Stalker kann ich die Auswirkungen von Lichtern in Häusern in der Umwelt beobachten, wenn es dann nachts noch Blitzt wir der Schatten wirklich korrekt in jedem Haus gezeichnet. Ja jedes doofe Loch im Dach läßt auch Licht durch. So habe ich das noch nicht gesehen. aber du kannst mir ja sicher noch eine Hand voll Spiele nennen in denen ich gleichwertige Effekte sehe.

Warum kackt dann eigentlich immer noch irgend einer der 3dmurkse bei mir ab wenn er 8 dynamisch Lichter zeichen soll aber Stalker steckt das ohne weiters weg?

Und danke für deine Antwort die ja wirklich sehr kompetent war und mir durchaus geholfen hat. Nen Link zum Thema hätte es ja auch getan. :(

[Spasstiger]

Ich finde das recht faszinierend. Kann mir jemand irgend wie Laienhaft erklären wie die das hinbekommen haben?
Indem sie einen Deferred-Renderer verwendet haben. ;)

Beim Stencil-Shadowing wie in Doom 3 oder Fear wird für jedes Dreieck, jedes Pixel/Fragment und jede Lichtquelle bestimmt, ob ein Bildpunkt im Schatten liegt oder nicht. Auch wenn eine Lichtquelle offensichtlich einen großen Bildbereich gar nicht erreichen kann, wird jedes Pixel und jedes Dreieck für diese Lichtquelle überprüft.

Mit Deferred-Rendering wird die Beleuchtungsberechnung so lange herausgezögert, bis die gesamte sichtbare Geometrie in einem Bild bekannt ist. Die gesammelten Bildinformationen müssen für jedes Pixel in einen Buffer mit Gleitkomma-Präzision abgelegt werden. So wird viel Rechenarbeit gespart, da nicht mehr jedes Dreieck und jede Lichtquelle für die Beleuchtungsberechnungen abgearbeitet werden muss. D.h. bei komplexen Szenen und vielen Lichtquellen ist Deferred-Rendering wesentlich effizienter als Stencil-Shadowing.

Stencil-Shadowing braucht dafür wesentlich weniger Bandbreite und Speicher, es ist keine Pixelshader-Fähigkeit erforderlich und es arbeitet wunderbar mit MSAA zusammen (Deferred-Rendering funktioniert erst ab D3D10 mit MSAA).

P.S.: Stalker schluckt in 1600x1200 glatt 600 MB Grafikspeicher:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5350314#post5350314.
Das ist neben dem fehlenden MSAA der Preis für das Deferred-Rendering. Ein nicht zu vernachlässigender Teil des Grafikspeichers dürfte allerdings auch für die Höheninformationen der Texturen (Heightmaps) draufgehen.

[RaumKraehe]

Indem sie einen Deferred-Renderer verwendet haben. ;)

Beim Stencil-Shadowing wie in Doom 3 oder Fear wird für jedes Dreieck, jedes Pixel/Fragment und jede Lichtquelle bestimmt, ob ein Bildpunkt im Schatten liegt oder nicht. Auch wenn eine Lichtquelle offensichtlich einen großen Bildbereich gar nicht erreichen kann, wird jedes Pixel und jedes Dreieck für diese Lichtquelle überprüft.

Mit Deferred-Rendering wird die Beleuchtungsberechnung so lange herausgezögert, bis die gesamte sichtbare Geometrie in einem Bild bekannt ist. Die gesammelten Bildinformationen müssen für jedes Pixel in einen Buffer mit Gleitkomma-Präzision abgelegt werden. So wird viel Rechenarbeit gespart, da nicht mehr jedes Dreieck und jede Lichtquelle für die Beleuchtungsberechnungen abgearbeitet werden muss. D.h. bei komplexen Szenen und vielen Lichtquellen ist Deferred-Rendering wesentlich effizienter als Stencil-Shadowing.

Stencil-Shadowing braucht dafür wesentlich weniger Bandbreite und Speicher, es ist keine Pixelshader-Fähigkeit erforderlich und es arbeitet wunderbar mit MSAA zusammen (Deferred-Rendering funktioniert erst ab D3D10 mit MSAA).

P.S.: Stalker schluckt in 1600x1200 glatt 600 MB Grafikspeicher:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5350314#post5350314.
Das ist neben dem fehlenden MSAA der Preis für das Deferred-Rendering. Ein nicht zu vernachlässigender Teil des Grafikspeichers dürfte allerdings auch für die Höheninformationen der Texturen (Heightmaps) draufgehen.

Im Internet habe ich noch ein paar infos gefunden. Sprechen wir hier vom Deferred-Rendering oder vom Deferred Shading? Das sollen zwei unterschiedliche Dinge sein, da die heutigen Mainstream Grakas wohl nicht wirklich deferred Redering können?

[deekey777]

Im Internet habe ich noch ein paar infos gefunden. Sprechen wir hier vom Deferred-Rendering oder vom Deferred Shading? Das sollen zwei unterschiedliche Dinge sein, da die heutigen Mainstream Grakas wohl nicht wirklich deferred Redering können?
Deferred Rendering ist ein Oberbegriff wie Pipeline.
Deferred Shading oder Deferred Lighting geben an, welche Stufe der Pipeline "deferred" ist.

Dito.


Was ist daran so faszinierend? Das war schon in Doom 3 so ;)
Es ist schon ein Unterschied, ob man die Taschenlampe in Doom 3 nutzt oder in Stalker. Macht man die Taschenlampe in einer dunklen Ecke an (D3), bringt sie kaum was. Ziemlich gelungen ist die Taschenlampe in HL2: Ep. 1. :)
Selbst mit dem Nachtsichtgerät bringt die Taschenlampe einiges.
-------------------------------------------------------------
Was an Doom 3 so besonders ist, dass die ganze Beleuchtung bzw. Schattendarstellung in Echtzeit berechnet wird, es gibt beinahe keine vorgefertigten Schattenflächen. Das ist, was Doom 3 so einzigartig macht. Dass die Schatten so hart aussehen, liegt es daraf, dass wir FPS sehen wollen und nicht SPF. ;)

[Coda]

Doom 3 habe ich nicht intensiv gespielt und dort ist mir das def. auch nicht so aufgefallen. Zumindest nicht so gut wie in Stalker. :( Wobei ich die Aussage "das ist bei allen Spielen so" stark anzweifle. Was ist wenn nur eine dynamische Lichtquelle pro Szene unterstützt wird.
Mir ist kein Spiel bekannt wo das so wäre. Und Licht multipliziert sich nicht sondern addiert sich.

Es ist schon ein Unterschied, ob man die Taschenlampe in Doom 3 nutzt oder in Stalker.
Ist bloß Artwork. Da gibt's keine prinzipiellen Unterschied.

Was an Doom 3 so besonders ist, dass die ganze Beleuchtung bzw. Schattendarstellung in Echtzeit berechnet wird, es gibt beinahe keine vorgefertigten Schattenflächen.
Keine.

Das ist, was Doom 3 so einzigartig macht. Dass die Schatten so hart aussehen, liegt es daraf, dass wir FPS sehen wollen und nicht SPF. ;)
Stencil-Schatten sind halt nicht der Weisheits letzter Schluss.

[RaumKraehe]

Mir ist kein Spiel bekannt wo das so wäre. Und Licht multipliziert sich nicht sondern addiert sich.


Ist bloß Artwork. Da gibt's keine prinzipiellen Unterschied.


Keine.


Stencil-Schatten sind halt nicht der Weisheits letzter Schluss.

Es wäre schön wenn du, da du ja Wissen zu haben scheinst, das etwas näher ausführen könntest. Wenn du keinen Bock dazu hast dann lass es doch einfach. Deine Postings haben mir im Gegensatz zu denen von DK777 so gar nicht geholfen. Man hätte sie sich sozusagen auch sparen können.

[MrMostar]

Eine Frage: wäre bei DF AA möglich durch das rendering in ein höher aufgelöstes rendertarget, welches dann auf die Zielauflösung herunterskaliert wird? Könnte dies nachträglich erzwungen werden?

Gibt es eine Tabelle mit dem Speicherbedarf zu Auflösung, ist der Speicherbearf linear(+Offset für Texturen)?

800x600___150MB?
1024x768__?
1280x1024_?
1600x1200_600MB
2048x1536_?

edit: habe gerade im anderen Thread gesehen, dass die 600 MB immer benötigt werden unabhängig von der Auflösung

zu Addition und Multiplikation:
-Verwendung Addition bei Nachbildung von Überlagerten Lichtquellen
-Verwendung von Multiplikation bei Nachbildung von z.B. übereinandergelegten Folien/Dias

[Kladderadatsch]

- Das Verfahren ist nicht kompatibel mit MSAA
in den stalker-threads kursiert ja das gerücht, dass das an dx9 hinge, bzw. mit dx10 ginge:confused:

[deekey777]

in den stalker-threads kreist ja das gerücht, dass das an dx9 hinge, bzw. mit dx10 ginge:confused:
Ist es auch so: Es ist eine Restriktion seitens DX9, dass kein MSAA bei MRTs erlaubt ist. Mit D3D10(.1?) wird diese aufgehoben.
STALKER hat dagegen sein eigenes Verfahren, um die Treppenbildung visuell zu verstecken.

[Mastermind]

Ist es auch so: Es ist eine Restriktion seitens DX9, dass kein MSAA bei MRTs erlaubt ist. Mit D3D10(.1?) wird diese aufgehoben.
STALKER hat dagegen sein eigenes Verfahren, um die Treppenbildung visuell zu verstecken.
Aber G80 und Vista sind doch schon draußen und trotzdem habe ich noch keine entsprechenden Screens gesehen. Haben die etwa den D3D10-Renderer noch nicht eingebaut?

[Coda]

Was heißt hier "in etwa"? Das ist sehr viel Arbeit, und nein es gibt ihn noch nicht - falls er überhaupt kommt.

[Mastermind]

Was heißt hier "in etwa"? Das ist sehr viel Arbeit, und nein es gibt ihn noch nicht - falls er überhaupt kommt.
Es ist nun nicht so, als hätten die sich keine Zeit genommen. :wink:

Dass es sehr viel Arbeit wäre hätte ich allerdings nicht gedacht. Mein Gedanke war, dass sich das meiste im Prinzip übernehmen ließe und dank D3D10 "automatisch" MSAA ermöglicht wird. So wie man jetzt eben ohne Deferred Rendering auch nichts extra tun muss, um MSAA zu ermöglichen.

[Coda]

Es ist nun nicht so, als hätten die sich keine Zeit genommen. :wink:
D3D10-Entwicklung ist erst möglich seit es G80-Karten gibt.

Dass es sehr viel Arbeit wäre hätte ich allerdings nicht gedacht. Mein Gedanke war, dass sich das meiste im Prinzip übernehmen ließe und dank D3D10 "automatisch" MSAA ermöglicht wird. So wie man jetzt eben ohne Deferred Rendering auch nichts extra tun muss, um MSAA zu ermöglichen.
Das ist beides falsch. D3D10 ist ziemlich verschieden zu D3D9 und automatisch geht da überhaupt nichts.

[=Floi=]

naja
das lasse ich nicht gelten denn bestimmte firmen werden sicherlich schon 3monate vor release des G80 karten im rechner gehabt haben auch ist die unterstützung seitens NV gegeben und die standards sind auch definiert

[Kai]

Keine.


Das ist leider falsch. Auch in Doom3 gibt es "vorgefertigte" Schattenflächen. Zwar nicht per Lightmap, aber es gibt genügend Beispiele die mir jetzt so direkt einfallen - und ich habe lange für Doom3 Maps gebastelt. Prominentestes Beispiel sind z.B. die Ventilator oder Gitterschatten.

[Piffan]

naja
das lasse ich nicht gelten denn bestimmte firmen werden sicherlich schon 3monate vor release des G80 karten im rechner gehabt haben auch ist die unterstützung seitens NV gegeben und die standards sind auch definiert

In drei Monaten kann man auch nicht mehr viel machen.

Ich habe keine Ahnung, aber ein Gefühl sagt mir, dass bestimmte Dinge von Anfang an "drin" sein müssen. Nachträgliches Ummodeln ist meist zeitraubender als Hänschen sich so vorstellt. :tongue:

Wenn man in Stalker so durch die Innenlevels zittert, dann hat man ne Grafik wie im 3d- Murks, aber halbwegs performant. Hätte nie gedacht, dass die Spiele so schnell Anschluss finden würden. :cool:

Doom war ja schon nix für Hasenherzen, aber was Stalker sich da leistet, ist ein Fall für den Arzt...Endlich sieht man, wozu die Pickelshaderei und Lichthuberei nütze ist.

[Spasstiger]

Dass es sehr viel Arbeit wäre hätte ich allerdings nicht gedacht. Mein Gedanke war, dass sich das meiste im Prinzip übernehmen ließe und dank D3D10 "automatisch" MSAA ermöglicht wird. So wie man jetzt eben ohne Deferred Rendering auch nichts extra tun muss, um MSAA zu ermöglichen.
Von Direct3D 9 auf Direct3D 10 umzusatten, bedeutet etwas genausoviel Arbeit wie einen OpenGL-Renderer zu erstellen. Soweit ich das gelesen habe, ist für Stalker kein Direct3D-10-Patch in Entwicklung. Ich sehe auch keinen Grund, warum die Entwickler jetzt noch dahingehend investieren sollten, nachdem das Spiel bereits draußen ist. Ich denke nicht, dass irgendjemand die X-Ray-Engine lizensieren wird. Und wenn, dann müsste sie bei der gegenwärtigen Konkurrenz (z.B. Unreal Engine 3, Cryengine 2) vergleichsweise günstig sein, so dass sich die nachträgliche Programmierung des D3D10-Renderers nicht lohnen würde.

Bei der Unreal-Engine-3 ist es was anderes, die wird von dutzenden Spieleentwicklern lizensiert und auch noch in mehreren Jahren verwendet werden. Da ist ein D3D10-Renderer absolut sinnvoll. UT2007 wird im DX10-Renderpfad mit Sicherheit Deferred-Shadowing + MSAA unterstützen.

Ich bin ja mal gespannt, ob im nächsten 3DMark Ansätze des Deferred-Renderings auftauchen werden. Scheint auf jeden Fall dem Geist der Zeit zu entsprechen. Die Cryengine 2 zeigt aber, dass es auch ohne geht.

[deekey777]

naja
das lasse ich nicht gelten denn bestimmte firmen werden sicherlich schon 3monate vor release des G80 karten im rechner gehabt haben auch ist die unterstützung seitens NV gegeben und die standards sind auch definiert
Lässt du aber das gelten: Wer soll die Kosten übernehmen, um einen D3D10-Renderer zu entwickeln?
Die Aussage eines GSC-Offiziellen: Es ist ungewiss.
Ungewiss ist für mich gleich "kommt nicht".
GSC ist kein so großer Entwickler wie VALVe oder auch Crytek. Für sie zählt der kleinste gemeinsame Nenner, und dieser ist aktuell D3D9.0c. Alles andere ist Resourcenverschwendung.

Weiter sagt der Typ: "Selbst wenn wir den Programcode von STALKER nur direkt portieren würden, ohne die neuen DX10-Features zu unterstützen, würde das einen Leistungsvorteil von 10 Prozent bringen." (PCGH 02/2007, Seite 81)

Was meint er damit? Den Treiberoverhead kann er wohl nicht meinen?

[Expandable]

Das ist wie es schon beim Bumpmapping war. Für die Höhen und Tiefen ist eine zweite (Graustufen-)Textur zuständig.

Bzw. eine Normalmap, die ist meistens eher lila-blau ;) Du meintest wohl eine Heightmap, wobei man diese natürlich in eine Normalmap umrechnen kann.

Beim Stencil-Shadowing wie in Doom 3 oder Fear wird für jedes Dreieck, jedes Pixel/Fragment und jede Lichtquelle bestimmt, ob ein Bildpunkt im Schatten liegt oder nicht. Auch wenn eine Lichtquelle offensichtlich einen großen Bildbereich gar nicht erreichen kann, wird jedes Pixel und jedes Dreieck für diese Lichtquelle überprüft.

Wohl kaum. Es gibt verschiedene Möglichkeiten zur Optimierung. Ein Beispiel wäre ein Scissor-Test. Ein Scissor-Test ist aber auch eine extrem gute Optimierung bei einem Deferred Renderer.

D.h. bei komplexen Szenen und vielen Lichtquellen ist Deferred-Rendering wesentlich effizienter als Stencil-Shadowing.

Aber Deferred-Rendering hat nicht nur was mit den Schatten zu tun. Du meinst wohl Deferred-Rendering im Gegensatz zu einem Multipass-Verfahren. Prinzipiell sind auch bei einem Deferred Renderer Stencil Shadows möglich.

Keine.

Falsch. Wenn Du Dir mal die Map-Files von Doom 3 ansiehst wirst Du sehen, dass es in Doom 3 sehr wohl vorberechnete Shadow-Volumes gibt. Und zwar für statische Geometrie, deren Schatten sich nicht ändern. Klar, dass man das nicht völlig unnötigerweise dynamisch berechnet. Es gibt allerdings keine Lightmaps mehr, das ist richtig, falls Du das meintest (weiß man bei Deinen Ultrakurzantworten ja nie so genau...)

[deekey777]

Wohl kaum. Es gibt verschiedene Möglichkeiten zur Optimierung. Ein Beispiel wäre ein Scissor-Test. Ein Scissor-Test ist aber auch eine extrem gute Optimierung bei einem Deferred Renderer.
Ein Scissor-Test?


Aber Deferred-Rendering hat nicht nur was mit den Schatten zu tun. Du meinst wohl Deferred-Rendering im Gegensatz zu einem Multipass-Verfahren. Prinzipiell sind auch bei einem Deferred Renderer Stencil Shadows möglich.
Da musst du auch den ersten Absatz dazu "addieren", dann wird der Zusammenhang deutlich. So wäre es besser:
Beim Stencil-Shadowing wie in Doom 3 oder Fear wird für jedes Dreieck, jedes Pixel/Fragment und jede Lichtquelle bestimmt, ob ein Bildpunkt im Schatten liegt oder nicht. Auch wenn eine Lichtquelle offensichtlich einen großen Bildbereich gar nicht erreichen kann, wird jedes Pixel und jedes Dreieck für diese Lichtquelle überprüft. Mit Deferred-Rendering wird die Beleuchtungsberechnung so lange herausgezögert, bis die gesamte sichtbare Geometrie in einem Bild bekannt ist. Die gesammelten Bildinformationen müssen für jedes Pixel in einen Buffer mit Gleitkomma-Präzision abgelegt werden. So wird viel Rechenarbeit gespart, da nicht mehr jedes Dreieck und jede Lichtquelle für die Beleuchtungsberechnungen abgearbeitet werden muss. D.h. bei komplexen Szenen und vielen Lichtquellen ist Deferred-Rendering wesentlich effizienter als Stencil-Shadowing.
Ich glaube, anstelle des Stencil-Shadowing wäre "verwendete Schattentechnik" oder "Schattenberechnung" besser.

Was ist Deferred Shadowing schonwieder?

[Expandable]

Ein Scissor-Test?

Wird z.B. gerade von Doom 3 exzessiv verwendet. Damit sagst Du der Grafikkarte im wesentlichen, dass sich potenziell nur die Fragments in einem gewissen (rechteckigen) Ausschnitt des Framebuffers ändern. Beispielsweise: Nur die rechte Hälfte des Bildschirms wird von einer Lichtquelle beeinflusst (kann man ja einfach ausrechnen) bzw. ist durch das aktuelle Portal sichtbar. Die Geometrie muss natürlich trotzdem komplett berechnet werden, allerdings werden nur die Fragmente im rechten Bildschirm-Teil berechnet, was die Fragment-Shader-Last halbiert (der linke Teil des Bildschirms wird gar nicht erst angetastet). Mit diesem Verfahren kann man sowohl einen Deferred Renderer als auch eine Multipass-Lösung extrem beschleunigen, wenn man für "kleine" Lichter so einen Scissor-Test einführt.

Das funktioniert natürlich nur, wenn man jedes Licht einzeln berechnet oder die Lichter irgendwie so sortiert nach Einflussgröße, dass man noch einen Scissor-Test machen kann. Falls man in jedem Bildschirmeck ein kleines Licht hat und alle 4 in einem Pass berechnen will, muss man leider auf einen Scissor-Test verzichten.


Ich glaube, anstelle des Stencil-Shadowing wäre "verwendete Schattentechnik" oder "Schattenberechnung" besser.

Hmm... ich bin mir nicht sicher, ob wir das gleiche meinen: Ein Deferred Renderer kann sowohl mit Stencil Schatten als auch mit Shadow Maps genau so wie ein Multipass Renderer arbeiten. Deswegen: Deferred Lighting ist im Gegensatz zu einer Multipass-Lösung zu sehen, nicht im Gegensatz zu einer der möglichen Schattenberechnungstechniken.

[Gast]

Auch wenn eine Lichtquelle offensichtlich einen großen Bildbereich gar nicht erreichen kann, wird jedes Pixel und jedes Dreieck für diese Lichtquelle überprüft.



sollte nicht genau das durch dieses hyper-shadow oder ultra-shadow, oder wie auch immer es genannt wurde verhindert werden?

[Spasstiger]

sollte nicht genau das durch dieses hyper-shadow oder ultra-shadow, oder wie auch immer es genannt wurde verhindert werden?
Ja, es gibt schon Techniken, die die Effizienz beim Single-/Multipass-Rendering etwas steigern, mir gings auch nur ums Prinzip. Ich kenn mich mit den Implementierungsdetails und den mathematischen Hintergründen ja auch nicht aus.

[Gast]

Prominentestes Beispiel sind z.B. die Ventilator oder Gitterschatten.


geht ja nicht anders, shadow-volumes sehen ja nur die geometrie, ein gitter ist aber eine einfache alpha-textur.

[Spasstiger]

geht ja nicht anders, shadow-volumes sehen ja nur die geometrie, ein gitter ist aber eine einfache alpha-textur.
Richtig. Klar hätte man die Gitter auch ausmodellieren können, aber das kostet mehr Rechenleistung ohne optische Vorteile. Die vorgefertigten Schatten sind zudem auch weich und sorgern für eine stellenweise etwas hübschere Optik.

[Mr. Lolman]

ein gitter ist aber eine einfache alpha-textur.

Wo wir bei nem weiterem Vorteil von Deferred Shadowing wären...

[Expandable]

Wo wir bei nem weiterem Vorteil von Deferred Shadowing wären...

Wobei man mit transparenten Objekten beim Deferred Rendering große Probleme bekommt...

[Gast]

Wobei man mit transparenten Objekten beim Deferred Rendering große Probleme bekommt...

nur halbtransparente (alphablending) objekte haben probleme, vollständig transparente (alpha-testing) nicht, sonst hätte stalker ein gewaltiges problem, die gesamte vegetation besteht schließlich aus transparenten objekten ;)

[deekey777]

nur halbtransparente (alphablending) objekte haben probleme, vollständig transparente (alpha-testing) nicht, sonst hätte stalker ein gewaltiges problem, die gesamte vegetation besteht schließlich aus transparenten objekten ;)
Ich bin mal so frech und kopiere etwas rein:
Cons of Deferred Shading 1/2

Can be bandwidth/memory intensive
On some platforms, attributes must be written once, and read back many times.
Multiple attribute buffers at high framebuffer resolutions gobble memory
Very high hardware requirements
Especially at typical PC game resolutions, or with FSAA

Cons of Deferred Shading 2/2

Per-material shaders or multiple BRDF’s are impractical on some platforms
On some platforms/shader models it’s infeasible to use multiple pixel shader programs to shade the scene
Fully texture driven shaders take on more importance
Alpha blending
“Real” alpha blending (over operator [6]) is difficult
To do it “correctly”, multiple pixels must be independently lit and shaded before applying the over operator
Excuse: Alpha blending is a total hack anyway
We’ll show some hacks that can be decent alternatives on some platforms

Aus: pritchard_matt.ppt (http://www.gdconf.com/conference/archives/2004/pritchard_matt.ppt)

[Armaq]

Excuse: Alpha blending is a total hack anyway

Der ist geil. :D

Gott sei Dank, gibts ja Entwicklung in vielerlei Hinsicht und von X-Ray bin ich für jede Art von RPG/FPS überzeugt. Denn die Beleuchtung bringt einfach viel mehr als AA.
Wobei ich Company of Heroes für RTS eher bevorzuge.

[Gast]

Ich bin mal so frech und kopiere etwas rein:

Aus: pritchard_matt.ppt (http://www.gdconf.com/conference/archives/2004/pritchard_matt.ppt)

und, wo widerspricht das meiner aussage? oder war das als bestätigung gemeint?

[deekey777]

und, wo widerspricht das meiner aussage? oder war das als bestätigung gemeint?
Bestätigung. :)
Excuse: Alpha blending is a total hack anyway

Der ist geil. :D

Gott sei Dank, gibts ja Entwicklung in vielerlei Hinsicht und von X-Ray bin ich für jede Art von RPG/FPS überzeugt. Denn die Beleuchtung bringt einfach viel mehr als AA.
Wobei ich Company of Heroes für RTS eher bevorzuge.
Es gibt da auch eine andere Engine, die dafür bekannt ist, riesige Areale darstellen zu können, ohne irgendwelche Nachladeruckler. Fängt mit C an und endet mit ryEngine. ;)
Aber es ist nicht nur die Grafik, was STALKER ausmacht, sondern die NPCs.

[Gast]

Excuse: Alpha blending is a total hack anyway



nebenbei stellt stalker sogar richtig gutes alphablending dar, die ganzen zäunte sind im gegensatz zu HL2 nämlich keine AT-texturen sondern werden schön geblendet und flimmern deshalb nicht.

[K4mPFwUr$t]

und die NPCs können schlau als auch dumm sein ;)
da könnte ich locker ein paar beispiele bringen.

nur was bringt einem schöne grafik und eine halbwegs brauchbare KI wenn die performance so unterirdisch ist und von stuttering verseucht ist, so dass man schnell den spaß am spiel verliert. musste ich heute schmerzlich feststellen.

[Armaq]

Bestätigung. :)

Es gibt da auch eine andere Engine, die dafür bekannt ist, riesige Areale darstellen zu können, ohne irgendwelche Nachladeruckler. Fängt mit C an und endet mit ryEngine. ;)
Aber es ist nicht nur die Grafik, was STALKER ausmacht, sondern die NPCs.
Geb ich dir recht, aber nicht bei der Beleuchtung.
Die KI hat ihre Stärken, aber sie wirkt doch irgendwie begrenzt auf bestimmte Gebiete.

[Gast]

nur was bringt einem schöne grafik und eine halbwegs brauchbare KI wenn die performance so unterirdisch ist und von stuttering verseucht ist, so dass man schnell den spaß am spiel verliert. musste ich heute schmerzlich feststellen.

bei mir ist die performance sehr gut, es gibt nur manchmal kurze nachladeruckler, diese sind aber sehr selten und bei dem riesen terrain auch kein wunder.

[Hackschmatz]

sers
es werden immer neue engines rauskommen und es waren alle revolutionär am anfang ihrer laufbahn denk mal nur an die unreal engine. deswegen darfs du auch nicht die stalker engine so besonders bewerten. klar es ist etwas neues aber ein jahr darauf kommt ne neue engine raus die es noch mehr drauf hat

[Armaq]

sers
es werden immer neue engines rauskommen und es waren alle revolutionär am anfang ihrer laufbahn denk mal nur an die unreal engine. deswegen darfs du auch nicht die stalker engine so besonders bewerten. klar es ist etwas neues aber ein jahr darauf kommt ne neue engine raus die es noch mehr drauf hat
Das stimmt so nicht. Unreal war eher revolutionär als evolutionär. Genauso FarCry, HalfLife, Quake3, Warcraft 3 (teilweise), Deus Ex uvm. Manche stellen in bestimmten Punkten einfach Leuchttürme auf.

[Piffan]

Ich habe jetzt nicht den ganzen Kram hier gelesen. Der Anfang war mir zu technisch und dogmatisch....

Mal mein Eindruck als spielender Laie: Ja, die Engine ist momtan das Maß der Dinge.

Weil:

Reich detailiert, keine Polygonarmut, große Sichtweite, gut ausstaffiert mit tollen Texturen.

UND tolle Beleuchtung. So was hätte man zu Zeiten von Doom III nie und nimmer für möglich gehalten.

Bisher war es doch immer so: Entweder tolle Schatten- und Lichterspiele und dann Schmalkost beim Rest, siehe auch FEAR.

Oder extrem detailliert und dann sparen beim Lichtmodell, siehe Farcry oder Oblivion.....

Die X-Ray Engine bringt endlich mal alles unter einen Hut, was den Spieler verzückt. Der Mangel an AA stört mich übrigens nicht, irgendwie sind die Kanten retuschiert, mag am Bloom liegen, k. A.

Die Performance ist fürs Gebotene extremst sauber, ich fahre mit allen Optionen volles Rohr und habe noch nicht mal High- End: Einen San Diego @2,6 Ghz (Oc) und eine AGP- X1950XT....Die einzigen Mucken, die mich bis eben schmerzten waren die Ruckler beim Laufen und das Abbrechen der FPS bei Blitzen. So stimmungsvoll die Gewitter bei Stalker mit allen aktivierten Optionen auch sein mögen, zum Spielen war das nix bei Einbrüchen bis runter auf 3-5 FPS. Die Ruckelei habe ich mit dem Swicht "-noprefetch" drastisch reduzieren können und die Einbrüche bei den Blitzen dadurch, dass ich einfach die Taschenlampe ständig leuchten lasse. Krass und für mich rätselhaft, aber es funzt. :tongue:

Eine tiefe Verbeugung vor den Gurus, die dieses Kabinettstück an Programmierkunst vollbracht haben. Die Labertaschen von id und epic sind dagegen Schaumschläger. :biggrin:

Edit: Stalker ist endlich mal wieder ein Produkt, dass mich zum Aufrüsten meiner alten Hardware animiert hat und ich bereue es auf keinen Fall. Wer hätte das gedacht, dass es ein solch feines Spiel noch mal für den PC- Zocker geben wird, das mit der Hardware in einem derartigen Umfange skalieren würde und unter allen Bedinungen überzeugt. Wer es flimmerfrei haben muss, kann ja auf die famose Lichtengine verzichten und bekommt ein immer noch sehr ansehnliches vom Content her überzeugendes Spiel geboten, das ausgezeichnet performt. Der Vergleich mancher Tester, die es auf dem Niveau von HL2 sehen, ist nur lächerlich......

[Piffan]

Das stimmt so nicht. Unreal war eher revolutionär als evolutionär. Genauso FarCry, HalfLife, Quake3, Warcraft 3 (teilweise), Deus Ex uvm. Manche stellen in bestimmten Punkten einfach Leuchttürme auf.

Sehe ich ähnlich. Es spielt auch das Timing eine große Rolle. Was nützt ein Superhirn mit Visionen, wenn die Leistung der Hardware einfach noch nicht da ist. Beispiel DoomIII: Es verschimmelte quasi in den Startlöchern, weil einfach nicht genug Power da war. Als es dann endlich mit der R300 bzw. dem Pendant von Nvidia gut performte, hat es keinen mehr soo vom Hocker gehauen. Weil andere Entwickler mit herkömmlichen Mitteln ebenfalls sehr eindruckvolle Bilder produzieren konnten, siehe Max Payne mit seinen Fakes oder UT2003 mit seinen Pseudo- Strukturen.....

Die Xray- Engine kommt genau richtig. Der Clou: ursprünglich war es ja mal für ältere Hardware angepeilt und als Bonus läufts jetzt in HighEnd oder in Mainstream optisch und performance- technisch tadellos. HL2 war diesbezüglich eher enttäuschend: Toller Gesamteindruck, dann aber an allen Ecken Murkserei im Hinblick auf schwächere Systeme.......

[deekey777]

http://www.gamedev.ru/community/gamedev_lecture/articles/r_e_n_de_r
Wie man unschwer erkennen kann, ist dieser Artikel in einer komischen slawischen Sprache und zwar in Russisch. Ansich ist es eine Art Vorlesung, wo Zeux den in Stalker verwendeten Renderer erklärt. Da das Ganze in Russisch (bis auf einige englische Begriffe), habe ich noch weniger Ahnung, wovon da geredet wird.
Aber eins nach dem anderen:
Stalker nutzt Deferred Shading. Was DS ist, hat Demirug in wenigen Worten erklärt: Man versucht die Beleuchtung so lange, wie es geht, hinauszuzögern.
Zunächst wird ein Geometry-Buffer (G-Buffer) erstellt. Das ist eine oder mehrere Texturen, die die Größe des Bildschirms haben. STALKERs G-Buffer besteht aus drei Texturen (RGBA16-Texturen). Diese Texturen enthalten die nötigen Infos, um die Szene dann von einer Lichtquelle zu beleuchten, mit Schatten zu versehen...
Das Alpha-Blending stellt ein riesiges Problem für DS dar: Es ist schlichtweg unmöglich. Für halbtransparente Objekte gibt es einen eigenen Pass - nach dem DS.
Schatten: Es werden Shadow-Maps verwendet, einige sind 2k*2k groß. Die herstellerspezifischen Spinnereien werden benutzt (DF24X8/PCF bei NV, DF24/fetch4 bei ATi).
Es gibt Indoor bis im Druchschnitt 5 Lichtquellen per Pixel, draußen außer der Sonne höchstens eine.
Neben dem G-Buffer gibt es noch den L-Buffer (L wie Lichtign, also Textur mit der Beleuchtung). L-Buffer besteht aus zwei RGBA8-Texturen. Die eine enthält die nach dem Tonemapping enstandene LDR-Farbe. Die andere enthält die HDR-Farbe für Bloom sowie für die gesamte Beleuchtung der Szene. In die Tone-Mapping-Texturen werden die halbtransparenten Objekte gerendert.
Irgendwann landet das Zeug im Backbuffer.

Argh: unabsichtlich auf Antworten gedrückt.
Es wird geschrieben, dass anders als beim Forward Rendering, wo man eine Balance zwischen VS und PS finden kann, wird beim DS die Arbeit auf PS umgewälzt.
Die Landschaft wird mit 30-50 "Patches" (es sind eher Batches gemeint) gezeichnet, wobei jeder Batch 50-200 Dreiecke enthält. Die Landschaft an sich besteht aus 10 Texturen.



Sollte irgendwas unklar sein, dann liegt es an mir.

[DaEmpty]

Schatten: Es werden Shadow-Maps verwendet, einige sind 2k*2k groß. Die herstellerspezifischen Spinnereien werden benutzt (DF24X8/PCF bei NV, DF24/fetch4 bei ATi).
Wird da noch was fortschrittlicheres wie CSM,PSM oder TSM verwendet?

Es wird geschrieben, dass anders als beim Forward Rendering, wo man eine Balance zwischen VS und PS finden kann, wird beim DS die Arbeit auf PS umgewälzt.
Weswegen USA Chips hier einen netten Vorteil haben.
Die Landschaft wird mit 30-50 "Patches" (es sind eher Batches gemeint) gezeichnet, wobei jeder Batch 50-200 Dreiecke enthält. Die Landschaft an sich besteht aus 10 Texturen.
Patches sind schon richtig. Als Patches bezeichnet beim Terrainrendering meistens ein quadratisches Stück des Terrains (vgl Geometrical MipMapping) Die Zahlen sind aber etwas seltsam, da daraus folgen würde, dass das Terrain max 10000 Polygone hat. :|
Fehlt da vielleicht irgendwo noch eine Null?

[deekey777]

Das ist nur die Landschaft zB ohne Bäume. Bäume haben ihren eigenen Abschnitt. Für Bäume/Gras wird Geometry Instancing (Shader-basiert) benutzt, 50 "Instanzen" können aufeinmal gezeichnet werden. Ein Baum hat um 720 Polygone, ein Busch 250, eine Person 4500 (4.000 für den Körper und 500 fürs Gesicht). Die Zahl der Dreiecke an sich liegt zw. 700.000 und 1.200.000.
Zu den Schatten: Deine Schlagworte tauchen nicht auf.
Nochwas: Stalker berechnet alles mit halber Präzision, die float32-Mod erzwingt die Berechnung mit voller Präzision.

So wie es aussieht, ist Stalker nicht so sehr MATH-lastig, eher TEX-lastig.

[deekey777]

*pushipushi*

Ich hoffe, ich bin nicht im falschen Film.
STALKERs ReadMe:
SYSTEMANFORDERUNGEN

MINIMALE SYSTEMANFORDERUNGEN:
Microsoft® Windows® XP (Service Pack 2)/Microsoft® Windows® 2000 SP4
Prozessor: Intel Pentium 4 2.0 GHz / AMD XP 2200+
512 MB RAM
10 GB freier Platz auf der Festplatte
128 MB DirectX® 8.0 kompatible Grafikkarte / nVIDIA® GeForce™ 5700 / ATI Radeon® 9600
...
Tastatur, Maus
http://www.beyond3d.com/content/articles/19/2
At a minimum this requires 10 channels and in practise we will use several more. Currently there are no texture formats with that many channels, which implies multiple textures to store all the data. I tend to use 16 channels as this allows enough spare channels to customise the light equation but 12 may be enough in many cases.

The minimum hardware support for G-Buffers is therefore Pixel Shader 2 and render-to-texture. If the hardware only supports 8 bit per channel, any channels that need higher precision will need extra passes and be recombined when used (currently the NVIDIA GeForce FX needs these technique, this may be driver fixable in future).

If the card supports Multiple Render Targets (MRT) (like ATI 9500 and higher), we can use this to reduce the number of passes used to create the G-Buffer. The ATI 9500 and higher cards support up to 4 render-targets simultaneously and each render-target can be an A16B16G16R16 surface so we can generate the G-Buffer used here in 1 pass. Multiple Element Textures may also allow a similar reduction in passes but isn't well supported in hardware yet.

MRT and 16 bit integer render-targets enable single pass G-Buffers to be used as simply as standard rendering, for cards without MRT or higher precision surfaces we have to fall-back to multi-pass techniques to generate the G-Buffer.
Wenn mich nicht täuscht, wurde der fehlende Support für MRT bei der FX-Serie kritisiert. Wie wurde das in Strelok gelöst? Haben die R300 bzw. die FXen ihren eigenen Renderer oder nutzen sie den kleinsten gemeinsamen Nenner?

:|

[Gast]

Beispiel DoomIII: Es verschimmelte quasi in den Startlöchern, weil einfach nicht genug Power da war. Als es dann endlich mit der R300 bzw. dem Pendant von Nvidia gut performte, hat es keinen mehr soo vom Hocker gehauen.
hä?
der r300 ist ende 2002 erschienen, die gf fx serie von nvidia nur unwesentlich später. doom3 kam aber erst anfang 2004 auf den markt...

[deekey777]

hä?
der r300 ist ende 2002 erschienen, die gf fx serie von nvidia nur unwesentlich später. doom3 kam aber erst anfang 2004 auf den markt...
Doom 3 kam zwar August 2004, aber Piffans Posting verstehe ich trotzdem nicht.

[deekey777]

Stalker. Das Spiel wird quälend langsam durch HDR. Gibt ja kaum einen der das nicht bemerkt. Und nicht jeder ist ein Tombman. Und unterm Strich siehts trotzdem nich besser aus als HL². Die C'T ist immerhin auch dieser Meinung.
Das SSAA dasselbe Problem hat ist ja wohl auch bekannt. Oder?
....aber nun ja, wir werden wieder off-topic. Und du wirst sowieso anderer Meinung sein.
Das Posting ist zwar aus einem anderen Thread, aber egal.
Aus dem vorigen externen Link von Gamedev.ru (Seite 5):
"Jetzt müssen wir auf der Basis des G-Buffers und der Textur mit der Beleuchtung (ich nenne sie L-Buffer, da kürzer) das eigentliche Bild machen. Dafür, nachdem der "L-Buffer" gefüllt wurde, wird das ganze Bild in zwei Texturen gerendert mit Format A8R8G8B8 (klingt irgendwie blöd). In die erste Textur wird die LDR-Farbe geschrieben, besser gesagt das Ergebnis des Anwendung des Tonemappings auf die HDR-Farbe. In der anderen Textur wird die HDR-Farbe für Bloom und für die Berechnung der gesamten Belechtung benutzt (extrem abgekürzt: für die entsprechende Tageszeit, dann kommt Nebel dazu; dann gibt's wieder Tonemapping)."
ergibt das irgendeinen Sinn?

[Simon]

Stalker. Das Spiel wird quälend langsam durch HDR. Gibt ja kaum einen der das nicht bemerkt. Und nicht jeder ist ein Tombman. Und unterm Strich siehts trotzdem nich besser aus als HL². Die C'T ist immerhin auch dieser Meinung.
Das SSAA dasselbe Problem hat ist ja wohl auch bekannt. Oder?
....aber nun ja, wir werden wieder off-topic. Und du wirst sowieso anderer Meinung sein.Das Posting ist zwar aus einem anderen Thread, aber egal.
In dem Artikel zu Stalker in GPU Gems 2 ist die Rede davon, dass das HDR-Rendering nicht mal 1% Performance kostet. Und bis jetzt hab ich noch keine gegenteiligen Beweise oder Messungen gesehen...

[deekey777]

In dem Artikel zu Stalker in GPU Gems 2 ist die Rede davon, dass das HDR-Rendering nicht mal 1% Performance kostet. Und bis jetzt hab ich noch keine gegenteiligen Beweise oder Messungen gesehen...
Das glaube ich sogar. :smile:
Man kann es auch nicht deaktivieren, höchtens mit r2_sun off die Sonne und somit eine Lichtquelle ausschalten:
Volle dynamische Belechtung plus float32:
http://img507.imageshack.us/img507/8168/ssarnoldie081207144226lqy2.th.jpg (http://img507.imageshack.us/my.php?image=ssarnoldie081207144226lqy2.jpg)
+r2_allow_r1_lights on (verrammelte Fenster!):
http://img407.imageshack.us/img407/5954/ssarnoldie081207144243lvj4.th.jpg (http://img407.imageshack.us/my.php?image=ssarnoldie081207144243lvj4.jpg)
+r2_sun off:
http://img407.imageshack.us/img407/6742/ssarnoldie081207144256lda8.th.jpg (http://img407.imageshack.us/my.php?image=ssarnoldie081207144256lda8.jpg)
Nur r2_sun off (r2_allow_r1_lights off):
http://img407.imageshack.us/img407/3439/ssarnoldie081207144305ldq4.th.jpg (http://img407.imageshack.us/my.php?image=ssarnoldie081207144305ldq4.jpg)
Noch was anderes:
r2_aa off:
http://img407.imageshack.us/img407/1900/ssarnoldie081207141913ldf9.th.jpg (http://img407.imageshack.us/my.php?image=ssarnoldie081207141913ldf9.jpg)
r2_aa on:
http://img407.imageshack.us/img407/4372/ssarnoldie081207141906ldx1.th.jpg (http://img407.imageshack.us/my.php?image=ssarnoldie081207141906ldx1.jpg)
Die Bilder haben deshalb so eine schlechte Qualität, weil das Spiel mit der Standardverknüpfung lief.

[Coda]

Paar Anmerkungen:

Das ist kein Antialiasing im letzten Bild sondern ein fieser Blurfilter.

Das glaube ich sogar. :smile:
Das ist bei deferred shading auch klar.

Nochwas: Stalker berechnet alles mit halber Präzision, die float32-Mod erzwingt die Berechnung mit voller Präzision.
G80/R600/R5xx berechnen trotzdem immer alles mit voller Präzision. R3xx und R4xx immer mit FP24.

Wenn mich nicht täuscht, wurde der fehlende Support für MRT bei der FX-Serie kritisiert. Wie wurde das in Strelok gelöst? Haben die R300 bzw. die FXen ihren eigenen Renderer oder nutzen sie den kleinsten gemeinsamen Nenner?
Auch wenn es durchgestrichen war: Dann musst du die Szene für jedes Rendertarget jeweils neu rendern, d.h. die Vertexarbeit fällt mehrfach an und auch die sonstige Performance dürfte leiden.

[deekey777]

Es wurde durchgestrichen, weil es falsch war bzw. Klärungsbedarf nötig ist. Der "DX8"-Renderer scheint ein Forward Renderer zu sein.


Zu r2_AA:
Es ist kein fieser Blurfilter perse, da steckt schon etwas dahinter, was vielleicht von Werk aus falsch einstellt ist.
Aus der USER.LTX:
r2_aa off
r2_aa_break 0.800000,0.500000,0.000000
r2_aa_kernel 0.5
r2_aa_weight 0.250000,0.250000,0.000000

http://www.tweakguides.com/STALKER_7.html
r2_aa [on,off] - This setting controls whether a blur-shader form of fake Antialiasing is enabled in the game or not. It is not the same as the Antialiasing slider in the game, and is not a real form of Antialiasing. It does not reduce the actual jaggedness of outlines; it masks them by blurring the screen at the cost of some FPS - you can get much the same effect (without the FPS drop) by running an LCD monitor in a non-native resolution for example. Given the in-game Antialiasing slider is essentially non-functional, and AA cannot be forced by using your graphics card's control panel either (since the game uses Deferred Shading - see the In-Game Settings section), this is the only form of AA possible for the game. You can control the level of blur used with the r2_aa_ parameters below.



r2_aa_kernel [0.300 - 0.700] - This setting controls the overall blur effect used for the fake Antialiasing if the r2_aa option is enabled. The higher the value, the greater the blur effect used. Enabling fake AA and setting this option to 0.3 provides a reasonable fake AA effect without too much blur.



r2_aa_break [0.000000 - 1.000000,0.000000 - 1.000000,0.000000 -1.000000] - This setting appears to control the distance at which the fake AA effect operates. The higher the values used, the further away the effect will be implemented. However because the values are vector-based, setting them all to maximum doesn't necessarily ensure the best result. Experiment to see which values suit your needs (e.g. r2_aa_break 0.000000,1.000000,0.000000 gives sharp close imagery and blurred distance imagery)



r2_aa_weight [0.000000 - 1.000000,0.000000 - 1.000000,0.000000 - 1.000000] - This setting provides more precise control over the strength of the blurring effect. The higher the values used, the more blurring will be implemented, but again note the values are vector-based.

G80/R600/R5xx berechnen trotzdem immer alles mit voller Präzision. R3xx und R4xx immer mit FP24.
Beherrscht der R520 kein FP24 mehr (als halbe Genauigkeit)?
Das ist schon klar, aber es gibt Grafikkarten aus dem Hause nVidia, die mit halber Genauigkeit besser rechnen.

[Coda]

Es wurde durchgestrichen, weil es falsch war bzw. Klärungsbedarf nötig ist. Der "DX8"-Renderer scheint ein Forward Renderer zu sein.
Natürlich ist der das. Deshalb geht ja auch MSAA damit.

Beherrscht der R520 kein FP24 mehr (als halbe Genauigkeit)?
Nope. Wäre auch nicht sinnvoll, weil man FP24 nicht besser in einem auf 32-Bit ausgelegten Registerfile packen könnte und auch sonst mehr Transistoren dafür brauchen würde.

[derwalde]

Die Bilder haben deshalb so eine schlechte Qualität, weil das Spiel mit der Standardverknüpfung lief.

kannst du mir bitte den zusammenhang zwischen bildquali und das starten des spiels per standardverknüpfung? :confused:

[AnarchX]

kannst du mir bitte den zusammenhang zwischen bildquali und das starten des spiels per standardverknüpfung? :confused:

Nein, man kann an die Verknüpfung einen Parameter anhängen sodass die interne Screenshotfunktion unkomprimierte Bilder auswirft, Standard ist nämlich bei Stalker komprimierte JPEGs(?).

[derwalde]

ok dankeschön ;)

[d2kx]

Habt ihr schonmal das neue Float32 Update probiert? Das geht tierisch ab, damit sieht Stalker viel, viel besser aus:

www.thefloatingpoint.org

[Gast]

Das ist kein Antialiasing im letzten Bild sondern ein fieser Blurfilter.




so fies ist der garnicht, immerhin scheint er mit einer art kantenerkennung zu arbeiten.

[derwalde]

Habt ihr schonmal das neue Float32 Update probiert? Das geht tierisch ab, damit sieht Stalker viel, viel besser aus:

www.thefloatingpoint.org

den patch muss man einfach per installer installieren right? kann ich irgendwo auch sehen ob der patch angenommen wurde bzw. welche version von float32 ich letztendes nutze?

[Gast]

Habt ihr schonmal das neue Float32 Update probiert? Das geht tierisch ab, damit sieht Stalker viel, viel besser aus:

www.thefloatingpoint.org

Nope, sehe ich nicht so. Es hebt zwar gewisse Details stärker hervor, was dann aber auch wieder tlw. übertrieben wirkt, dazu sind belichtete Flächen generell greller und Schatten viel zu dunkel. Mitten am Tag ist's im Bahnhanger zappenduster und das ist einfach Bullshit - hier fehlt dann der klassische Effekt, der HDR-Rendering so berühmt gemacht hat: die Anpassung der Augen an das Umgebungslicht. Davon abgesehen, dass Streulicht derartige Dunkelheit auch vermindert.
Das Ding macht aus der sehr um realistische Optik bemühte Stalker-Grafik mehr ein FarCry als alles andere, ein Stalker auf Steroiden oder so ...

[Gast]

Lest einfach die GPU Gems 2. Da wurde das Deferred Lighting/Shading in Stalker schon vor Jahren erklärt.
...

Theoretisch ginge ja immer noch SSAA.
Und wenn man keine Lust hat, dieses Taschenbuch zu kaufen: Gibt es diese Präsentation von der GDC auch irgendwo zum Herunterladen?
http://www.4a-games.com/209_gems2_ch09.pdf

[Simon]

http://www.4a-games.com/209_gems2_ch09.pdf
Seit wann ist der Artikel denn freigegeben von nvidia??? Sieht schwer nach Urheberrechtsverletzung aus... und damit illegal :rolleyes:

[san.salvador]

Habt ihr schonmal das neue Float32 Update probiert? Das geht tierisch ab, damit sieht Stalker viel, viel besser aus:

www.thefloatingpoint.org
Klingt sehr interessant, allerdings finde ich auf der ganzen Seite keine Vergleichsscreens, auch im Forum nicht.
Hat jemand einen Link? :)

[Gast]

Seit wann ist der Artikel denn freigegeben von nvidia??? Sieht schwer nach Urheberrechtsverletzung aus... und damit illegal :rolleyes:
:rolleyes:
Jedesmal, wenn ich diesen :rolleyes:-Smiley sehe, hasse ich ihn mehr und mehr.
Schaue mal auf den Link: http://www.4a-games.com/
Die Seite ist zwar noch nicht fertig, aber wenn man die einzelnen Personen anklickt, taucht ein gewisser Oles Shishkovtsov auf.
4a-Games besteht aus den Machern bzw. Abgängern vons STALKER (Oles war einer der Programmierer der X-Ray-Engine). Der Artikel ist somit weder illegal noch sonstwas, sondern von seinem Autor hochgeladen.

[Simon]

:rolleyes:
Jedesmal, wenn ich diesen :rolleyes:-Smiley sehe, hasse ich ihn mehr und mehr.
Schaue mal auf den Link: http://www.4a-games.com/
Die Seite ist zwar noch nicht fertig, aber wenn man die einzelnen Personen anklickt, taucht ein gewisser Oles Shishkovtsov auf.
4a-Games besteht aus den Machern bzw. Abgängern vons STALKER (Oles war einer der Programmierer der X-Ray-Engine). Der Artikel ist somit weder illegal noch sonstwas, sondern von seinem Autor hochgeladen.
Ach deswegen ist der Download-Link auf der HP direkt zu finden...

[deekey777]

Kann es sein, dass die zusätzlichen Beleuchtungseffekte (auf mittleren Einstellungen) interlaced sind?
Ich werde später einige Screenshots nachliefern (wenn die Sonne scheint).