HalfLife 2 mit HDR?

[betasilie]

Nutzt HalfLife HDR?

[R300]

Ich denke ja, da in den Vorschau Videos ein paar überbelichtete Fenster zu sehen waren. Oder war das nur ein Glow Effekt?

[Gast]

Glaube eher nicht. Sah mehr nach Overbright Lighting aus.

[Hatake]

ähm.......was ist HDR ??

[R300]

HDR= High Dynamic Range
Damit kann man Licht viel heller leuchten lassen. Es sieht so aus, als ob man geblendet wird.
http://img66.exs.cx/img66/214/AtiSushi02.jpg

[MechWOLLIer]

Soweit ich weiß benutzt HL2 kein HDR, allerdings sicher bin ich mir nicht.
Zumindest bei FC kann man ja nicht HDR und AA gleichzeitig benutzen. Da man bei HL2 bis jetzt noch nichts von AA Problemen gehöhrt habe, vermute ich, dass es kein HDR benutzt.

[san.salvador]

Soweit ich weiß benutzt HL2 kein HDR, allerdings sicher bin ich mir nicht.
Zumindest bei FC kann man ja nicht HDR und AA gleichzeitig benutzen. Da man bei HL2 bis jetzt noch nichts von AA Problemen gehöhrt habe, vermute ich, dass es kein HDR benutzt.
Es gibt aber auch kaum Spieler, die HL2 so ausgiebig gespielt haben, um von AA Problemen (klingt irgendwie nach Dünnpfiff :ueye: ) berichten zu könnnen.

[Quasar]

Zumindest bei FC kann man ja nicht HDR und AA gleichzeitig benutzen.
Das können nur die GeForces nicht - wie das bei der Radeon aussieht und ob dort überhaupt HDR angeboten wird in FC, ist AFAIK noch unklar.

Und wenn HL2 ebenfalls einen FP-Framebuffer nutzt, um HD-Renderingergebnisse zu speichern, dann wird auch in HL2 auf der GF kein HDR und AA zugleich möglich sein, da das eine HW-Limitierung ist.

[TheCounter]

Das können nur die GeForces nicht - wie das bei der Radeon aussieht und ob dort überhaupt HDR angeboten wird in FC, ist AFAIK noch unklar.

Also die HDR Demo von HL2 (Von November 2003) hat auf der Radeon 9800 Pro richtig gut ausgesehen, Qualitativ auch exzellent imho. Wär schade wenn die das wieder ausgebaut hätten.

[Coda]

Also in der Demo gab's zumindest HDR-Cubemaps. Aber einen Floating Point Framebuffer halte ich für sehr unwahrscheinlich.

[Quasar]

War das denn auch wirklich HDR oder nur Overbright Lighting?

[TheCounter]

War das denn auch wirklich HDR oder nur Overbright Lighting?

Laut Valve war es HDR. Eine entsprechende HDR Shader DLL war dabei auch vorhanden.

[deekey777]

Sagen wir so, die Source Engine kann HDR. ;)

[Quasar]

Ah, ok. :)

[DrumDub]

Das können nur die GeForces nicht - wie das bei der Radeon aussieht und ob dort überhaupt HDR angeboten wird in FC, ist AFAIK noch unklar.


aths meinte mal, dass es sich bei fc nicht um wirkliches hdr handelt, sondern nur um mdr. ich denke, bei hl2 ist es ähnlich. echtes hdr ist ja auch nur mit dem nv40 möglich.

[Quasar]

aths 'spinnerte' Umdefinitionen sorgen nur für Verwirrung. Das ist hier ziemlich ohne Belang, soweit mir bekannt.

aths sieht 'echtes' HDR erst ab durchgehend 32Bit pro Komponente und nicht FP16, wie es der nV40 zuwege bringt.

[betasilie]

echtes hdr ist ja auch nur mit dem nv40 möglich.
Quelle?

[TheCounter]

aths meinte mal, dass es sich bei fc nicht um wirkliches hdr handelt, sondern nur um mdr. ich denke, bei hl2 ist es ähnlich. echtes hdr ist ja auch nur mit dem nv40 möglich.

Wo liegt da der qualitative Unterschied? Ich kann nämlich nicht wirklich nen Unterschied zwischen dem HDR auf ner R9800 und einer GF6800 entdecken.

Wenns nur nen technischer Unterschied ist kanns einem ja eigentlich egal sein, funktionieren tut es jedenfalls auch auf ner Radeon ab 9500 und es sieht wirklich auch super aus, deshalb seh ich keinen Grund das nicht auch für Radeon karten zu implementieren.

[DrumDub]

aths 'spinnerte' Umdefinitionen sorgen nur für Verwirrung. Das ist hier ziemlich ohne Belang, soweit mir bekannt.

aths sieht 'echtes' HDR erst ab durchgehend 32Bit pro Komponente und nicht FP16, wie es der nV40 zuwege bringt.

ah so. dann hab aich das also falsch verstanden. sry. ;(

die frage ist dann nur, wie the counter auch nachfragt, worin unterscheidet sich das schon existiernde hdr auf dem r3x0 von dem, was der nv40 kann?

[Coda]

NV40 kann floating point texturen filtern, R300 nicht.

[Quasar]

Der nV40 kann bsw. FP-Texturfilterung in den TMUs machen - 'quasi' wie normale Texturfilterung. Bei der R300 (und aufwärts) müssen das die Pixelshader übernehmen, was natürlich ein 'bißchen' Leistung kostet.

Dazu gibt's FP16-Framebuffer (wobei ich nicht weiß, ob die Radeons das nicht auch können), Tone-Mapping via RAMDAC (muss sonst auch der Pixelshader machen).

Mehr fällt mir aus dem Kopf dazu nicht ein.

[aths]

aths 'spinnerte' Umdefinitionen sorgen nur für Verwirrung. Das ist hier ziemlich ohne Belang, soweit mir bekannt.

aths sieht 'echtes' HDR erst ab durchgehend 32Bit pro Komponente und nicht FP16, wie es der nV40 zuwege bringt.Das ist nicht spinnert. Nur weil man über den normalen 0..1-Bereich hinaus geht (LDR) gibt es noch lange keinen Grund, von HDR zu sprechen. (NV spricht von HPDR, halte ich aber auch für übertrieben.)

aths meinte mal, dass es sich bei fc nicht um wirkliches hdr handelt, sondern nur um mdr. ich denke, bei hl2 ist es ähnlich. echtes hdr ist ja auch nur mit dem nv40 möglich.Möglich ja, aber nur sehr, sehr langsam.

[Quasar]

Nun, dann sorg' auch für Aufklärung, was deine hausgemachten Begriffsverwirrungen angeht. :)

HDR kann auch für "Higher Definition R..." stehen, womit deinem Korrektheitsanspruch wieder genüge getan wäre. ;)

[betasilie]

Nun, dann sorg' auch für Aufklärung, was deine hausgemachten Begriffsverwirrungen angeht. :)

HDR kann auch für "Higher Definition R..." stehen, womit deinem Korrektheitsanspruch wieder genüge getan wäre. ;)
Ack

@aths
Das wär doch mal ein Artikel wert. =)

[TheCounter]

Der nV40 kann bsw. FP-Texturfilterung in den TMUs machen - 'quasi' wie normale Texturfilterung. Bei der R300 (und aufwärts) müssen das die Pixelshader übernehmen, was natürlich ein 'bißchen' Leistung kostet.

Dazu gibt's FP16-Framebuffer (wobei ich nicht weiß, ob die Radeons das nicht auch können), Tone-Mapping via RAMDAC (muss sonst auch der Pixelshader machen).

Also gibts so gut wie keinen Bildqualitätsunterschied zwischen R3x0 und NV4x HDR? Der NV40 kanns also nur schneller darstellen?

[Quasar]

Solange FP24-Genauigkeit ausreicht, sollte sich das alles auch mit einem R300 (und aufwärts) machen lassen, denke ich.

[aths]

Nun, dann sorg' auch für Aufklärung, was deine hausgemachten Begriffsverwirrungen angeht. :)

HDR kann auch für "Higher Definition R..." stehen, womit deinem Korrektheitsanspruch wieder genüge getan wäre. ;)IIRC kann auch für "Im innersten Rechen-Centrum" stehen. Für mich gibts "HDR" erst ab FP32, während FP16 und FP24 noch "MDR" sind.

Dynamikmäßig kommt FP24 an FP32 schon ganz gut ran, bietet aber deutlich weniger Auflösung als FP32. Doch schon FP16 ist im Vergleich mit FX8 sehr gut für Overbright Lighting geeignet. Man benötigt angesichts heute gebotener GPU-Rechenkraft noch kein HDR, um mit Overbright Lighting und gesteigerter Auflösung viel glaubwürdige Beleuchtungseffekte zu rendern als wir das bislang kennen.

[Quasar]

IIRC kann auch für "Im innersten Rechen-Centrum" stehen. Für mich gibts "HDR" erst ab FP32, während FP16 und FP24 noch "MDR" sind.

Du stellst, wie so oft, deine Sicht als Maß der Dinge hin.

[aths]

Du stellst, wie so oft, deine Sicht als Maß der Dinge hin.Meine Sicht basiert in diesem Fall auf Begriffen aus der digitalen Bildverarbeitung/Fotografie. Dort braucht es 32 Bit pro Kanal für HDR. (Allerdings sind in der Regel Fixpoint-Formate gemeint.)

[Xmas]

Ich will mal die Begriffsverwirrung etwas beseitigen.
HDR steht in der Regel für High Dynamic Range, was im Prinzip bedeutet dass man einen sehr großen Wertebereich für die Intensität von Licht bei der Berechnung hat, und dass dieser Bereich dynamisch an das Ausgabegerät angepasst wird.

In der Realität ist die Intensität von Licht ja nach oben nicht limitiert. Ab wann wir einen Grauton als "Weiß" empfinden, hängt immer von der relativen Helligkeit der Umgebung ab.

Wie man nun Wertebereiche wie [-8, +8] bezeichnet sei mal außen vor, aber ich denke, mehr als das 65000-Fache als bisher kann man durchaus als High Dynamic Range bezeichnen.

Dynamic wird das ganze erst durch Tone Mapping, also die Abbildung des genutzten Wertebereichs auf den darstellbaren. Ohne Tone Mapping kann man eigentlich nicht von HDR sprechen, wird aber trotzdem oft getan. Um die Limitierungen des Ausgabegeräts noch etwas Aufzuweichen, nutzt man Post-Processing-Effekte wie Bloom/Glow. Man nimmt hier optische Effekte im Auge voraus.

In dem von R300 geposteten Bild sieht man gleich zwei Unterschiede. Zum einen sieht man dass der Wertebereich beim Rechnen nicht mehr limitiert, wodurch das Licht in der mittleren Glaskugel nun richtig weiß, und nicht mehr grau erscheint. Zum anderen wird ein Glow-Effekt verwendet, so dass starkes Licht die Umgebung überstrahlt.

Es gibt nun aber nicht eine Art, HDR zu realisieren, sondern mehrere. Und es gibt natürlich auch Implementationen, die den Namen HDR nicht verdienen ;)
Nicht alles wird von jeder Hardware unterstützt. Für manche HW-Features gibt es Alternativen, die mehr oder weniger aufwändig sind.
(im Folgenden kann man statt FP auch überall breite Fixed-Point-Formate einsetzen)

FP-Shader (NV30, R300) sind für HDR notwendig.

FP-Rendertargets und FP-Texturen (R300, NV30 eingeschränkt, NV40) benötigt man, wenn man Image Based Lighting (IBL), Transparenz/Blending, Post-Processing oder Tone Mapping machen will.
AA auf FP-Rendertargets unterstützt AFAIK noch kein Chip (es besteht eine geringe Möglichkeit dass der 3DLabs P20 es kann, aber genaue Angaben gibt es dazu nicht)

FP-Texturfiltering (NV40) beschleunigt oder verschönert IBL und Post-Processing.

FP-Blending (NV40) beschleunigt Transparenz-Darstellung und spart Speicher, weil man sonst "Ping-Pong-Blending" machen muss.

Tone Mapping im RAMDAC spart Bandbreite und Füllrate. Allerdings habe ich davon beim NV40 bis auf Ankündigungen noch nichts gesehen. P20 sollte es können. Nur fehlt die API dazu noch.

[Benedikt]

FP-Rendertargets und FP-Texturen (R300, NV30 eingeschränkt, NV40) benötigt man, wenn man Image Based Lighting (IBL), Transparenz/Blending, Post-Processing oder Tone Mapping machen will.
AA auf FP-Rendertargets unterstützt AFAIK noch kein Chip (es besteht eine geringe Möglichkeit dass der 3DLabs P20 es kann, aber genaue Angaben gibt es dazu nicht)


Zwei Fragen:
1.) Warum funktioniert bei rthdribl dann trotzdem AA?


FP-Texturfiltering (NV40) beschleunigt oder verschönert IBL und Post-Processing.

FP-Blending (NV40) beschleunigt Transparenz-Darstellung und spart Speicher, weil man sonst "Ping-Pong-Blending" machen muss.

Tone Mapping im RAMDAC spart Bandbreite und Füllrate. Allerdings habe ich davon beim NV40 bis auf Ankündigungen noch nichts gesehen. P20 sollte es können. Nur fehlt die API dazu noch.

2.) Was ist Tone Mapping, wozu braucht man es und gibt es davon Screenshots?

MFG,
B. W.

[Quasar]

AFAIK nutzt RTHDRIBL keine FP-Rendertargets, nur "normale" MRT.

[aths]

2.) Was ist Tone Mapping, wozu braucht man es und gibt es davon Screenshots?Tonemapping überträgt den Inhalt auf eine vom Auge wahrnehmbare (bzw. vom Monitor darstellbare) Intensität zwischen 0 und 100%. (Ich weiß nicht ob das im Begriff schon mit drin ist, aber vernünftiges Tone Mapping sollte neben Min und Max auch eine Gamma-Korrektur für den Bereich zwischen Min und Max mit einschließen.)

[Xmas]

Zwei Fragen:
1.) Warum funktioniert bei rthdribl dann trotzdem AA?
Meine Formulierung war nicht ganz richtig, für IBL braucht man nur FP-Texturen (bzw. breite Fixed-Point-Formate, RGBE oder ähnlich "komprimiertes"), keine FP-Rendertargets.

MRT kann man anstelle von FP-Rendertargets verwenden.

[aths]

Meine Formulierung war nicht ganz richtig, für IBL braucht man nur FP-Texturen (bzw. breite Fixed-Point-Formate, RGBE oder ähnlich "komprimiertes"), keine FP-Rendertargets.Wozu braucht es FP-Texturen für IBL? Imo sind FP-Texturen für viele IBL-Zwecke nützlich, aber nicht unbedingt erforderlich. Selbst wenn man einen größeren Bereich hat, kann man das u. U. mit einer FX8-Textur lösen (die z. B. in sRGB-Abständen speichert, was im Pixelshader dann noch auf einen größeren Bereich skaliert werden kann.)

[Xmas]

Wozu braucht es FP-Texturen für IBL? Imo sind FP-Texturen für viele IBL-Zwecke nützlich, aber nicht unbedingt erforderlich. Selbst wenn man einen größeren Bereich hat, kann man das u. U. mit einer FX8-Textur lösen (die z. B. in sRGB-Abständen speichert, was im Pixelshader dann noch auf einen größeren Bereich skaliert werden kann.)
Deswegen erwähnte ich ja auch RGBE. Mit reinen 256 Zwischenstufen pro Kanal kommt man nur selten hin.

[aths]

Deswegen erwähnte ich ja auch RGBE. Srykthx.

Das wär doch mal ein Artikel wert. =)Ich hätte viele Ideen für Artikel, z. B. um mal sRGB zu erklären. Leider ist die Leserschaft zu dünn, um den Aufwand angesichts meiner jetzt im Studium recht knappen freien geistigen Ressourcen zu rechtfertigen.

[betasilie]

Ich hätte viele Ideen für Artikel, z. B. um mal sRGB zu erklären. Leider ist die Leserschaft zu dünn, um den Aufwand angesichts meiner jetzt im Studium recht knappen freien geistigen Ressourcen zu rechtfertigen.
Schade. ;(

[Gast]

Srykthx.

Ich hätte viele Ideen für Artikel, z. B. um mal sRGB zu erklären. Leider ist die Leserschaft zu dünn, um den Aufwand angesichts meiner jetzt im Studium recht knappen freien geistigen Ressourcen zu rechtfertigen.

Au mann aths, bitte nicht abheben. Hab deine Beiträge bisher eigentlich ganz gern gelesen.

[aths]

Au mann aths, bitte nicht abheben. Hab deine Beiträge bisher eigentlich ganz gern gelesen.Ist unabgehoben gemeint. Zeitlich wäre das möglich, aber etliche Wachstunden am Tag bin ich zu keiner geistigen Leistung mehr fähig – die Konzentration ist einfach nicht mehr da. Die aktiven Phasen benötige ich aktuell vor allem fürs Studium, um da hinterher zu kommen.