[SAMMELTHREAD] Sehenswerte Videos

[CodingCat]

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

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

[Chromanoid]

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.

[Schrompf]

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.

[j.klugmann]

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

[Artificial Mind]

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 ;)

[eXile]

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.

[Chromanoid]

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.

[eXile]

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.

[eXile]

Es gibt auch offizielle Infos zum verwendeten GI-Algorithmus:

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.)

[CodingCat]

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:

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?

[Chromanoid]

[vimeo]43800150[/vimeo]

[eXile]

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.

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.

[CodingCat]

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.

[eXile]

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

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.

[CodingCat]

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

[eXile]

[youtube]6_DrgiwLABk[/youtube]

(Dass Jacco Bikker und Co. integer sind, sieht man schon daran, dass die die Sample-Akkumulation ausgeschaltet haben. ;))

[Schrompf]

Beeindruckend - die haben es anscheinend tatsächlich geschafft, mit Path Tracing in die Nähe brauchbarer Performance zu kommen. Wobei ich durch das Gekriesel nach gröberen Bildwechseln den Eindruck habe, dass ein subtanzieller Teil der Performance nur durch Back Projection zustande kommt. Und natürlich ist die Auflösung immernoch winzig, wenn ich das richtig sehe. Und Unreal4 (und viele andere auch) kriegen all das mit der selben Rechenleistung hundertmal schneller hin. Aber naja... ich bin halt kein erklärter Raytracing-Fan. Nichtsdestotrotz sehr beeindruckend.

[CodingCat]

In der Tat höchst beeindruckend, auch wenn das Rauschen noch immer enorm stört. ;)

(Dass Jacco Bikker und Co. integer sind, sieht man schon daran, dass die die Sample-Akkumulation ausgeschaltet haben. ;))

Inwiefern Sample-Akkumulation ausgeschaltet? Ich hätte aus dem gleichen Grund wie Schrompf (Bildwechsel) auch eher auf Back Projection mit massiver Akkumulation getippt. Wobei das bei zweiten Hinsehen wohl eher ein bewusster Unschärfeeffekt sein soll, der der relativ niedrigen Sample-Zahl wegen im Rauschen untergeht.

[eXile]

Wobei ich durch das Gekriesel nach gröberen Bildwechseln den Eindruck habe, dass ein subtanzieller Teil der Performance nur durch Back Projection zustande kommt.

Meiner bescheidenen Meinung nach kann ich weder Sample-Akkumulation noch Back-Projection erkennen; ohne Quellcode oder Beschreibung der Algorithmen ist das aber alles herumgerate (die beknackte Video-Enkodierung tut sein übriges). ;)

Vielleicht liegt es ja daran, dass Depth of Field aktiviert ist? (So wie ich das im Video sehe, wird auf die Tiefe des Pixels in der Bildmitte fokussiert, wobei die Linsenstellung linear angepasst wird, so dass bei Wechseln der Bildtiefe eben einige Zeit lang erst einmal Unschärfe zu sehen ist.)

Und Unreal4 (und viele andere auch) kriegen all das mit der selben Rechenleistung hundertmal schneller hin. Aber naja... ich bin halt kein erklärter Raytracing-Fan. Nichtsdestotrotz sehr beeindruckend.

Das ist korrekt. Ich denke aber, dass wir zumindest im Bereich der niederfrequenten Beleuchtung (globale Illumination) oder in bestimmten Spezialfällen (Screen-Space Reflections) bestimmte durch Ray-Tracing beeinflusste Algorithmen sehen werden; so wie die Unreal-4-Engine es eben auch mit dem Voxel-Cone-Tracing macht.

Inwiefern Sample-Akkumulation ausgeschaltet? Ich hätte aus dem gleichen Grund wie Schrompf (Bildwechsel) auch eher auf Back Projection mit massiver Akkumulation getippt.

Ich glaube, die machen gar keine Akkumulation. Erstens ist mir Back-Projection im Bereich des Ray-Tracings eher unbekannt (das kann aber an mir liegen), zweitens müsste man dann nicht in der Nähe der Bildschirmkanten Regionen mit unterschiedlicher Konvergenz ausmachen können? (Dass Sample-Akkumulation mit Back-Projektion bei Bewegung viel besser aussieht als ohne ist klar; trotzdem keine ich noch niemanden dort, der eine Back-Projektion benutzt. Man sieht halt dann häufig extremes Ghosting bei Bewegung.)

Dass es keine Akkumulation irgendwelcher Art gibt, sieht man bei Sekunde 50 des Videos (siehe Schatten unten links.) Wer so mutig ist, kann sich ja mal Reflect runterladen (benötigt eine nVidia GPU mit mindestens CUDA Compute Capability 2.0).

[CodingCat]

Ich glaube, die machen gar keine Akkumulation. Erstens ist mir Back-Projection im Bereich des Ray-Tracings eher unbekannt (das kann aber an mir liegen), zweitens müsste man dann nicht in der Nähe der Bildschirmkanten Regionen mit unterschiedlicher Konvergenz ausmachen können? (Dass Sample-Akkumulation mit Back-Projektion bei Bewegung viel besser aussieht als ohne ist klar; trotzdem keine ich noch niemanden dort, der eine Back-Projektion benutzt. Man sieht halt dann häufig extremes Ghosting bei Bewegung.)

Dass es keine Akkumulation irgendwelcher Art gibt, sieht man bei Sekunde 50 des Videos (siehe Schatten unten links.) Wer so mutig ist, kann sich ja mal Reflect runterladen (benötigt eine nVidia GPU mit mindestens CUDA Compute Capability 2.0).

Wenn du Back Projection geschickt machst, sampelst du Stellen mit geringer Übereinstimmung (Ränder) einfach mehr als Stellen mit hoher Übereinstimmung, insofern muss das nicht unbedingt in der Konvergenz sichtbar sein. Wie schon im Post obendrüber nachgetragen, bin ich mir aber auch nicht mehr sicher, ob da wirklich Back Projection zum Einsatz kommt. Sollte es momentan nicht zum Einsatz kommen, wäre das vielleicht sehr interessant zur Reduktion des Rauschens?! Andererseits funktioniert es vermutlich nur für diffuse Beleuchtung. Bei Reflexionen, Brechungen etc. hätte man wohl in der Tat starkes Ghosting.

Reflect habe ich vor ein paar Monaten btw. mal getestet. Mir ist allerdings nach wenigen Minuten speiübel geworden vom vielen Rauschen. ;)

[Schrompf]

Auf deren Webseite war ich gerade, aber das im Video gezeigte Demo gibt es leider nicht öffentlich. Ich weiß aber, dass ein älteres Demo (die von Assimp berühmte Collada Dining Room-Szene mit dem Glas-Drachen auf dem Tisch) massiv über mehrere Frames hinweg akkumuliert, dort allerdings nur bei stillstehender Kamera. Das kann man mit gutem Willen als Anfang der Back Projection betrachten, aber es ist natürlich nur reine Spekulation von mir.

[edit] Die Spekulation ist übrigens vorbei - der Author hat den Film soeben auf Youtube als "privat" markiert. Ich glaube mich aber an eine Stelle zu erinnern, bei der die Kamera durch eine Wand durchflog. Die erste Sekunde nach dem Durchfliegen war extrem verkrieselt. Daher kommt auch meine BackProjection-Vermutung.

[CodingCat]

[youtube]7Tu6SmsEKeY[/youtube]

Sehr schön umgesetzt. Nutzt Blender für VFX. ;)

[Artificial Mind]

[edit] Die Spekulation ist übrigens vorbei - der Author hat den Film soeben auf Youtube als "privat" markiert. Ich glaube mich aber an eine Stelle zu erinnern, bei der die Kamera durch eine Wand durchflog. Die erste Sekunde nach dem Durchfliegen war extrem verkrieselt. Daher kommt auch meine BackProjection-Vermutung.

Also bei mir geht es noch.

[eXile]

Schöner Film, schön gemacht, schöne versteckte Referenzen zur Differentialgeometrie ;)

Also bei mir geht es noch.

Ja, es geht jetzt wieder.

[CodingCat]

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.

Runtime-Compiled C++ von einigen (GameDev-)Hobbyisten, kam gerade via Twitter rein. Hier gibts den Source Code. Ich steige auf die Schnelle nicht ganz durch, aber auf jeden Fall rufen sie einfach den VC++ Compiler auf, um nach Veränderung neu zu compilieren. Crash Recovery mit Debugger Integration haben sie auch drin. Sicher eine gute Inspiration, sollte man sich an sowas mal versuchen wollen.

[eXile]

Runtime-Compiled C++ von einigen (GameDev-)Hobbyisten, kam gerade via Twitter rein. Hier gibts den Source Code. Ich steige auf die Schnelle nicht ganz durch, aber auf jeden Fall rufen sie einfach den VC++ Compiler auf, um nach Veränderung neu zu compilieren. Crash Recovery mit Debugger Integration haben sie auch drin. Sicher eine gute Inspiration, sollte man sich an sowas mal versuchen wollen.

Vielen Dank dafür! Der Code sieht eigentlich wie zu erwarten aus: Der Standard-WinAPI-Monitor für Dateien, ein paar Pipes für die Compiler-Anbindung, wie schon vermutet GetProcAddress um sich die Funktionen zu holen; das Exception-Handling ist gut durchdacht, so weit habe ich noch nicht mitgedacht.

Nur musste ich die Kommandozeilengenerierung so anpassen, dass er auch Pfade mit Leerzeichen korrekt behandelt. :evil:

[eXile]

[youtube]cKC6j7pW6T0[/youtube]

[Artificial Mind]

Interessantes Video, ich hätte gedacht die meisten solcher "High-Speed with Moving Camera"-Clips seien nahezu komplett gerendert.

[eXile]

Ich halte der Produktionsfirma sehr zugute, dass tatsächliche echte Objekte abgefilmt werden und keine CG benutzt wird; allerdings haut es mich um ehrlich zu sein nicht wirklich vom Hocker, weil die Bilder doch sehr generisch wirken.

[Andre]

Mir ist eben erst einmal klar geworden in wie viel der Werbung, die man so sieht (Und ich schaue nun wirklich nicht viel Fernsehen), von diese Firma ihre Finger im Spiel hatte.

Schon beeindruckend was man aus alltäglichen Dingen manchen kann. Auch wenn man es nach dem 15. Bier was eingegossen wird auch langsam eintönig wird, wie eXile schon meinte ;)