HDR auf R300 in Half-life 2

[Tigerchen]

Vertue ich mich oder sehe ich in den Kanal-Leveln sowas wie die berühmten HDR-Effekte auf meiner R9700 Pro?

Weil ic die "Orginal HDR-nV40 Effekte noch nie gesehen habe weiß ich natürlich nicht ob ich da was verwechsle. Bitte um Aufklärung.

[dildo4u]

Nein das ist nichtmal im entferntesten HDR.

[Gast]

Vom technischen her natürlich nicht, optisch ist es ein ähnlicher Effekt

[Gast]

Sorry, aber was ist HDR?

+danke

[mapel110]

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=183257
so ähnlich jedenfalls :ugly:

http://www.xbitlabs.com/articles/video/display/farcry13.html

[Tigerchen]

Vom technischen her natürlich nicht, optisch ist es ein ähnlicher Effekt


Warum wird das echte HDR denn so in den Himmel gelobt, wenn man ähnliches doch viel billiger haben kann. Manche Screenshots wirken ja toll. Aber andere lassen doch Zeifel aufkommen:

http://onfinite.com/libraries/167426/d6a.jpg

[Kladderadatsch]

Warum wird das echte HDR denn so in den Himmel gelobt, wenn man ähnliches doch viel billiger haben kann. Manche Screenshots wirken ja toll. Aber andere lassen doch Zeifel aufkommen:

http://onfinite.com/libraries/167426/d6a.jpg

weil hdr dynamisch die licht-intensität ändert.

[Gast]

Warum wird das echte HDR denn so in den Himmel gelobt, wenn man ähnliches doch viel billiger haben kann.
Weil einige 3DGurus (möchte hier nicht persönlich werden) es alles vom technischem her betrachten. Ob es bei der BQ wirklich was bringt, interessiert keinen.

http://onfinite.com/libraries/167426/d6a.jpg
Das sieht wirklich übel aus.

[Demirug]

Das HDR bei Farcry ist sowieso reingepfuscht. Der gesamte Content wurde nicht mit HDR im Hinterkopf entworfen. Deswegen ist es nicht verwunderlich wenn es zu merkwürdigen Stellen kommt.

[tb]

Für die meisten Leute ist HDR einfach nur ein Blur/Glow-Effekt. Dies ist aber falsch! HDR bedeutet High Dynamic Range - und genau dies ist es. Farbinformationen werden mit einem viel größerem Dynamikumfang gespeichert. Alles andere sind Berechnungen/Effekte, welche erst dadurch möglich werden. Dort ist dann alles erlaubt, was der Entwickler möchte, ob realistisch oder nicht....
HDR bietet alsos die Grundlage für verbesserte Berechnungen im Bild. Dadurch können u.a. folgende Effekte erzielt werden, welche durch Fake-HDR nur schwer realisierbar sind:

- dynamische Helligkeitsanpassung
- Blauverschiebung (Farben in lichtarmen Szene tendieren in ein Blaugrau)
- greller Glanzeffekt
- ...

Die meisten Spiele, welche mit HDR werben, verwenden jedoch bisher nur den Glanzeffekt, welcher auch mit DX8 Karten, bzw. DX9 Karten ohen vollst. Fließkommatextursupport zu erzielen ist und kein HDR benötigt.
Die HDR Methode in FarCry ist nicht gerade eine gute Implementierung. Half-Life 2 scheint da auch nicht mehr zu bieten.


weitere Infos:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_Summer_04/directx/graphics/TutorialsAndSamples/Samples/HDRLighting.asp
http://www.debevec.org/Research/HDR/

Thomas

[Demirug]

Half-Life 2 scheint da auch nicht mehr zu bieten.

Thomas

Eigentlich sogar weniger. Bisher konnte ich noch keine Verwendung von FP Texturen oder Buffern feststellen. Oder gibt es da noch einen Trick?

[betasilie]

HDR wird sicherlich ganz groß kommen. Mit HDR werden Effekte wie im Film möglich sein, weil man einfach eine Farbdynmaik hat, mit der schlicht alles möglich ist, wie beim echtem Film.

Mag sein, dass momentan Glow und Bloomeffekte den Zockern subjektiv völlig reichen, wenn allerdings erstmal Spiele kommen, deren Content voll auf HDR ausgelegt sind, wird jeder den Unterschied zu solchen Pseudo HDR Effekten sehen können. :)

Ich freue mich tierisch auf HDR, auch wenn ich erst ab 2006 mit Spielen rechne, die die Vorteile von HDR deutlich zeigen werden.

[Demirug]

betareverse, wenn dir das erste mal jemand eine Blendgrante vor die Füsse wirft wenn du gerade mit dem Restlichverstärker rumläufst (um überhaupt noch was zu sehen) überlegst du dir das nochmal.

Ich dachte mir geht der Monitor kaputt.

[tb]

Eigentlich sogar weniger. Bisher konnte ich noch keine Verwendung von FP Texturen oder Buffern feststellen. Oder gibt es da noch einen Trick?

Nö. Das "mehr" bezog sich auf Bloom/Glare-Effekt, welcher ja gern als HDR bezeichnet wird.

P.S. Momentan verwende Half-Life 2 nur einen Bloom-Effekt, kein HDR, also auch keine 64 Bit FP/Int Texturen :( jedoch ist die R3xx/R4xx HDR Abfrage noch aktive "mat_info" ...

Thomas

[Quasar ohne Keks]

Warum wird das echte HDR denn so in den Himmel gelobt, wenn man ähnliches doch viel billiger haben kann. Manche Screenshots wirken ja toll. Aber andere lassen doch Zeifel aufkommen:

http://onfinite.com/libraries/167426/d6a.jpg
Hm, tja, vielleicht weil es eben nur "sowas ähnliches" ist und nicht dasselbe?

Warum ist DX9 toller als DX8, welches toller als DX7 ist? Die allermeisten Effekte bekommt man "so ähnlich" auch mit DX7 hin - trotzdem ist DX7 sowas von untendurch in der Spielergemeinde...

[betasilie]

betareverse, wenn dir das erste mal jemand eine Blendgrante vor die Füsse wirft wenn du gerade mit dem Restlichverstärker rumläufst (um überhaupt noch was zu sehen) überlegst du dir das nochmal.

Ich dachte mir geht der Monitor kaputt.
Hehe. Genau das wollen wir doch; Realismus bis uns der CRT um die Ohren fliegt.

[Spasstiger]

Eigentlich könnte ein echter HDR Monitor für HDR Spiele nicht schade. Also einer, wo es wirklich in den Augen tut, wenn es sehr hell ist und nicht weh tut, wenn nur normales weiß ist. So wie in Wirklichkeit halt. Schonmal in die Sonne mit voll geöffneten Augen geschaut? :biggrin:

[tb]

Eigentlich könnte ein echter HDR Monitor für HDR Spiele nicht schade. Also einer, wo es wirklich in den Augen tut, wenn es sehr hell ist und nicht weh tut, wenn nur normales weiß ist. So wie in Wirklichkeit halt. Schonmal in die Sonne mit voll geöffneten Augen geschaut? :biggrin:

http://www.cs.ubc.ca/~heidrich/Projects/HDRDisplay/

[Tigerchen]

Für die meisten Leute ist HDR einfach nur ein Blur/Glow-Effekt. Dies ist aber falsch! HDR bedeutet High Dynamic Range - und genau dies ist es. Farbinformationen werden mit einem viel größerem Dynamikumfang gespeichert. Alles andere sind Berechnungen/Effekte, welche erst dadurch möglich werden. Dort ist dann alles erlaubt, was der Entwickler möchte, ob realistisch oder nicht....
HDR bietet alsos die Grundlage für verbesserte Berechnungen im Bild. Dadurch können u.a. folgende Effekte erzielt werden, welche durch Fake-HDR nur schwer realisierbar sind:

- dynamische Helligkeitsanpassung
- Blauverschiebung (Farben in lichtarmen Szene tendieren in ein Blaugrau)
- greller Glanzeffekt
- ...

Die meisten Spiele, welche mit HDR werben, verwenden jedoch bisher nur den Glanzeffekt, welcher auch mit DX8 Karten, bzw. DX9 Karten ohen vollst. Fließkommatextursupport zu erzielen ist und kein HDR benötigt.
Die HDR Methode in FarCry ist nicht gerade eine gute Implementierung. Half-Life 2 scheint da auch nicht mehr zu bieten.

weitere Infos:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_Summer_04/directx/graphics/TutorialsAndSamples/Samples/HDRLighting.asp
http://www.debevec.org/Research/HDR/

Thomas


Ah ja. Man könnte es also so zusammen fassen. Entweder man macht es billig wie bei Half-life 2, so daß alle was davon haben. Oder aber man implementiert es von Anfang an richtig mit allen Schikanen. Schon allein damit es nicht zu so Merkwürdigkeiten wie babyblaue Stahlträger kommt.

Was meinst du. Werden zukünftige Grafikkarten da bessere Implementationen bieten die das Ganze so richtig beschleunigen? Im Moment scheint HDR ja einen ziemlichen Kraftakt für die Grafikkarte darzustellen.

[Dunkeltier]

Ah ja. Man könnte es also so zusammen fassen. Entweder man macht es billig wie bei Half-life 2, so daß alle was davon haben. Oder aber man implementiert es von Anfang an richtig mit allen Schikanen. Schon allein damit es nicht zu so Merkwürdigkeiten wie babyblaue Stahlträger kommt.

Was meinst du. Werden zukünftige Grafikkarten da bessere Implementationen bieten die das Ganze so richtig beschleunigen? Im Moment scheint HDR ja einen ziemlichen Kraftakt für die Grafikkarte darzustellen.


Der Effekt ist doch richtig dargestellt, der Rundstahl wird halt überblendet. So solls sein. Außerdem hat eine fehlerhafte Implementierung in diesen Falle eher was mit der Engine als mit der Grafikkarte zu tun.

[Tigerchen]

Der Effekt ist doch richtig dargestellt, der Rundstahl wird halt überblendet. So solls sein. Außerdem hat eine fehlerhafte Implementierung in diesen Falle eher was mit der Engine als mit der Grafikkarte zu tun.


Daß der Effekt so korrekt ist bezweifel ich. Kennst du ein Foto der Wirklichkeit wo sowas zu sehen ist? Hellblau erstrahlender rostiger Stahl?

[Dunkeltier]

Daß der Effekt so korrekt ist bezweifel ich. Kennst du ein Foto der Wirklichkeit wo sowas zu sehen ist? Hellblau erstrahlender rostiger Stahl?







Kuck dir mal an, wie auf diesen realen Bild der schwarze Boden sich leicht rötlich verfärbt durch die Sonne: http://www.mnd-umwelttechnik.fh-wiesbaden.de/flare/Flare/Weltraumwetter/sonne.jpg

Oder hier, wie der Typ "überschienen" wird: http://www.meneweger.sbg.at/pics/pberber%20sonne.jpg

Je nach Situation kann das Gegenlicht der Sonne wirklich viel stärker sein, und läßt Details verschwinden/ Objekte in Farbschatten absaufen/ und sonstiges.


Edit: Am besten ist aber immer noch dieses Bild: http://www.solar-gerold.de/bilder/sonne%20mit%20paar.jpg VS http://onfinite.com//libraries/15633/167423/banner_12918670041120101840.jpg

Da säuft alles ab... Nur statt im blau wie bei dir im abendlichen Rot. Liegt halt an den Staubteilchen in der Atmossphäre und am Sonnenstand... Aber für dich scheint wohl selbst die Realität unreal zu sein. ;)

[Tigerchen]

Kuck dir mal an, wie auf diesen realen Bild der schwarze Boden sich leicht rötlich verfärbt durch die Sonne: http://www.mnd-umwelttechnik.fh-wiesbaden.de/flare/Flare/Weltraumwetter/sonne.jpg

Oder hier, wie der Typ "überschienen" wird: http://www.meneweger.sbg.at/pics/pberber%20sonne.jpg

Je nach Situation kann das Gegenlicht der Sonne wirklich viel stärker sein, und läßt Details verschwinden/ Objekte in Farbschatten absaufen/ und sonstiges.


Edit: Am besten ist aber immer noch dieses Bild: http://www.solar-gerold.de/bilder/sonne%20mit%20paar.jpg VS http://onfinite.com//libraries/15633/167423/banner_12918670041120101840.jpg

Da säuft alles ab... Nur statt im blau wie bei dir im abendlichen Rot. Liegt halt an den Staubteilchen in der Atmossphäre und am Sonnenstand... Aber für dich scheint wohl selbst die Realität unreal zu sein. ;)

Wenn du das unbedingt so sehen willst will ich dich nicht weiter aufhalten.

[Dunkeltier]

Wenn du das unbedingt so sehen willst will ich dich nicht weiter aufhalten.



Es steht dir ja frei, HDR abzuschalten wenn du damit nicht klarkommst.

[Coda]

Das Problem an dem Bild ist eher dass das Blau des Meeres unrealistisch kräftig ist. Aber es ist schon richtig das wenn man in nen blauen Spot schauen würde alles blau wird drumrum.

Das ist der selbe Effekt wie hier: http://home.ewha.ac.kr/~kimy/class/CO643/rthdribl.jpg
oder hier: http://www.deathfall.com/images/misc/hdriRealTime-001.jpg

Und so Bilder bekommst du wirklich nur mit FP Blending hin, ob die jetzt im Pixelshader oder im ROP laufen ist prinzipiell egal. Es ist im ROP nur um einiges schneller.

[Jesus]

Das Problem an dem Bild ist eher dass das Blau des Meeres unrealistisch kräftig ist. Aber es ist schon richtig das wenn man in nen blauen Spot schauen würde alles blau wird drumrum.

Das ist der selbe Effekt wie hier: http://home.ewha.ac.kr/~kimy/class/CO643/rthdribl.jpg
oder hier: http://www.deathfall.com/images/misc/hdriRealTime-001.jpg

Und so Bilder bekommst du wirklich nur mit FP Blending hin, ob die jetzt im Pixelshader oder im ROP laufen ist prinzipiell egal. Es ist im ROP nur um einiges schneller.

Also Bild 1 sieht bei Painkiller genauso aus, wenn man in die Sonne schaut (die Waffen glenzen dabei so ähnlich )

[Coda]

Also Bild 1 sieht bei Painkiller genauso aus, wenn man in die Sonne schaut (die Waffen glenzen dabei so ähnlich )
Nicht genauso, sonder "so ähnlich". Das ist kein HDR, weil eben nicht mit High Definition gerendert wird. Und komm jetzt nicht mit "das ist doch genauso gut", mit HDR kann man deutlich mehr machen als den Overbright Effekt der Sonne (das ist ein Hack in Painkiller, bei normalem HDR würde das auch mit jeder anderen Lichtquelle funktionieren)
Besonders anschaulich wird HDR bei Cubemaps, weil multipliziert wird (siehe Bild 2 auf den Kugeln). Hier wäre ohne HDR kein grelles Weiß sondern grau.

HDR ist für realistisches Rendering immens wichtig, das ist für ziemlich viele Sachen das was das Bild noch unrealistisch aussehn lässt bei GC.

[aths]

HDR ist für realistisches Rendering immens wichtig, das ist für ziemlich viele Sachen das was das Bild noch unrealistisch aussehn lässt bei GC.Allerdings. Ohne HDR (bzw. MDR) müsste man in den normalen Helligkeitsbereichen extrem Auflösung opfern. Mit "Fake-HDR" kann man lediglich bisschen Überstrahlung erzeugen, es ist aber wichtig, durchgehend Overbright Lighting zu haben, und das bei hoher Intensitäts-Auflösung. Nur mit HDR (bzw. MDR-) Effekten kann man Tageslicht-Beleuchtung realistisch rendern.

[betasilie]

Daß der Effekt so korrekt ist bezweifel ich. Kennst du ein Foto der Wirklichkeit wo sowas zu sehen ist? Hellblau erstrahlender rostiger Stahl?



Das ist oft das Problem. Wenn neuen Effekte kommen meinen viele Leute, dass es nicht realistisch wäre (z.B. Glanzeffekte auf Hölzböden, Haut etc), aber das liegt einfach dran, dass man das im Alltag garnicht mehr so wahrnimmt. Bei HDR ist es das selbe.

Im Endeffekt wird es künstlerisch nun noch anspruchsvoller gut Spielszenen zu entwerfen. Ist halt wie in der Fotografie; man kann mit ein und der selben Kamera einen Ort je nach Kameraeinstellung und Tageszeit total unterschiedlich darstellen.

HDR ist ein zwingender, riesiger Schritt in richtung Fotorealismus.

Bei FarCry wirkt das ganze schlicht so übertrieben, weil es schon ohne HDR völlig hochgepitchte Farben hat, was dann mit HDR nochmal verstärkt wird. Das sowas also mit anderem Content besser aussehen würde, sollte doch langsam wirklich klar werden.

[Demirug]

Allerdings. Ohne HDR (bzw. MDR) müsste man in den normalen Helligkeitsbereichen extrem Auflösung opfern. Mit "Fake-HDR" kann man lediglich bisschen Überstrahlung erzeugen, es ist aber wichtig, durchgehend Overbright Lighting zu haben, und das bei hoher Intensitäts-Auflösung. Nur mit HDR (bzw. MDR-) Effekten kann man Tageslicht-Beleuchtung realistisch rendern.

Ich würde das nicht nur auf Tageslicht begrenzen. Auch im Bereich der Nachtlicht Darstellung ermöglicht HDR besseres rendern.

[betasilie]

Ich würde das nicht nur auf Tageslicht begrenzen. Auch im Bereich der Nachtlicht Darstellung ermöglicht HDR besseres rendern.
Ack. Mann muss sich nur mal eine Nachtszene in einer Stadt vorstellen, wo man von gut beleuteten Straße in eine dunkle Gasse abbiegt und dann nach einigen Sekunden den Sternenhimmel anschaut. :) Oder Suchstrahler in einem Wald, wo einen nicht nur die Strahler kirre machen, sondern auch die hell angeleuchteten Objekte. *schwärm*

[aths]

Ich würde das nicht nur auf Tageslicht begrenzen. Auch im Bereich der Nachtlicht Darstellung ermöglicht HDR besseres rendern.Allerdings. In Doom3 ist es dunkel, wenn es dunkel ist. Dabei gewöhnt sich das Auge daran, nach einiger Zeit müsste man umrisshaft mehr sehen als nur schwarz.

[HOT]

Wenn man Farcry mal ein wenig mit HDR spielt und dagegen Painkiller setzt, wird auffallen, was HDR eigentlich wirklich ist, obwohl es in Farcry fehlerhaft, sagen wir mal early-beta ist. Denn dann fällt auf, dass die heutige Grafik zwar gut ist, aber noch viiiieeeel besser sein könnte :D

[Tigerchen]

Das ist oft das Problem. Wenn neuen Effekte kommen meinen viele Leute, dass es nicht realistisch wäre (z.B. Glanzeffekte auf Hölzböden, Haut etc), aber das liegt einfach dran, dass man das im Alltag garnicht mehr so wahrnimmt. Bei HDR ist es das selbe.
.

Ähem. Ich habe sehen wirklich gelernt und schon reichlich Bilder gemalt wo ich mich mit dem Problem des Raums in der Tiefe und des Lichts auseinandergesetzt habe. Ich kann schon beurteilen was realistisch ist und was nicht. Und dieses FarCry Bild ist es nicht. Die Sonne ist kein blauer Spot.

[Tigerchen]

Allerdings. In Doom3 ist es dunkel, wenn es dunkel ist. Dabei gewöhnt sich das Auge daran, nach einiger Zeit müsste man umrisshaft mehr sehen als nur schwarz.

Nicht nur dass. Bei genügend schwachem Licht siehst du schwarz/weiß. Nur da wo das Licht ausreicht wirds bunt. Beleuchtung/Schatten bei Doom3 sind sowieso auf Effekt und nicht auf Realismus ausgerichtet. Das ist auch durchaus zweckmäßig bei so einem Schocker. (Mir ists trotzdem zu dunkel)

[Coda]

Ähem. Ich habe sehen wirklich gelernt und schon reichlich Bilder gemalt wo ich mich mit dem Problem des Raums in der Tiefe und des Lichts auseinandergesetzt habe. Ich kann schon beurteilen was realistisch ist und was nicht. Und dieses FarCry Bild ist es nicht. Die Sonne ist kein blauer Spot.
Ack. Aber das liegt wie gesagt nicht an HDR, sondern am falschen Content von Far Cry dafür.
Hier nochmal ein gutes Beispiel: http://www.deathfall.com/article.php?sid=3384

[Tigerchen]

Ack. Aber das liegt wie gesagt nicht an HDR, sondern am falschen Content von Far Cry dafür.
Hier nochmal ein gutes Beispiel: http://www.deathfall.com/article.php?sid=3384

Darum bin ich ja auch für mich zu dem Fazit gekommen daß Crytec oder andere es gescheit machen sollten bevor es auf die Menschheit losgelassen wird.

Warum wollen einige aus der Kritik an der momentanen Situation eine Ablehnung von HDR durch meine Person herauslesen?

Ich wäre allerdings glücklich wenn man sich im Moment mehr mit dieser Overbright-Geschichte befassen würde da ja Hardware für HDR doch noch sehr, sehr, sehr dünn gesät ist.

[Dr Hake]

Ähem. Ich habe sehen wirklich gelernt und schon reichlich Bilder gemalt wo ich mich mit dem Problem des Raums in der Tiefe und des Lichts auseinandergesetzt habe. Ich kann schon beurteilen was realistisch ist und was nicht. Und dieses FarCry Bild ist es nicht. Die Sonne ist kein blauer Spot.


fack. Die Traeger koennten hoechstens (ein bisschen) blau strahlen, wenn sie direkt von einem blauen Spot von vorne angestrahlt wuerden. Da das Licht von hinten kommt, kann sogar der Ueberstrahleffekt des Himmels nicht so viel ausmachen. Die gezeigten Gegenbeweise zeigen jeweils andere Szenarien: entweder wird eine reflektierende Flaeche von vorne angestrahlt, oder die Oberflaechen sind nicht 100% Lichtabsorbierend, und/oder die Restlichtmenge ist bedeutend geringer als auf dem FC screenie. Ob das jetzt speziel an FC liegt, oder es mit HDR unmoeglich ist solche Grenzfaelle zu vermeiden entzieht sich allerdings meiner Kenntnis.

[Coda]

Ich wäre allerdings glücklich wenn man sich im Moment mehr mit dieser Overbright-Geschichte befassen würde da ja Hardware für HDR doch noch sehr, sehr, sehr dünn gesät ist.
Muss man HDR in FC benützen? :rolleyes:

Diese "Overbright Geschichte" kann man damit überhaupt nicht vergleichen und HDR Cubemaps kann man z.B. wunderbar mit jeder PS 2.0 HW benützen.
Es muss ja nicht gleich der ganze Framebuffer HDR sein.

[Tigerchen]

Muss man HDR in FC benützen? :rolleyes:

Diese "Overbright Geschichte" kann man damit überhaupt nicht vergleichen und HDR Cubemaps kann man z.B. wunderbar mit jeder PS 2.0 HW benützen.
Es muss ja nicht gleich der ganze Framebuffer HDR sein.

Hmm. Einige hier haben das so rübergebracht daß man dafür schon einen nV40 braucht und selbst der dann noch derbe mit Performanceeinbrüchen zu kämpfen hat.

[Coda]

Würde er bei einer intelligenten Implementierung nicht mal haben, aber Demirug hat ja anschaulich analyisiert das FC eigentlich alles verpfuscht hat was es zu verpfuschen gab.

75% der Performance wäre mit HDR sicherlich noch drin, wenn man's richtig macht.

[tb]

Ah ja. Man könnte es also so zusammen fassen. Entweder man macht es billig wie bei Half-life 2, so daß alle was davon haben. Oder aber man implementiert es von Anfang an richtig mit allen Schikanen. Schon allein damit es nicht zu so Merkwürdigkeiten wie babyblaue Stahlträger kommt.

Was meinst du. Werden zukünftige Grafikkarten da bessere Implementationen bieten die das Ganze so richtig beschleunigen? Im Moment scheint HDR ja einen ziemlichen Kraftakt für die Grafikkarte darzustellen.


Also erstmal zu Half-Life 2, im Moment verwendet es kein HDR, sprich es werden keine 64 Bit or 128 Bit Render Targets verwendet, welche für HDR nötig sind. Es verwendet einfach nur einen Bloom-Filter, welcher nichts mit HDR zu tun hat.

Zukünftige Karten werden die gleichen Probleme haben, wie heutige. HDR - High Dynamic Range braucht min. 2 mal soviel Bandbreite wie normles 32 Bit Rendering. Dazu kommen dann diverse Effekte wie z.B. Bloom/Glow Filterung, Blauverschiebung und autom. Helligkeitsanpassung. Je nachdem wie Rechenintensiv diese Schritte sind, benötigt HDR mal mehr, mal weniger Befehle pro Pixel.

Thomas

[aths]

Zukünftige Karten werden die gleichen Probleme haben, wie heutige. HDR - High Dynamic Range braucht min. 2 mal soviel Bandbreite wie normles 32 Bit Rendering. Dazu kommen dann diverse Effekte wie z.B. Bloom/Glow Filterung, Blauverschiebung und autom. Helligkeitsanpassung. Je nachdem wie Rechenintensiv diese Schritte sind, benötigt HDR mal mehr, mal weniger Befehle pro Pixel.Die Entwicklung sehe ich so: Alles bisher ist Vorgeplänkel, also 16 oder 32 Bit pro Pixel. Jetzt sind wir in einer Übergangzeit, später werden wir uns fragen, wie man es nur ohne HDR ausgehalten hat.

Antialiasing wird hin und wieder als hinterlistige Methode verschrien, dem User eine teure Grafikkarte schmackhaft zu machen. Dabei ist Antialiasing bei normalen Render-Methoden für eine gute Grafik unabdingbar.

Es wird wohl nicht mehr lange dauern bis gelästert wird, mit den HDR-Effekten wollen die nur ihre eigentlich zu starke Grafikkerne an den Mann bringen. Dabei ist die FP16-Auflösung und die gebotene Dynamik unbedingt notwendig (und stellt eher die Untergrenze dar) um realistische Beleuchtungsverhältnisse zu berechnen.

[tb]

Jetzt sind wir in einer Übergangzeit...

Ist man dies nicht immer, auf dem Weg zur Perfektion?
Ob man FSAA bei einem Display mit 8192x8192 Pixeln noch braucht ;) ?

Thomas

[aths]

Ist man dies nicht immer, auf dem Weg zur Perfektion?
Ob man FSAA bei einem Display mit 8192x8192 Pixeln noch braucht ;) ?
Wozu quadratische Displays? Wozu ultrahohe Auflösungen? VHS hat 240 Zeilen, NTSC 480, PAL 576, HDTV je nach dem 720 oder 1152. Reicht für eine realistische Darstellung offenbar aus.

[betasilie]

Wozu quadratische Displays? Wozu ultrahohe Auflösungen? VHS hat 240 Zeilen, NTSC 480, PAL 576, HDTV je nach dem 720 oder 1152. Reicht für eine realistische Darstellung offenbar aus.
Mal abgesehen davon, dass tbs Format nicht ergonomisch ist, was er sicherlich gemerkt hat, ... Du empfindest Pal als realistisch? :O

Also ich merke genau, wann ich auf einen Fernseher gucke und wann ich aus dem Fenster schaue. ... Und meinst Du in 100 Jahren werden die Leute noch mit HDTV 1080 zufrieden sein?

Richtig realistisch wird es, wenn man nahezu die Auflösung des menschlichen Auges erreicht. Also entweder janz weit weg vom Monitor oder aber extrem hohe Auflösungen bedeutet.

[aths]

Mal abgesehen davon, dass tbs Format nicht ergonomisch ist, was er sicherlich gemerkt hat, ... Du empfindest Pal als realistisch? :OJahrzehntelang kamen die Leute mit PAL und sogar NTSC, und lange Zeit sogar mit VHS aus.

Ein Fernsehbild ist trotz gegenüber Computergrafik geringer Auflösung realistischer als Far Cry mit HDR-Patch :) oder ein anderes modernes Spiel. Um den Realismus zu steigern ist es nicht notwendig, die Auflösung so weit zu treiben dass man FSAA nicht mehr merken würde.

HDTV mit 1080 Zeilen halte ich persönlich für extrem wünschenswert. Doch wenn man eine gegebene Grafikleistung hat, ist es nicht immer klug, diese nur in Auflösung zu stecken. Echtes Motion Blur z. B. würde helfen, dass wir uns an vergleichsweise geringen Frameraten nicht mehr stören würden. Außerdem wäre es realistischer.

Um Pixel kleiner zu kriegen steigt der Rechenaufwand quadratisch. Selbst Supersampling Antialiasing skaliert "nur" linear, sofern man eine sparsed Subpixelmaske einsetzt. Anstatt die Grafikkarten für 1600x1200 zu optimieren, wo kaum einer den passenenden Monitor hat, wäre es sinnvoller, bestmögliche anisotrope Filterung anzubieten. Der AF-Aufwand steigt ebenfalls nur linear.

Die wahre Optimierung bestünde also darin, den Anwender vom Zwang zu erlösen, für den besten Grafikeindruck die Auflösung zu maximieren. (Das klingt nach einem guten Thema für eine Kolumne.)

[Chris Lux]

Richtig realistisch wird es, wenn man nahezu die Auflösung des menschlichen Auges erreicht. Also entweder janz weit weg vom Monitor oder aber extrem hohe Auflösungen bedeutet.
'Given a foveal resolution of the eye of 30 arc-sec, 4800x3840 pixels are needed for a 40°x30° FOV display viewed at 46cm.'
Comparison of the Human Sensory Capabilities with Technical Specifications of Virtual Environment Equipment, W. Barfield, C. Hendrix et al 1995

auf deutsch so weit weg sind wir dann auch nicht mehr von den auflösungen. ich habe mir aber noch nicht ganz überlegt wie das abtasttheorem da reinpasst (2*höchste frequenz <= abtastfrequenz), dh ob nicht doch die doppelte auflösung nötig wäre um auf AA verzichten zu können.

[Gast]

Kann eine PS2 HDR ?

Habe eben meine US Version von MGS 3 bekommen, und da sieht man am Anfang einen wirklich sehr beeindruckenden Blendeffekt (als die Klappe vom Flugzeug aufgeht und man die Sonne sieht). Das Bild wird sehr hell, die umrisse verschwimmen, nach ein paar Sekunden isses vorbei.

Sieht verdammt nach HDR aus ! (wesentlich besser als das in FC auf jeden Fall)

[aths]

Kann eine PS2 HDR ?

Habe eben meine US Version von MGS 3 bekommen, und da sieht man am Anfang einen wirklich sehr beeindruckenden Blendeffekt (als die Klappe vom Flugzeug aufgeht und man die Sonne sieht). Das Bild wird sehr hell, die umrisse verschwimmen, nach ein paar Sekunden isses vorbei.

Sieht verdammt nach HDR aus ! (wesentlich besser als das in FC auf jeden Fall)Nicht alles, was Blendeffekte erzeugt, ist HDR-Lighting. Ich würde mich wundern, wenn die PS2 über HDR-Rendertargets verfügt.

[betasilie]

Jahrzehntelang kamen die Leute mit PAL und sogar NTSC, und lange Zeit sogar mit VHS aus.

Ein Fernsehbild ist trotz gegenüber Computergrafik geringer Auflösung realistischer als Far Cry mit HDR-Patch :) oder ein anderes modernes Spiel. Um den Realismus zu steigern ist es nicht notwendig, die Auflösung so weit zu treiben dass man FSAA nicht mehr merken würde.

HDTV mit 1080 Zeilen halte ich persönlich für extrem wünschenswert. Doch wenn man eine gegebene Grafikleistung hat, ist es nicht immer klug, diese nur in Auflösung zu stecken. Echtes Motion Blur z. B. würde helfen, dass wir uns an vergleichsweise geringen Frameraten nicht mehr stören würden. Außerdem wäre es realistischer.

Um Pixel kleiner zu kriegen steigt der Rechenaufwand quadratisch. Selbst Supersampling Antialiasing skaliert "nur" linear, sofern man eine sparsed Subpixelmaske einsetzt. Anstatt die Grafikkarten für 1600x1200 zu optimieren, wo kaum einer den passenenden Monitor hat, wäre es sinnvoller, bestmögliche anisotrope Filterung anzubieten. Der AF-Aufwand steigt ebenfalls nur linear.

Die wahre Optimierung bestünde also darin, den Anwender vom Zwang zu erlösen, für den besten Grafikeindruck die Auflösung zu maximieren. (Das klingt nach einem guten Thema für eine Kolumne.)
Ok, jetzt weiß cih worauf Du hinaus willst. ;) Stimmt natürlich schon, das es nichts bringt nur die Auflösung immer höher zu pushen.

Deswegen bin ich übrigens so ein Freund der PS2, weil mit der EE der PS2 so tolle Animationen möglich sind, die im Gesamteindruck manches PS2 Spiel realistsicher erscheinen lassen, als man ein grafisch besseres Spiel.

Von daher stimme ich dir absolut zu, dass Projektionsauflösung, Polygone und Basistexturen nicht ausreichen, um ein Spiel realistisch erscheinen zu lassen. Neue tolle Features wie HDR müssen her. ;) ... Zurückdrehen will ich allerdings auch nicht mehr mit der Auflösung.

[tb]

Wozu quadratische Displays? Wozu ultrahohe Auflösungen? VHS hat 240 Zeilen, NTSC 480, PAL 576, HDTV je nach dem 720 oder 1152. Reicht für eine realistische Darstellung offenbar aus.

Es ging mir bei den 8192x8192 nur um FSAA, nicht um eine realistische Darstellung.

Thomas

[DanMan]

Bin da gerade auf der M$ Seite drauf gestoßen. Keine Ahnung ob das bekannt ist oder nicht: http://www.daionet.gr.jp/~masa/rthdribl/

[FlashBFE]

Ich bin auch der Meinung, dass früher oder später nichts an hoher Auflösung vorbeiführt und dann wäre auch das Thema FSAA erledigt. Es bremsen ja eher die Monitore in der Auflösung als die Grafikkarten. Tatsächlich schalte ich bei meinem 17'' TFTLCD mit der üblichen Auflösung nur selten FSAA ein, weil die Pixel schon klein genug sind bei größerem Abstand und ich lieber AF und die Details hochdrehe. Neue Features bei Grafikkarten und Spielen kommen mit der Zeit sowieso dazu und mit der Leistung gehts logischerweise auch immerweiter nach oben, also wäre es unlogisch, ewig auf den 1024*768 sitzen zu bleiben.
Crytek hat HDR mit Absicht nicht in FC offiziell eingebaut, vielleicht weil es nur ein Funktionalitätstest für das nächste Spiel, welches auf dieser Engine basiert, sein sollte. Bei derartig leistungsfressender Implementation hätten die sich eh nur Kritik anhören können, wenn sie es offiziell für den Patch beworben hätten.

[Coda]

Also mit meinem CRT seh ich auch bei 1600x1200 noch einen sehr großen Unterschied zwischen kein-AA und 4xAA.

http://www.daionet.gr.jp/~masa/rthdribl/
Das benützt die PS Emulation beim Blending, ist deshalb nicht gerade schnell. Ich hab ja nicht gesagt das es auf ATi Karten überhaupt nicht geht.

[Trap]

Also mit meinem CRT seh ich auch bei 1600x1200 noch einen sehr großen Unterschied zwischen kein-AA und 4xAA.
Geh soweit weg, dass der Monitor nurnoch etwa 10 Grad Sichtfeld bedeckt, dann sollte der Unterschied verschwinden.

HDTV ist nett, aber die Blu-Ray Demo (mit Qualia 005 als Display) im Sony Center in Tokyo ist nochmal ne ganze Stufe besser :)

[PrefoX]

glaube nicht das sony einen höheren standart als HDTV 1080p hat.
das sind immerhin 1920x1080 pixel und allein weil sony gar keine eigenen TV panels baut, denke ich nicht das es wenn sony technik ist.

und nur mal am rande, blu ray ist für HDTV 1080i/p ausgelegt also kann es gar net besser sein.
und es gibt erst einen TV der überhaupt 1080p schafft ;)

[zeckensack]

Den Primärnutzen von HDR sehe ich nach wie vor beim Environment Mapping und verwandten Techniken (zB Refraktion).
Blend-Effekte welcher Art auch immer finde ich höchst langweilig.

[Chris Lux]

Den Primärnutzen von HDR sehe ich nach wie vor beim Environment Mapping und verwandten Techniken (zB Refraktion).
Blend-Effekte welcher Art auch immer finde ich höchst langweilig.
ich möchte dir echt nicht zu nahe treten, aber HDR rein für environmentmapping abzustellen finde ich sehr engstirnig. der einsatz von verschiedensten tonemapping verfahren und die mögliche abbildung von hohen intensitätsverläufen natürlicher szenen mittels dieser macht IMO den primärnutzen von HDR aus.

[zeckensack]

ich möchte dir echt nicht zu nahe treten, aber HDR rein für environmentmapping abzustellen finde ich sehr engstirnig. der einsatz von verschiedensten tonemapping verfahren und die mögliche abbildung von hohen intensitätsverläufen natürlicher szenen mittels dieser macht IMO den primärnutzen von HDR aus.Und ich halte tone mapping für stark über-/falschbewertet ;)

a)Entsättigung etc bei geringer mittlerer Helligkeit sind korrekt, keine Frage. Der Effekt ist aber reichlich subtil. Dafür volles HDR zu fahren ist IMO mit Kanonen auf Spatzen geschossen. Zudem hat man ja an Doom 3 schön sehen können, wie die Userschaft auf im Rahmen der Möglichkeiten korrekte Darstellung von dunklen Umgebungen reagiert: mit Ablehnung und/oder aufgedrehten Helligkeitsreglern.
Simulatoren ala Cave-Systeme, oder allgemein "ernsthafte" Anwendungen, sind davon natürlich nicht zwangsläufig betroffen. Da hast du dann allerdings wieder den Vorteil sündteurer hochwertiger Displays. Mit etwas Glück kriegst du da deine Entsättigung einfach dadurch, dass es in der Höhle so schön dunkel ist, und das Auge des "Opfers" diesen Spezialeffekt ganz alleine berechnet :usweet:
Bei Unterhaltungssoftware scheint's jedenfalls nicht wirklich gut anzukommen.

b)Für typische Iris-/Erblindungseffekte ist HDR auch nicht zwanfsläufig nötig. Ich empfehle einen kurzen Blick auf Metroid Prime, spezifisch die Außenareale der "Chozo ruins", zu erreichen nach etwa 30 Minuten Spielzeit. Beim direkten Blick in die Sonne wird schön knuffig überstrahlt und die Umgebung erscheint dunkler. Tone mapping also, zumindest in irgendeiner Form. HDR aber definitiv nicht, dafür hat der Cube definitiv zu wenig Speicher. Das ist IMO der Beweis: man kann tone mapping und HDR trennen. Im Sinne der Performance sollte man das auch zumindest mal versuchen.

Und der Lösungsansatz ist ziemlich offensichtlich. Um zu wissen ob/wie weit die stärkeren Lichtquellen Sonne, Flutlicht, etc, sichtbar sind, muss man kein HDR machen. Das kann man geometrisch lösen, oder (besser) mit occlusion queries. OQs am besten auch beim Erzeugen von env maps machen und Position/Radius innerhalb der env map "merken". Dann hat man sogar Spiegelungen starker Lichtquellen ganz gut im Griff.

Mit der Sichtbarkeit der primären LQs kannst du dann eine mittlere Helligkeit gut annähern, und das "tone mapping" schon beim ersten farbigen Render-Pass erschlagen. Eine Konstante und ein MUL im Vertex Shader sei hiermit vorgeschlagen.

c)Von einer anderen Seite aus betrachtet: mit HDR, gefolgt von tone mapping erreichst du letztlich dass der (große) Dynamikumfang für's Display wieder auf [0;1] (oder je nach Geschmack auch weniger) abgebildet wird. Wenn du es schaffst, dass dein Bild direkt in [0;1] zu liegen kommt, wird dieser Schritt unnötig.

____

HDR per se halte ich für eine gute Sache. Ich denke nur man sollte sich nicht zu sehr darauf versteifen. Viele Probleme lassen sich auch ohne die enormen Bandbreitenkosten und sonstige Einschnitte in der HW-Kompatibilität und/oder Performance lösen.

[aths]

a)Entsättigung etc bei geringer mittlerer Helligkeit sind korrekt, keine Frage. Der Effekt ist aber reichlich subtil. Dafür volles HDR zu fahren ist IMO mit Kanonen auf Spatzen geschossen. Zudem hat man ja an Doom 3 schön sehen können, wie die Userschaft auf im Rahmen der Möglichkeiten korrekte Darstellung von dunklen Umgebungen reagiert: mit Ablehnung und/oder aufgedrehten Helligkeitsreglern.Imo ist die Doom3-Umgebung nicht besonders korrekt. Sofern es Lichtquellen gibt, beleuchten die ja (schwach) den Raum. Man müsste nach einiger Zeit wenigstens Schemen erkennen. Bei normalen Helligkeitseinstellungen sehe ich aber reines schwarz.

b)Für typische Iris-/Erblindungseffekte ist HDR auch nicht zwanfsläufig nötig. Ich empfehle einen kurzen Blick auf Metroid Prime, spezifisch die Außenareale der "Chozo ruins", zu erreichen nach etwa 30 Minuten Spielzeit. Beim direkten Blick in die Sonne wird schön knuffig überstrahlt und die Umgebung erscheint dunkler. Tone mapping also, zumindest in irgendeiner Form. HDR aber definitiv nicht, dafür hat der Cube definitiv zu wenig Speicher. Das ist IMO der Beweis: man kann tone mapping und HDR trennen. Im Sinne der Performance sollte man das auch zumindest mal versuchen.Im Sinne der Genauigkeit wird man da vermutlich schnell an Grenzen stoßen.

c)Von einer anderen Seite aus betrachtet: mit HDR, gefolgt von tone mapping erreichst du letztlich dass der (große) Dynamikumfang für's Display wieder auf [0;1] (oder je nach Geschmack auch weniger) abgebildet wird. Wenn du es schaffst, dass dein Bild direkt in [0;1] zu liegen kommt, wird dieser Schritt unnötig.Mit 8 Bit Auflösung pro Kanal? Je geringer die räumliche Auflösung, desto unanfälliger ist man gegen Colorbanding. Nur weil was auf einer Konsole klappt muss das noch lange nicht gleich für den PC geeignet sein. Man müsste letztlich mit einer Art übersteigertem sRGB arbeiten, oder wie möchtest du Sonnenlichstärke und Halbschatten zwischen [0; 1] quetschen?

[zeckensack]

Imo ist die Doom3-Umgebung nicht besonders korrekt. Sofern es Lichtquellen gibt, beleuchten die ja (schwach) den Raum. Man müsste nach einiger Zeit wenigstens Schemen erkennen. Bei normalen Helligkeitseinstellungen sehe ich aber reines schwarz.Was in Doom 3 natürlich komplett fehlt, ist die Simulation der variablen Iriskontraktion in Reaktion auf wechselnde Umgebungshelligkeit. Ich wollte auch nicht behaupten, dass Doom 3 das kann.

Es war ein Beispiel für dunkle Spielumgebungen.
(Darüberhinaus, wie man an den Shader-Dateien klar sehen kann, rechnet Doom 3 in einem strikt linearen Farbraum. Das nicht ganz neue Problem dabei ist, dass dein Monitor nicht linear arbeitet. Gamma anpassen wirkt Wunder.
Der Textur-Content in Doom 3 ist leider -- branchenüblich -- mehr oder weniger "vorkompensiert". Von daher ist Gamma 2,2 auch wieder zuviel)
Im Sinne der Genauigkeit wird man da vermutlich schnell an Grenzen stoßen.Warum glaubst du dass Genauigkeit verbraucht wird, wenn man eine Farbe mit wie auch immer gearteter Shader-Präzision korrigiert bevor man sie in den Framebuffer schreibt?

Zum Thema Banding komme ich gleich noch ...
Genauigkeitsanforderungen sind ziemlich unabhängig von tone mapping. Genauigkeit brauchst du wenn du viele kleine Beträge akkumulierst, oder sonstwie extremes Blending betreibst. Sonst eher nicht.

High Dynamic Range gibt's de facto nur in direkter Kombination mit höherer Genauigkeit, das ist wohl richtig. Aber du musst dich mal fragen was du hier forderst: Genauigkeit oder Dynamikumfang oder beides.

Mit 8 Bit Auflösung pro Kanal? Je geringer die räumliche Auflösung, desto unanfälliger ist man gegen Colorbanding. Nur weil was auf einer Konsole klappt muss das noch lange nicht gleich für den PC geeignet sein.Wenn eine Szene in 8 Bit pro Kanal unter Banding leidet, dann wird sie das sowohl mit HDR=>tone mapping=>8bpc als auch mit vorkompensierten Farben=>8bpc tun. Warum sollte es anders sein?

Natürlich kannst du nun fordern dass der Framebuffer pro Kanal mehr als 8 Bits haben sollte, um Banding zu minimieren. Eine Lösung wäre den FP16-fähigen RAMDAC auszunutzen. Nur schneidet auch der Werte über 1.0 ab. Der Gewinn "beschränkt" sich dann auf die höhere Präzision zwischen 0 und 1. Vom höheren Zahlenraum hast du am RAMDAC garnichts, wenn du kein tone mapping machst.
Das wiederspricht alles in allem IMO nicht dem, was ich vorhin schrieb.

Man müsste letztlich mit einer Art übersteigertem sRGB arbeiten, oder wie möchtest du Sonnenlichstärke und Halbschatten zwischen [0; 1] quetschen?Mit der gleichen Arithmetik wie beim klassischen tone mapping, nur an anderer Stelle in der Verarbeitungskette ausgeführt. Funktioniert das eine, funktioniert auch das andere +/- 1ULP.

Lichtintensitäten die auch nach der Irissimulation noch weit über 1,0 liegen muss man eben abschneiden. Und einen Überstrahleffekt dazu basteln, damit's nicht gar so dumm aussieht.

[aths]

Was in Doom 3 natürlich komplett fehlt, ist die Simulation der variablen Iriskontraktion in Reaktion auf wechselnde Umgebungshelligkeit. Ich wollte auch nicht behaupten, dass Doom 3 das kann.

Es war ein Beispiel für dunkle Spielumgebungen.
(Darüberhinaus, wie man an den Shader-Dateien klar sehen kann, rechnet Doom 3 in einem strikt linearen Farbraum. Das nicht ganz neue Problem dabei ist, dass dein Monitor nicht linear arbeitet. Gamma anpassen wirkt Wunder. Der Textur-Content in Doom 3 ist leider -- branchenüblich -- mehr oder weniger "vorkompensiert". Von daher ist Gamma 2,2 auch wieder zuviel)Doom 3 als Beispiel für dunkle Umgebungen könnte durch "HDR-Effekte" an Realismus gewinnen. Die Rechnung im linearen Farbraum ist ja richtig, sofern die Texturen entsprechend entzerrt werden. Wenn Doom3 sRGB-Texturen hat, müssen diese erst mal linearisiert werden. Bei Normalmaps dürfte das nicht viel Sinn ergeben, die sollten dann linear interpretiert werden.

Die Nichtlinearität des Monitors wird ja mit der finalen Gammakorrektur bedacht.

Warum glaubst du dass Genauigkeit verbraucht wird, wenn man eine Farbe mit wie auch immer gearteter Shader-Präzision korrigiert bevor man sie in den Framebuffer schreibt?

Zum Thema Banding komme ich gleich noch ...
Genauigkeitsanforderungen sind ziemlich unabhängig von tone mapping. Genauigkeit brauchst du wenn du viele kleine Beträge akkumulierst, oder sonstwie extremes Blending betreibst. Sonst eher nicht.

High Dynamic Range gibt's de facto nur in direkter Kombination mit höherer Genauigkeit, das ist wohl richtig. Aber du musst dich mal fragen was du hier forderst: Genauigkeit oder Dynamikumfang oder beides.

Wenn eine Szene in 8 Bit pro Kanal unter Banding leidet, dann wird sie das sowohl mit HDR=>tone mapping=>8bpc als auch mit vorkompensierten Farben=>8bpc tun. Warum sollte es anders sein?Das mit dem Banding meinte ich so: Um bei einer Ramp mit 256 Stufen überhaupt Banding zu sehen, muss man sie auf mehr als 256 Pixel ausdehen. Die PAL-Auflösung einer Konsole ist da weniger anfällig als ein PC der traditionell höhere Auflösungen verarbeitet, bei der Konsole kommt auch noch die TV-übliche Unschärfe hinzu.

Genauigkeit brauche ich zum Multiplizieren. Ich möchte sowohl Dynamik, als auch (mindestens) die herkömmliche Genauigkeit im [0; 1]-Bereich.

Da die interne Genauigkeit im PS für fast alle Fälle völlig ausreicht, ist der Banding-Bringer der 8-Bit-Framebuffer (bzw. der Alphablender.) Kommen Postprocessing-Effekte ins Spiel, ist es in vielen Fällen wünschenswert, die alten Werte noch in FP16 vorliegen zu haben.

Was Gamma angeht, sollten im auch JPEGs und MPEG mit mindestens 10, besser 12 Bit Genauigkeit entpackt werden, damit man bei der Gammakorrektur keine Farbauflösung verliert. (Außerdem sollte es gesetzliche Pflicht werden, dass alle ins Web gestellten Grafiken eine Gamma-Angabe bekommen, damit sie der Browser entzerren kann.)
Natürlich kannst du nun fordern dass der Framebuffer pro Kanal mehr als 8 Bits haben sollte, um Banding zu minimieren. Eine Lösung wäre den FP16-fähigen RAMDAC auszunutzen. Nur schneidet auch der Werte über 1.0 ab. Der Gewinn "beschränkt" sich dann auf die höhere Präzision zwischen 0 und 1. Vom höheren Zahlenraum hast du am RAMDAC garnichts, wenn du kein tone mapping machst.
Das wiederspricht alles in allem IMO nicht dem, was ich vorhin schrieb.

Mit der gleichen Arithmetik wie beim klassischen tone mapping, nur an anderer Stelle in der Verarbeitungskette ausgeführt. Funktioniert das eine, funktioniert auch das andere +/- 1ULP.Ich bin mir nicht sicher, ob wir nicht fürchterlich aneinander vorbei reden.

Dynamisches Tonemapping ohne extra-Pass ist kaum möglich. Wo willst du da an anderer Stelle ansetzen, wenn nicht erst zum Schluss, ggf. vor dem finalen Alphablending-Glow-Effekt?

Lichtintensitäten die auch nach der Irissimulation noch weit über 1,0 liegen muss man eben abschneiden. Und einen Überstrahleffekt dazu basteln, damit's nicht gar so dumm aussieht.Unreal hat einen Corona-Effekt, sogar mit allmählichem Ausblenden bei Überdeckung. Das ist natürlich kein HDR-Effekt, aber HDR-Lighting mit Glow könnte einen Corona-ähnlichen Effekt nebenbei miterledigen. Imo ist es wünschenswert, wenn möglichst wenig "gefakt" wird. Real time HDR lighting with radiosity and smooth dynamic shadows überfordert heutige Grafikkarten sicher, da muss man irgendwo faken. Insofern stimme ich dir zu: Glow-Effekte etc. könnten begrenzt mit herkömmlichen Technologien verwirklicht werden. Aber echtes HDR-Lighting eröffnet eine ganze Paletten an netten Effekten.

[Chris Lux]

oje was hab ich getan ;)

nur kurz: @zeckensack:
sicher, wenn man eine stark limitierte umgebung hat wie in doom3, reicht auch eine auf diese umgebung angepasste auflösung. wenn man aber allgemeinere umgebungen hat (mal weg von nur spielen auch hin zu VR) kommt man für das realitätsnahe abbilden dieser intensitätsverläufe an HDR mit tone mapping nicht umher. klar kann man wieder viel hinfaken (siehe hl2), aber das ist auch nicht der weisheit letzter schuss, warum wohl ist ein carmack für doom3 auf eine uniformes lichtmodell umgestiegen. genau, weil er nicht für tausend oberflächen und objecke spezielle hacks machen möchte. genauso wird das mir hdr, es gibt den entwicklern und contentdesignern mehr freiheiten und lässt es zu die darstellung der farben und lichtverhältnisse näher an die wirklichkeit bringen zu können. dazu noch: in spielen sind vielleicht gute hdr effekte 'eingefaket' worden, aber das betrifft wiederum nur die angesprochenen blend, gloom, bloom effekte... reeller wirken sie dadurch nicht, da immer noch alles nach blassen cg-spielewelten aussieht.

[Chris Lux]

High Dynamic Range gibt's de facto nur in direkter Kombination mit höherer Genauigkeit, das ist wohl richtig. Aber du musst dich mal fragen was du hier forderst: Genauigkeit oder Dynamikumfang oder beides.
IMO beides! wie gesagt kommt man mit fp-farbdaten in richtung der funktionsweise des menschlichen wahrnehmungsvermögens. wie nehmen in dunklen breichen viel mehr details und kleinste helligkeitsunterschiede wahr. in hellen bereichen nehmen wir nur noch große unterschiede wahr. so haben wir mit HDR in dunklen bereichen genauigkeit und für die hellen dynamikumfang.

Wenn eine Szene in 8 Bit pro Kanal unter Banding leidet, dann wird sie das sowohl mit HDR=>tone mapping=>8bpc als auch mit vorkompensierten Farben=>8bpc tun. Warum sollte es anders sein?
daran sind mehr die DA wandler schuld, nv hat ja angeblich in den nv40ern bessere DA wandler, aber nen unterschied konnte ich nicht erkennen.

Natürlich kannst du nun fordern dass der Framebuffer pro Kanal mehr als 8 Bits haben sollte, um Banding zu minimieren. Eine Lösung wäre den FP16-fähigen RAMDAC auszunutzen. Nur schneidet auch der Werte über 1.0 ab. Der Gewinn "beschränkt" sich dann auf die höhere Präzision zwischen 0 und 1. Vom höheren Zahlenraum hast du am RAMDAC garnichts, wenn du kein tone mapping machst.
Das wiederspricht alles in allem IMO nicht dem, was ich vorhin schrieb.
wieso? mittels tonemapping kannst du jedes mal einen anderen intensitätsbereich auf den 0..1 bereich mappen, wodurch du die dynamik der szene ausnutzen kannst, bei (wiedermal) d3 braucht man nicht versuchen hellere bereiche hervorzuheben, weil die dann einfach scheisse aussehen. camack hat ja angesprochen, dass er noch daran arbeitet, denn designer haben ihn angesprochen, dass wenn sie szenen real hell beleuchten wollen meist nur weisse flächen entstehen. dies ist sicher auch der grund, warum er derzeit an hdr (oder besser mdr) fähigkeiten bastelt.

Lichtintensitäten die auch nach der Irissimulation noch weit über 1,0 liegen muss man eben abschneiden. Und einen Überstrahleffekt dazu basteln, damit's nicht gar so dumm aussieht.
nicht unbedingt. mit der mittleren luminanz der szene kannst du mittels (oh es kommt doch zu oft ;)) tonemapping einen idealen intensitätsbereich für die ausgabe auf deinem LDR device (monitor) bestimmten.
p.s. ich glaube langsam deine irissimulation ist nichts anderes als ein tonemapping. und klar, wenn danach noch werte weit über 1 liegen werden die abgeschnitten. beispiel photo, wenn du die blende falsch einstellst hast du auch nichts anderes als weisse (auf 1 geclampte) stellen.

[Chris Lux]

[...]
FULL ACK genau das sind die fakten und gründe, warum HDR benötigt wird. ich kanns leider nicht besser ausdrücken. ;)

p.s.
Die Nichtlinearität des Monitors wird ja mit der finalen Gammakorrektur bedacht.

i.e. tonemapping ;)

[zeckensack]

Da die interne Genauigkeit im PS für fast alle Fälle völlig ausreicht, ist der Banding-Bringer der 8-Bit-Framebuffer (bzw. der Alphablender.)Exakt mein Punkt.
Das Banding kommt durch die Konvertierung nach 8bpc. Egal ob du erst mit FP16 rechnest und das Ergebnis später in einen Integer-Puffer quetschst, oder ob du sofort quetschst.

Dass man insbesondere für häufiges Blending höhere Präzision braucht, hatte ich ja schon eingeräumt. Kein Widerspruch.
Kommen Postprocessing-Effekte ins Spiel, ist es in vielen Fällen wünschenswert, die alten Werte noch in FP16 vorliegen zu haben.Tone mapping und Überstrahlung sind eben zwei Postpro-"Effekte", die man IMO bei durchaus vergleichbarer Qualität auch ohne FP16 hinbekommt. Wobei es da sicher noch wüsteres Zeug gibt.
<schnipp> (Gamma)
Ich bin mir nicht sicher, ob wir nicht fürchterlich aneinander vorbei reden.

Dynamisches Tonemapping ohne extra-Pass ist kaum möglich. Wo willst du da an anderer Stelle ansetzen, wenn nicht erst zum Schluss, ggf. vor dem finalen Alphablending-Glow-Effekt?Ja eben so wie ich es schon beschrieben habe. Du ermittelst die mittlere Helligkeit nicht nachdem du die Szene fertig hast, sondern davor, zumindest näherungsweise. Und dann machst du dein tone mapping eben sofort im ersten farbigen Pass.

Dazu sollte ich noch fragen: was meinst du denn wie du nach dem Rendern die mittlere Helligkeit ermittelst? Den Framebuffer auslesen halte ich nicht wirklich für elegantesten Weg. Besser wird's, wenn man aus dem Framebuffer -- wie auch imemr -- erstmal Mipmaps erzeugt, und dann nur das kleinste 1x1-Level zurückliest. Damit tauscht man dann Busbandbreite gegen Graka-Bandbreite, idR ist das ein Gewinn.
Aber ist das wirklich so viel besser als die Sichtbarkeit der Lichtquellen direkt zu bestimmen, dass du dafür die Kosten des FP16-Framebuffers auf dich nehmen willst? Du sagst ja. Chris Lux sagt auch ja. Und ich sage, unter gewissen Umständen, jein.

Im einfachsten Fall, wenn du nur die Helligkeit dynamisch nachjustieren willst, und wenn man ohnehin im Pixel Shader schon eine per-vertex-Farbe in das Ergebnis einmultipliziert, eben so:
(im Vertex Shader)
#Konstante k_ool:=1.0/mittlere_Helligkeit;
MUL out.color,unkompensierte_farbe,k_ool;

Es sei dir selbst überlassen, beliebig kompliziertere Arithmetik einzuetzen. Wenn du das tone mapping in Shader-Code ausdrücken kannst, dann kannst du diesen Code auch ausführen bevor die Szene fertig ist. Ich weiß nicht was daran so unmöglich sein soll :|

[zeckensack]

p.s. ich glaube langsam deine irissimulation ist nichts anderes als ein tonemapping. und klar, wenn danach noch werte weit über 1 liegen werden die abgeschnitten. beispiel photo, wenn du die blende falsch einstellst hast du auch nichts anderes als weisse (auf 1 geclampte) stellen.Natürlich ist "meine" Irissimulation eine konkrete Anwendung für tone mapping. Ich wollte nur den Begriff vermeiden, weil er eben mit Postpro assoziiert ist. Gerade davon wollte ich ja weggehen.

[Demirug]

Dazu sollte ich noch fragen: was meinst du denn wie du nach dem Rendern die mittlere Helligkeit ermittelst? Den Framebuffer auslesen halte ich nicht wirklich für elegantesten Weg. Besser wird's, wenn man aus dem Framebuffer -- wie auch imemr -- erstmal Mipmaps erzeugt, und dann nur das kleinste 1x1-Level zurückliest. Damit tauscht man dann Busbandbreite gegen Graka-Bandbreite, idR ist das ein Gewinn.
Aber ist das wirklich so viel besser als die Sichtbarkeit der Lichtquellen direkt zu bestimmen, dass du dafür die Kosten des FP16-Framebuffers auf dich nehmen willst? Du sagst ja. Chris Lux sagt auch ja. Und ich sage, unter gewissen Umständen, jein.

Vorberechnen sehe ich als etwas problematisch an. Gerade bei vielen Lichtquellen Outdoor kann das verdammt aufwendig werden.

Den Framebuffer auslesen für den Mittelwert ist auf jeden Fall ein NO GO. Wie kommt jemand überhaupt auf eine solche Idee? Runterrechnen in der Grafikkarte ist der einzige gangbare Weg.

[aths]

Es sei dir selbst überlassen, beliebig kompliziertere Arithmetik einzuetzen. Wenn du das tone mapping in Shader-Code ausdrücken kannst, dann kannst du diesen Code auch ausführen bevor die Szene fertig ist. Ich weiß nicht was daran so unmöglich sein soll :|Man kann doch nicht bevor die Szene fertig ist, wissen, wie hoch die akkumulierte Helligkeit ist. FC rendert in eine Textur und filtert die dann stufenweise runter. Dazu müssen aber letzlich alle "Pexel" (nenn ich mal so, Pixel-Texel :)) mehrfach angefasst werden. Man könnte sich vielleicht einen Chip überlegen, der beim RAMDAC-Readout auch eine (dem Framebuffer gleich große) Textur ausliest und die Werte akkumuliert, so dass man in einem Register die Helligkeit vom letzten Frame hat.

[RLZ]

Man kann doch nicht bevor die Szene fertig ist, wissen, wie hoch die akkumulierte Helligkeit ist.
Man kann die Helligkeit des letzten Bildes nehmen.
Da das Auge auch eine Trägheit besitzt macht man damit nichtmal einen Fehler...

[aths]

Man kann die Helligkeit des letzten Bildes nehmen.
Da das Auge auch eine Trägheit besitzt macht man damit nichtmal einen Fehler...Ja, aber auch dann muss man diese Helligkeit erst mal ermitteln, wozu ein extra Pass erforderlich ist.

[betasilie]

Ja, aber auch dann muss man diese Helligkeit erst mal ermitteln, wozu ein extra Pass erforderlich ist.
Besser als ein Viertel der Bandbreite zu opfern, die NVs 64bit HDR schluckt.

[aths]

Besser als ein Viertel der Bandbreite zu opfern, die NVs 64bit HDR schluckt.Ein 64-Bit-Format kostet gegenüber einem 32-Bit-Format die doppelte Bandbreite, egal ob es von Nvidia oder von ATI implementiert wird. Um die echte Gesamthelligkeit zu ermitteln, musst du schon mit 64 Bit pro Pixel arbeiten. NV40s 64-Bit-Fähigkeiten gehen über R420s 64-Bit-Fähigkeiten weit hinaus, NV40 kann 64 Bit breite FP16-Texturen in der TMU filtern und im Alphablender blenden.

R300 // R420 kann in eine FP16- (oder FP32-) Textur rendern. Kein Problem. Nur krieg die mal auf 1 Texel reduziert. Da kommt die FP-Filterfähigkeit vom NV40 ins Spiel.

Alphablending, wichtig für diese "Strahleffekte", kann NV40 direkt machen, während R420 die ganzen Daten umständlich umherschieben muss. Gegenüber R420 kann man bei "HDR-Rendering" à la Far Cry auf dem NV40 jede Menge Füllrate und Bandbreite sparen. Far Cry nutzt den NV40 leider nicht in Gänze aus, sondern verballert unnütz Füllrate und Bandbreite.

[Jesus]

Kann eine PS2 HDR ?

Habe eben meine US Version von MGS 3 bekommen, und da sieht man am Anfang einen wirklich sehr beeindruckenden Blendeffekt (als die Klappe vom Flugzeug aufgeht und man die Sonne sieht). Das Bild wird sehr hell, die umrisse verschwimmen, nach ein paar Sekunden isses vorbei.

Sieht verdammt nach HDR aus ! (wesentlich besser als das in FC auf jeden Fall)

Anscheinend : http://www.cmpevents.com/GD05/a.asp?option=C&V=11&SessID=3934

und hier noch HL2 "HDR" ?

http://www.geocities.com/z3r0_d/files/hl2_hdr.jpeg

[Coda]

Das sind HDR Cubemaps in HL². Das kann die ATi auch.

Du must unterscheiden zwischen HDR Texturen und einem HDR Framebuffer.

[zeckensack]

Ja, aber auch dann muss man diese Helligkeit erst mal ermitteln, wozu ein extra Pass erforderlich ist.Es kommt darauf an, ob du dich mit einer Approximation zufrieden geben kannst. Das kannst du nicht immer.

Die Reflektion bsw einer tiefstehenden Sonne über einer großen Wasserfläche ist geometrisch schwer erfassbar. Diese ist sehr ausgedehnt und "länglich", obwohl die LQ selbst annähernd kreisförmig ist. Die Lichtintensität ist um ein vielfaches höher als bei der Direktansicht.

Wenn du dagegen "nur" diffus/spekular/glatt reflektiertes Licht hast, dann kannst du sehr gut annähern wie hell das ganze sein wird, ohne es sichtbar zu rendern und zurückzulesen. Auf die Gefahr hin, mich zu wiederholen: occlusion queries plus Oberstufengeometrie.

Man kann die Helligkeit des letzten Bildes nehmen.
Da das Auge auch eine Trägheit besitzt macht man damit nichtmal einen Fehler...Ja, aber auch dann muss man diese Helligkeit erst mal ermitteln, wozu ein extra Pass erforderlich ist.Besser als ein Viertel der Bandbreite zu opfern, die NVs 64bit HDR schluckt.Das funktioniert nicht.
Wenn man die Szene nicht in einen HDR-Puffer rendert (Schwerpunkt hierbei auf Dynamikumfang, nicht Präzision), dann werden alle Werte über 1 abgeschnitten und die ermittelte mittlere Helligkeit ist verfälscht. Dadurch lässt sich die Bandbreite für HDR-Rendering keinesfalls einsparen.

Das schafft man nur, wenn man die Helligkeit nicht durch Zurücklesen des Framebuffers ermittelt.

[aths]

Es kommt darauf an, ob du dich mit einer Approximation zufrieden geben kannst. Das kannst du nicht immer.

Die Reflektion bsw einer tiefstehenden Sonne über einer großen Wasserfläche ist geometrisch schwer erfassbar. Diese ist sehr ausgedehnt und "länglich", obwohl die LQ selbst annähernd kreisförmig ist. Die Lichtintensität ist um ein vielfaches höher als bei der Direktansicht.

Wenn du dagegen "nur" diffus/spekular/glatt reflektiertes Licht hast, dann kannst du sehr gut annähern wie hell das ganze sein wird, ohne es sichtbar zu rendern und zurückzulesen. Auf die Gefahr hin, mich zu wiederholen: occlusion queries plus Oberstufengeometrie.Wenn ich dich richtig verstanden habe, schlägst du die (seit GF3 eingeführten) occlusion queries vor, (seinerzeit wurden sie für Corona-Effekte empfohlen) um die Anzahl und Art der Lichtquellen abzuschätzen und daraus die Gesamthelligkeit über den Daumen zu peilen.

Was aber, wenn das orthogonal einfallende Licht von einer Säule fast (jedoch nicht ganz) überdeckt wird. Der occlusion query müsste dann doch "war im letzten Frame sichtbar" zurückliefern, und die ganze Lichtquelle geht in die Approximation der Gesamthelligkeit ein.

HDR-Rendering ist imo auch nützlich für Skisport-Simulationen und alles, wo beleuchteter Schnee vorkommt. Der Schnee ist ja unglaublich hell, hier braucht man eine hohe Präzision um auch die dunkleren Bereiche noch gut aufzulösen, andererseits aber noch feine Helligkeitsabstufungen im Schnell zu erlauben (da müsste beim Tonemapping u. U. eine Spezialformel ran, damit da Weiße nicht komplett "zuläuft", andererseits aber Unterbelichtung zu vermeiden.)

Geht man von konstanten Beleuchtungsverhältnissen aus, könnte man den Skisport-Simulator vielleicht ohne HDR-Buffer tonemappen. In einem RPG, wo es jedes Klima gibt (bzw. einzelne Schneeflecken) wäre ein HDR-Buffer dann wieder nützlich.

[betasilie]

Ein 64-Bit-Format kostet gegenüber einem 32-Bit-Format die doppelte Bandbreite, egal ob es von Nvidia oder von ATI implementiert wird. Um die echte Gesamthelligkeit zu ermitteln, musst du schon mit 64 Bit pro Pixel arbeiten. NV40s 64-Bit-Fähigkeiten gehen über R420s 64-Bit-Fähigkeiten weit hinaus, NV40 kann 64 Bit breite FP16-Texturen in der TMU filtern und im Alphablender blenden.

R300 // R420 kann in eine FP16- (oder FP32-) Textur rendern. Kein Problem. Nur krieg die mal auf 1 Texel reduziert. Da kommt die FP-Filterfähigkeit vom NV40 ins Spiel.

Alphablending, wichtig für diese "Strahleffekte", kann NV40 direkt machen, während R420 die ganzen Daten umständlich umherschieben muss. Gegenüber R420 kann man bei "HDR-Rendering" à la Far Cry auf dem NV40 jede Menge Füllrate und Bandbreite sparen. Far Cry nutzt den NV40 leider nicht in Gänze aus, sondern verballert unnütz Füllrate und Bandbreite.
Das hast Du nochmal schön zusammengefasst.

64-bit HDR ist sicherlich die Zukunft und sinnvoll und das HDR im NV40 gut gelöst, nur ist es schon ziemlich krass, dass es 1/4 der Bandbreite schluckt, wo die aktuellen GPUs sowieso schon ohne HDR mit der Bandbreite zu kämpfen haben.

Imho wird das HDR erst richtig interessant, wenn wir Karten mit mehr als 256bit sehen. Aber ich bin trotzdem mal auf STALKER gespannt. Vielleicht haben die das HDR ja ordentlich implementiert.

[zeckensack]

Wenn ich dich richtig verstanden habe, schlägst du die (seit GF3 eingeführten) occlusion queries vor, (seinerzeit wurden sie für Corona-Effekte empfohlen) um die Anzahl und Art der Lichtquellen abzuschätzen und daraus die Gesamthelligkeit über den Daumen zu peilen.Jein.
Anzahl und Art der wichtigsten LQs muss die Applikation schon selbst wissen. Die occlusion queries können und sollen natürlich nur die Sichtbarkeit dieser Lichtquellen feststellen. Das Ergebnis muss dann mit passenden "Materialkonstanten" der einzelnen Lichtquellen verrechnet werden, um deren Lichtbeiträge zu erhalten.
Was aber, wenn das orthogonal einfallende Licht von einer Säule fast (jedoch nicht ganz) überdeckt wird. Der occlusion query müsste dann doch "war im letzten Frame sichtbar" zurückliefern, und die ganze Lichtquelle geht in die Approximation der Gesamthelligkeit ein.OQs liefern nicht nur ja/nein-Ergebnisse, sondern die Anzahl der Pixel. Auch nicht zwingend "sichtbar", das soll ja erst später passieren. Eine OQ erfasst zum Glück alles, was nicht irgendwie verworfen wurde.
Für diesen Fall wäre das Kriterium "hat den Z-Test überlebt, aber sonst ist nichts dabei rumgekommen" gerade angemessen.

<...>
Skisport-Simulationen <...>Ja, Schnee ist so ähnlich wie mein Beispiel mit dem Wasser. Sehr viel indirektes Licht, und damit reicht es nicht mehr aus, nur die Sichtbarkeit der Lichtquellen abzuschätzen.
Schnee ist IMO aber trotzdem einfacher, weil die Reflektion sehr diffus ist. Schnee ist immer hell, solange kein Schatten darauf fällt, ganz egal welche Winkel zwischen Fläche/Betrachter und Fläche/Sonne anliegen.

Meer mit Wellengang ist da viel chaotischer.

[deekey777]

Und weiter gayt's:

Valve have once again released a progess update over Steam, detailing some information on the upcoming HL2 Deathmatch update, as well as plans to add HDR (High Dynamic Range) lighting to the Source Engine:
...

One feature that we'll be adding to the Source engine in the coming months is high dynamic range lighting. To showcase this we've taken a part of the Highway 17 chapter of Half-Life 2 and worked it into a single level that incorporates HDR along with some new gameplay. We're calling this short level "The Lost Coast," and it will be made available free of charge to Half-Life 2 customers that meet a specific set of high end hardware requirements. We'll be publishing those requirements soon.


...

To view the update yourself, simply restart your Steam Client.

Gestohlen von www.halflife2.net .
Könnte interessant sein, besonders in Hinblick, auf welcher HW dieses HDR zu sehen sein soll - falls es echtes HDR(mit dem Framebuffer und so) ist.

[Demirug]

Und weiter gayt's:

Valve have once again released a progess update over Steam, detailing some information on the upcoming HL2 Deathmatch update, as well as plans to add HDR (High Dynamic Range) lighting to the Source Engine:
...



...

To view the update yourself, simply restart your Steam Client.

Gestohlen von www.halflife2.net .
Könnte interessant sein, besonders in Hinblick, auf welcher HW dieses HDR zu sehen sein soll - falls es echtes HDR(mit dem Framebuffer und so) ist.

"meet a specific set of high end hardware requirements"

Kommt das Level etwa zum R520 Launch?

[deekey777]

"meet a specific set of high end hardware requirements"

Kommt das Level etwa zum R520 Launch?


Könnte gut sein, aber dann dauert es noch wohl ("in the coming months"), und es klingt zu sehr nach den versprochenen ATi-Level.

[Coda]

Es könnte sich aber auch nur um paar HDR Cubemaps + Overbright handeln. Valve würde ich das zutrauen...

[urbi]

Das wird sowas wie fake HDR sein, Valve hat das ja auch benutzt. :)

[r3ptil3]

nix da fake hdr,, auch in far cry war es noch ziemlich gut implentiert worden, und in der source engine wirds wahrscheinlich noch besser weil sie das schon avon anfang an schon drin hatten jedoch später wieder rausnahmen!

[Coda]

auch in far cry war es noch ziemlich gut implentiert wordenÖhm...


Nein.

und in der source engine wirds wahrscheinlich noch besser weil sie das schon avon anfang an schon drin hatten jedoch später wieder rausnahmen!Wo hatten die das von Anfang an drin? Es gab paar HDR Cubemap Screenshots sonst nix.

[Ailuros]

nix da fake hdr,, auch in far cry war es noch ziemlich gut implentiert worden, und in der source engine wirds wahrscheinlich noch besser weil sie das schon avon anfang an schon drin hatten jedoch später wieder rausnahmen!

Ich wuerde ernsthaft mal wissen wie "ziemlich schlechtes" HDR aussehen wuerde. Irgendwo hab ich wohl den Massstab verloren..... :|

[MechWOLLIer]

Ich wuerde ernsthaft mal wissen wie "ziemlich schlechtes" HDR aussehen wuerde. Irgendwo hab ich wohl den Massstab verloren..... :|
Nunja, schlecht aussehen tut HDR in Far Cry imo nicht(wenns auch vollkommend übertrieben bin, ich bin ein Fan solcher Effekte). Das einzig schlecht implementierte ist imo die Performance und Kompatiblität, das aber heftig.

[Demirug]

Nunja, schlecht aussehen tut HDR in Far Cry imo nicht(wenns auch vollkommend übertrieben bin, ich bin ein Fan solcher Effekte). Das einzig schlecht implementierte ist imo die Performance und Kompatiblität, das aber heftig.

Die Performance ist wirklich nicht sonderlich da man da teilweise einfach zu viel unnötiges rechnet.

Was meinst du aber mit slechter Kompatibilität? Es läuft doch bisher auf jedem Chip der die festgelegten technischen Vorraussetzungen erfüllt.

[MechWOLLIer]

Was meinst du aber mit slechter Kompatibilität? Es läuft doch bisher auf jedem Chip der die festgelegten technischen Vorraussetzungen erfüllt.
Dies stimmt ja, aber soweit ich weiß, ist HDR auch auf Karten möglich, die keinen 64-Bit-Framebuffer(wars das überhaupt?) haben. Genau da hakt es imo derzeit etwas, ebenso am nichtfunktionieren von AA; was aber imo auch möglich sein kann, wenn man HDR anders implementiert.

[Demirug]

Dies stimmt ja, aber soweit ich weiß, ist HDR auch auf Karten möglich, die keinen 64-Bit-Framebuffer(wars das überhaupt?) haben. Genau da hakt es imo derzeit etwas, ebenso am nichtfunktionieren von AA; was aber imo auch möglich sein kann, wenn man HDR anders implementiert.

Für richtiges HDR braucht man schon einen 64Bit FP Buffer (streng genommen eigentlich sogar 128 Bit). Es gibt zwar Möglichkeiten etwas HDR ähnliches auch ohne einen solchen Buffer zu realisieren allerdings haben diese Verfahren allesamt irgendwo mindestens einen Nachteil gegenüber einem 64 Bit FP Buffer.

Das kein AA geht ist schlicht und ergreifend eine Hardware limitierung weil die Karte derezit noch kein AA in Verbindung mit FP Buffer erlauben. Das wird sich aber sicherlich ändern. Supersampling AA könnte die Applikation notfalls selbst erzeugen aber das liegt wohl leider ebenfalls ausserhalb des realistisch machbaren weil die Leistung dafür derzeit eher unzureichen ist. Darum: Echtes HDR = Kein oder nur langsames SSAA.

Bei Farcry ist es übrigens nicht die Notwendigkeit eines FP64 Buffers der HDR nur auf NV4X Karten erlaubt. Diese Buffer haben auch NV3X sowie die Radeons ab R300. Was benötigt wird ist die möglichkeit mit diesen Buffer Alphablend Operationen auszuführen. Das kann derzeit aber nur der NV4X (ein paar 3dlabs Karten wahrscheinlich auch aber die sind ja weniger zum Spielen geeignet). Ohne diese Fahigkeit muss das ganze aufwendig mit den Pixelshadern und mehreren Buffer emuliert werden. Davor schrecken die meisten Entwickler aber zurück.

[Ailuros]

Nunja, schlecht aussehen tut HDR in Far Cry imo nicht(wenns auch vollkommend übertrieben bin, ich bin ein Fan solcher Effekte). Das einzig schlecht implementierte ist imo die Performance und Kompatiblität, das aber heftig.

Stellen wo HDR in FC die Bildqualitaet erhoeht sind nicht unbedingt die Mehrheit; entweder kommt es zu abscheulichem texture-aliasing (in-door scenes mostly) oder es wird stellenweise so uebertrieben belichtet, dass die Szene ueberhaupt nichts mehr mit Realismus zu tun hat.

Lass doch bitte mal das Research-demo laufen, einmal mit HDR und einmal ohne. Falls Dir das HDR Resultat als "normal" oder sogar "schoen" erscheint, dann ist wohl eher eine merkwuerdige Geschmackssache.

HDR ist in FC leider ein Nachgedanke und IMHO einer ziemlich schlechte Praesentation der Technologie. Mit Mass bitte und nur da wo es absolut noetig sein koennte und nicht eine uebertriebene Ueberschmiererei unter allen Faellen.

[papachrischi]

Allerdings. In Doom3 ist es dunkel, wenn es dunkel ist. Dabei gewöhnt sich das Auge daran, nach einiger Zeit müsste man umrisshaft mehr sehen als nur schwarz.

Nein, wo kein Licht ist, wird auch nichts mehr reflektiert.
Allerdings würde mit sinkender Lichtintensität das Farbsehen reduziert.
Die Frage ist nur, wer braucht soviel "Realismus" in einem Spiel (voran tasten geht ja nicht :D ).

betareverse, wenn dir das erste mal jemand eine Blendgrante vor die Füsse wirft wenn du gerade mit dem Restlichverstärker rumläufst (um überhaupt noch was zu sehen) überlegst du dir das nochmal.

Ich dachte mir geht der Monitor kaputt.

Stimmt. Auch ohne Nachtsichtgerät sind die Dinger ne Qual. Da ist dann auch wieder Schluss mit Realismus. Wo ist der verdammte "Mach die Augen zu- oder nimm die Hand vor die Augen- Knopf"? ;D

[Coda]

Doom ist wirklich viel zu dunkel. Ein bischen ambient Brightness oder doch Lightmaps statt alles mit Perpixel Light erschlagen zu wollen hätte nicht geschadet.

[Chris Lux]

[...]Ein bischen ambient Brightness oder doch Lightmaps statt alles mit Perpixel Light erschlagen zu wollen hätte nicht geschadet.
sorry, aber: willkommen zu _gestern_!

[deekey777]

Für HL2 wurde eine Art "HDR" Mod released: HL2 R8 HDR Bloom Mini-mod (http://forum.neotokyohq.com/viewtopic.php?p=6486#6486)
Aus der ReadMe:

"4) Is this really HDR?
That's a good question. With out getting too technical, the effect itself is processed in a High Dynamic Range before it is Tone-Mapped to the low dynamic range Half-Life 2 and your video card are using. So yes and no ;D."

In jedem Fall sind die Standardsettings "zu hell". mat_R8BloomGamma (Default: 0.75) auf 1.00 setzen schafft Abhilfe. Dennoch ist das Zielkreuz draussen im Licht fast nicht zu sehen. Sieht trotzdem gut aus.

Screenshots? Nö. ;D

[Coda]

sorry, aber: willkommen zu _gestern_!Mag sein, D3 sieht so trotzdem nicht besonders toll aus.
Da fehlt einfach noch die Power um alles dynamisch hell genug auszuleuchten.

[Mr. Lolman]

Schon mal mit HDRish Shader ausprobiert (http://img118.exs.cx/img118/5606/d3hdr1pd.jpg)?


BTW: HL² HDR Mod:
http://www.halflife2.net/news//1109354235_3.jpg

[Coda]

Könttest du den Shader bitte Overbright nennen? Mit HDR hat es einfach nix zu tun. HDR ist ja nicht nur auf den Overbright Effekt beschränkt, deshalb passt es schonmal nicht.

[Quasar]

Schon mal mit HDRish Shader ausprobiert (http://img118.exs.cx/img118/5606/d3hdr1pd.jpg)?
Sieht fast so unscharf aus, wie quincunx - nur heller. :|

[deekey777]

Ein Paar Screenshots:
mat_R8Bloom (Default: 1) : 0=Turns the effect off, 1=The default setting, 2=Blurs the Bloom effect a bit more.

mat_R8Bloom 0 (http://img99.exs.cx/my.php?loc=img99&image=09uh.jpg)
mat_R8Bloom 1 (http://img99.exs.cx/my.php?loc=img99&image=16pd2.jpg)
mat_R8Bloom 2 (http://img99.exs.cx/my.php?loc=img99&image=24ri.jpg)

Der Unterschied zw. 1 und 2 ist hauptsächlich die Performance, weniger visuell.
Nur so:
http://img210.exs.cx/my.php?loc=img210&image=d1canals03xr.jpg
http://img210.exs.cx/my.php?loc=img210&image=d1canals1ig.jpg

[Mr. Lolman]

Sieht fast so unscharf aus, wie quincunx - nur heller. :|

:confused:

Stimmt doch garnicht :|

[mapel110]

Ein Paar Screenshots:
mat_R8Bloom (Default: 1) : 0=Turns the effect off, 1=The default setting, 2=Blurs the Bloom effect a bit more.

mat_R8Bloom 0 (http://img99.exs.cx/my.php?loc=img99&image=09uh.jpg)
mat_R8Bloom 1 (http://img99.exs.cx/my.php?loc=img99&image=16pd2.jpg)
mat_R8Bloom 2 (http://img99.exs.cx/my.php?loc=img99&image=24ri.jpg)

Der Unterschied zw. 1 und 2 ist hauptsächlich die Performance, weniger visuell.
Nur so:
http://img210.exs.cx/my.php?loc=img210&image=d1canals03xr.jpg
http://img210.exs.cx/my.php?loc=img210&image=d1canals1ig.jpg

Ohne gefällts mir besser. Die Übergänge zu dem grellen sind aber nicht fliessend wie bei Farcry, oder?

[hmx]

Aber echtes 64bit Renderinmg ist es nicht, oder? Ich meine diesen "Bloom-Effekt"gabs schon bei Naturetest von 3DM01. Und im Wasser sind die Spiegelungen imo zu schwach. Wüsste gerne wie das in Bewegung Aussieht. Beim HDR in FC hat man Übrigens neben dem Bloom auch einen Deutlich besseren Kontrast. Im vgl zum HDR-Rendering sieht das Bild einfach deutlich "echter" und weniger Blass aus. Das fehlt mir irgendwie diesen Screenshots. Die Farben sind nicht so schön wie bei FC mit HDR und es sieht noch genause "blass" aus.
Das HDR sieht in FC zwar auf den 1. Blick unrealistisch aus (auf den Überhellungs-Effekt mag das sicher tw zutreffen, da dieser oft etwas unpassend oder eifach zu stark ist), aber wenn man HDR ausschaltet sieht das Bild halt irgendwie blass aus. Die Farben und der Kontrast sind einfach besser und das ohne das irgendwelche Details im Dunkeln verloren gehen, was ja bei einer einfachen nachträglichen Kontrasterhöhung passieren würde.

[q@h]

:confused:

Stimmt doch garnicht :|
Doch, irgendwie wirkt's, als läge da ein heller, hauchdünner Schleier über dem Bild. Vielleicht bin auch nur zu müde - ich schau morgen nochmal drauf.

[deekey777]

Was ist los? Die Spiegelungen im Wasser sind zu schwach? Die waren auf "Reflect All" eingestellt. :P

( ;D )

Was vergessen: 9800 Pro, keine NV40. Darum kann ich keinen Vergleich zu Far Cry machen.

[rgt]

bei mir hat die einstellung von mat_r8bloom und mat_r8bloomlvl irgendwie keinen einfluss auf das bild.

nur mat_r8bloomgamma verändert das bild, zusätzlich gibts noch eine variable die ein art cell-shading aktiviert.

ich find nicht dass es sich insgesamt besser aussieht als das standardmäßige hl2.

vor allem reagiert das ganze teilweise umgekehrt zum hdr ;)

[BlackBirdSR]

:confused:

Stimmt doch garnicht :|

Kotor2 wird auch recht unscharf damit.

[Quasar]

Klar, es ist heller (woohoo! Toller Effekt für Doom3), aber Quincunx ist nicht wesentlich unschärfer... obwohl es doch Teufels Beitrag zu Gottes Werk in Reininkarnation sein soll.

Komisch. :|

"HDRish":
http://img118.exs.cx/img118/5606/d3hdr1pd.jpg


Quincunx:
http://img224.exs.cx/img224/8913/d3demo0wp.jpg

[Jesus]

Was ist beim zweiten Bild los ?

[Mr. Lolman]

Was ist beim zweiten Bild los ?

so schaut D³ mit normalen Gammaeinstellungen und Quincunx AA aus. Ich weiss auch nicht inwiefern das mit HDRish vergleichbar sein soll. Klar einen kleinen Schleier gibts um hell erstrahlte Objekte, aber den gibts ja bei jedem Bloomfilter - und eigentlich ist der HDRish Shader eh nix anderes...

/edit: Quasar, schau dir mal die UAC Box an. Der Text ist bei Quincunx imho leicht unschärfer, auf jedenfall sieht mans aber bei der Oberkante...

/edit2: Und an der Oberkante vom linken Geländer sieht man, dass das Quincunx AA trotz zusätzlicher Unschärfe unzufriedenstellend ist. (Ganz im GGs. zu ATis 4xAA was beim oberen Screenshot zum Einsatz kam)

[Coda]

Das Problem an Doom 3 ist doch dass es gar keine Indirekte Beleuchtung gibt.
Wenn eine Stelle komplett schwarz ist, dann bringt Overbright auch nix mehr.

Es gibt eine CVAR mit der man die Beleuchtung skalieren kann, das erzeugt auch helleres Licht, aber für die Stellen die im Schatten liegen hat das auch keinen Effekt.

[Quasar]

Ich behaupte auch nicht, daß Quincunx-AA toll ist - wie soll auch ein 2-Sample-AA besser sein, als eines mit vier Samples?

Erstaunlich ist aber, daß es offenbar nur eine einzige Stelle zu geben scheint, wo dir das unheilige Quincunx schlechter vorkommt, als normales, 8xAF-geschärftes Rendering mit diesem "HDRish" Shader. Spricht eigentlich für meinen Eindruck, daß auf dem ganzen Bild ein Unschärfeschleier liegt - schließlich vernichtet QC ja auch wirksam im Full-Screen Bildinformationen.

[StefanV]

sorry, aber: willkommen zu _gestern_!
Das Ergebnis zählt, nicht der Weg!

Für die gebotene Leistung schaut Dumm3 ziemlich schlecht aus, nicht wirklich besser als manch ein älteres Game, nur lahmer...


Man hätte besser dran arbeiten sollen, das man möglichst beste Qualität bei möglichst bester Leistung hat, was man aktuell hat, ist eine Durchschnittliche Qualität bei schlechter Leistung, warum auch immer...

[Coda]

Wie gesagt, dezente radiosity Lightmaps hätten Wunder gewirkt imho.

[Jesus]

Hab mal noch ein paar shots mit dem HDR Mod gemacht:
(1280x1024, 6xAA, 16xAF)

http://nemesis.rushers.net/pics/1.jpg
http://nemesis.rushers.net/pics/2.jpg
http://nemesis.rushers.net/pics/3.jpg
http://nemesis.rushers.net/pics/4.jpg
http://nemesis.rushers.net/pics/5.jpg
http://nemesis.rushers.net/pics/6.jpg
http://nemesis.rushers.net/pics/7.jpg

[Lolman]

Erstaunlich ist aber, daß es offenbar nur eine einzige Stelle zu geben scheint, wo dir das unheilige Quincunx schlechter vorkommt, als normales, 8xAF-geschärftes Rendering mit diesem "HDRish" Shader.

Naja, wenn dein Screenshot so dunkel ist, dass man kaum was erkennt...

[Mr. Lolman]

Hab mal noch ein paar shots mit dem HDR Mod gemacht:
(1280x1024, 6xAA, 16xAF)


Hm, wie ist denn die Performance in 1280 mit 4xAA und 4xbi?

[aths]

Das Ergebnis zählt, nicht der Weg!

Für die gebotene Leistung schaut Dumm3 ziemlich schlecht aus, nicht wirklich besser als manch ein älteres Game, nur lahmer...Ich finde, dass Doom3 für die Leistung (zumindest auf einer GeForce, hehe ...) sehr gut aussieht.

[MadManniMan]

Hm, HL2 mit dem Mod sieht ungefähr so aus, wie wenn ich nach 3 Stunden Schlaf aus meiner (stets recht dunklen) Wohnung gehe und erleben darf, wie sehr die Mittagssonne die dicke Schneedecke meinen Augen weh tun läßt.
Ebenso ist der HDRish Shader übel mit Unschärfe verbunden, leider. Der Content wird nicht vermatscht, wie bei QC, wohl aber fehlts an der Abstimmung zwischen Effekt und Content.

Dennoch muß ich sagen, daß Doom3 mit echtem HDR/Tone Mapping/die-ganze-real-Licht-Bandbreite nochmal Welten besser aussähe.
Ist eurer Meinung nach evtl. in Aussicht, daß JC der Engine ein Update in die Richtung verpassen könnte? Oder geht das eher in Richtung seines neuen Projekts? Und könnte eine Modifikation der - vorher teuer lizensierten - Doom3-Engine da Erfolg haben?
IMHO ist Doom3 geradezu prädestiniert für Licht, wie es das MDR-Demo zum R300-Launch, bzw. RTHDRIBL bieten.

[deekey777]

New Half-Life 2 Technology to Premiere on G4's Attack of the Show (http://www.halflife2.net/forums/showthread.php?s=&threadid=76353)

Tune into G4’s ATTACK OF THE SHOW! next Wednesday to see Valve’s Doug Lombardi exclusively demonstrate an upcoming new level from what many have named the best PC game of all time – Half-Life 2.

This previously unseen Half-Life 2 area, dubbed “The Lost Coast”, demonstrates a brand new technology which Valve is implementing into the Source engine, called high-dynamic range lighting. This new technology enables a leap in lighting realism from even the current high benchmark set by Half-Life 2 and the existing Source engine. Tune in to glimpse the future of PC graphics with this live demonstration on G4’s ATTACK OF THE SHOW! LIVE next Wednesday [30th March] at 4PM PST / 7PM EST.

Die ATi-Levels sind wieder da!!!

Geklaut von HL2.Net (www.halflife2.net)


Das könnte wirklich sehr interessant sein, insbesondere, welche HW genutzt wird.

[mapel110]

Na da bin ich mal gespannt.

Müssen die eigentlich für HDR endlich diese grottigen, absolut falsch berechneten Schatten korrigieren?
Das sollte sich doch beißen, oder?! Ich mein, sonst wird man vom HDR "verwöhnt", wenn man es eigentlich garnicht sehen sollte.
:ugly:

[deekey777]

Na da bin ich mal gespannt.

Müssen die eigentlich für HDR endlich diese grottigen, absolut falsch berechneten Schatten korrigieren?
Das sollte sich doch beißen, oder?! Ich mein, sonst wird man vom HDR "verwöhnt", wenn man es eigentlich garnicht sehen sollte.
:ugly:

Was für Schatten? Es gibt in HL2 so etwas wie Schatten? ;)

Exclusive: New Half-Life 2 Technology (http://www.g4tv.com/attackoftheshow/features/51399/Exclusive_New_HalfLife_2_Technology_.html)

"On Wednesday’s show, Valve’s Doug Lombardi will give an exclusive demonstration of the previously unseen “The Lost Coast,” an upcoming expansion that utilizes a brand-new technology that Valve is implementing into the Source engine. Called “high-dynamic range lighting,” this new technology enables a leap in lighting realism from even the current high benchmark set by Half-Life 2 and the existing Source engine."

[Demirug]

Na da bin ich mal gespannt.

Müssen die eigentlich für HDR endlich diese grottigen, absolut falsch berechneten Schatten korrigieren?
Das sollte sich doch beißen, oder?! Ich mein, sonst wird man vom HDR "verwöhnt", wenn man es eigentlich garnicht sehen sollte.
:ugly:

Es gibt keinen technischen Grund die Schatten zu ändern.

Den meine neue Liebingsbeschreibung für HDR sagt:

HDR rendering stellt dem Postfilter die Bildinformationen in einer höheren Genauigkeit zur Verfügung als die bisherigen 8 Bit pro Kanal Formate. Sonst ändert sich aus technischer Sicht eigentlich nichts

[Quasar]

:)
9-Bit-Integer+ pro Kanal? Das wird aths aber gar nicht freuen.

[Demirug]

:)
9-Bit-Integer+ pro Kanal? Das wird aths aber gar nicht freuen.

Man könnte natürlich noch weiter einschränken das es mindestens 16 Bit Fliesspunkt sein müssen. Aber das wird ja dann schon wieder zu technisch für eine Kurzerklärung.

[Gast]

Ich finde, dass Doom3 für die Leistung (zumindest auf einer GeForce, hehe ...) sehr gut aussieht.

Ach, hier stören Dich die Matschtexturen, lahmes Leveldesign, schlechte Waffensounds ect. nicht?
Klar, D3 ist halt NV, während HL2 Ati ist.
Traurig, aber wahr.

[Quasar]

Ach, hier stören Dich die Matschtexturen, lahmes Leveldesign, schlechte Waffensounds ect. nicht?
Klar, D3 ist halt NV, während HL2 Ati ist.
Traurig, aber wahr.
aths sagte doch, daß es IHHO "gut aussieht" - das hat doch nichts mit den von dir angebrachten Punkten zu tun.

[deekey777]

In der TV-Sendung (siehe News oben) meinte Doug Lombardi*, daß die sog. Lost Coast Map in wenigen Wochen erscheint. Zusätzlich soll das ganze Spiel mit HDR aufgewertet werden, auch per SDK können Modder HDR in ihre Mods (nachträglich) einbauen.

Ergo: Bisjetzt kannte HL2 HDR nur von Hörensagen.






*Man sollte den Terminangaben von Doug Lombardi nicht so recht trauen, ist aber egal.
Bidchen: http://webpages.charter.net/tork64/
http://webpages.charter.net/tork64/0330164558_3.jpg


€dit: Argh, was vergessen.
Das Video aus der Sendung:
http://forums.gaminghorizon.com/showthread.php?t=127

[mapel110]

Es gibt keinen technischen Grund die Schatten zu ändern.

Den meine neue Liebingsbeschreibung für HDR sagt:
;(


text und bild
:up: Dann kann man wieder gespannt sein, wie sie es implemtiert haben.

[The_Invisible]

Ach, hier stören Dich die Matschtexturen, lahmes Leveldesign, schlechte Waffensounds ect. nicht?
Klar, D3 ist halt NV, während HL2 Ati ist.
Traurig, aber wahr.

Matschtexturen hat so ziemlich jedes spiel

mfg

[TheCounter]

They didn't specify any hardware by name, but the impression I got is that you're going to need at least a Radeon x800 for it to run.

Na hoffentlich :)

Ich hoffe es gibt bald mal ne Aussage von Valve dazu.

http://ve3d.ign.com/articles/600/600220p1.html?fromint=1

[deekey777]

:up: Dann kann man wieder gespannt sein, wie sie es implemtiert haben.


Wenn das Ganze schon auf der R420 Generation laufen soll, könnten die nVidianer mit ihren 6800ern benachteiligt werden, da deren "HDR" HW brachliegen wird.

[mapel110]

http://ve3d.ign.com/articles/600/600220p1.html?fromint=1
HDR (high dynamic range lighting) is similar technology to id's DOOM III shadows, except it focuses on light instead of darkness.
;D Der Vergleich ist mal geil.
at least x800 könnte auch sein, dass ene 6800 GT/Ultra im Rechner war. Außerdem nur eine pure Vermutung, allein basierend auf der benötigten Performance.

[deekey777]

HDR (high dynamic range lighting) is similar technology to id's DOOM III shadows, except it focuses on light instead of darkness.
;D Der Vergleich ist mal geil.
at least x800 könnte auch sein, dass ene 6800 GT/Ultra im Rechner war. Außerdem nur eine pure Vermutung, allein basierend auf der benötigten Performance.


Die ganze Präsentation per Torrent: http://home.earthlink.net/~dgagne/data/Attack%20of%20the%20Show-%20Doug%20Lombardi%20Interview.torrent

Da bekommt man auch mit, was der Vergleich zu Doom 3 sollte. Da ging es um das Wörtchen "Dynamic". Auch die Definition von Bloom ist nicht schlecht. :D

[mapel110]

Ich hab jetzt das Video gesehen und toll, sie hätten gleich Screenshots zeigen können. Auf dem Video tut sich garnichts. Nix dynamic, oder bin ich blind?
/edit
jetzt hab ich auch das komplette Filmchen gesehen und da sieht man auch nichts, was auf HDR schließen läßt.
Die Intensität ändert sich nicht.

btw auf die Frage, welchen IHV er bevorzugen würde, hat er sehr diplomatisch reagiert. Tolle Antwort, hätte ihn nicht erwartet. :up:

[Dunkeltier]

Wenn das Ganze schon auf der R420 Generation laufen soll, könnten die nVidianer mit ihren 6800ern benachteiligt werden, da deren "HDR" HW brachliegen wird.


Wenn das Valve-Zeugs auch nur wieder so ein Bloom-Scheiß wie der "HDRish"-Smartshader ist, bleibt das Zeugs bei mir sowieso aus. Ich habe mehrmals damit probiert Natural-Selection zu zocken, aber davon kriegste ja voll den Augenkrebs.

[deekey777]

Wenn das Valve-Zeugs auch nur wieder so ein Bloom-Scheiß wie der "HDRish"-Smartshader ist, bleibt das Zeugs bei mir sowieso aus. Ich habe mehrmals damit probiert Natural-Selection zu zocken, aber davon kriegste ja voll den Augenkrebs.

Bloom ist es nicht, denn Bloom ist der kleine Bruder in Richtung HDR und ist zu statisch (oder so ähnlich).
HDRish ist ein Smartshadereffekt.

Ich wette, daß die Lost Coast Map (und vielleicht auch das HDR Update) kurz vor oder gleichzeitig mit dem R520 erscheint, damit jeder sieht, wie schlecht seine Grafikkarte ist. ;(

[Demirug]

mapel, wenn HDR verwendet wird muss nicht zwangsläuf auch einen Postfilter zum Einsatz kommen welcher die Anpassung des Auges an das Umgebungslicht nachbildet. Da das aber IMHO eigentlich der "HDR-Effekt" überhaupt ist wäre es natürlich sehr schade wenn man das nicht eingebaut hätte.

[mapel110]

Da das aber IMHO eigentlich der "HDR-Effekt" überhaupt ist wäre es natürlich sehr schade wenn man das nicht eingebaut hätte.
Ganz genau auch meine Meinung. Und danach siehts leider aus auf den Videos.

[Gast]

mapel, wenn HDR verwendet wird muss nicht zwangsläuf auch einen Postfilter zum Einsatz kommen welcher die Anpassung des Auges an das Umgebungslicht nachbildet. Da das aber IMHO eigentlich der "HDR-Effekt" überhaupt ist wäre es natürlich sehr schade wenn man das nicht eingebaut hätte.
Aber das ist doch nicht der Kern von HDR, sondern ein Gimmick. Ich persönlich fände schon einen viel größeren Farbraum sinnvoll, der einfach realitischer Kontraste zulässt.

[Demirug]

Aber das ist doch nicht der Kern von HDR, sondern ein Gimmick. Ich persönlich fände schon einen viel größeren Farbraum sinnvoll, der einfach realitischer Kontraste zulässt.

Ohne Anzeigegeräte die diesen größeren Farbraum auch nutzen können bringt das aber noch nicht viel. Ohne Tonemapping geht es also nicht und da finde ich es schon durchaus sinnvoll das solange man keine entsprechenden Anzeigegeräte hat die Anpassung der Augen an die vorhandenen Lichtmenge simuliert.

[Mr. Lolman]

Ohne Anzeigegeräte die diesen größeren Farbraum auch nutzen können bringt das aber noch nicht viel. Ohne Tonemapping geht es also nicht und da finde ich es schon durchaus sinnvoll das solange man keine entsprechenden Anzeigegeräte hat die Anpassung der Augen an die vorhandenen Lichtmenge simuliert.


Ich dachte die Anzeigegeräte sind wurscht. Und wenn man HDR über Tonemapping definieren will, muss man sich damit abfinden dass ein getweaktes "The Project" auch HDR bietet:http://www.forum-3dcenter.de/vbulletin/showthread.php?p=2874328#post2874328

[Demirug]

Ich dachte die Anzeigegeräte sind wurscht. Und wenn man HDR über Tonemapping definieren will, muss man sich damit abfinden dass ein getweaktes "The Project" auch HDR bietet:http://www.forum-3dcenter.de/vbulletin/showthread.php?p=2874328#post2874328

Ich definiere HDR dorch gar nicht über das Tonemapping. Ich schrieb lediglich das ohne Anzeigegeräte die direkt etwas mit dem größeren Farbraum anfangen können ein Tonemapping in Verbindung mit HDR derzeit unerlässlich ist.

"The Project" kann in Verbidnung mit "MRT HDR" kein echtes HDR sein weil die dynamische Komponeten im Farbraum fehlt. Dafür ist ein Fliesskomma Format unerlässlich.

[Mr. Lolman]

"The Project" kann in Verbidnung mit "MRT HDR" kein echtes HDR sein weil die dynamische Komponeten im Farbraum fehlt. Dafür ist ein Fliesskomma Format unerlässlich.

Du meinst, dass das Tonemapping beim Project sich innerhalb eines fixen Farbraums abspielt, ohne die Farbnuancierung beeinflussen zu können? Ok. das ist gut möglich, blöderweise macht das NV-HDR bei Farcry AFAIK auch nicht von der Möglichkeit Gebrauch (im GGs. zu bspw. TM Sunrise), weswegen sich dieses optisch auch kaum vom "MRT HDR" abhebt - was wohl der Hauptgrund für meine Starrköpfigkeit bezüglich des HDR Themas sein dürfte X-D

/edit:

Hast du dir jetzt schon mal die Option "Dynamic Colors" bei der TM Sunrise Demo näher angesehen? Wirkt irgendwie verdammt wie HDR (inkl. dynamischer Farbnuancierung) und funzt auch auf SM2.0 Karten :|

[Demirug]

Du meinst, dass das Tonemapping beim Project sich innerhalb eines fixen Farbraums abspielt, ohne die Farbnuancierung beeinflussen zu können? Ok. das ist gut möglich, blöderweise macht das NV-HDR bei Farcry AFAIK auch nicht von der Möglichkeit Gebrauch (im GGs. zu bspw. TM Sunrise), weswegen sich dieses optisch auch kaum vom "MRT HDR" abhebt - was wohl der Hauptgrund für meine Starrköpfigkeit bezüglich des HDR Themas sein dürfte X-D

Ja, Farcry nutzt einen festen Farbraum der allerdings merkwürdig koodiert ist.

Zum einen haben sie einen normalen RGBA Buffer mit dem Bereich von 0-1 bei 8 Bit Genauigkeit. Desweiteren gibt es einen L-Buffer (Luminezens) von 0-16 aber auch nur mit 8 Bit. Auf der Basis des L-Buffers wird dann Mittelgrey, also die Durchschnittliche Helligkeit, bestimmt. Dieser wird dann benutzt um den RGBA Buffer zu remapen. Da dieser aber ja bei 1 clampt kann es zu den von mir erwähnten Effekten kommen wenn sich unterschiedliche Lichtquellen mit unterschiedlicher Farbe überschneiden.

/edit:

Hast du dir jetzt schon mal die Option "Dynamic Colors" bei der TM Sunrise Demo näher angesehen? Wirkt irgendwie verdammt wie HDR (inkl. dynamischer Farbnuancierung) und funzt auch auf SM2.0 Karten :|

Ich habe einen Blick darauf geworfen. Das Teil ist allerdings noch etwas störisch was die Aufzeichnung der Daten angeht. Sowiet ich das sehen konnte wird das ganze durch einen Postfilter erreicht der duch die CPU gesteuert ist. So ganz steige ich da aber noch nicht durch. Der Effekt das die Sonne andere Dinge überlagert hat damit allerdings nichts zu tun. Das wird erreicht indem man den Hintergrund der die Sonne enthält am Ende so rendert das die Stellen die sehr Lichtstark sind einfach das was schon da ist überdecken.

[dildo4u]

http://www.4players.de/4players.php/dispnews/Allgemein/Aktuelle_News/40493.html

So wies zu erwarten war das HL2 HDR wird extrem CPU lastig.

[mapel110]

http://www.4players.de/4players.php/dispnews/Allgemein/Aktuelle_News/40493.html

So wies zu erwarten war das HL2 HDR wird extrem CPU lastig.
Naja, Grafikkarte haben sie auch genannt. ;)

[Quasar]

Eigentlich haben sie die Voraussetzung für diesen speziellen Level genannt. Ob die hohe CPU-Anforderung am HDR liegt, darüber kann man nur raten in diesem Falle.

[dildo4u]

Eigentlich haben sie die Voraussetzung für diesen speziellen Level genannt. Ob die hohe CPU-Anforderung am HDR liegt, darüber kann man nur raten in diesem Falle.
Naja ich dachte Demurig hats Klar gemacht wenns "HDR" ist was auch auf ATI karten Funzt wirds eher CPU lastig.

[Gast]

naja, HDR sollte die lastverteilung eher in richtung GPU richten, aber valve schafft es bestimmt auch den prozessor genug rechnen zu lassen :(

[deekey777]

Ich glaub, die Hardware-Voraussetzungen dienen eher als "Abschreckung" für Leute, die immernoch denken, ihre 5700Ultra oder 9600Pro und die dazugehörenden Rechner wären optimal für Lost Coast.

Was eingefallen...
http://www.4players.de/4players.php/dispnews/Allgemein/Aktuelle_News/40493.html

So wies zu erwarten war das HL2 HDR wird extrem CPU lastig.


Nur so am Rande: Da stehen nur die Voraussetzungen für die Verlorene Küste, nicht für das später HDR Update für das Spiel selbst. Daß die ATi Level HW-hungrig sein werden, war auch längst klar.

Dennoch haben sich Leute aufgeregt, da der Doug Lombardi im Interview (für sie) nicht eindeutig sagte, daß HL2 auf HDR updated wird, sondern die Half-Life 2 Technologie, worauf sie meinten, daß die User selbst per SDK das HDR in das Spiel einbauen müßten. Oder so...

[Coda]

Ich vermute mal die hohe CPU Last kommt von einem Readback. Bravo Valve...

[Quasar]

Ein Readback würde aber nur die CPU, sondern höchstens den Rückkanal belasten. Ich glaube nicht, daß der Readback auf einem 2,4GHz-P4 schneller wäre als auf einem mit 3,8GHz - es sei denn, es wird irgendwas sinnvolles mit den Daten auf der CPU angestellt. ;(

[Gast 2005]

Ich wüsste auch nicht, was ein ReadBack bringen sollte, auch nicht für HDR.

[Chris Lux]

Ich wüsste auch nicht, was ein ReadBack bringen sollte, auch nicht für HDR.
durch diese technik kann man AA nutzbar machen, was bei render to texture heute nicht nutzbar ist.

[Gast]

durch diese technik kann man AA nutzbar machen, was bei render to texture heute nicht nutzbar ist.

dass würde imo auch mit dem üblichen rendern in texturen funktionieren solange man beim nv40 nicht die hardware-blending-einheiten verwendet.

[Demirug]

Render 2 Texture funktioniert über einen Trick auch mit AA. Allerdings nur für die Formate für die es auch für den normalen Framebuffer funktioniert. Zudem auch nur bei nVidia Karten weil bei ATI die entsprechenden Funktion nicht richtig arbeitet. Angeblich aber nur ein Treiberproblem.

[Chris Lux]

Render 2 Texture funktioniert über einen Trick auch mit AA. Allerdings nur für die Formate für die es auch für den normalen Framebuffer funktioniert. Zudem auch nur bei nVidia Karten weil bei ATI die entsprechenden Funktion nicht richtig arbeitet. Angeblich aber nur ein Treiberproblem.
dabei muss aber ein interner copy gemacht werden. ein nv engineer hat mal erklärt, dass ein rendertarget mit multisample buffer nicht als textur gebunden werden könne, da die textureinheiten nicht damit zurecht kommen. während eines buffer copys würde das downsampling geschehen, wodurch das fertige bild als textur verwendet würde.

[Coda]

Ja, und diese Kopie kann ATi nicht mit downsampling zur Zeit.

[mapel110]

Will keinen extra Thread für diese kleine Frage aufmachen. :)

Gibts eigentlich (halbwegs aktuelle) Spiele, die die Schatten genauso berechnen wie HL2? Also dass nur eine Lichtquelle berücksichtigt wird und dadurch reihenweise komplett falsche Schatten entstehen?

Mir fällt da wirklich nichts ein. Hab sowas noch nie in einem Spiel zuvor wahrgenommen und ich zocke recht viel. :)

[Grestorn]

Will keinen extra Thread für diese kleine Frage aufmachen. :)

Gibts eigentlich (halbwegs aktuelle) Spiele, die die Schatten genauso berechnen wie HL2? Also dass nur eine Lichtquelle berücksichtigt wird und dadurch reihenweise komplett falsche Schatten entstehen?

Mir fällt da wirklich nichts ein. Hab sowas noch nie in einem Spiel zuvor wahrgenommen und ich zocke recht viel. :)Falsche Schatten gibt's doch wie Sand am Meer.

Z.B. alle aufgebohrten Q3-Engine Spiele, wie EliteForce II, Jedi Knight Outcast & Academy usw.

Das der Schatten haltlos ohne Verbindung zum werfenden Objekt oder auf der falschen Seite von Oberflächen projeziert wird, habe ich auch schon x-mal gesehen.

Allerdings: eines der ersten Spiele mit korrekter Schattenberechnung (mehrere Lichtquellen) war übrigens Vampire: Redemption. Und das ist schon einige Jahre alt. Grafisch ziemlich geil damals. Und das erste Spiel, dass ich auf der Voodoo 5 so richtig mit AA genossen habe. Interesse halber mal neulich neu installiert, und es hält immer noch gut mit. Beeindruckend.

[Gast]

Will keinen extra Thread für diese kleine Frage aufmachen. :)

Gibts eigentlich (halbwegs aktuelle) Spiele, die die Schatten genauso berechnen wie HL2? Also dass nur eine Lichtquelle berücksichtigt wird und dadurch reihenweise komplett falsche Schatten entstehen?

Mir fällt da wirklich nichts ein. Hab sowas noch nie in einem Spiel zuvor wahrgenommen und ich zocke recht viel. :)

massenhaft spiele, z.b. in rennspielen wo die sonne als einzige lichtquelle existiert fällt es aber nicht wirklich auf.

früher war man ja froh überhaupt irgendwelche schatten zu haben da war nicht so wichtig ob diese korrekt waren ;)
im zeitalter von doom3&co wirkt das aber doch ziemlich peinlich (vor allem wenn man behauptet eine next-gen-engine zu besitzen ;) )

[mapel110]

Z.B. alle aufgebohrten Q3-Engine Spiele, wie EliteForce II, Jedi Knight Outcast & Academy usw.

Speziell bei so alten Titeln gabs ja im normalfall nur eine Lichtquelle. Warst du draußen, Sonne, warst du drin, eine grössere Lampe und falls noch eine kleinere Lampe vorhanden war, hatte die eh nur einen Vorberechneten Schatten. Außerdem gabs nicht so viele bewegliche Objekte, mit denen man falsche Schatten provozieren konnte. Meist warf ja nur der eigene Körper und eben die NPCs berechnete Schatten.
Also speziell bei alten Spielen fällt mir das aus den Gründen gar nicht auf.

[Grestorn]

Speziell bei so alten Titeln gabs ja im normalfall nur eine Lichtquelle. Warst du draußen, Sonne, warst du drin, eine grössere Lampe und falls noch eine kleinere Lampe vorhanden war, hatte die eh nur einen Vorberechneten Schatten. Außerdem gabs nicht so viele bewegliche Objekte, mit denen man falsche Schatten provozieren konnte. Meist warf ja nur der eigene Körper und eben die NPCs berechnete Schatten.
Also speziell bei alten Spielen fällt mir das aus den Gründen gar nicht auf.Naja, welche Spiele "dürfen" denn dann berücksichtigt werden? Sooo alt ist ja EF II und JK: A auch nun wieder nicht.

Wir haben in den letzten 2 Jahren einige Spiele gesehen, die sich sehr um eine korrekte Schattendarstellung bemüht haben (Splinter Cell 1 war wegweisend, Deus Ex 2, FC, Thief 3, Riddick und Doom3 haben das nur noch weiter verfeinert). Aber nicht jedes Spiel hat oder braucht korrekte Schatten, um gut zu sein. In KOTOR2 oder Gothic2 gehen sie mir nicht ab, und auch in EQ2 sind die reines Gimmick. In EQ2 werden die Schatten ohnehin meist abgeschaltet, da sie zu viel kosten.

Ich denke im übrigen, dass es weniger um die Anzahl der Lichtquellen geht, sondern mehr um die verwendete Technik für die Schattenberechnung. Dazu können andere sicher mehr schreiben, wie z.B. aths, aber man erkennt m.E. ziemlich deutlich den Generationswechsel in den "Schattenengines" zwischen Spielen aus der Q3- und UT2k3 Ära und den modernen Spielen wie FC, Doom3, Deus Ex2 oder SC.

HL2 scheint eine sehr einfache Schattenengine zu nutzen, die nicht nur lediglich eine Lichtquelle berücksichtigt, sondern auch den Schatten sehr oft völlig falsch projeziert.

[Gast]

Naja, welche Spiele "dürfen" denn dann berücksichtigt werden? Sooo alt ist ja EF II und JK: A auch nun wieder nicht.



verwendet jedi knight nicht stencil shadows, die allerdings auf 1 lichtquelle eingeschränkt wurden und auch nur auf die wenigen beweglichen objekte angewendet wird (imo eh nur charaktere)?

[Banshee18]

Andere Frage (will keinen extra Thread eröffnen): Warum haben die Schatten in JK:JA so viel Performance gekostet? Auf meiner Radeon 9700 war das Spiel auf 1024x768 mit Schatten fast unspielbar, alles andere zu dieser Zeit lief auch in höheren Auflösungen mit AA und AF noch sehr gut. Der Jedi Knight-Teil davor hatte afaik zumindest sehr ähnlich aussehende Schatten und lief 1000 mal besser.

mfg

Banshee

[Gast]

Vertue ich mich oder sehe ich in den Kanal-Leveln sowas wie die berühmten HDR-Effekte auf meiner R9700 Pro?

Weil ic die "Orginal HDR-nV40 Effekte noch nie gesehen habe weiß ich natürlich nicht ob ich da was verwechsle. Bitte um Aufklärung.



HDR auf R300 das Geht auch weil im Sader Mod 2 auch HDR darstellen kann . Aber HL 2 Stellt ken HDR da.

[Coda]

R300/R420 ist nur bedingt für HDR geeignet weil die FP ROPs fehlen. Aber das wurde ja schon oft durchgekaut.

[Igzorn]

R300/R520 ist nur bedingt für HDR geeignet weil die FP ROPs fehlen. Aber das wurde ja schon oft durchgekaut.


Bist du sicher das du den R520 mit ein beziehnen wolltest? Denke mal das du R420 meinst. Der R520 sollte doch schon wesentlich besser HDR unterstützen als bisher möglich. Zumindestens würde ich das von einer neuentwicklung erwarten die so lange auf sich warten lässt ;)

[Coda]

Ich meinte R420. War ein Schreibfehler.

Der R520 sollte doch schon wesentlich besser HDR unterstützen als bisher möglich.NV40 kann da eigentlich auch schon alles nötige.

[Igzorn]

Naja dachte da an besser das es vielleicht nicht mehr so stark an der Geschwindigkeit zieht.

Also jetzt nicht nur da durch das der R520 höher getaktet ist sondern das er vielleicht allgemein etwas schneller damit umgehen kann.

[Coda]

Unterstützen heißt bei mir was anderes als schnell sein.

[Demirug]

Ich meinte R420. War ein Schreibfehler.

NV40 kann da eigentlich auch schon alles nötige.

Nein.

- MSAA für FP16 Rendertargets fehlt
- FP32 HDR wird nicht aktiv unterstützt. (Wäre ganz praktisch wenn man eine GPU als Sound DSP missbrauchen will)
- Kein Scanout von FP16 Targets. (Wobei das von DX ja sowieso nicht unterstützt wird)

[Coda]

Urks. Ganz vergessen *schäm*

[Gast]

Naja dachte da an besser das es vielleicht nicht mehr so stark an der Geschwindigkeit zieht.

Also jetzt nicht nur da durch das der R520 höher getaktet ist sondern das er vielleicht allgemein etwas schneller damit umgehen kann.

da man eigentlich davon ausgehen kann dass das speicherinterface bei 256bit bleibt, wird man da nicht allzuviel beschleunigen können. bei 64bit limitiert einfach wieder die bandbreite.

es wird wohl eher so wie damals beim übergang von 16bit auf 32bit sein.

bereits die RivaTNT konnte 32bit (mit starken einbrüchen). erst auf der gf1DDR waren die verluste einigermaßen in grenzen, und irgendwann ab gf3/4 war es quasi for free.

auch beim 64bit-puffer wird es wohl noch einige generationen dauern bis der geschwindigkeitseinbrauch nicht mehr nennenswert sein wird.

[Gast 2005]

da man eigentlich davon ausgehen kann dass das speicherinterface bei 256bit bleibt, wird man da nicht allzuviel beschleunigen können. bei 64bit limitiert einfach wieder die bandbreite.

es wird wohl eher so wie damals beim übergang von 16bit auf 32bit sein.

bereits die RivaTNT konnte 32bit (mit starken einbrüchen). erst auf der gf1DDR waren die verluste einigermaßen in grenzen, und irgendwann ab gf3/4 war es quasi for free.

auch beim 64bit-puffer wird es wohl noch einige generationen dauern bis der geschwindigkeitseinbrauch nicht mehr nennenswert sein wird.
Naja, der NV40 hat ein kleines Problem damit, direkt 64Bit Werte in den FrameBuffer zu schreiben. NVidia empfiehlt ja, gleichzeitig in 2x32 Bit Rendertargets zu schreiben weil das Speicherinterface sonst langsamer ist als nötig. Das macht aber noch kein Spiel (FarCry oder SC3), weil es bedeutet, dass die Spieleentwickler alle(!) Shader nur für den HDR-Einsatz neu schreiben müssten.
Diese Unzulänglichkeit könnte der R520 beseitigen, so dass FarCry und SC3 so deutlich schneller als bei dem NV40 laufen.

[Gast]

Naja, der NV40 hat ein kleines Problem damit, direkt 64Bit Werte in den FrameBuffer zu schreiben. NVidia empfiehlt ja, gleichzeitig in 2x32 Bit Rendertargets zu schreiben weil das Speicherinterface sonst langsamer ist als nötig. Das macht aber noch kein Spiel (FarCry oder SC3), weil es bedeutet, dass die Spieleentwickler alle(!) Shader nur für den HDR-Einsatz neu schreiben müssten.
Diese Unzulänglichkeit könnte der R520 beseitigen, so dass FarCry und SC3 so deutlich schneller als bei dem NV40 laufen.

in einem ATI-paper empfiehlt ATI ebenfalls 2x32bit-puffer zu verwenden, und da HDR wohl erst mit dem R520 interessant wird ist stark davon auszugehen dass das dafür gelten wird.

ist auch recht praktisch da wohl beide IHV´s mit 2x32bit schneller als mit 1x64bit sein dürften. wenn die shader von anfang an so geplant sind gibt es auch keinen mehraufwand, und mittlerweile gibt es ja erst 2 spiele bei denen die shader geändert werden müssten (wobei bei farcry wohl andererseits noch wesentlich mehr optimierungspotential stecken dürfte)

[Gast 2005]

in einem ATI-paper empfiehlt ATI ebenfalls 2x32bit-puffer zu verwenden, und da HDR wohl erst mit dem R520 interessant wird ist stark davon auszugehen dass das dafür gelten wird.

ist auch recht praktisch da wohl beide IHV´s mit 2x32bit schneller als mit 1x64bit sein dürften. wenn die shader von anfang an so geplant sind gibt es auch keinen mehraufwand, und mittlerweile gibt es ja erst 2 spiele bei denen die shader geändert werden müssten (wobei bei farcry wohl andererseits noch wesentlich mehr optimierungspotential stecken dürfte)
Meinst du dieses Paper: http://www.ati.com/developer/gdc/D3DTutorial08_FarCryAndDX9.pdf ?
Das ist nur etwas von ATI gesponsort, stammt aber eigentlich von CryTek. Und die könnten sich mit dem Tip speziell auf den NV40 beziehen. Von daher hab ich noch etwas Hoffnung für den R520.

Zu den Shadern: Das Problem ist ja, dass man die normalen 32-Bit Shader nicht mehr verwenden könnte, wenn man in 2 Rendertargets schreiben will. Daher müssten die Entwickler für den NV40 jeden popilgen Gras-Pixelshader neu schreiben, was man sich beim R520 (eventuell!) ersparen könnte wenn der effizient in ein 64Bit Rendertarget zeichnen könnte.

[Gast]

nein ich meinte ein anderes paper, glaub aber nicht dass ich das noch finde.

war jedenfalls ein typisches ati-pdf mit rotem rahmen und ati-logo in kopf- und fußzeile (also halt das typische ati-design, nicht das crytec-design von deinem)

es wurde auch nur allgemein geschrieben dass 2x32 besser ist, nicht im bezug auf ein spiel.

[~Norsk~]

Hi,
ich habe gehört das bald eine HL²:Deathmatch Map rauskommt wo HDR vorkommt?!

[deekey777]

Hi,
ich habe gehört das bald eine HL²: Deathmatch Map rauskommt wo HDR vorkommt?!

Dann hast du dich verhört. ;(

Heute wurde das Video zu Lost Coast veröffentlicht:
http://www.pcgames.de/?article_id=366120
(166MB)

[Jesus]

Dann hast du dich verhört. ;(

Heute wurde das Video zu Lost Coast veröffentlicht:
http://www.pcgames.de/?article_id=366120
(166MB)

Es heisst zumindest hdr_lostcoast :rolleyes:

[IVN]

Es heisst zumindest hdr_lostcoast :rolleyes:

:uclap:

[deekey777]

:uclap:

Und was soll dein Spam?

Es wird im Video tatsächlich HDR mit der Source-Engine gezeigt. Jesus meinte wohl, daß zumindest im Namen des Videos HDR vorkommt.

[aths]

da man eigentlich davon ausgehen kann dass das speicherinterface bei 256bit bleibt, wird man da nicht allzuviel beschleunigen können. bei 64bit limitiert einfach wieder die bandbreite.

es wird wohl eher so wie damals beim übergang von 16bit auf 32bit sein.

bereits die RivaTNT konnte 32bit (mit starken einbrüchen). erst auf der gf1DDR waren die verluste einigermaßen in grenzen, und irgendwann ab gf3/4 war es quasi for free.

auch beim 64bit-puffer wird es wohl noch einige generationen dauern bis der geschwindigkeitseinbrauch nicht mehr nennenswert sein wird.Genau. Noch auf längere Sicht wird 32-Bit-Rendering Standard sein. Der 64-Bit-Framebuffer ist aus meiner Sicht aber trotzdem unumgänglich.

Wenn ich jetzt nicht voll daneben liege, würde sich eine TDBR-Architektur sehr gut eigenen, um schnelles 64-Bit-Rendering mit Multisampling AA zu bieten.

[PCGH_Thilo]

Dann hast du dich verhört. ;(

Heute wurde das Video zu Lost Coast veröffentlicht:
http://www.pcgames.de/?article_id=366120
(166MB)

*schleichwerbung on*
ist übrigens auch auf der kommenden PCGH (EVT: 4.5.) =)
*schleichwerbung off*

[mapel110]

*schleichwerbung on*
ist übrigens auch auf der kommenden PCGH (EVT: 4.5.) =)
*schleichwerbung off*
weißt du, wann das Level an sich veröffentlich wird?

[PCGH_Thilo]

weißt du, wann das Level an sich veröffentlich wird?

der level soll noch im mai kommen

[Rage3d-Member]

Die neuesten Meldung deuten aber darauf hin, dass Sommer wahrscheinlicher ist. Hoffentlich macht Valve einen guten Job und zeigt der Nvidia-Propaganda-Truppe, dass es eben auch mit PS2.0 möglich ist HDR vernünftig darzustellen.

[aths]

Die neuesten Meldung deuten aber darauf hin, dass Sommer wahrscheinlicher ist. Hoffentlich macht Valve einen guten Job und zeigt der Nvidia-Propaganda-Truppe, dass es eben auch mit PS2.0 möglich ist HDR vernünftig darzustellen.Ob man vernünftiges HDR-Rendering gestalten kann hängt nicht davon ab, ob man PS2 oder PS3 hat (PS1 hingegen ist ungeeignet), sondern ob es bestimmte Zusatz-Features gibt (die NV40 im wesentlichen hat, R420 jedoch nicht. Konkret Floating-Point-Alphablending und Floating-Point-Texturfilterung.)

[Demirug]

Die neuesten Meldung deuten aber darauf hin, dass Sommer wahrscheinlicher ist. Hoffentlich macht Valve einen guten Job und zeigt der Nvidia-Propaganda-Truppe, dass es eben auch mit PS2.0 möglich ist HDR vernünftig darzustellen.

Ich muss ja leider noch die Klappe halten aber du wirst wahrscheinlich enttäuscht werden.

[Rage3d-Member]

Naja, ich kenn jetzt nur die HDR Effekte von Farcry und die haben mich wirklich nicht umgehauen. Sie wirken auf mich eher störend als realistisch. Vollkommen übertrieben und unrealistisch. Es wundert mich eh warum fast alle förmlich nach HDR schreien. Aber wenn das HDR der Source-Engine jetzt noch übertriebener Dargestellt wird, wonach es auf dem Promo-Video doch stark aussah, dann gute nacht.

[Spasstiger]

@rage3d: HDR ist eine Annäherung an die Realität und hat eigentlich nix mit krassen Überblendeffekten oder ähnlichem zu tun (auch wenn aktuelle HDR-Games diesen Anschein erwecken). Zukünftige Spiele werden allesamt HDR unterstützen und wahrscheinlich will man dann HDR auch gar nicht mehr missen. Wenn ich mir z.b. eine Oberfläche mit realistisch aussehendem gebürsteten Metall vorstelle, die variierenden Beleuchtungsszenarien ausgesetzt ist (z.b. Tag/Nacht-Wechsel) ... ich denke nicht, dass man da ohne HDR weit kommen würde.
Bei Farcry kann man das HDR übrigens ziemlich gut anpassen an den jeweiligen persönlichen Geschmack.

[deekey777]

Ich muss ja leider noch die Klappe halten aber du wirst wahrscheinlich enttäuscht werden.

Das macht richtig Vorfreude...

Aber auf dem Video sind sehr oft weiße "Klötzchen" (ähnlich den Artefakten bei zu niedriger Bitrate bei Videos) zu sehen.

[Botcruscher]

*schleichwerbung on*
ist übrigens auch auf der kommenden PCGH (EVT: 4.5.) =)
*schleichwerbung off*

Dann giebts aber hoffetlich auch einen schönen Artikel dazu. :)

Ich muss ja leider noch die Klappe halten aber du wirst wahrscheinlich enttäuscht werden.

Wie sieht den die Zukunft aus? Wird sich HDR richtig durchsetzen, oder ein Eyecandy ,was auf wenige Stellen beschrenkt ist, beleiben?

[Coda]

FP Framebuffer werden sich mit Sicherheit früher oder später durchsetzen.

[Gast]

Naja, ich kenn jetzt nur die HDR Effekte von Farcry und die haben mich wirklich nicht umgehauen. Sie wirken auf mich eher störend als realistisch. Vollkommen übertrieben und unrealistisch. Es wundert mich eh warum fast alle förmlich nach HDR schreien. Aber wenn das HDR der Source-Engine jetzt noch übertriebener Dargestellt wird, wonach es auf dem Promo-Video doch stark aussah, dann gute nacht.

HDR sieht in SC3 extrem gut aus, und in Farcry lässt es sich sehr gut an "natürliche" verhältnisse anpassen. klarerweise protzt man am anfang mit überblendeffekten, diese sieht man halt am besten.

[Mr. Lolman]

Ob man vernünftiges HDR-Rendering gestalten kann hängt nicht davon ab, ob man PS2 oder PS3 hat (PS1 hingegen ist ungeeignet), sondern ob es bestimmte Zusatz-Features gibt (die NV40 im wesentlichen hat, R420 jedoch nicht. Konkret Floating-Point-Alphablending und Floating-Point-Texturfilterung.)

Dynmic Colors bei TM Sunrise bringen auch HDR ähnliche Effekte - und funktionieren sogar problemlos mit meinem 64MB 9500 Kärtchen...

[Coda]

Jaja... Und Voodoos 16 bit würde auch 2010 noch reichen :rolleyes:

[Lolman]

Jaja... Und Voodoos 16 bit würde auch 2010 noch reichen :rolleyes:

Tests doch selbst, wenn du mir nicht glaubst. BTW: Mit 2xAA/4xAF auf nem XP2000+ (winXP, 512MB, 1.66GHz, 133MHz FSB) hat man ~30fps (mit aktivem Emule im Hintergrund:

http://www.forum-3dcenter.de/vbulletin/showthread.php?p=2840701#post2840701

[dildo4u]

Ich hatte heute meine neue PCGH im Postfach da wurde Gary Mc Taggart von Valve interviewt zum Thema HDR und Source Engine auf der seite 86 in der Ausgabe 6/2005

PCGH:Gibt es verschiedene HDR Render Modi?

Gary:Ja die neue Engine Erweiterung besitzt zwei Modi.Für die Optimale Darstellungsqualität wird Shader Model 3.0 Benötigt,außerdem müssen Texturen mit 16Bit pro Komponente fließkommagenau gefiltert werden.Für eine verringerte Qualität reicht SM 2.0 aus,Texturen sind dann nur mit 16Bit pro Komponente ganzzahlengenau zu filtern.


PCGH:Wodurch unterscheiden sich die Qualitätsstufen optisch?

Gary:Beim HDR mit einer niedrigeren Qualitätsstufe ist der Sättigungsgrad
der Wasserreflexionen geringer,das Tone-Mapping besitzt nur eine lineare
Farbskala und auch die Glanzeffekte sind weniger detailliert.Dafür kann in diesem Modus FSAA aktiviert werden.

PCGH:Nutzt ihr beim Tone Mapping nur die Helligkeitsdaten des aktuellen Frames?

Gary:Nein,wir nutzen die Helligkeitsdaten vieler vorheriger Frames,
um die Adaption der Auges an die geänderten Lichtverhältnisse zum simulieren.

[mapel110]

PCGH:Nutzt ihr beim Tone Mapping nur die Helligkeitsdaten des aktuellen Frames?

Gary:Nein,wir nutzen die Helligkeitsdaten vieler vorheriger Frames,
um die Adaption der Auges an die geänderten Lichtverhältnisse zum simulieren.
Das sieht man auf den Videos aber nicht wirklich. Wäre ja nett, wenns doch drin ist.

btw ich seh schon wieder die flamewars kommen. "Oh, der schlechtere Modus ist ja sowas von geil weil da AA geht." -> "Nein, der sieht bescheiden aus. Der SM3-Modus ist tausend mal besser, auch wenn kein AA geht." :rolleyes:

[Demirug]

Ich hoffe meine Fragen waren nicht zu technisch^^

[Spasstiger]

Das sieht man auf den Videos aber nicht wirklich. Wäre ja nett, wenns doch drin ist.

btw ich seh schon wieder die flamewars kommen. "Oh, der schlechtere Modus ist ja sowas von geil weil da AA geht." -> "Nein, der sieht bescheiden aus. Der SM3-Modus ist tausend mal besser, auch wenn kein AA geht." :rolleyes:

Bin noch viel mehr gespannt auf die Flamewars ATI vs. Nvida: "Meine Radeon X800 ist in Half-Life 2 viel besser als deine GeForce 6800" - "Trottel, ich kann echtes HDR in Half-Life 2 anschalten und du nicht." ;D

[Coda]

Tests doch selbst, wenn du mir nicht glaubst. BTW: Mit 2xAA/4xAF auf nem XP2000+ (winXP, 512MB, 1.66GHz, 133MHz FSB) hat man ~30fps (mit aktivem Emule im Hintergrund:Es ist mir egal ob man gute Perfo damit rausholt, es ist und bleibt kein HDR.

HDR wird viel zu sehr mit dem Blur von sehr hellen Lichtquellen gleichgesetzt. Es gibt deutlich mehr was damit machbar ist.

[Gast]

PCGH:Gibt es verschiedene HDR Render Modi?

Gary:Ja die neue Engine Erweiterung besitzt zwei Modi.Für die Optimale Darstellungsqualität wird Shader Model 3.0 Benötigt,außerdem müssen Texturen mit 16Bit pro Komponente fließkommagenau gefiltert werden.Für eine verringerte Qualität reicht SM 2.0 aus,Texturen sind dann nur mit 16Bit pro Komponente ganzzahlengenau zu filtern.


PCGH:Wodurch unterscheiden sich die Qualitätsstufen optisch?

Gary:Beim HDR mit einer niedrigeren Qualitätsstufe ist der Sättigungsgrad
der Wasserreflexionen geringer,das Tone-Mapping besitzt nur eine lineare
Farbskala und auch die Glanzeffekte sind weniger detailliert.Dafür kann in diesem Modus FSAA aktiviert werden.

PCGH:Nutzt ihr beim Tone Mapping nur die Helligkeitsdaten des aktuellen Frames?

Gary:Nein,wir nutzen die Helligkeitsdaten vieler vorheriger Frames,
um die Adaption der Auges an die geänderten Lichtverhältnisse zum simulieren.

könnte es dann sein dass das "bessere" HDR sogar schneller läuft, weil die FP16-blending-einheiten benützt werden, als das qualitativ schlechtere HDR?

[Spasstiger]

könnte es dann sein dass das "bessere" HDR sogar schneller läuft, weil die FP16-blending-einheiten benützt werden, als das qualitativ schlechtere HDR?

Das echte HDR dürfte wohl so schnell laufen wie man es z.b. schon aus Farcry oder Splinter Cell CT kennt.

[Coda]

So schlecht wie in FarCry auf keinen Fall. In Splinter Cell ist es auch gar nicht so übel...

Wenn Valve noch den Trick mit den 2 FP16 writes benützt (naja unwahrscheinlich) ist es nochmal deutlich schneller.

[HeldImZelt]

Ist das, was die PS3 ausspuckt schon HDR oder nur fake? Ist ja ein nVidia Chip mit mindestens PS3.0.
http://www.ps2nfo.com/news/ps3_heavenlysword_01.jpg
http://www.ps2nfo.com/news/ps3_heavenlysword_03.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_01.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_02.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_04.jpg

[Gast]

Ist das, was die PS3 ausspuckt schon HDR oder nur fake? Ist ja ein nVidia Chip mit mindestens PS3.0.
http://www.ps2nfo.com/news/ps3_heavenlysword_01.jpg
http://www.ps2nfo.com/news/ps3_heavenlysword_03.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_01.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_02.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_04.jpg

kann man auf den screenshots nicht wirklich sagen, da man die dynamik nicht sieht, ich denke aber schon dass es sich um echtes HDR handelt, alles andere wäre für eine next-gen konsole wirklich eine enttäuschung.

[HeldImZelt]

Das heisst, die Stärke (oder der Schwerpunkt) des HDR Renderings liegt in der Dynamik, also in der Bewegung/Veränderung der Farben? Sprich, Standbilder sind für die Veranschaulichung dieser Technik eher ungeeignet?
Kann man das so sagen?

[dildo4u]

Das heisst, die Stärke (oder der Schwerpunkt) des HDR Renderings liegt in der Dynamik, also in der Bewegung/Veränderung der Farben? Sprich, Standbilder sind für die Veranschaulichung dieser Technik eher ungeeignet?
Kann man das so sagen?
Jup da HDR ein dynamischen Prozess simuliert nämlich die Anpassung der Augen
an verschiedene Lichtverhältnisse.

[Gast]

Das heisst, die Stärke (oder der Schwerpunkt) des HDR Renderings liegt in der Dynamik, also in der Bewegung/Veränderung der Farben? Sprich, Standbilder sind für die Veranschaulichung dieser Technik eher ungeeignet?
Kann man das so sagen?

prinzipiell erhöht hdr-rendering mal nur die farbtiefe, was man damit macht ist eine andere sache. wenn du dich erinnerst als 32bit-rendering eingeführt wurde hat man lange keinen unterschied zu 16bit gesehen.

wenn "nur" hdr-rendering zum einsatz kommt wirst du bei heutigem content auch kaum einen unterschied sehen. entscheidend ist aber nun dass der erhöhte farbraum es erlaubt sogenanntes tone-mapping einzusetzen, welches die augenanpassung an verändernde lichtverhältnisse simuliert. dieses kommt eigentlich immer in verbindung mit hdr-rendering zum einsatz. diesen effekt sieht man in erster linie in bewegung.

weiters tritt z.b. in splinter-cell3 mit 32bit-rendering teilweise color-banding auf, was mit hdr nicht mehr der fall ist.

[Demirug]

Wobei das neue HL2 Level FP16 Lightmaps haben soll.

[Xmas]

Ist das, was die PS3 ausspuckt schon HDR oder nur fake? Ist ja ein nVidia Chip mit mindestens PS3.0.
http://www.ps2nfo.com/news/ps3_heavenlysword_01.jpg
http://www.ps2nfo.com/news/ps3_heavenlysword_03.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_01.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_02.jpg
http://www.ps2nfo.com/news/ps3_elderscrolls4_04.jpg
Das sind eh keine PS3-Screenshots, die stammen alle von einem PC. Und die Heavenly Sword-Shots sind ganz bestimmt nicht mehr repräsentativ ;)

[HeldImZelt]

Hast recht.. aber vielleicht nicht alle. Verbindliches gibt's wohl erst auf der E3. Das einige Bilder von 05/2004 sind ist mir gerade erst aufgefallen. ;)
Ich geh aber mal davon aus dass die endgültige Konsolenversion ähnliche Effekte aufweisen wird...

[Ailuros]

Genau. Noch auf längere Sicht wird 32-Bit-Rendering Standard sein. Der 64-Bit-Framebuffer ist aus meiner Sicht aber trotzdem unumgänglich.

Wenn ich jetzt nicht voll daneben liege, würde sich eine TDBR-Architektur sehr gut eigenen, um schnelles 64-Bit-Rendering mit Multisampling AA zu bieten.

Sogar moderate hybride SS/MSAA modi waeren moeglich, falls die Leistung mit 64bpp HDR nicht allzu niedrig ist.

Pures MSAA ist natuerlich schneller, aber ich sehe viel zu oft mit eingeschaltetem float HDR auf der NV40 Texturen-aliasing. So viele Kleinigkeiten sind mir nun auch nicht bekannt, aber ich will auch nicht ausschliessen dass jegliche erster Generation SM3.0 GPUs mit 64bpp HDR Faehigkeiten, vielleicht das gleiche Problem gehabt haetten und da hilft natuerlich ein Schuss SSAA, wenn's nicht anders geht.

[aths]

Sogar moderate hybride SS/MSAA modi waeren moeglich, falls die Leistung mit 64bpp HDR nicht allzu niedrig ist.

Pures MSAA ist natuerlich schneller, aber ich sehe viel zu oft mit eingeschaltetem float HDR auf der NV40 Texturen-aliasing. So viele Kleinigkeiten sind mir nun auch nicht bekannt, aber ich will auch nicht ausschliessen dass jegliche erster Generation SM3.0 GPUs mit 64bpp HDR Faehigkeiten, vielleicht das gleiche Problem gehabt haetten und da hilft natuerlich ein Schuss SSAA, wenn's nicht anders geht.Es geht anders – bei vernünftigen Texturen kann ein vernünftiger Texturfilter vernünftige, also aliasingfreie Ergebnisse bringen.

[Xmas]

Es geht anders – bei vernünftigen Texturen kann ein vernünftiger Texturfilter vernünftige, also aliasingfreie Ergebnisse bringen.
Bei ordentlichen Shadern hilft es nicht mehr viel dass die Texturen aliasingfrei gefiltert werden.

[aths]

Bei ordentlichen Shadern hilft es nicht mehr viel dass die Texturen aliasingfrei gefiltert werden.Ordentliche Shader kennen ihre Zielfrequenz :)

[Xmas]

Ordentliche Shader kennen ihre Zielfrequenz :)
Und wenn diese vom (evtl. dynamischen) Content abhängig ist?

[aths]

Und wenn diese vom (evtl. dynamischen) Content abhängig ist?Dann muss man für den Content bestimmte Parameter kennen und dem Shader mitteilen.

[Ailuros]

Eine ausgezeichnete Erklaerung vom B3D board ueber HDR-Moeglichkeiten:

The OpenEXR open is several things, which causes no end of confusion. OpenEXR could mean any of the following:

* The 16 bit floating point datatype (though this is really called half, but people mix it up)
* The image file format, which among other things can contain pixels of the half datatype (which is the default)
* The library to read/write said files
* The whole library included related math functions that you get if you download the source of the directory

The one most pertinent to real-time applications is the half datatype. It's the exact same format as the fp16, which is to say 1 sign bit / 10 mantissa bits / 5 sign bits. Whenever you create a texture or render target of 16 bit data, or create a half in a shader, that's what you are working with. It's just a spec. No one owes it per se, just as no one ownes IEEE 32 bit floating point format. It just exists, and everyone uses it. To my knowledge, it was developed originally by ILM, then filtered into GPU land.

No graphics card company implements HDR directly. They can't. It's not an algorithm or a feature. It's a concept whose use is enabled by the existence of other features. In the most naive description, HDR requires a storage and processing datatype that is capable of representing dynamic ranges (ratio of largest to smallest value) that exceed that of an 8-bit unsigned integer (current pixel format). ATI has supported those since the 9700. Every card since then has fp16 and fp32 texture formats, and the shader artithmatic is floating point as well.

Now, for some applications, being able to do that is sufficient to say that the card supports HDR (again in this nebulous concept form). When we begin talking about games, we start making other assuptions that impose more features. What all current ATI cards are missing is blending on floating point render targets. Meaning, that after you rasterize a pixel, you can set some artithmetic operation to combine that pixel value with the value already in memory. This is set through API state flags and happens after the pixel shader. Anything with particle systems, glass, water, clouds, uses multipass rendering, or numerous other effects that games are expected to have need this feature.

The ping-pong refers to people manually doing that blending. Render to RT1, then on the next pass set RT1 as a texture, blend in your shader, and output to RT2. Then swap RT1 and RT2 and do it again, and again for ever object you need to blend. Again, this is not ATI's implementation of HDR (which isn't something you can directly implement), it's how clever developers have acheived blending of floating point render targets without having specific API support for it.

The problem with this ping-pong is it's really slow. Changing render targets and shaders are relatively heavy operations for the 3D runtime. They stall the pipeline a lot. Which is why they aren't really useable for games of any reasonable scene complexity like an FPS.

Now, regarding the F-buffer, this doesn't solve the current problem. The F-buffer was created to get around the maximum lengths of pixel shaders. A long pixel shader could be broken down into parts small enough to be run on the current hardware. Each part would be able to read from a block of memory where results from the previous pass would be stored and write to a block of memory for the next pass. From a D3D-level API standpoint, nothing changes except shaders that wouldn't compile because they were too long now do. Everything would be handled internally.

This doesn't really gain us anything because the drivers would still have to effectively ping-pong in order to guarantee the right results. If you've ever tried to do a gaussian blur reading/writing the same image, you'll understand that the pixels already done will affect new pixels being operated on. This gets even messier with texture caches and the like.

So what does this all mean? Well, since the F-buffer would have to ping-pong internally due to previous results affecting latter results, we still have the same problem. The existence of the F-buffer, a construct to allow arbitrarily long shaders, has no implications on whether or not blending on floating point surfaces is possible. So, we are stuck in the same place.

http://www.beyond3d.com/forum/viewtopic.php?t=22627


Uebrigens zum Thema Texture-aliasing: zwischen dem Optimum der Theorie, das was Entwickler am Ende zu Stande zu bringen und den moeglichen Limitierungen jeder HW gibt es stets bestimmte Abstaende. Theoretisch duerfte es in Spielen deren Entwicklung seit 2002 begann, keine oder nur minimale Not fuer jegliche Form von Supersampling geben. In einem gegeben Fall ueber eine miese Implementierung zu meckern hilft mir dann nicht viel, wenn ich trotz allem immer noch tanzende Maeander vor mir sehen kann.

Ich frage mich auch schon seit ein paar Wochen warum Dev bei B3D in letzter Zeit zu oft ueber SSAA relevante Themen fragt. Kann sein dass es dank seiner Bevorzugungen ist, oder auch vielleicht nicht...

[TheRealTentacle]

Ich hab ma ne Frage. Dieser Bloom Effekt ist doch eigendlich nichts weiter, als ein Shader, der ab einer bestimmten Helligkeit in einen (grossen) weißen Punkt auf eine Textur mahlt, und die Textur wird dann mit einem Unschärfefilter versehen und über das Ganze bild gespannt, oder? Weil ich hatte mal einen Fehler, wo eine flasche Textur über das Bild gespannt wurde, der Bloom Effekt funktionierte logischerweise nicht mehr.

[deekey777]

Es gibt einige (für Normalsterbliche) neue Infos zu Lost Coast und dem HDR Update der HL2 Engine: E3 2005: HL2 Lost Coast Update (http://pc.ign.com/articles/616/616578p1.html?fromint=1)

Man spricht eindeutig vom HDR Update der HL2 Engine und nicht des Spiels selbst.
"We talked with one of the Valve reps giving the presentation, and he said that although Lost Coast would require a pretty high-end system (3.2GHz CPU, 1GB RAM, 6800GT or X800 Pro, et cetera), the Aftermath expansion pack would allow the player to disable HDR and tweak the visuals as usual. He also mentioned that HDR would be partially implemented in HL2 in a future patch, but that they probably wouldn't completely overhaul the lighting for two reasons: one, it would require a download on the order of five gigabytes; and two, they felt that there were certain sections of the game that were actually better, gameplay-wise, with the current lighting."

Na toll...

[deekey777]

Half Life 2: Lost Coast HDR overview (http://www.bit-tech.net/gaming/2005/06/14/hl2_hdr_overview/1.html)

Ist ziemlich interessant zu lesen, was VALVe unter HDR so versteht. :D

Warum sieht die "Überhellung" auf dem ersten (auch dem zweiten) Bild Blooming-Foto so fleckig aus?


15/06/2005 Update: as mentioned in the original story, the net is rife with speculation that ATI specifically asked Valve to hold back Lost Coast until the launch of their next-gen GPU, R520, reported to be on the 26th of July. We can now firmly dispell that theory, thanks to an email follow-up from Doug Lombardi:

On the release date, right now we're looking at some time in July. The only reason for the change in date was internal development - no external factors.

Meanwhile, this will run on the X800 as well as the 6800 line of cards, as well as the coming highest-end products from both ATI & NVIDIA - it was shown on dual 6800s at E3.


Ach Mist, meine Verschwörungstheorie hat sich in die Luft aufgelöst...


der level soll noch im mai kommen


;(

[Quasar]

:lol:
Ja. Wenn dem so gewesen wäre, hätte Doug Lombardi es bestimmt den Jungs von bit-tech.net direkt auf die Nase gebunden.
Vermutlich hat wieder ein böser Hacker Code gestohlen.

[r3ptil3]

Oder vielleicht soll Lost Coast zur Vorstellung des R520 dabei sein und dann erst released werden!

[mapel110]

Oder vielleicht soll Lost Coast zur Vorstellung des R520 dabei sein und dann erst released werden!
Jo, davon ist auszugehen. Eventuell sollte R520 doch schon im Mai vorstellt werden und ist doch verschoben worden.

[Quasar]

Und Juli deckt sich zufällig halbwegs mit dem 26. Juli, der ja momentan für die R520 gemunkelt wird.

[deekey777]

Doug Lombardi Interview (http://www.halflife2.net/articles.php?article=30)


Lost Coast is the HDR level. It will require at least a 2GHz processor, 1 to 2GB of RAM, and the very latest GPU from ATI or NVIDIA. Once Lost Coast has shipped, we will be updating the Source SDK to include support for HDR authoring, and future Valve game releases will feature HDR modes in the video settings for those with the horses to run it.
Hey cool, nur 2.0 GHz: Bestimmt ist ein AMD64 mit 2.0GHz gemeint.

[Winter[Raven]]

@ deekey

das ist noch besser:

and the very latest GPU from ATI or NVIDIA

[deekey777]

']@ deekey

das ist noch besser:

Daß die Anforderung an die Grafikkarte sehr hoch sind, war schon lange bekannt, da hieß es immer X800 oder 6800.
Bei den ersten Meldungen zu Lost Coast hieß es aber, daß man auch eine sehr schnelle CPU mit über 3.0 GHz (bzw. entsprechendes PR) brauchen werde.

[aths]

Ich möchte an dieser Stelle noch mal darauf hinweisen, dass "HDR-Rendering" nicht nur heißt, Überstrahl-Effekte oder so einzufügen. HDR-Rendering (mit FP16) erlaubt auch ganz normale Szenen ohne Überstrahl-Effekte zu rendern, aber in einer höheren Präzision, also frei von jeglichem Color-Banding. Das wird über kurz oder lang auch Standard, da Color Banding bei dem 32-Bit-Framebuffer (mit 24 Bit Farbe) ja heute schon ein Problem ist.

Nebenbei kann man recht effektiv dann noch Überstrahl-Effekte und ähnliches realisieren. Es gibt aber wie gesagt noch andere Gründe, weg vom FX8-Format für einen Farbkanal zu gelangen, hin zum FP16-Format. Das Auge ist übrigens noch dynamischer als FP16 (und zwar ungefähr um 2 dB.) Irgendwann wird HDR also heißen, FP32 pro Farbkanal zu verwenden. Mit FP16 als Framebuffer-Format hat man aber auf längere Sicht erst mal Ruhe.

[Gast]

auf golem steht dass das "hdr" in lost coast sm2.0 ist:
http://golem.de/0508/39788.html
was ist davon zu halten?

[mapel110]

auf golem steht dass das "hdr" in lost coast sm2.0 ist:
http://golem.de/0508/39788.html
was ist davon zu halten?
Echtes HDR wirds nur mit einer SM3-Karte geben. Aber dieses Zusatzlevel soll beides bieten. Also FakeHDR(wo auch noch AA funktioniert) mit SM2 und echtes mit SM3.

[r3ptil3]

Echtes HDR wirds nur mit einer SM3-Karte geben. Aber dieses Zusatzlevel soll beides bieten. Also FakeHDR(wo auch noch AA funktioniert) mit SM2 und echtes mit SM3.

Ja laut DirectX ab Shader Model3. Aber selber die NV40 - G70 Karten können eigentlich kein vollkommenes HDR, da sie nur 16bit pro kanal haben, für echtes HDR benötigt man 32bit pro Kanal.

[Coda]

Ja laut DirectX ab Shader Model3. Aber selber die NV40 - G70 Karten können eigentlich kein vollkommenes HDR, da sie nur 16bit pro kanal haben, für echtes HDR benötigt man 32bit pro Kanal.1. Hat HDR nix mit SM 3.0 zu tun. Es müssen "nur" FP-Blending fähige ROPs vorhanden sein, was z.B. die GeForce 6200 trotz SM 3.0 nicht hat.

2. Ich sehe FP16 sehr wohl als HDR an, wobei das Ansichtssache ist. 0-65000 statt 0-1 sollte auf jeden Fall ausreichend sein.

[mapel110]

1. Hat HDR nix mit SM 3.0 zu tun. Es mussen "nur" FP-Blending fähige ROPs vorhanden sein, was z.B. die GeForce 6200 trotz SM 3.0 nicht hat.

2. Ich sehe FP16 sehr wohl als HDR an, wobei das Ansichtssache ist. 0-65000 statt 0-1 sollte auf jeden Fall ausreichend sein.
Ja, aber man kanns sich einfach machen, weil es keine SM2-Hardware mit HDR-Support gibt bzw mit "FP-Blending fähigen ROPs" und wohl auch nie geben wird.

[r3ptil3]

1. Hat HDR nix mit SM 3.0 zu tun. Es mussen "nur" FP-Blending fähige ROPs vorhanden sein, was z.B. die GeForce 6200 trotz SM 3.0 nicht hat.

2. Ich sehe FP16 sehr wohl als HDR an, wobei das Ansichtssache ist. 0-65000 statt 0-1 sollte auf jeden Fall ausreichend sein.

Ja dann geht HDR bei R420-R480 auch nur mit verringerter Qualität.

[Coda]

Ja, aber man kanns sich einfach machen, weil es keine SM2-Hardware mit HDR-Support gibt bzw mit "FP-Blending fähigen ROPs" und wohl auch nie geben wird.Es gibt aber jede Menge SM 3.0 HW ohne FP-Blending.

Ja dann geht HDR bei R420-R480 auch nur mit verringerter Qualität.Ich würde einfach mal sagen: Gar nicht.
Was das visuelle Ergebnis natürlich nicht unbedingt schlecht machen muss.

[Winter[Raven]]

Mich würde jetzt aber wirklich mal interessieren wie es ATI schafft "HDR" in SC3 zu rendern...

Shader? Müsste aber nicht in dem Fall die Performance einbrechen? Softwareemulation vs Hardwarerendering.

[r3ptil3]

']Mich würde jetzt aber wirklich mal interessieren wie es ATI schafft "HDR" in SC3 zu rendern...

Shader? Müsste aber nicht in dem Fall die Performance einbrechen? Softwareemulation vs Hardwarerendering.

Vergleich mal NV40-G70 HDR mit R420-R480 HDR.
Da ist nur Fake, wahrscheinlich mit Bloom geregelt und so.

[Winter[Raven]]

Ich habe leider kein SC3, ist kein Spiel für das ich Geld ausgeben würde. Könnte vielleicht jemand Vergleichsbilder machen?

*Ich weiß nur, das die R4xx Bilder dunkler aussehn, von der Beleuchtung her.

[deekey777]

HDR comparison, I16 vs FP16 (http://www.beyond3d.com/forum/showthread.php?t=22828)
Interessant: So schlimm wird das "SM2.0-HDR" wohl nicht. :biggrin:

[Coda]

Das Problem an der Methode ist, dass es zu schlechteren Resultaten führt (hier nicht) die gleiche Bandbreite braucht und dazu noch die Pixelshader mehr Instructions brauchen. Außerdem ist die verfügbare dynamic range sehr viel kleiner als bei FP16.

Bei der 7800 GTX erwarte ich dass der FP16 Modus schneller sein sollte, bei NV40 bremst da ja was anderes als die Bandbreite.

Das damit MSAA geht ist natürlich auch ein nicht zu verachtender Vorteil.

[deekey777]

Hoffentlich kommt bei VALVe niemand auf die Idee, den nVidias nur den "SM3.0"-Modus aufzuzwingen, damit jede Möglichkeit der Vergleichbarkeit verschwindet.

[Gast]

Das Problem an der Methode ist, dass es zu schlechteren Resultaten führt (hier nicht) die gleiche Bandbreite braucht und dazu noch die Pixelshader mehr Instructions brauchen. Außerdem ist die verfügbare dynamic range sehr viel kleiner als bei FP16
Ja sicher. Auch wenn das den Namen HDR nichtmal verdient, es scheint gut machbar zu sein. Es ist nicht perfekt, es ist nunmal nicht HDR, es wird vielleicht von aths problemlos sogar ohne Standbilder erkannbar sein, aber der HDR-like Effekt ist für ATIs reine SM2 Hardware imho sehr gut umgesetzt. Und ATI ist mit SM2 sauschnell. Die Unterschiede zwischen dem I16-workaround und FP16 sind bis jetzt imho weniger auffällig als die HQ-Unterschiede zwischen dem NV40 und G70 ;)