[SAMMELTHREAD] Sehenswerte Videos

[CodingCat]

Ich habe eben diesem Interview auf Channel 9 mit den C++-Sprachhütern Alexandrescu, Meyers, Sutter gelauscht.

Ich bin mir mit static if noch nicht wirklich sicher. static if ist halt die deklarative Version von if, so wie das normale if in einer constexpr die definitorische Version von if ist.

Was constexpr angeht, habe ich noch überhaupt keinen Überblick, was darin eigentlich erlaubt ist. Über static if wäre ich deshalb froh, weil damit endlich eine saubere Alternative zu SFINAE (enable_if) und impliziter partieller Template-Instantiierung bestünde. In ersterem Fall wäre es zwar allenfalls eine Übergangslösung, in letzterem Fall würde es seinen Nutzen aber wohl auch nach der Einführung von Concepts beibehalten, weshalb mir die Einführung von static if grundsätzlich sinnvoll erscheint.

[dot]

if geht iirc nicht, aber conditionals. Wobei ich gefühlsmäßig von static if nicht gerade so viel halte, ka wieso genau...

[Chromanoid]

[youtube]YDXOioU_OKM[/youtube]
[vimeo]46627975[/vimeo]
[via Short of the Week]

[eXile]

Na endlich macht mal jemand etwas halbwegs neues im Shooter-Genre:
[youtube]GCThInmzjXw[/youtube]
[youtube]M-XyvgqXwZs[/youtube]
(Bevor sich jemand fragt, wie man in sieben Tagen eine solche Engine schreiben soll: Die benutzen Unity.)

[CodingCat]

Neues von Bikker und Co. Laut Kommentaren nicht ganz der neuste Stand des Ray Tracers.

[youtube]FJLy-ci-RyY[/youtube]

In den Kommentaren wird auch über das angestrebte Einbauen von temporaler Reprojektion gesprochen. Das wird interessant, wir hatten ja schon diskutiert, dass die solide Implementierung einer solchen Reprojektion wohl eine beträchtliche Herausforderung ist, wenn man nicht überall Ghosting haben will.

[Krishty]

Ich <3 die Beleuchtung und die Qualität des Umgebungs-Meshs. Hat es was zu bedeuten, dass sich die Räder nicht drehen? :P

[CodingCat]

It's running on a couple of Geforce cards.
- http://raytracey.blogspot.co.nz/2012/09 ... -game.html

Was der andere Typ mit AO + Skydome in den Kommentaren will, ist mir schleierhaft.

[Krishty]

Mir fällt auch gerade auf, dass das AA ohne Gammakorrektur ist. Wie man bei sowas Professionellem sowas Banales verkacken kann, erschließt sich mir auch nicht.

[Artificial Mind]

Wieso muss man bei Anti-Aliasing Gammakorrektur machen? (Auf die Gefahr hin, mich zum Deppen zu machen)

[Krishty]

Weil das AA einen höher aufgelösten Bildschirm simulieren soll als da ist. Auf deinem normalen Bildschirm wird vor der Anzeige alles getonemappt – wenn du also ein paar Schritt zurückgehst, siehst du das Mittel von getonemappten Pixeln. Genauso sollst du auch beim AA das Mittel von getonemappten Subsamples sehen.

Was passiert, wenn man das missachtet, siehst du hier:

In den dunklen Bereichen ist das AA perfekt weich (z.B. an den Laternen vor dem Bürgersteig). Dort, wo dunkle Bereiche ins Helle übergehen (an den Kanten der Hochhäuser vor dem Himmel) ist das AA aber quasi nicht existent, weil ein einziges lineares Subsample ausreicht, um den ganzen Pixel mit Helligkeit zu fluten. Dummerweise sind das auch gleichzeitig die Bereiche, an denen AA am stärksten auffällt, also am Wichtigsten ist.

[Artificial Mind]

Ah, vielen Dank. Was würde man für die Korrektur tun?

[Krishty]

Erst Tonemapping und Gammakorrektur, dann Multisampling auflösen.

(Den Zeitpunkt, zu dem die GPU das Multisampling auflöst, kann man seit D3D 10 ja mehr oder weniger frei bestimmen.)

[CodingCat]

Ich stehe gerade auf dem Schlauch. Sollte nicht erst aufgelöst und dann gammakorrigiert, also im linearen Farbraum (nach Tonemapping) aufgelöst werden? Verschwimmen die Pixel eines Bildschirms, von dem wir uns entfernen, nicht linear?

[eXile]

Was ist Multisampling? Angenommen, wir haben plötzlich keine Speicherprobleme mehr, und können einfach unsere Szene auf einen viermal so großen Back-Buffer rendern (also 3840 × 2160 statt 1920 × 1080). Man nimmt jetzt „einfach“ (wie wir gleich sehen, doch nicht so einfach) vier Farbwerte, und rechnet die irgendwie zu einem Farbwert runter. Und zwar eigentlich so, dass wenn uns aus einem Pixel \($2 \frac{W}{\mathrm m^2}$\), aus den anderen Pixeln \($4 \frac{W}{\mathrm m^2}$\), \($6 \frac{W}{\mathrm m^2}$\) und \($8 \frac{W}{\mathrm m^2}$\) entgegenstrahlen, wir einen Pixel mit \($5 \frac{W}{\mathrm m^2}$\) herauskriegen. Klingelt etwas? Richtig, es ist physikalisch linear.

Machen wir uns doch mal klar, was wir haben:

1. Wir haben Texturen und Farben von unseren Artists (als ob). Wir nehmen einfach mal an, sie haben kein Farbprofil dabei, sondern es sind einfach nur Zahlentripel \($(x_1, x_2, x_3)^{\mathrm T}$\). Wie nehmen by default an, dass die Zahlentripel aus dem sRGB-Farbraum stammen.
2. Der tolle Master-Farbraum CIEXYZ ist physikalisch linear. In ihm kann man mit handelsüblicher Arithmetik rechnen und damit auch lineare Interpolationen durchführen.
3. Wir wollen also unsere sRGB-Zahlentripel der sRGB→CIEXYZ-Transformation unterziehen,
4. dann mit den CIEXYZ-Zahlentripel lustig rumrechnen,
5. dann sie wieder der CIEXYZ→sRGB-Transformation unterziehen.

Wie macht man die sRGB→CIEXYZ-Transformation? Wikipedia liefert:\($$\operatorname{t}_{\mathrm{sRGB}\rightarrow\mathrm{CIEXYZ}}\begin{pmatrix}x_1 \\ x_2 \\ x_3\end{pmatrix} = \begin{pmatrix}0.4124&0.3576&0.1805\\0.2126&0.7152&0.0722\\0.0193&0.1192&0.9505\end{pmatrix}\begin{pmatrix}\operatorname{h}(x_1)\\ \operatorname{h}(x_2)\\ \operatorname{h}(x_3)\end{pmatrix}$$\)mit irgendeiner Hilfsfunktion\($$\operatorname{h}(x)=\begin{cases}\frac{x}{12.92}, & x\le0.04045\\\left(\frac{x+0.055}{1.055}\right)^{2.4}, & x>0.04045\end{cases}$$\)Der letzte Teil mit der Potenz kommt doch einem irgendwie bekannt vor: Sieht irgendwie wie eine Gamma-Korrektur aus. Richtig, man kann obige Hilfsfunktion mit\($$\operatorname{h}(x) \approx x^{2.2}$$\)approximieren, aber es ist nur eine sehr, sehr krude Approximation (gerade bei \($x\approx0$\) geht's in die Hose). Die inverse Funktion \($\operatorname{t}_{\mathrm{CIEXYZ}\rightarrow\mathrm{sRGB}}$\) sei dem geneigten Leser als Übungsaufgabe nicht empfohlen.

Aber zu diesen Zeitpunkt höre ich schon das Fluchen: Was soll der Mist, eine Matrixtransformation nur für so einen einzelnen popeligen Farbwert, nö keine Lust dadrauf, zu ineffizient, hau doch ab, etc. pp. Ja richtig, wir überlegen mal gerade: Wir brauchen nur eine Transformation in irgendeinen linearen Farbraum; warum gerade in den CIEXYZ ist vollkommen unklar. Und das stimmt auch: Wir können einfach die Matrix oben weglassen. Warum? Weil die Matrixmultiplikation einfach nur eine lineare Transformation ist; d.h. wenn wir mit \($\operatorname{h}$\) transformiert haben, sind wir bereits in irgendeinem linearen Farbraum (aber noch nicht in dem CIEXYZ-Farbraum).

Also sagen wir einfach: \($$\operatorname{t}_{\mathrm{sRGB}\rightarrow\mathrm{Linear}}\begin{pmatrix}x_1 \\ x_2 \\ x_3\end{pmatrix} = \begin{pmatrix}\operatorname{h}(x_1)\\ \operatorname{h}(x_2)\\ \operatorname{h}(x_3)\end{pmatrix}$$\) und fertig ist die Laube.

Ich kann das auch noch einmal praktischer erklären. Nehmen wir einfach das Beispiel vom Anfang. Sei \($A$\) der fette Buffer mit 3840 × 2160 Auflösung, und \($B$\) der normale Buffer in 1920 × 1080 Auflösung. Wir können die Buffer einfach via \($B(x, y)$\) adressieren; wir sagen einfach, \($A(x, y)_1, ..., A(x, y)_4$\) seien die vier Pixel vom feinen Buffer, die unter der Grundfläche des Pixels \($(x, y)$\) vom groben Buffer liegen.

Nach obiger Betrachtung kriegen wir also die Pixel korrekt in den Buffer \($B$\), wenn wir folgendes machen:\($$B(x, y) = \operatorname{t}_{\mathrm{Linear}\rightarrow\mathrm{sRGB}}\Big(\frac{1}{4}\sum_{i = 1}^4 \operatorname{t}_{\mathrm{sRGB}\rightarrow\mathrm{Linear}}\big(A(x, y)_i\big)\Big)$$\)Die Summenbildung und die Division durch 4 nennt man übrigens einen Downsample-Filter. Der sagt einem, was man mit den vier Pixeln aus dem feinen Buffer machen soll, um einen einzigen Pixel zu erhalten. Es sind andere Downsample-Filter denkbar. Benutzt aber niemand.

Wenn jemand das implementieren will: Exakte Werte gibt es hier. Eine falsche Implementierung in HLSL findet man hier; bitte lest zuerst den ersten Link, um zu sehen, warum der zweite falsch ist. Schrott überall wo man hinschaut, aber das ist man ja gewohnt. :evil:

Korrekt wäre:

Code: Alles auswählen

float3 color; 
color = (color <= 0.0404482362771082) ? color / 12.92
                                      : pow((color + 0.055) / 1.055, 2.4)

Und schließlich: Wenn man sRGB-Texturen aus den neueren Direct3D-Versionen benutzt, macht man einfach nur:\($$B(x, y) = \frac{1}{4}\sum_{i = 1}^4 A(x, y)_i$$\)Das sollte im großen und ganzen alles gewesen sein. Noch die schnelle Antwort:

Verschwimmen die Pixel eines Bildschirms, von dem wir uns entfernen, nicht linear?

Genau das tun sie: Sie verschimmen linear. Damit muss man im linearen Farbraum (korrekter: in einem linearen Farbraum) seine Berechnungen anstellen. Aber Multisampling auflösen kommt immer zum Schluss. Immer dran denken: Mal rendert einfach nur ein übergroßes Bild (3840 × 2160) das man dann am Ende herunterrechnen will (1920 × 1080). ;)

Random Katzen-Bild damit dieser Beitrag überhaupt gelesen wird:

[CodingCat]

Verschwimmen die Pixel eines Bildschirms, von dem wir uns entfernen, nicht linear?

Genau das tun sie: Sie verschimmen linear. Damit muss man im linearen Farbraum (korrekter: in einem linearen Farbraum) seine Berechnungen anstellen. Aber Multisampling auflösen kommt immer zum Schluss. Immer dran denken: Mal rendert einfach nur ein übergroßes Bild (3840 × 2160) das man dann am Ende herunterrechnen will (1920 × 1080). ;)

Wie jetzt, widerspricht sich das nicht, zum Schluss und linear? Zum Schluss sind wir doch in der Regel wieder in SRGB, nur vor der Gammakorrektur sind wir noch linear?! Klar kannst du auch das SRGB-Endresultat nochmal in den linearen Farbraum zurückrechnen, runterrechnen und dann nochmal Gammakorrektur durchführen, aber wozu? ;)

[eXile]

Wie jetzt, widerspricht sich das nicht, zum Schluss und linear? Zum Schluss sind wir doch in der Regel wieder in SRGB, nur vor der Gammakorrektur sind wir noch linear?! Klar kannst du auch das SRGB-Endresultat nochmal in den linearen Farbraum zurückrechnen, runterrechnen und dann nochmal Gammakorrektur durchführen, aber wozu? ;)

Bei der Beantwortung deiner Frage war ich bereits im Direct3D-10-Modus und war davon ausgegangen, dass Direct3D 10 benutzt wird. Wenn nicht, dann ist dein letzter Schritt das oben angegebene:\($$B(x, y) = \operatorname{t}_{\mathrm{Linear}\rightarrow\mathrm{sRGB}}\Big(\frac{1}{4}\sum_{i = 1}^4 \operatorname{t}_{\mathrm{sRGB}\rightarrow\mathrm{Linear}}\big(A(x, y)_i\big)\Big)$$\)Dies fasse ich als einen Schritt auf, deswegen bezeichne ich das als den letzten Schritt. Oder kurz:

1. Render deine tolle Szene auf \($A$\).
2. Benutze obige Formel um auf \($B$\) zu kommen und zeige \($B$\) auf dem Bildschirm an.

[CodingCat]

Okay, ich habe gerade weder im Kopf wie das in D3D9 noch wie das in D3D11 genau aussieht, aber auf jeden Fall lag ich nicht völlig daneben. Und Danke für deine ausführliche Erklärung.

[Krishty]

Danke für die Erklärung – meine Persönliche wäre auf „wenn von vier Pixeln einer grell ist und die anderen dunkel sind, willst du, dass der Pixel auf dem Bildschirm nur zu einem Viertel hell ist“ beschränkt :(

[Zudomon]

Ich bin mir nicht sicher, aber hat Krishty nicht recht?
Man will ein smoothes Bild... im linear Space sind doch Lichtwerte von z.B. 0.001 bis 100k... da reicht ein Sample um alles zu versauen.
Meiner Meinung nach hat das auch nicht mit Gamma sondern mit Tonemapping zu tun... mittelt man die Samples nach dem Tonemapping sollte alles passen.

[CodingCat]

Ja, genau das meinte ich ja. Nach Tonemapping vor Gamma. eXile und Krishty haben aber auch Recht, wenn man die Konvertierung zurück in den linearen Bildschirmraum vor dem Herunterrechnen und das Konvertieren zurück in den SRGB-Raum danach mit zum Auflösen dazurechnet. ;)

[Artificial Mind]

[youtube]_1mB5rM8WHU[/youtube]
Endlich mal eine gute Vorlage, um realistisches Lightning-Rendering anzufangen :)

EDIT: Dazu ein "Artikel" wie Lightning funktionier: http://what-if.xkcd.com/16/

[Krishty]

Ich sehe dieses Spiel zum ersten Mal. Gemessen an dem Freiheitsgrad, den ich dort sehe, finde ich aber beachtlich, dass es überhaupt so funktioniert, wie es funktioniert. Vor allem aber macht es scheinbar Mordsspaß.

[Schrompf]

Ich hab so gewiehert bei diesem Film... Danke dafür! Speziell die völlig trockene Präsentation ohne Musik finde ich genial.

[Chromanoid]

hehe
allerdings sollte man den Freiheitsgrad nicht überschätzen. animation und phyikengine gehen da einfach sehr geschickt in einander über.

[Krishty]

Bei den meisten Situationen muss ich sagen, dass ich ziemlich zu kauen hätte um es besser hinzukriegen als das Gezeigte. Vor allem würde ich mir wahrscheinlich hundert Jahre Zeit nehmen um die Physik durch neuronale Netze gesteuert mit durchverifizierter Festkommaarithmetik zu implementieren statt es einfach so auf den Markt zu schmeißen :P

[Chromanoid]

Ganz interessant dazu :) http://www.gamasutra.com/view/feature/1 ... hp?print=1

What physics solution did you use for the game?

SB: It's actually a RenderWare-based physics solution. We did look at a lot of different physics packages... and now I'm going back over two years. Actually, at that time, RenderWare had a really cool physics package that one guy developed, and they were called Drives. Essentially what Drives were, was a hinge. It's a neat way to make an intensive thing like a saloon door.

Our guys took these Drives and turned them into all the joints in your body. So now with Drives, we can create a full, physically accurate replica of the human body and all the joints, and you can even... say, take your right knee, and we can weaken it by 50 percent, and your guy would walk differently, based on that. So we use Drives as the foundation for everything that we do in physics, even your skateboard. Your trucks are Drives, and your wheels and hinges. Everything's Drives.

In fact, the way you're popping your board off the ground, it's not animation-driven. It's actually real forces on that board popping off the ground. We'd never have been able to get the same feel without our team [taking the] foundation of Drives and [building] a lot on top of it. We did mocap, and we have all that animation in the game, but animation is a target.

With Drives, I can say that I want to be 100 percent of that target, with every joint and limb, or I can be zero, which would be ragdoll -- I would be limp. But you have everything in between. I could even take my right arm and say, "Well, that's going to be 10 percent, so it's super-limp, but my other one's 100." It's amazing the amount of flexibility it gave us, and it is the foundation of the whole game and what gives it that great feel.

Doch mehr Physik als ich dachte :)

PS: Dieser Artikel inkl. verlinkter Papers ist auch ganz lesenswert http://aigamedev.com/insider/review/hol ... ocomotion/

[Krishty]

RenderWare? War das nicht gta III? Das erklärt dann auch die frappierende Ähnlichkeit …

[Alexander Kornrumpf]

Ich will mal wieder ein Salonfähiges Tony Hawk's Pro Skate.

[CodingCat]

Sofern kein Fake, absolut unglaublich (aber durchaus möglich und höchst beeindruckend):

[youtube]PvZchE30StQ[/youtube]

[Schrompf]

Was ist daran so enorm? Ich finde es spektakulär, was dieser Mensch bzw. die Leute alleine geschafft haben. Das ist eine beachtenswerte Leistung. Abgesehen davon sehe ich da aber nur eine solide Engine und ein beachtenswertes, aber nicht einzigartiges Physik-System für menschliche Bewegungen. Und gute Texturarbeit :)