ZFX + Developia

Ich liebe C++. Aus Bequemlichkeit der Typsicherheit mit expliziten Casts das Genick brechen und zugleich für maximale Sicherheit durch das Typsystem den Typ mit Tag-Enum-Template-Argumenten annotieren.
So unvollkommen die Metaprogrammierung mit C++ auch noch immer ist, so sehr hat mir dieses Gefühl von Intelligenz und Überlegenheit nach gelungenem Template-Entwurf auch gefehlt. :mrgreen:

Twitter Introduces Innovators Patent Agreement. Ein kleiner Schritt für die Menschheit, und doch ein großer Schritt in die richtige Richtung.

Ich weiß nicht so recht, wohin damit, also kommt es einfach hier rein:

Order-Independent Transparency in DirectX 11 hat geschrieben:UAV Counter Alternative

• Create a 1x1 UAV, this “Global Counter” is used to allocate links in our linked lists. Initialized to 0.
• Instead of IncrementCounter(), get the current value of Global Counter and increment it using InterlockedAdd().
• All threads will be fighting for atomic access in global memory (Could use a NxN buffer with pixel sub-counters to improve performance)
• The global counter method is ~30% slower than using the UAV counter

Was läuft da richtig/falsch?

Egal, folgendes kommt mir dazu in den Sinn: Ist so ein UAV-Counter dann nicht ideal für Stream Compaction bei gleichzeitiger Vermeidung von Bankkonflikten? Mir schwebt folgendes vor: Jeder GPU-Thread zählt seine (unkompaktierten) Datenpakete und ruft für jedes Paket einmal IncrementCounter() zur Allokation eines Speicherslots im Puffer auf. Liegt es nicht in der Natur der SIMD-Architektur, dass benachbarte Threads dies einigermaßen synchron tun, und so ihre Datenpakte gerade nach dem Reißverschlussprinzip bankkonform und kompakt nebeneinander in den Puffer legen?

Wäre das dann nicht wesentlich günstiger und zugleich optimaler als eine deterministische Präfixsumme, welche die Daten obendrein uninterleaved so perfekt nebeneinander in den Speicher legen würde, dass mit massig Bankkonflikten gerechnet werden müsste?

Nach meinem Verständnis würden benachbarte Threads nicht im Reißverschlussprinzip, sondern wirklich parallel zu inkrementieren versuchen, und damit die Konfliktanzahl maximieren. Die zitierte Methode würde dagegen nur einmal pro Fragment incrementieren, was bei Shaderlängen von potentiell hunderten Befehlen nur alle Jubeljahre mal zu Konflikten führen würde.

Die ANimationen sehen jetzt in meinem Viewer so aus, wie im Assimp Viewer. Ein kleiner Bug muss noch irgendwo im Ogre-Importer sein, aber ansonsten scheint es jetzt echt zu funktionieren. Noch etwas Feinschliff und ich poste mal was richtiges dazu. Soviel vorweg: Beschlossen dass ich Animationen programmieren will, hab ich wohl so ungefähr zu dieser Zeit in 2008 :D

Glückwunsch; wenn es dich aufmuntert: Bei mir sind zwischen dem Zeitpunkt, an dem ich angefangen hab Animationen zu programmieren und sie fertig hatte auch ca. 2 Jahre ins Land gezogen. Wenn ich nun auch noch überlege, wann ich BESCHLOSSEN hab Animationen zu programmieren... NEIN, ich will da gar nicht dran denken, sonst fühl ich mich so alt. :lol:

Kurze Durchsage: Ich habe mal alle meine mathematischen Beiträge auf MathJax umgestellt, und benutze keine halb-garen externen Anbieter mehr. Kurze Auswahl:

• Normal Interpolation
• Radiosity
• Beleuchtung durch Environment Map
• Globaler volumetrischer Nebel
• BRDF für Reflektion
• Diffuser Shader - Normalen-Transformation?

Wenn hier jemand noch mit der LaTeX-Syntax struggelt, kann derjenige einen Blick auf den LaTeX-Code werden (einfach auf „zitieren“ beim jeweiligen Beitrag klicken).

Insbesondere wenn man den Zeilenabstand beispielsweise via \\[-5pt] verringern will, klappt das mit MathJax noch nicht, aber der Bug ist bereits gemeldet, und man kann ihn via /smash{…} und einem positiven Abstand (z.B. \\[5pt]) umgehen.

D3DX ist gar nicht tot, nur verteilt. DirectXTex (*.dds Loader, Block Compression, ...), DirectXMath, DirectXTK (C++-Varianten von XNA-Hilfsklassen: Sprite Batch, Sprite Font, Bitmap Font Conversion Utility, State Management, Input Layout Management, ...). Muss ich bei Gelegenheit mal reinsehen.

Ich habe Variance Shadow Maps für mich entdeckt. Ergeben richtig schöne weiche Schatten, ohne Magic Numbers (*hust*depth * .999999 - .000001*hust*) zur Artefakt-Bereinigung und haben selbst bei geringer ShadowMap-Auflösung ein gutes weiches Ergebnis. Die Geschwindigkeit ist dabei auch nicht langsamer als PCF.
Bei all diesen Vorteilen kann ich sogar das Light Bleeding verkraften, das bei meiner naiven Implementierung an einigen Stellen auftritt.

Exakt das Light Bleeding hat mich immer aufgehalten, es überhaupt zu probieren. Deine Szene sieht aber auch gut geeignet aus. Und allgemein gut aus :)

Vielen Dank ;) Ich mach grade für mein Studium ein Softwarepraktikum, in welchem wir ein Pinball-Game programmieren müssen und ich bin halt für die Effekte zuständig.
Das Light Bleeding tritt eigentlich nur auf, wenn aus mehreren Höhen, die verhältnismäßig weit auseinander liegen, Schatten auf eine gemeinsame Fläche fällt (Sich also Schatten verschiedener Höhen "überlagern"). Ganz unten auf der Fläche gibt es dann das Light Bleeding, da dort die Varianz abnormal hoch ist. Kann man aber auch vermeiden, indem man die Varianz limitiert oder den Blur etwas intelligenter macht und so ein Spaß.

Danke für die Tipps. Ich muss das mal bei Gelegenheit ausprobieren... aktuell sieht 32xPCF bei den Splitterwelten auch gut aus, aber es frisst doch Grafikkarten zum Frühstück. Und mit VSM eröffnen sich auch viele Möglichkeiten, eine korrekte Penumbra zu simulieren. Nur das Light Bleeding macht mir mal Sorgen - bei den Splitterwelten sind solche Mehrfach-Tiefen-Szenarien mit Bergen fern, Bäumen in der Mitte und nahen Charakteren eigentlich an der Tagesordnung. Aber VSM ist ja auch schnell implementiert, also ist es einen Versuch wert.

Wieso VSM und nicht ESM?

dot hat geschrieben:Wieso VSM und nicht ESM?

Ja, hab mir grade das Paper durchgelesen und implementiert. Das verhindert tatsächlich das Light-Bleeding in den meisten Fällen und sieht gut aus. Ich bin von meinem 9x9 Gauß-Filter auch zurück auf einen 5x5 gegangen, da die Schatten zu weich waren :D
Viele Dank für den Tipp ;)

Nachtrag: Es ist sogar noch schneller als VSM implementiert O.o

Thought you're done? Chen, Tatarchuk – Lighting Research at Bungie. Ganz viele Slides und Tipps zu ESM. ;)

Hey, darf ich beim Shadow-Mapping-Bingo auch noch mitmachen? Wie wärs mit LVSM? Oder SDSM? Oder RTW?

Soll ich jetzt in den Jammer-Thread schreiben dass ich mich gefreut habe das mein Soft Shadowing das ich einigermaßen schnell implementiert habe relativ gut funktioniert, ihr mir aber den Spaß verderbt? ;P

Ne, mal im Ernst, vom Preis-Leistung-Implementierungsaufwand-Rating her finde ich "normales" ESM am Besten. LVSM klingt nach Hack. Wie sind die anderen?

Woah. Die neue Keplerarchitektur (Hyper-Q, Dynamic Parallelism) könnte alle meine Probleme lösen. Überhaupt, wenn das so funktioniert, wie es angepriesen wird, dann dürfte Realtime Raytracing damit ein Klacks werden. :P

CodingCat hat geschrieben:Dynamic Parallelism

Das ist doch im Augenblick nur für CUDA 5, oder?

Naja, ich hoffe einfach mal, dass sich das durchsetzt. Insbesondere Hyper-Q wäre ein gewaltiger Gewinn für den gleichförmigen, aber inkohärent langen Programmablauf, wie ich ihn selbst gerade habe, und wie er wohl in jeder Art von Ray Tracing und Ray Casting auftritt. Damit sollte man sich endgültig auf den datenparallelen und voll skalierbaren Ansatz verlassen können, Endlosschleifen wie in Ailas Paper dürften dagegen eher schaden (und sind ja eigentlich eh nur ein hässlicher Hack, um vom sonst versteckten Half-Warp-Scheduling zu profitieren, wenn ich das richtig sehe).

Lacht mich aus, aber ich finde, dass die Unreal Engines früher scheiße aussahen (grobe Polygone mit verwaschenem Plastik-Shading auf den Bildschirm geklatscht) und dass die neuen Schnappschüsse nur deshalb gut aussehen, weil

• ihnen besserer Content zur Verfügung steht als anderen Engines; und
• all die Depth-of-Field-/Bokeh/Color-Correction-Post-Processing-Effekte dank der gestiegenen Compute Shading-Leistung ohne großen Hirnschmalz halbwegs korrekt implementiert werden können.

Schön, dass die Oberflächen für die neuen Schnappschüsse matter geworden sind; bei dem letzten Demo-Video war es aber wieder ein- und derselbe Hochglanz-Prolo-Glitzerbrei, den ich von 2 & 3 kenne und hasse.

Ich finde es alles fett, überladen, Brute-Force; und schätze, dass andere Engines mit ähnlich liebevoll detailliertem Content besser aussähen – den 80er-Jahre-Cyberpunk- / Post-Apo- / Futu-Dungeon-Kram, den sie immer zeigen, will nur sonst keiner.

Aber wem’s gefällt …

Hast du dich im Thread geirrt? ;) *scnr*

Spätestens seit Doom 3 ist doch klar, dass jedes Level mit Schuhcreme auf Hochglanz bepinselt werden muss. Übrigens ist das von dir genannte mattere Aussehen wohl auch physikalisch plausibler.

Insbesondere, wenn man beispielsweise das Radiosity-Verfahren (hat als Grundvoraussetzung diffuse Oberflächen) nimmt, kommen meiner Geschmacksrichtung nach schöne Ergebnisse raus (beispielsweise bei den nicht von Radiosity generierten Lightmaps von Stalker oder den durch Radiosity generierten Lightmaps von Mirror's Edge).

Eine moderne Alternative zu Radiosity ist übrigens ein paar SH-Maps mit PRT zu berechnen (von mir aus auch in H-Basis oder was auch immer), auch wenn dadurch der Speicherbedarf für anständige Darstellungen (neun Koeffizienten) verneunfacht wird, aber das kriegt man mit anständiger Kartierung und Texturkompression wieder runter. Ich glaube bei Halo 3 haben die das auch gemacht (siehe hier und da).

Die Stalker-Lightmap war so nur im Direct3D-8-Modus sichtbar, der ein Relikt der Alphas und Betas von vor 2005 war. Aber die waren in der Tat sehr hübsch (ich schaue sie mir immer wieder gern an). Schade, dass das fertige Spiel durch fehlendes Antialiasing, völlig verflimmertes Parallax und grobe Lightmaps wieder eine einzige Flimmerorgie wurde.

Mirror’s Edge ist wunderschön. Es war ganz exakt, wozu man die Hardware einsetzen sollte. Sowas war damals immer mein Ziel.

Ich habe mich immer gewundert, dass so viele Spiele – insbesondere die, die eigentlich für ihr Aussehen gelobt wurden, z.B. Far Cry oder eben Doom – so nach glänzendem Plastik aussehen. Niemand scheint an halbwegs realistischer Reflektionsverteilung interessiert (und wenn, dann wird es Blinn-Phong genannt ;) ). Eine Schande.

Ich stimme dir völlig zu, Mirror's Edge ist toll.
Und momentan sind alle mit Plastik zufrieden. In Skyrim fällt mir das jedesmal besonders stark auf. Skyrim Drachen, Plastik. Skyrim Metalltüren, Plastik.
Lass uns für bessere BRDFs kämpfen. Für Cook-Torrance, für Oren-Nayar, für Minnaert und all die anderen.

Hm.. als ich vorher auf der Seite mit den Bildern war, waren da aber noch tw. ganz andere. Vergleicht nur mal das Wireframe-Bild von dem Gebirge mit dem Nicht-Wireframe-Bild davon. Das Wireframe-Bild wurde anscheinend nicht ausgetauscht.
Auch das mit den Planeten war vorher fast schon richtig hässlich. Zum Glück gibts da noch einen direktlink aus dem Chat mit einem Freund:
http://www.wired.com/gamelife/wp-conten ... 4_8_ss.jpg

Die haben mir mal so gar nicht zugesagt, dafür, dass die man mit der UE4 Samatarian locker in den Schatten stellen können solle.

Die Bilder, die jetzt da sind, sehen besser aus. Aber es hat halt immer noch hier und da ein paar Fehler (Transparenz und DoF z.B.) und mMn. immer noch den Typischen UnrealEngine-Look.

^ ^ ^

:lol: :lol: :lol: :lol: :lol:

ZLIB vs. Snappy

Jeweils ein 158kB File:

• ZLIB
  > Kompression auf 8,86kB
  > Zeit zum Dekompromieren der Datei 9,4ms
  - Komplexe API
  - viele Defines
  - Komprimieren dauert ewig
• Snappy
  > Kompression auf 17,2kB
  > Zeit zum Dekomprimieren der Datei 5,1ms
  + Namespace
  - Scheiße zu kompilieren
  + Schneller

Ich habe ZLIB aus meinen API-Funktionen aktiv entsorgt - so wie die Stadtreinigung meinen Müll.