ZFX + Developia

[youtube]Z8yW5cyXXRc[/youtube]

[youtube]w9SH8xlgzoI[/youtube]

Hat es irgendwo eine Beschreibung, was die da treiben? So spektakulär ist normales Ray Tracing ja nicht?

CodingCat hat geschrieben:Hat es irgendwo eine Beschreibung, was die da treiben?

Nope, kam gerade über den Twitter-Äther rein. Manchmal habe ich das Gefühl, andere Leute würden schneller über solche Dinge erfahren als der Normalbürger. Ich gehe der Sache auf den Grund.

CodingCat hat geschrieben:So spektakulär ist normales Ray Tracing ja nicht?

Normales Whitted-Ray-Tracing ist ziemlich unspektakulär; erst mit MC-Integration wird die Sache interessant.

Jep, es sieht aber ziemlich whitted aus, oder kannst du was Besonderes entdecken?

eXile hat geschrieben:Normales Whitted-Ray-Tracing ist ziemlich unspektakulär; erst mit MC-Integration wird die Sache interessant.

Ich höre ja gerade die Global Illumination Vorlesung und deswegen würde ich gerne mal kurz die Zusammenhänge hinterfragen: Whitted-Ray-Tracing ist dieses normale rekursive Ray-Tracing, mit den \($LS^*(D|G)E$\)-Pfaden, richtig? Und die "MC-Integration" wird vernünftige Monte-Carle-Integration mit Importance Sampling sein, sodass man mit Wahrscheinlichkeikten proportional zu \($BRDF \cdot cos(\theta)$\) neue Strahlen von den Oberflächen emittiert (also das Emittieren mit Wahrscheinlichkeit der Reflektivität und die Richtung ist \($BRDF \cdot cos(\theta)$\) verteilt), um damit Oberflächen, die nicht komplett Specular und dann einmal Glossy/Diffus sind, zu rendern. Sehe ich das richtig? Ist das das sogenannte Path-Tracing?

Artificial Mind hat geschrieben:Ich höre ja gerade die Global Illumination Vorlesung und deswegen würde ich gerne mal kurz die Zusammenhänge hinterfragen: Whitted-Ray-Tracing ist dieses normale rekursive Ray-Tracing, mit den \($LS^*(D|G)E$\)-Pfaden, richtig?

Whitted-Ray-Tracing ist das „normale“, rekursive Ray-Tracing, aber ich denke eher, das betrachtet nur Pfade der Art \($LD?S^*E$\). Man kann mit Glossy-Reflexionen nichts anfangen, weil eine glossy BRDF weder gleichverteilt ist (wie die diffuse BDRF für \($D$\)) noch eine Dirac-Verteilung hat (wie die spekulare Reflexion/Transmission für \($S$\)). Da hier kein solcher Spezialfall vorliegt, muss man tatsächlich die BRDF sampeln, und das wird beim Whitted-Ray-Tracing nicht gemacht. Von daher sind glossy-Interaktionen \($G$\) schon einmal raus. Quark mit Soße, siehe zwei Posts weiter unten.

Terminiert wird ein Pfad immer dann, wenn entweder man auf eine diffuse Oberfläche trifft (dann werden Pfade zu allen sichtbaren Lichtquellen gezogen, und die Farbe berechnet), oder wenn man direkt in eine Lichtquelle trifft (was nur möglich ist, wenn man zuvor eine spekulare Relexion hatte).

Artificial Mind hat geschrieben:Und die "MC-Integration" wird vernünftige Monte-Carle-Integration mit Importance Sampling sein, sodass man mit Wahrscheinlichkeikten proportional zu \($BRDF \cdot cos(\theta)$\) neue Strahlen von den Oberflächen emittiert (also das Emittieren mit Wahrscheinlichkeit der Reflektivität und die Richtung ist \($BRDF \cdot cos(\theta)$\) verteilt), um damit Oberflächen, die nicht komplett Specular und dann einmal Glossy/Diffus sind, zu rendern. Sehe ich das richtig? Ist das das sogenannte Path-Tracing?

Prinzipiell hat Monte-Carlo-Integration nichts mit Importance-Sampling zu tun. Monte-Carlo-Integration ist einfach ein stochastischer Schätzer der Form:
\($$\int_X f(\mathbf x) \, \mathrm d \mathbf x = \mu(X) \cdot \frac{1}{N} \sum_{i=1}^N f(\mathbf x_i) \quad \text{ für } n \to \infty$$\)wobei \($\mu(X)$\) das Maß des Integrationsgebiets ist (siehe Nachtrag unten), und die \($\mathbf x_1, ..., \mathbf x_n$\) die Monte-Carlo-Samples sind. Aber wie die Monte-Carlo-Samples dabei gezogen werden, ist vollkommen unklar: Man kann Importance-Sampling, Multiple-Importance-Sampling, Wavelet-Importance-Sampling usw. nehmen, oder einfach die Samples aus dem Integrationsgebiet raten, oder sich von einem Boten im versiegelten Umschlag aus Timbuktu liefern lassen. ;)

Importance-Sampling ist eine Methode, um Samples zu ziehen; Monte-Carlo-Integration eine Methode, um ein Integral im stochastischen Sinne zu schätzen.

Ob bei euch Path-Tracing an irgendwelche Methoden, um Samples zu ziehen, oder um das Integral zu schätzen, gebunden ist, weiß ich nicht; denn das hängt von eurem Herrn Kobbelt ab.

Bei mir ist es das nicht, sondern entscheidend ist, dass tatsächlich das Integral der Rendering-Gleichung gelöst wird, egal ob mit Monte-Carlo-Integration, oder einem uber-1337-Integrator, der ganz ohne Samples auskommt, oder ob jemand die Funktion auf ein Blatt kariertes Papier malt, und dann die Kästchen zählt.

Nachtrag:
Das Maß für die Halbkugeloberfläche ist das berühmte \($2 \pi$\), denn:
\($$\int_\Omega \mathrm d \omega = \int_0^{2 \pi} \int_0^{\frac{\pi}{2}} \mathrm d \omega = \int_0^{2 \pi} \int_0^{\frac{\pi}{2}} \sin(\vartheta) \cdot \mathrm d \vartheta \mathrm d \varphi = 2 \pi$$\)

Ja, ich meinte natürlich \($L(D|G)S^*E$\), hatte das beim Schreiben umgedreht und dann wahrschleinlich einmal zu viel invertiert ;) und mit dem \($(D|G)$\) zur Lichtquelle meinte ich, dass man doch häufig ein lokales Beleuchtungsmodell am Ende des Pfades auswertet, oder? Das kann dann ja prinzipiell alles sein.

Und ja, ich habe da wohl bei "MC-Integration" zu viel zusammengeworfen. So wie du das beschreibst macht das Sinn, danke ;)

Artificial Mind hat geschrieben:Ja, ich meinte natürlich \($L(D|G)S^*E$\), hatte das beim Schreiben umgedreht und dann wahrschleinlich einmal zu viel invertiert ;) und mit dem \($(D|G)$\) zur Lichtquelle meinte ich, dass man doch häufig ein lokales Beleuchtungsmodell am Ende des Pfades auswertet, oder?

Mmh, ja stimmt, da hast du recht. Da hat man schon eigene (MC-)Raytracer geschrieben, und macht's trotzdem falsch. Danke! :)

Allerdings musst du noch immer die Möglichkeit eines direkten Treffers in eine Lichtquelle in Betracht ziehen, daher: \($L(D|G)?S^*E$\) ;)

Direkter Treffer in Punktlichtquellen ;) Und alle anderen Lichtquellen sind ja eher selbstleuchtende Dreiecke.

Artificial Mind hat geschrieben:Direkter Treffer in Punktlichtquellen ;)

Mmh, ja, ich bin irgendwie nicht ausgeschlafen. Hast schon recht. Einigen wir uns auf \($L(D|G)S^*E$\). :)

Selbstleuchtende Dreiecke gibt's meiner Meinung nach beim Whitted-Ray-Tracing nicht, da man eine Lichtrichtung braucht, und um die zu bekommen, muss du wieder die Lichtquelle sampeln, was hier nicht gemacht wird. Direktionale Lichtquellen sind aber sehr wohl erlaubt. ;)

[youtube]apnU2PqZ6s4[/youtube]

Hier geht's zur Demo. ;)

[youtube]UVX0OUO9ptU[/youtube]

Unreal Engine 4 Developer Walkthrough
[youtube]MOvfn1p92_8[/youtube]

Unreal Engine 4 Tech Demo
[youtube]OZmRt8gCsC0[/youtube]

Das schönste ist für mich immer noch, dass sie unrealscript mit C++ ablösen. Da das ganze eine gezielte Ablösung ist, gehe ich außerdem davon aus, dass die API durchdacht und elegant daherkommt.

Die Editor-Präsentation ist sehr beeindruckend. Eigentlich alles keine Magie, aber konsequent durchgezogen und mit angemessenem Eigenhirn-Einsatz. Wenn ich mal groß bin, bau ich mir auch sowas.

[Edit] Ich fand aber die ganzen indirekten Lichtreflektionen und allgemein das indirekte Licht ziemlich wabbelig, wenn sich Dinge in der Szene bewegt haben... es sieht wirklich ein wenig nach Crytek Light Propagation Volumes aus, mit einer räumlichen Auflösung von vielleicht einem halben oder viertel Meter.

Ich seh nur Plastik. Das "Unreal" bekommt immer mehr Bedeutung...

j.klugmann hat geschrieben:Ich seh nur Plastik. Das "Unreal" bekommt immer mehr Bedeutung...

Ja das kenne ich, ich guck mir in der Uni Stahlträger, Alu-Gehäuse oder metallische Stuhlrahmen an und sehe nur noch Plastik. Ist wahrscheinlich so ein Fluch für Computergrafiker ;)

Das Hot-Swapping von C++-Code hat mich zugleich überrascht wie auch inspiriert. Code ist auch nur ein Asset der Engine; warum also auch nicht hier Hot-Swapping einbauen? Natürlich ist das nicht schwer (GetProcAddress for the win), aber es umgeht das Nichtvorhandensein von Edit&Continue in Visual C++ unter x64-Code.

Allerdings bedeutet das wohl auch, dass jeder, der anständig mit dem Unreal-Framework arbeiten will, zwingen Visual Studio braucht; und wie wir wissen, ist für Visual Studio 2012 nicht mehr die Express-Version ausreichend. Aber ich denke mal, die bleiben erst einmal auf dem Visual-C++-2010-ABI.

Meinst du nicht die haben ihren "eigenen" C++ Compiler beigelegt? Ich könnte mir sowieso vorstellen, dass der C++ Code vielleicht sogar in einer VM läuft (eine VM, die das vielleicht wie Flash mit C++ und Alchemy macht). Ich weiß nicht, ob sie den iOS und Flash Support in der UE4 aufgeben wollen. Ich glaube nicht, dass man da auf den Compiler von MS VC++ angewiesen sein sollte.

Da könntest du wohl recht haben. Aber trotzdem müssen die zwischen Engine und Game-Code das gleiche ABI haben; je nach Platform kann das unterschiedlich sein, aber die jeweiligen ABIs müssen passen. Die können also:

• Je nach Platform einen anderen Compiler benutzen,
• oder ein C-Interface benutzen, welches ja eine standardisierte ABI hat.

Quake 3 hat ja damals auch den Game-Code (reines C-Interface) in eine VM gepackt, und das hat ganz gut funktioniert.

Es gibt auch offizielle Infos zum verwendeten GI-Algorithmus:

http://www.geforce.com/whats-new/articles/stunning-videos-show-unreal-engine-4s-next-gen-gtx-680-powered-real-time-graphics/ hat geschrieben:What is Global Illumination and why is it so important to game realism?
Global Illumination refers to the calculation of light bouncing around a scene. GI is responsible for many of the subtle shading effects and ambience we see in real-world environments, as well as glossy and metallic reflections. Introducing real-time Global Illumination into Unreal Engine 4 is the biggest breakthrough in lighting since Unreal Engine 1 introduced real-time Direct Illumination in 1995.

Please give us an overview of how the algorithm works from generating the octree, to cone tracing, to the gathering pass.
The technique is known as SVOGI – Sparse Voxel Octree Global Illumination, and was developed by Andrew Scheidecker at Epic. UE4 maintains a real-time octree data structure encoding a multi-resolution record of all of the visible direct light emitters in the scene, which are represented as directionally-colored voxels. That octree is maintained by voxelizing any parts of the scene that change, and using a traditional set of Direct Lighting techniques, such as shadow buffers, to capture first-bounce lighting.

Performing a cone-trace through this octree data structure (given a starting point, direction, and angle) yields an approximation of the light incident along that path.

The trick is to make cone-tracing fast enough, via GPU acceleration, that we can do it once or more per-pixel in real-time. Performing six wide cone-traces per pixel (one for each cardinal direction) yields an approximation of second-bounce indirect lighting. Performing a narrower cone-trace in the direction of specular reflection enables metallic reflections, in which the entire scene is reflected off each glossy surface.

Mir sind noch nicht ganz die Unterschiede zu Cyril Crassins Arbeit klar; ich hab dem entsprechenden Engine Developer mal eine Twitter-Nachricht geschrieben.

(Ich finde es super, dass wenigsten die von Epic nicht mit irgendwelchem Marketing-Geschwätz kommen, sondern die Computer-graphisch korrekten Begriffe verwenden; yes, I'm looking at you, Crytek.)

Ja, das hört sich sehr nach Cyrils Arbeit an. Und in der Tat fällt die Diskretisierung etwas auf, wenn sich reflektierte Objekte bewegen. Aber auch in niedriger Auflösung dürfte das schon ordentlich Speicher verschlingen. ;)

Hat eigentlich schon jemand was zum Partikel-Rendering gefunden? Erlauben moderne GPUs ohnehin abertausende Partikel, oder sträubt sich da die auf größere Flächen optimierte GPU? Wenn man die Dinger effizient sortiert bekommt, könnte man womöglich mit einem geclusterten Ansatz besser davonkommen, der vielleicht die Cluster-eigenen Partikel sogar im Group-Shared Memory blendet (bäh, Atomics?) und dann kollektiv in den Framebuffer kopiert? Wie sieht es eigentlich mit Tessellation aus, da werden die Dreiecke ja auch wesentlich kleiner; arbeiten GPUs mit eingeschalteter Tessellation anders? In meinen bisherigen Experimenten waren einfache pass-through Tessellation Shaders langsamer als ein pass-through Geometry Shader, aber der Anwendungsfall war auch wenig repräsentativ, weil viele Dreiecke Subpixelausdehnung hatten ... Jedenfalls erschienen viele Dreiecke mit um die 1 Pixel Ausdehnung in meinen Experimenten mit Voxelisierung durch konservative Rasterisierung äußerst suboptimal.

Viele offene Fragen, die vor allem meine Gedanken ordnen (a parallel algorithm a day keeps the doctor away); jetzt weiß ich schonmal, nach welchen Antworten ich suchen muss. ;)

== Nachträge ==

Mehr Marketing-Geschwätz mit minimalem Informationsgewinn:

nVidia hat geschrieben:GeForce GTX 400 GPUs are built with up to fifteen tessellation units, each with dedicated hardware for vertex fetch, tessellation, and coordinate transformations. They operate with four parallel raster engines which transform newly tessellated triangles into a fine stream of pixels for shading. The result is a breakthrough in tessellation performance—over 1.6 billion triangles per second in sustained performance. Compared to the fastest competing product, the GeForce GTX 480 is up to 7.8x faster as measured by the independent website Bjorn3D.

==

Auch interessant: Implicit Radix Sorting on GPUs - 180 Millionen Elemente pro Sekunde auf einer fast schon antiken GTX 260. 1 Million Partikel sollten da auf 600er-Karten in 2 ms sortierbar sein?

[vimeo]43800150[/vimeo]

CodingCat hat geschrieben:Hat eigentlich schon jemand was zum Partikel-Rendering gefunden? Erlauben moderne GPUs ohnehin abertausende Partikel, oder sträubt sich da die auf größere Flächen optimierte GPU?

Da war wohl jemand zu faul, eine 434-MiB-große Präsentation runterzuladen. ;) Ich denke zumindest mal, dass die einen sehr ähnlichen, wenn nicht den gleichen Ansatz wie bei den Partikeln von Halo: Reach verwenden.

CodingCat hat geschrieben:Auch interessant: Implicit Radix Sorting on GPUs - 180 Millionen Elemente pro Sekunde auf einer fast schon antiken GTX 260. 1 Million Partikel sollten da auf 600er-Karten in 2 ms sortierbar sein?

Danke, der Link scheint mir irgendwie entgangen zu sein. Ich muss allerdings auch eingestehen, dass ich im Bereich der GPU-Sortierverfahren den Überblick verloren habe. :(

Damit das hier auch irgendwie on topic bleibt: Nettes Video da Chromanoid.

eXile hat geschrieben:

CodingCat hat geschrieben:Hat eigentlich schon jemand was zum Partikel-Rendering gefunden? Erlauben moderne GPUs ohnehin abertausende Partikel, oder sträubt sich da die auf größere Flächen optimierte GPU?

Da war wohl jemand zu faul, eine 434-MiB-große Präsentation runterzuladen. ;) Ich denke zumindest mal, dass die einen sehr ähnlichen, wenn nicht den gleichen Ansatz wie bei den Partikeln von Halo: Reach verwenden.

Naja, da gehts nicht wirklich um Rendering. Und weil die Partikelzahl durch die Interaktion irgendwo über 24.000 begrenzt ist, sagt die Präsentation auch nicht viel über die Performance der Standardrasterisierung bei Millionen von Partikeln aus.

Sorry, dass mein Link nicht weiterhalf; nach meinem Kenntnisstand ist aber bisher über das gezeigte Partikelsystem nicht mehr bekannt.

CodingCat hat geschrieben:In meinen bisherigen Experimenten waren einfache pass-through Tessellation Shaders langsamer als ein pass-through Geometry Shader, aber der Anwendungsfall war auch wenig repräsentativ, weil viele Dreiecke Subpixelausdehnung hatten ... Jedenfalls erschienen viele Dreiecke mit um die 1 Pixel Ausdehnung in meinen Experimenten mit Voxelisierung durch konservative Rasterisierung äußerst suboptimal.

Naja, warum 1×1-Pixel-große Dreiecke oder gar Subpixel-große Dreiecke schlecht sind, ist doch klar: Alle modernen GPUs legen ein 2×2-Tiling auf dem Framebuffer an, und jedes Tile für sich wird rasterisiert (und generiert damit ddx und ddy). Es hängt sogar vom Alignment der Dreiecke ab, wie gut sie rasterisiert werden: Wenn du 2×2-Quads (oder zwei Dreiecke) renderst und die um einen Pixel nach unten/oben oder zur Seite verschiebst, so dass die nicht mehr mit dem 2×2-Grid alignt sind, ist das eine Performancestrafe, die bei vielen solcher Quads (oder zwei Dreiecken) durchaus ins Gewicht schlägt.

Ja, genau deshalb meine Überlegungen, ob Partikel-Rendering mittels Computer Shader sich lohnen könnte.