Archiv verlassen und diese Seite im Standarddesign anzeigen : Wieviel Aufwand für 3d nötig?
Karümel
2010-06-16, 19:12:21
Da jetzt ja Crytek und vor allen Sony auf 3D setzen, frage ich mich wieviel Mehraufwand das nachsichzieht?
Ist das eigentlich nur eine Sache der Engige/ des Codes oder muß da noch mehr eachtet werden, Content oder sonstige Sachen?
Du meinst für Spiele?
Da ist es eigentlich kaum ein Aufwand für die Engine (für die Berechnung natürlich schon), es liegen ja schon alle Daten in 3D vor, man muss im Prinzip nur 2x aus leicht unterschiedlichen Perspektiven rendern.
Spasstiger
2010-06-16, 19:30:31
Sinnvoll wäre es, die GUI in die 3D-Welt einzubinden wie z.B. bei Dead Space teilweise umgesetzt. Sonst schweben die Anzeigen immer vor dem eigentlichen Geschehen.
Karümel
2010-06-16, 19:37:31
Du meinst für Spiele?
Ja, sorry hätte ich dazuschreiben sollen, die Frage bezoeht sich auf Spiele.
Also Crysis 2 oder Killzone 3 etc.
Monger
2010-06-16, 20:13:53
Es gibt ein paar Effekte in Spielen, die üblicherweise nicht in 3D gerendert werden. Manche Partikeleffekte, das HUD, Texteinblendungen, Post Processing Effekte o.ä. ...
Das kann in einer 3D Perspektive möglicherweise Probleme bereiten.
Aber abgesehen davon muss eigentlich die Grafikkarte nur zwei verschiedene Viewports berechnen. Das braucht natürlich Leistung, ist aber kein besonderes technisches Hindernis.
Sinnvoll wäre es, die GUI in die 3D-Welt einzubinden wie z.B. bei Dead Space teilweise umgesetzt. Sonst schweben die Anzeigen immer vor dem eigentlichen Geschehen.
Wird ja nun via Scaleform vermehrt auch gemacht.
Interessante Frage, vor allem für mich als Grafiklaie.
Wie würde die Rechenlast denn nun steigen? Faktor 2 oder knapp drunter, eher kleiner 1,5 oder gar kaum mehr?
Gewiss nicht einfach zu beantworten, aber so Pi mal Daumen sollten die Experten hier doch eine Einschätzung abgeben können.
Interessante Frage, vor allem für mich als Grafiklaie.
Wie würde die Rechenlast denn nun steigen? Faktor 2 oder knapp drunter, eher kleiner 1,5 oder gar kaum mehr?
Gewiss nicht einfach zu beantworten, aber so Pi mal Daumen sollten die Experten hier doch eine Einschätzung abgeben können.
"...kaum mehr als 1?" sollte da natürlich stehen!
Aquaschaf
2010-06-16, 22:53:48
Wie würde die Rechenlast denn nun steigen? Faktor 2 oder knapp drunter, eher kleiner 1,5 oder gar kaum mehr?
Man braucht pro Frame zwei Bilder die die selbe Szene aus leicht unterschiedlicher Perspektive zeigen. D.h. für die Grafikkarte ist die Last ziemlich genau doppelt so hoch. Natürlich ist das auch eine perfekte Anwendung für Dual-GPU-Systeme.
Spasstiger
2010-06-16, 22:57:43
Da die Frames auch synchronisiert werden müssen, damit immer die passenden Bilder im Wechsel angezeigt werden, wird VSync zur Pflicht. D.h. man benötigt die doppelte GPU-Leistung und muss noch den fps-Einbruch durch VSync einrechnen. Wenn man im 2D-Modus ohne VSync 50 fps bei starker GPU-Limitierung hat, dann sinds im 3D-Modus wahrscheinlich nur noch 20 fps.
Man braucht pro Frame zwei Bilder die die selbe Szene aus leicht unterschiedlicher Perspektive zeigen. D.h. für die Grafikkarte ist die Last ziemlich genau doppelt so hoch. Natürlich ist das auch eine perfekte Anwendung für Dual-GPU-Systeme.
Bisher optimieren die Treiber aber offenbar noch nicht darauf, denn die Skalierung ist trotzdem schlechter als 100%.
D.h. also am Beispiel eines von einer Figur geworfenen Schattens, dass obwohl anhand der Lichtquelle und Form der Figur die Lage und Form des Schattens eindeutig festgelegt ist, alles 2 mal berechnet wird. Klingt irgendwie nicht so effizient.
Man braucht pro Frame zwei Bilder die die selbe Szene aus leicht unterschiedlicher Perspektive zeigen. D.h. für die Grafikkarte ist die Last ziemlich genau doppelt so hoch. Natürlich ist das auch eine perfekte Anwendung für Dual-GPU-Systeme.
Du brauchst aber nicht die doppelte Framerate, schließlich bekommst du alle Frames zu sehen, wenn auch immer nur abwechselnd für jedes Auge.
Also fühlen sich 2x30fps zwar nicht an wie 60fps, aber doch deutlich mehr als 1x30fps für beide Augen. Die Wahrheit liegt irgendwo in der Mitte.
D.h. also am Beispiel eines von einer Figur geworfenen Schattens, dass obwohl anhand der Lichtquelle und Form der Figur die Lage und Form des Schattens eindeutig festgelegt ist, alles 2 mal berechnet wird. Klingt irgendwie nicht so effizient.
Es wird immer abwechselnd für jedes Auge ein Frame berechnet. Damit braucht man natürlich 2x den Backbuffer. Du brauchst aber nicht die doppelte Framerate gegenüber der normalen Darstellung um den gleich flüssigen Bildeindruck zu erhalten.
Grafiklaie
2010-06-16, 23:41:56
Letzte Frage vorm Schlafen:
Ihr wollt mir aber doch nicht erzählen, dass z.B. der der "rohe" Texturspeicherbedarf mindestens doppelt so groß wird, nur weil die Textur 2 statt 1 mal gezeichnet wird?!
ne die Textur ist ja eh im Speicher. Auch für normales Rendern.
Ihr wollt mir aber doch nicht erzählen, dass z.B. der der "rohe" Texturspeicherbedarf mindestens doppelt so groß wird, nur weil die Textur 2 statt 1 mal gezeichnet wird?!
Hat auch niemand behauptet, Texturen werden oft sogar deutlich öfter als 2x pro Frame gezeichnet.
Grafiklaie
2010-06-17, 18:05:54
Naja, wenn so ziemlich alle Berechnungen - zumindest in der Theorie - unnötigerweise 2 mal durchgeführt werden, warum dann nicht auch doppelter Speicherbedarf? Wäre für mich als Laie auch nicht viel unlogischer.
Monger
2010-06-17, 19:10:13
Die Berechnung des Viewports ist ja nicht die einzige Aufgabe, die die Grafikkarte hat. Wahrscheinlich ist es nichtmal die größte.
Eigentlich sollte das deutlich weniger als doppelte Rechenlast brauchen, aber ich schätze mal, da stehen noch ganz andere, architekturelle Probleme im Weg.
Grafiklaie
2010-06-17, 19:16:43
Die Berechnung des Viewports ist ja nicht die einzige Aufgabe, die die Grafikkarte hat. Wahrscheinlich ist es nichtmal die größte.
Eigentlich sollte das deutlich weniger als doppelte Rechenlast brauchen, aber ich schätze mal, da stehen noch ganz andere, architekturelle Probleme im Weg.
Eben, so sehe ich das auch. Z.B. müsste doch alles, was Schatten ist (inkl. POM) Nur einmal berechnet werden, um im 2. Bild nur noch als feste Textur wie vor 1000 Jahren auf die Objekte gelegt zu werden. Das ist doch eigentlich trivial oder mache ich da einen großen Denkfehler?
3d Guru & Übercoder
2010-06-17, 19:48:59
Aber abgesehen davon muss eigentlich die Grafikkarte nur zwei verschiedene Viewports berechnen. Das braucht natürlich Leistung, ist aber kein besonderes technisches Hindernis.
Das ist nicht korrekt.
Denn die 3d Szene ist ja nicht statisch!
Erstmal wären da die 3d Gegner, die müssen fast alle, sofern sie in Sichtweite sind, für fast jedes Frame neu berechnet werden.
Und das gleiche gilt für andere Objekte, wie rollende Fässer oder eben im Wind schwingende Bäume.
Man braucht pro Frame zwei Bilder die die selbe Szene aus leicht unterschiedlicher Perspektive zeigen.
Ach so ist das gemeint.
Ein Fehler des Threadstarters.
Er hätte Stereo 3d schreiben sollen, so daß es auch jeder versteht.
Denn 3d ist es ja schon.
Das ist doch eigentlich trivial oder mache ich da einen großen Denkfehler?
Ja, alle Berechnungen passen nur für den Blickwinkel für den sie berechnet wurden, und müssen natürlich auch für den anderen Blickwinkel berechnet werden.
Grafiklaie
2010-06-17, 22:41:29
Ja, alle Berechnungen passen nur für den Blickwinkel für den sie berechnet wurden, und müssen natürlich auch für den anderen Blickwinkel berechnet werden.
Ich bin mir ziemlich sicher, dass dem nicht so ist, jedenfalls nicht für alle Berechnungen. Die einzig nötige Berechnung ist die für die korrekte Darstellung der Textur (+ "Zusatzlayer"), was schon seit Wolfenstein oder Doom kein Problem ist. Das sollte aber ein winziger Bruchteil dessen sein, was für für die eigentliche Berechnung von Bild 1 nötig war.
Simples Beispiel: eine Kugel wirft einen Schatten auf eine Backsteinwand (simple 2D-Textur). Für Bild 1 muss viel rumgerechnet werden, bis irgendwann ein korrekter, sagen wir mal zur Vereinfachung in diesem Fall, runder Schatten entsteht.
Für Bild 2 aus anderem Blickwinkel sollte nun nicht alles noch einmal neu berechnet werden (Lichtquelle, Entfernung und viele weitere Dinge...), sondern der vorhandene schwarze Kreis einfach perspektivisch korrekt verzerrt werden, so dass aus dem Kreis eine Elipse wird und aus den rechteckigen Steinen trapezförmige aufgrund des Blickwinkels. Und das sollte für sehr, sehr viele andere Effekte ebenso funktionieren.
Obs geht (Architektur...), weiss ich allerdings nicht, weil ich nur Laie bin.
Ich bin mir ziemlich sicher, dass dem nicht so ist, jedenfalls nicht für alle Berechnungen. Die einzig nötige Berechnung ist die für die korrekte Darstellung der Textur (+ "Zusatzlayer"), was schon seit Wolfenstein oder Doom kein Problem ist. Das sollte aber ein winziger Bruchteil dessen sein, was für für die eigentliche Berechnung von Bild 1 nötig war.
Simples Beispiel: eine Kugel wirft einen Schatten auf eine Backsteinwand (simple 2D-Textur). Für Bild 1 muss viel rumgerechnet werden, bis irgendwann ein korrekter, sagen wir mal zur Vereinfachung in diesem Fall, runder Schatten entsteht.
Für Bild 2 aus anderem Blickwinkel sollte nun nicht alles noch einmal neu berechnet werden (Lichtquelle, Entfernung und viele weitere Dinge...), sondern der vorhandene schwarze Kreis einfach perspektivisch korrekt verzerrt werden, so dass aus dem Kreis eine Elipse wird und aus den rechteckigen Steinen trapezförmige aufgrund des Blickwinkels. Und das sollte für sehr, sehr viele andere Effekte ebenso funktionieren.
Obs geht (Architektur...), weiss ich allerdings nicht, weil ich nur Laie bin.
So einfach ist das nicht. Was machst du wenn im ersten Bild hinter der Kugel etwas ist, was durch die Kugel verdeckt wird, im zweiten Bild aus anderer Perspektive aber sichtbar ist? Das kannst du nicht mit einer einfachen perspektivischen Verzerrung des ersten Bildes rekonstruieren, denn im ersten Bild siehst du es ja gar nicht.
Wenn du es richtig machen willst dann musst du das Bild mit dem geänderten Viewport neu berechnen, alles andere ist Quirks.
So einfach ist das nicht. Was machst du wenn im ersten Bild hinter der Kugel etwas ist, was durch die Kugel verdeckt wird, im zweiten Bild aus anderer Perspektive aber sichtbar ist? Das kannst du nicht mit einer einfachen perspektivischen Verzerrung des ersten Bildes rekonstruieren, denn im ersten Bild siehst du es ja gar nicht.
Wenn du es richtig machen willst dann musst du das Bild mit dem geänderten Viewport neu berechnen, alles andere ist Quirks.
Klar, die "Drahtgitter" werden neu berechnet werden müssen - sinnvoll jedenfalls nur bis zu einer bestimmten Distanz - und es wird WorstCase-Szenarien geben, in denen der Aufwand fürs 2. Bild erheblich steigt. Beispielsweise wenn man vor einer Aussenecke steht, auf Bild 1 sehe ich nur senkrecht auf ein Mauerstück, bei Bild 2 auch noch den anderen, nach vorne von mir weglaufenden Teil, der komplett neu und zusätzlich berechnet werden muss. Den Schatten auf dem Mauerteil direkt vor mir, den der hinter mir liegende, sich im Wind wiegende Baum wirft, werde ich aber nicht nochmal berechnen müssen. Ebensowenig das Flammenspiel des Lagerfeuers auf diesem Wandstück. Nur perspektivisch korrigieren muss man es -> simpel.
Neomi
2010-06-18, 00:02:06
@Grafiklaie:
Deine Idee geht schon in die richtige Richtung, die Vorgehensweise ist aber eine andere. Hier mal ein vereinfachtes Beispiel, wie das Rendering aufgeteilt wird, wenn eine Shadowmap zum Einsatz kommt:
1. Zuerst wird die Shadowmap berechnet. Dazu wird die Tiefe (Entfernung zur Lichtquelle) der Szene aus der Sicht der Lichtquelle berechnet, nicht aus der Sicht des Spielers. Schließlich liegt im Schatten, was die Lichtquelle nicht "sehen" kann. Außerdem können Objekte einen Schatten ins Blickfeld des Spielers werfen, ohne selbst im Blickfeld zu sein. Die Shadowmap liegt danach zur weiteren Verwendung vor.
2. Jetzt wird die Szene aus Sicht des Spielers berechnet. Also das, was er letztendlich auf dem Bildschirm zu sehen bekommt. Alles, was gerendert wird, muß den Schatten nicht mehr berechnen (das ist an dieser Stelle mangels Kenntnis der vollständigen Szene sowieso nicht möglich), sondern nur noch in der Shadowmap nachschlagen. Dazu wird pro Pixel die Position im Raum zu den entsprechenden Koordinaten in der Shadowmap transformiert. Daraus wird dann ein Tiefenwert gelesen, der mit der Entfernung zur Lichtquelle verglichen wird. Ist der Pixel weiter weg von der Lichtquelle als der hinterlegte Wert, dann ist ein Hindernis dazwischen und der Pixel liegt im Schatten.
Die Berechnung des Schattens ist letztendlich um einiges komplizierter als in Schritt 2 beschrieben, vor allem wenn Soft Shadows dazu kommen, aber so ist die generelle Vorgehensweise. Wenn jetzt ein stereoskopisches Bild berechnet werden soll, dann wird Schritt 2 für den 2. Viewport wiederholt, während das Ergebnis von Schritt 1 nach wie vor gültig ist. Voraussetzung ist hierfür, daß beide Bilder zum gleichen Zeitpunkt gerendert werden. Die Berechnung geschieht natürlich hintereinander, aber es darf keine Spielzeit zwischen den Bildern vergehen, also keine Objekte weiterbewegt werden. Das würde nämlich die Shadowmap invalidieren, sie wäre für den neuen Stand nicht mehr gültig. Generell ist ein Rendern der Bilder für beide Augen zu unterschiedlichen Zeitpunkten im Spiel aber eine Möglichkeit bei ausreichender Framerate, um mehr Bewegungsinformationen in die kombinierten Bilder zu bringen (ähnlich dem Interlaced-Format für Videos).
Es gibt noch weitere Berechnungen, die zwischen den zwei Viewports für stereoskopische Bilder geteilt werden können. In Rennspielen beispielsweise gibt es fast immer eine Spiegelung der Umgebung im Auto. Das geschieht, indem vor der Berechnung des eigentlichen Bildes eine Cubemap der Umgebung vom Mittelpunkt des Autos aus gerendert wird, die Cubemap bleibt genau wie die Shadowmap auch für den 2. Viewport gültig. Spiegelungen an Ebenen (z.B. die type Reflektion im Wasser) zählen allerdings nicht dazu, da hier die Spiegelung selbst winkelabhängig berechnet werden muß, während die Cubemap um ein spiegelndes Objekt herum nur winkelabhängig ausgelesen wird.
Dazu kommen noch Animationsdaten und weitere grafikbezogene Hilfsaufgaben, die für stereoskopische Bilder nur einmal anfallen. Schatten und Spiegelungen (wie gesagt nicht die planaren) sind wohl die mit Abstand größten Posten.
Postprocessing (z.B. Depth of Field, Motion Blur, Bloom) ist dann durchgängig pro Viewport einzeln durchzuführen.
@Grafiklaie:
Deine Idee geht schon in die richtige Richtung, die Vorgehensweise ist aber eine andere. Hier mal ein vereinfachtes Beispiel, wie das Rendering aufgeteilt wird, wenn eine Shadowmap zum Einsatz kommt:
1. Zuerst wird die Shadowmap berechnet. Dazu wird die Tiefe (Entfernung zur Lichtquelle) der Szene aus der Sicht der Lichtquelle berechnet, nicht aus der Sicht des Spielers. Schließlich liegt im Schatten, was die Lichtquelle nicht "sehen" kann. Außerdem können Objekte einen Schatten ins Blickfeld des Spielers werfen, ohne selbst im Blickfeld zu sein. Die Shadowmap liegt danach zur weiteren Verwendung vor.
2. Jetzt wird die Szene aus Sicht des Spielers berechnet. Also das, was er letztendlich auf dem Bildschirm zu sehen bekommt. Alles, was gerendert wird, muß den Schatten nicht mehr berechnen (das ist an dieser Stelle mangels Kenntnis der vollständigen Szene sowieso nicht möglich), sondern nur noch in der Shadowmap nachschlagen. Dazu wird pro Pixel die Position im Raum zu den entsprechenden Koordinaten in der Shadowmap transformiert. Daraus wird dann ein Tiefenwert gelesen, der mit der Entfernung zur Lichtquelle verglichen wird. Ist der Pixel weiter weg von der Lichtquelle als der hinterlegte Wert, dann ist ein Hindernis dazwischen und der Pixel liegt im Schatten.
Die Berechnung des Schattens ist letztendlich um einiges komplizierter als in Schritt 2 beschrieben, vor allem wenn Soft Shadows dazu kommen, aber so ist die generelle Vorgehensweise. Wenn jetzt ein stereoskopisches Bild berechnet werden soll, dann wird Schritt 2 für den 2. Viewport wiederholt, während das Ergebnis von Schritt 1 nach wie vor gültig ist. Voraussetzung ist hierfür, daß beide Bilder zum gleichen Zeitpunkt gerendert werden. Die Berechnung geschieht natürlich hintereinander, aber es darf keine Spielzeit zwischen den Bildern vergehen, also keine Objekte weiterbewegt werden. Das würde nämlich die Shadowmap invalidieren, sie wäre für den neuen Stand nicht mehr gültig. Generell ist ein Rendern der Bilder für beide Augen zu unterschiedlichen Zeitpunkten im Spiel aber eine Möglichkeit bei ausreichender Framerate, um mehr Bewegungsinformationen in die kombinierten Bilder zu bringen (ähnlich dem Interlaced-Format für Videos).
Es gibt noch weitere Berechnungen, die zwischen den zwei Viewports für stereoskopische Bilder geteilt werden können. In Rennspielen beispielsweise gibt es fast immer eine Spiegelung der Umgebung im Auto. Das geschieht, indem vor der Berechnung des eigentlichen Bildes eine Cubemap der Umgebung vom Mittelpunkt des Autos aus gerendert wird, die Cubemap bleibt genau wie die Shadowmap auch für den 2. Viewport gültig. Spiegelungen an Ebenen (z.B. die type Reflektion im Wasser) zählen allerdings nicht dazu, da hier die Spiegelung selbst winkelabhängig berechnet werden muß, während die Cubemap um ein spiegelndes Objekt herum nur winkelabhängig ausgelesen wird.
Dazu kommen noch Animationsdaten und weitere grafikbezogene Hilfsaufgaben, die für stereoskopische Bilder nur einmal anfallen. Schatten und Spiegelungen (wie gesagt nicht die planaren) sind wohl die mit Abstand größten Posten.
Postprocessing (z.B. Depth of Field, Motion Blur, Bloom) ist dann durchgängig pro Viewport einzeln durchzuführen.
Ah, endlich meldet sich jemand, der offenbar Ahnung statt Vermutungen hat.
Soweit alles klar, aber ist die theoretisch nötige Neuberechnung bei z.B. DoF, MB, Bloom (ist ja eh verschwommen...) angesichts des Augenabstands wirklich nötig, oder konnte man sich das ebenso wie eine Objektneuberechnung eines entfernten Objektes nicht einfach sparen, ohne hässlich zu werden?
EvilTechno
2010-06-18, 00:49:57
Mal eine naive Frage. Ist Stereo-3D nicht wie geschaffen für SLI/Crossfire?
Neomi
2010-06-18, 02:25:07
Soweit alles klar, aber ist die theoretisch nötige Neuberechnung bei z.B. DoF, MB, Bloom (ist ja eh verschwommen...) angesichts des Augenabstands wirklich nötig, oder konnte man sich das ebenso wie eine Objektneuberechnung eines entfernten Objektes nicht einfach sparen, ohne hässlich zu werden?
Postprocessing-Effekte sind nicht wiederverwendbar. Die werden auf ein berechnetes Bild angewendet, von denen es bei stereoskopischer Berechnung nunmal zwei gibt. Als kleines Beispiel kannst du ja mal den Blick auf irgendwas in der Ferne richten und dir eine Hand vor ein Auge halten. Dann hast du auf dem einen Auge noch ein fernes Objekt, das so weit weg ist, daß ein stereoskopisches Sehen dort irrelevant ist, auf dem anderen Auge fehlt dieses Objekt dank nahem Hindernis (der Hand) aber trotzdem. Wenn das ferne Objekt jetzt die Sonne ist, dann ist sie auf dem einen Auge nicht zu sehen und auf dem anderen blendet sie trotzdem. Soweit zur Veranschaulichung, weshalb Postprocessing-Effekte (in diesem Fall Bloom) jeweils separat berechnet werden müssen.
Ferne Objekte könnte man tatsächlich auf eine einmalige Berechnung für die zwei Bilder beschränken. Dazu muß ab einer bestimmten Entfernungsgrenze mit einer zentrierten Kamera ein Bild berechnet werden, das dann als Hintergrund für die beiden weiteren versetzten Bilder verwendet werden kann. Der Sichtkegel muß dazu leicht asymmetrisch sein, damit die versetzten Bilder an der Entfernungsgrenze exakt mit dem Sichtkegel vom Hintergrund zusammenfallen. Wie das aussehen muß, hab ich mal in einer schnellen (und übertrieben dargestellten) Skizze angehängt. Das hat allerdings auch Nachteile. Am Übergang hat man einen wortwörtlichen Knick in der Optik, je näher die Grenze ist desto stärker. Deferred Shading wird durch einen "abgeknickten" Hintergrund zwar nicht unmöglich gemacht, aber erschwert. Und außerdem kann es passieren, daß Sachen im Hintergrund gerendert werden (und damit Rechenzeit verschlingen), die in beiden Teilbildern verdeckt sind.
Mal eine naive Frage. Ist Stereo-3D nicht wie geschaffen für SLI/Crossfire?
Solange man auf sämtliche Wiederverwendbarkeit von Ressourcen wie z.B. der Shadowmap verzichtet, geht das sogar prima. Wenn man aber die Redundanz in den Berechnungen vermeiden will, fängt man sich genau die Probleme ein, wegen denen Split Frame Rendering eigentlich ausgestorben ist.
del_4901
2010-06-18, 08:51:10
Man kann auch einfach das Bild fuer das zweite Auge faken, indem man es aus dem Bild fuer das erste Auge un dem dazugehoerigen Z-Buffer rausrechnet. Unser Gehirn stoert sich da nicht wenn es mal nicht ganz genau ist.
Neomi
2010-06-18, 11:07:45
Meinst du eine Art Parallax Occlusion Mapping für das vollständige Bild? Interessanter und guter Ansatz. Ich bezweifle aber, daß das auch für nahe Objekte (z.B. die eigene Waffe in einem Egoshooter) akzeptabel funktioniert und auch sämtliche Effekte (z.B. Partikeleffekte wie Feuer, Rauch, Staub, Funken), die nicht in den Z-Buffer schreiben, werden Probleme machen. Aber damit könnte man beispielsweise den gemeinsam genutzten Hintergrund aus meinem vorigen Posting verbessern und die Grenze nach vorne ziehen, z.B. statt 500 m jetzt 50 m. Wenn in diesem Entfernungsbereich noch viele Details kostspielig gerendert werden, könnte sich das gut lohnen.
Die Berechnung geschieht natürlich hintereinander, aber es darf keine Spielzeit zwischen den Bildern vergehen, also keine Objekte weiterbewegt werden.
Aber genau das ist ja üblicherweise der Fall.
Wenn ein Spiel sagen wir mal mit konstanten 50fps rendert liegen zwischen linkem und rechten Bild konstant immer 0,04s. Es ist ja auch wesentlich sinnvoller, da man damit schon bei deutlich niedrigeren Frameraten einen guten Bewegungseindruck erhält.
Neomi
2010-06-18, 12:29:38
Wenn die Grafikkarte mit der Geschwindigkeit neue Bilder nachschieben kann, mit der zwischen linkem und rechtem Auge gewechselt wird, dann ist das sinnvoll. Nur ist man dann schon bei 120 Hz, also 60 Frames/s pro Auge, da ist die zusätzliche Bewegungsinformation nicht mehr so relevant wie sie bei niedrigeren Frameraten wäre. Bei niedrigeren Frameraten hat man dann aber ein gewaltiges Problem. Wenn das Bild für das rechte Auge neuer ist als das für das linke und wieder der Wechsel nach links ansteht, dann wird auf ein älteres Bild umgeschaltet. Die eigentlich positive zusätzliche Bewegungsinformation geht nach hinten los und sorgt für ein unangenehmes Zittern in der Bewegung. Deshalb sind bei nicht konstant hoher Framerate (120 Frames/s insgesamt) Bilder besser, die links und rechts virtuell gleich alt sind.
Dann gibt es neben der Shutterbrille noch andere Verfahren, die im Gegensatz dazu beide Bilder gleichzeitig darstellen, z.B. per Polfilterbrille. Hier müssen die Bilder gleich alt sein.
Dann gibt es neben der Shutterbrille noch andere Verfahren, die im Gegensatz dazu beide Bilder gleichzeitig darstellen, z.B. per Polfilterbrille. Hier müssen die Bilder gleich alt sein.
Bei den meisten Umsetzungen mit Polfilterbrille werden allerdings die Bilder auch abwechselnd gezeigt. Lediglich mit 2 Projektoren oder mit LCDs deren Zeilen unterschiedlich polarisiert sind kann man wirklich beide Bilder gleichzeitig darstellen, wobei man bei letzterem natürlich das Problem hat dass die Auflösung in 3D halbiert wird.
Grafiklaie
2010-06-19, 13:13:04
Postprocessing-Effekte sind nicht wiederverwendbar. Die werden auf ein berechnetes Bild angewendet, von denen es bei stereoskopischer Berechnung nunmal zwei gibt. Als kleines Beispiel kannst du ja mal den Blick auf irgendwas in der Ferne richten und dir eine Hand vor ein Auge halten. Dann hast du auf dem einen Auge noch ein fernes Objekt, das so weit weg ist, daß ein stereoskopisches Sehen dort irrelevant ist, auf dem anderen Auge fehlt dieses Objekt dank nahem Hindernis (der Hand) aber trotzdem. Wenn das ferne Objekt jetzt die Sonne ist, dann ist sie auf dem einen Auge nicht zu sehen und auf dem anderen blendet sie trotzdem. Soweit zur Veranschaulichung, weshalb Postprocessing-Effekte (in diesem Fall Bloom) jeweils separat berechnet werden müssen.
Ferne Objekte könnte man tatsächlich auf eine einmalige Berechnung für die zwei Bilder beschränken. Dazu muß ab einer bestimmten Entfernungsgrenze mit einer zentrierten Kamera ein Bild berechnet werden, das dann als Hintergrund für die beiden weiteren versetzten Bilder verwendet werden kann. Der Sichtkegel muß dazu leicht asymmetrisch sein, damit die versetzten Bilder an der Entfernungsgrenze exakt mit dem Sichtkegel vom Hintergrund zusammenfallen. Wie das aussehen muß, hab ich mal in einer schnellen (und übertrieben dargestellten) Skizze angehängt. Das hat allerdings auch Nachteile. Am Übergang hat man einen wortwörtlichen Knick in der Optik, je näher die Grenze ist desto stärker. Deferred Shading wird durch einen "abgeknickten" Hintergrund zwar nicht unmöglich gemacht, aber erschwert. Und außerdem kann es passieren, daß Sachen im Hintergrund gerendert werden (und damit Rechenzeit verschlingen), die in beiden Teilbildern verdeckt sind.
Hab mich nicht richtig ausgedrückt: für Dinge wie MB werden doch Berechnungen durchgeführt, bis klar wird ("Blurfaktor 3 in X,Y,Z"), welche Objekte wie stark in welche Richtung verschwommen gezeichnet werden müssen (aufgrund von Geschwindigkeit und Bewegungsrichtung). Diese Berechnungen müsste man sich ebenso sparen können und nur das Ergebnniss aus den Berechnungen von Bild 1 anwenden. Nun ist zwar der Blickwinkel fürs 2. Bild etwas anders, aber ich denke mal, dass beim Großteil der Szenen dieser Fehler nicht auffällt - so riesig ist der Augenabstand nun nicht. Und wenn das Objekt in Bild 2 garnicht sichtbar ist, wird es halt auch nicht gezeichnet - fertig.
Das sollte auch für die Berechnung weit entfernte Objekte gültigkeit haben, bei denen man nichtmal wirklich unterscheiden kann, ob es tatsächlich ein Objekt oder nur ein Hintergrundbild ist, womit der Knick in der Optik nicht bemerkbar sein sollte - oder unterschätze ich das Problem?
Wegen das geringen Augenabstands sollten diese Worstcaseszenen (siehe auch Mauerbeispiel oben) auch eher selten auftreten. So nah, dass die Bilder dermaßen stark voneinander abweichen, kommt man den Hindernissen beim zocken doch kaum. Zudem ist man der Wand dann schon so extrem nah, dass das Bild auf dem einen Auge quasi schwarz wird. Bei der Sonne hast du allerdings vollkommen recht, das tritt schon häufiger auf.
Wäre es eigentlich sinnvoll, immer abwechselnd rechtes und linkes Bild voll zu berechnen und das jeweils andere Folgebild mit den Ergebnissen zu füttern? Könnte ja zu unschönen Flimmererlebnissen kommen.
Neomi
2010-06-19, 14:22:08
Beim Motion Blur per Postprocessing wird ja nicht das Objekt verschwommen gezeichnet, sondern scharf. Der Motion Blur wird dann für das gesamte Bild berechnet, in dem das Objekt bloß enthalten ist. Wenn irgendwas in den beiden Bildern sich unterscheidet (und das ist der Fall, wenn Stereoskopie überhaupt eine Wirkung haben soll), kannst du nicht die Ergebnisse des einen Bildes für das andere benutzen. Nur weil es Dinge gibt, die wiederverwendbar sind (wie z.B. die Shadowmap), ist noch lange nicht alles wiederverwendbar. Und Postprocessing gehört nunmal zu den Dingen, die nicht wiederverwendbar sind.
Wäre es eigentlich sinnvoll, immer abwechselnd rechtes und linkes Bild voll zu berechnen und das jeweils andere Folgebild mit den Ergebnissen zu füttern? Könnte ja zu unschönen Flimmererlebnissen kommen.
Wenn jedes Bild voll berechnet wird, wozu dann mit den Ergebnissen des anderen Bildes füttern? Genau die Tatsache, nicht von den Ergebnissen eines anderen Bildes abhängig zu sein, zeichnet eine volle Berechnung aus.
Eine abwechselnde Berechnung (in dem Sinne, daß ein rechtes Bild animationstechnisch in der Mitte zwischen zwei linken Bildern liegt und umgekehrt) ist genau dann sinnvoll, wenn:
1. auch die Darstellung abwechselnd erfolgt (ist z.B. mit Shutterbrillen der Fall).
2. garantiert werden kann, daß zu jedem Wechsel auch ein neues Bild vorliegt.
Konkret bedeutet Punkt 2, daß eine gerantierte Framerate erreicht wird, das wäre bei vorberechnetem Content (z.B. Filme) machbar. Wenn es aber vorkommen kann, daß zu einem Wechsel noch kein neues Bild vorliegt (und bei Spielen, deren Mindestframerate unter 120 liegt, ist das der Fall), würde dann zu einem älteren als den für das andere Auge zuletzt dargestellten Bildes zurückgeschaltet. Die zusätzlichen Bewegungsinformationen durch abwechselnde Bilder lassen dann bewegte Bildteile vor und zurück springen, was gar nicht schön ist.
del_4901
2010-06-19, 14:26:24
Meinst du eine Art Parallax Occlusion Mapping für das vollständige Bild? Interessanter und guter Ansatz. Ich bezweifle aber, daß das auch für nahe Objekte (z.B. die eigene Waffe in einem Egoshooter) akzeptabel funktioniert und auch sämtliche Effekte (z.B. Partikeleffekte wie Feuer, Rauch, Staub, Funken), die nicht in den Z-Buffer schreiben, werden Probleme machen. Aber damit könnte man beispielsweise den gemeinsam genutzten Hintergrund aus meinem vorigen Posting verbessern und die Grenze nach vorne ziehen, z.B. statt 500 m jetzt 50 m. Wenn in diesem Entfernungsbereich noch viele Details kostspielig gerendert werden, könnte sich das gut lohnen.
Den ganzen Transparenten Kram wuerde ich deferred mit eigenem Depth Buffer zeichnen. und bei jedem Materialwechsel dann in den Buffer fuers Linke und Rechte Auge 'resolven'. Die Waffe zeichnet man ja eh in einem anderen Pass damit die nicht in die Geometrie einschneidet, die kann man notfalls auch zweimal zeichnen. Den ganzen PPFx Kram doppelt zu machen ist natuerlich haesslich. Da muesste man sich irgendwas ueberlegen, weil das ziehmlich teuer werden kann. Vllt sollte man die Partikel und Tansparenzen gleich mit Tonemapping und der ganzen PPFx Chain zeichnen und erst am Ende mit premultiplied Alpha auf das Bild packen.
So rendert man nur die Transparenzen und den Basepass extra, bestimmt draus dann die Parallaxen und generiert das zweite Bild aus dem ersten.
Grafiklaie
2010-06-19, 14:49:01
Beim Motion Blur per Postprocessing wird ja nicht das Objekt verschwommen gezeichnet, sondern scharf. Der Motion Blur wird dann für das gesamte Bild berechnet, in dem das Objekt bloß enthalten ist. Wenn irgendwas in den beiden Bildern sich unterscheidet (und das ist der Fall, wenn Stereoskopie überhaupt eine Wirkung haben soll), kannst du nicht die Ergebnisse des einen Bildes für das andere benutzen. Nur weil es Dinge gibt, die wiederverwendbar sind (wie z.B. die Shadowmap), ist noch lange nicht alles wiederverwendbar. Und Postprocessing gehört nunmal zu den Dingen, die nicht wiederverwendbar sind.
Wenn jedes Bild voll berechnet wird, wozu dann mit den Ergebnissen des anderen Bildes füttern? Genau die Tatsache, nicht von den Ergebnissen eines anderen Bildes abhängig zu sein, zeichnet eine volle Berechnung aus.
Eine abwechselnde Berechnung (in dem Sinne, daß ein rechtes Bild animationstechnisch in der Mitte zwischen zwei linken Bildern liegt und umgekehrt) ist genau dann sinnvoll, wenn:
1. auch die Darstellung abwechselnd erfolgt (ist z.B. mit Shutterbrillen der Fall).
2. garantiert werden kann, daß zu jedem Wechsel auch ein neues Bild vorliegt.
Konkret bedeutet Punkt 2, daß eine gerantierte Framerate erreicht wird, das wäre bei vorberechnetem Content (z.B. Filme) machbar. Wenn es aber vorkommen kann, daß zu einem Wechsel noch kein neues Bild vorliegt (und bei Spielen, deren Mindestframerate unter 120 liegt, ist das der Fall), würde dann zu einem älteren als den für das andere Auge zuletzt dargestellten Bildes zurückgeschaltet. Die zusätzlichen Bewegungsinformationen durch abwechselnde Bilder lassen dann bewegte Bildteile vor und zurück springen, was gar nicht schön ist.
Hm, entweder hab ich es einfach nicht verstanden, oder wir reden aneinander vorbei.
Was und wie wird bei MB denn genau berechnet und verschmiert? Das ganze Objekt nicht, ok, die Textur auf dem Objekt? Oder alles, was z.B. "links oben aufm Bild ist", was dann den Bereich betrift, wo sich das/die zu blurrende Objekt/"Grafik" + "Aura" grade befindet? Im letzten Fall muss zumindest bei nahen Objekten eine Neuberechnung erfolgen, da die zu blurrende Fläche im 2. Bild eine andere ist als auf dem 1. - bei weiter entfernten Objekten könnte die Differenz aber nur 1 Pixel oder gar weniger betragen, so dass spätestens bei einer so geringen Verschiebung keine erneute Berechnung erfolgen müsste.
Allerdings mal ein Beispiel aus der Realität der Bildverarbeitung: was ist, wenn auf Bild 1 ein geblurtes Objekt zu sehen ist, welches auf Bild 2 z.B. von von meiner Waffe verdeckt wird und ich mir die 2. Berechnung spare? Würde dann fälschlicherweise die Waffe in Bild2 geblurt gezeichnet?
Grafiklaie
2010-06-19, 15:06:33
Ach ja, mit der "vollen Berechnung" meinte ich das, was AlphaTier geschreiben hat - glaube ich ;). Also das man abwechselnd die Lösungen der Effekte für rechts und links berechnet und für das jeweils andere Bild übernimmt. Also kurz das die Rechenaufwand abwechselnd für die zwei nötigen Stereobilder bei einem Bild immer 1 (=2D) und für das andere z.B. 0,5 ist - nicht immer Faktor 1 für rechts, Faktor 0,5 für links.
Die Frage ist halt, ob man bei den vorgeschlagenen Vereinfachungen z.B. entfernte Dinge nur einmal zu berechnen und auf beiden Bildern gleich zu zeichnen nicht zu Flimmern, Unschärfe und zappelnden Objekten kommt.
Hm, entweder hab ich es einfach nicht verstanden, oder wir reden aneinander vorbei.
Was und wie wird bei MB denn genau berechnet und verschmiert?
Postprocessing (und MB ist Postprocessing) wird wie der Name schon sagt nach dem eigentlichen Rendern auf das fertige Bild angewandt.
Es gibt keine Flächen, Objekte oder ähnliches mehr beim Postprocessing, es gibt nur das fertig gerenderte Bild, welches vor der Ausgabe noch mal irgendwie verändert wird. Es ist im Prinzip das selbe was du mit einem Bild in einem Bildbearbeitungsprogramm alá Photoshop machen könntest.
Die gleichen Filter mit unterschiedlichem Input (die unterschiedlichen Bilder für linkes und rechtes Auge) werden in der Regel auch einen anderen Output erzeugen, wenn sie doch identisch wäre, wäre die Stereoskopie auch umsonst.
Grafiklaie
2010-06-19, 18:31:46
Postprocessing (und MB ist Postprocessing) wird wie der Name schon sagt nach dem eigentlichen Rendern auf das fertige Bild angewandt.
Es gibt keine Flächen, Objekte oder ähnliches mehr beim Postprocessing, es gibt nur das fertig gerenderte Bild, welches vor der Ausgabe noch mal irgendwie verändert wird. Es ist im Prinzip das selbe was du mit einem Bild in einem Bildbearbeitungsprogramm alá Photoshop machen könntest.
Die gleichen Filter mit unterschiedlichem Input (die unterschiedlichen Bilder für linkes und rechtes Auge) werden in der Regel auch einen anderen Output erzeugen, wenn sie doch identisch wäre, wäre die Stereoskopie auch umsonst.
Das würde bei dem Beispiel doch bedeuten, dass das Anwenden des Filters auf das 2. Bild eine fälschlich verblurrte Waffe an der Stelle zur Folge hätte, wo auf Bild 1. das Objekt ist.
Für mein Verständnis also bildlich wie eine klare Folie mit verschmiertem Fleck, die ich auf den Monitor klebe - funktioniert bei Bild 1. wunderbar, bei Bild 2 jedoch nicht. Nur wenn ich ein entfernteres Objekt habe, welches im 2. Bild nicht verdeckt ist und nur um wenige Pixel anders gezeichnet wird, würde die Folie dennoch hinreichend genau passen, ohne Augenkrebs zu bekommen - darauf will ich ja hinaus. Aber wahrscheinlich ist der Rechen- und Programmieraufwand um das alles zu differenzieren größer, als das 2. Bild nochmal komplett durchs Postprocessing zu jagen.
Cubitus
2010-06-20, 12:20:32
Wir müssen unterscheiden.
Was macht der Stereo(3D-Vision) Treiber?
Wie wird die 3D Technik im Spiel selbst z.b Metro 2033 integriert?
Sodass auf zusätzliche Effekte wie DOF und Post Processing nicht verzichtet werden muss!
MadManniMan
2010-06-20, 12:40:56
Da die Frames auch synchronisiert werden müssen, damit immer die passenden Bilder im Wechsel angezeigt werden, wird VSync zur Pflicht. D.h. man benötigt die doppelte GPU-Leistung und muss noch den fps-Einbruch durch VSync einrechnen. Wenn man im 2D-Modus ohne VSync 50 fps bei starker GPU-Limitierung hat, dann sinds im 3D-Modus wahrscheinlich nur noch 20 fps.
Für meine Lösung (zeilenweiser Polfilter an Zalman-ZM220W) ist VSync unnötig - was einen Segen für Nicht-High-End-Hardware darstellt. Kaum auszumalen, wie wenig Spiele ich noch zocken könnte, wenn ich VSync benötigte :eek:
Ferne Objekte könnte man tatsächlich auf eine einmalige Berechnung für die zwei Bilder beschränken.
Warum sollte man sich auf entfernte Objekte festlegen?
Ein Reprojection Cache löst da vieles automatisch.
Wenn man auch noch bereit ist mehr an seiner Pipeline anzupassen, besteht da noch Optimierungspotential.
AintCoolName
2010-06-25, 18:14:35
"You will laugh now," CEO and founder Cevat Yerli told VideoGamer.com. "Our impact is 1.5 per cent. You play 2D or 3D, you have no difference. It's pretty much for free. People, when they ask how, I say it's our little magic.
Quelle (http://www.videogamer.com/news/crytek_magic_prevents_crysis_2_3d_performance_issues.html)
Nakai
2010-06-25, 20:24:32
Haha, Crytek hald. ;D
Die machen das wohl ganz anders, vermutlich per Layer also Tiefe, die dann leicht verschoben werden. Ist physikalisch nicht ganz korrekt, aber einen Unterschied wird man da nicht so sehen, außer bei relativ nahen Objekten.
Naja ka, wie man es sonst machen würde...
mfg
Henroldus
2010-06-25, 23:01:32
ganz klar rendern aus 2 verschiedenen Perspektiven.
Aufwand je nach Overhead ca 2x
ganz klar DIE erste sinnvolle Anwendung für SLI/CF da das Balancing fast autmatisch ausgeglichen sein sollte, wir werden sehen, dauert noch. zumal eine Anzeigegerät ohne Brille und günstig mangelware ist....
Ich vermute sie machen es als Screenspace-Effekt. Da sind sie sowieso Spezialisten drin.
Haha, Crytek hald. ;D
Es ist auch eine Frage wie man die Performance ermittelt ;)
Am Monitor kommen ja noch immer gleich viel FPS (-1,5% von mir aus) an, aber jedes Auge bekommt jeweils nur jedes 2. zu sehen.
MadManniMan
2010-06-26, 11:21:49
Ich vermute sie machen es als Screenspace-Effekt. Da sind sie sowieso Spezialisten drin.
Sry 4 beeing dumb, aber kannst Du das vielleicht ganz fix andeuten?
Sry 4 beeing dumb, aber kannst Du das vielleicht ganz fix andeuten?
Eventuell berechnen sie das Bild seitlich etwas größer als für die Monitorauflösung notwendig und transformieren das ganze dann in 2 unterschiedliche Blickwinkel. Da man im Spiel auch die Tiefe jedes einzelnen Pixels kennt könnte das sogar recht gut funktionieren, nur Objekte die im berechneten Blickwinkel verdeckt sind können dann logischerweise auch nicht im transformierten auftauchen.
Aber selbst hier kann ich mir nicht vorstellen, dass man mit nur 1,5% Verlust auskommt. Da halte ich es schon für Wahrscheinlicher, dass Crytek einfach sagt wir schicken eben 59 statt 60fps an den Monitor, und dabei verschweigt, dass jedes Auge nur jedes 2. Bild zu sehen bekommt.
Neomi
2010-06-26, 12:39:33
Am Monitor kommen ja noch immer gleich viel FPS (-1,5% von mir aus) an, aber jedes Auge bekommt jeweils nur jedes 2. zu sehen.
Das ist Quatsch. Ein Performancehit von nur 1,5 % ist richtig gut und meint natürlich 1,5 % weniger Frames/s pro Auge als vorher insgesamt. Wenn die Augen abwechselnd Bilder bekommen und die zu einer Gesamtperformance zusammengezählt würden, wäre ein Hit von 1,5 % nichts besonders gutes, sondern eher peinlich schlecht.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.