ZFX + Developia

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.

TDK hat geschrieben:ZLIB vs. Snappy

Ob das gut oder schlecht ist, hängt von zwei Fragen ab:

1. Ist die Anwendung symmetrisch (wird auf dem Zielsystem genau so oft komprimiert wie extrahiert)?
2. Wo bekommt das Zielsystem deine Daten her? (Für das Internet wäre diese Kompressionsrate zu niedrig; für DVD wäre das eine schöne Verbesserung; auf PCs ist die meiste Kompression dieser Größenordnung Verschwendung.)

Trotzdem Glückwunsch.

Ich habe angefangen, das Shadowmapping von meinem Egoshooter-Projekt in "Das Volk und der Turm" zu integrieren. Bis auf ein paar kleine Grafikfehler sieht das auch schon ziemlich hübsch aus :)

Ist die Anwendung symmetrisch (wird auf dem Zielsystem genau so oft komprimiert wie extrahiert)?

Die Daten werden nur ein mal beim Import komprimiert. Da beim Komprimieren allerdings tausende Einzeldateien komprimiert werden, spielt die Zeit schon eine Rolle. Die Content Creator reagieren sonst immer so gereizt, wenn alles so lange dauert...

Ansonsten werden diese auch teilweise während des Simulationslaufes nachgeladen, ab und zu mehrmals. Und da ist eine schnelle Leserate, und vor allem auch weniger Festplattenknistern, von Vorteil. Und die CPU benötige ich nebenbei auch noch.

Ich verwende für alle komprimierten Dateien ein Format, welches zugleich die Versionierung und den Inhaltstyp gegenprüft. Zudem ist das Format so intelligent, dass wenn es eine Änderung der Originalversion festgestellt wird (besonders XML-Konfigurationen), die Datei sofort neu importiert werden kann.

Wo bekommt das Zielsystem deine Daten her? (Für das Internet wäre diese Kompressionsrate zu niedrig; für DVD wäre das eine schöne Verbesserung; auf PCs ist die meiste Kompression dieser Größenordnung Verschwendung.)

3D-Objekte, Konfigurationen (Node-Attribute-Value System), Texturen (teilweise DXT 5) und sonstige binäre Dateien wie World Files und Terrain Files. Jedes MB zählt, da das gesamte Programm mit den verschiedenen Welten viele Gigabyte in Anspruch nehmen wird.

TDK hat geschrieben:Da beim Komprimieren allerdings tausende Einzeldateien komprimiert werden, spielt die Zeit schon eine Rolle. Die Content Creator reagieren sonst immer so gereizt, wenn alles so lange dauert...

Dann komprimier es halt nicht während der Entwicklungsphase, sondern nur vorm Ausliefern; dann schrumpft der Zeitaufwand gegen Null.

TDK hat geschrieben:Ansonsten werden diese auch teilweise während des Simulationslaufes nachgeladen, ab und zu mehrmals. Und da ist eine schnelle Leserate, und vor allem auch weniger Festplattenknistern, von Vorteil. Und die CPU benötige ich nebenbei auch noch.

Dann komprimier am besten garnicht – dann werden ab dem zweiten Lauf weder Festplatte noch CPU überhaupt benötigt.

TDK hat geschrieben:Jedes MB zählt, da das gesamte Programm mit den verschiedenen Welten viele Gigabyte in Anspruch nehmen wird.

Bei Snappy kannst du mir nicht erzählen, dass „jedes Byte zählt“. Wenn die Welten sechs oder sieben GiB in Anspruch nehmen, dann sollen sie das halt. (Ich werte das auch einfach mal als die Daten kommen von der Festplatte eines PCs).

Afaik nutzen selbst RAD Game Tools Kompression nur noch auf Konsolen, weil der Windows Page Cache auf dem PC alles wegrockt. Und mit wegrocken meine ich an eigenen Beobachtungen: 12.000 Dateien in einer Drittelsekunde in den Speicher holen; 4 GiB unkomprimierte Texturen 100× schneller einblenden als die zlib-komprimierten Varianten – mit CPU-Unkosten gegen Null.

Ich habe bei meinem derzeitigen Projekt auch die Wahl, es mit einem komprimierten Paket aus zu starten oder mit einem unkomprimierten Verzeichnis (erwähnte 12k Dateien) – und ich nehme immer das Verzeichnis, weil mich die Wartezeiten sonst in den Wahnsinn treiben.

Komprimiert werden sollte nur für die Auslieferung via Installer. Davor und danach hat alles unkomprimiert zu sein.

Krishty hat geschrieben:Afaik nutzen selbst RAD Game Tools Kompression nur noch auf Konsolen, weil der Windows Page Cache auf dem PC alles wegrockt. Und mit wegrocken meine ich: 12.000 Dateien in einer Drittelsekunde in den Speicher holen; 4 GiB unkomprimierte Texturen 100× schneller einblenden als die zlib-komprimierten Varianten – mit CPU-Unkosten gegen Null.

Hart sekundiert. Das einzige, was man noch selber machen kann, ist, die Dateien selber zu prefetchen (d.h. ein Memory-Mapping darauf anlegen), wenn man weiß, dass man sie in Zukunft benötigen wird. In diesem Falle hat man einfach mehr Informationen als das Windows-Speichersystem, welches ja schlecht in die Zukunft schauen kann.

eXile hat geschrieben:In diesem Falle hat man einfach mehr Informationen als das Windows-Speichersystem, welches ja schlecht in die Zukunft schauen kann.

Wobei auch das selten zum Problem werden sollte – kommt der Kunde nach dem Kauf am Montag jeden Tag um 17:30 (nach Arbeit und Essen) an den PC, um eine Runde Deathmatch auf seiner Lieblingsspielkarte zu spielen, wird Windows ab MI alle Spieldaten um 17:25 vollständig im Page Cache haben. Falls man dann auf Kompression verzichtet hat, müsste der Kunde innerhalb von zehn Sekunden nach dem Klicken auf die Verknüpfung im Blut baden können. Falls man aber auf Kompression gesetzt hat, lädt es genau so lahm wie immer.

Unrelated: Ich habe shell32.dll aus meinem Programm entfernt gekriegt. Sie hatte von den 40 MiB Images, die mein Prozess benötigt, 13 ausgemacht – und damit etwa gleich viel wie Direct3D und AMD-Treiber zusammen.
Jetzt möchte ich unbedingt die VC-CRT raushaben – die frisst zwar nicht viel Speicher, mappt aber Font-Dateien und Locales aus dem Windows-Verzeichnis. Meine Fresse, was für ein Trauerspiel.

Krishty hat geschrieben:

eXile hat geschrieben:In diesem Falle hat man einfach mehr Informationen als das Windows-Speichersystem, welches ja schlecht in die Zukunft schauen kann.

Wobei auch das selten zum Problem werden sollte – kommt der Kunde nach dem Kauf am Montag jeden Tag um 17:30 (nach Arbeit und Essen) an den PC, um eine Runde Deathmatch auf seiner Lieblingsspielkarte zu spielen, wird Windows ab MI alle Spieldaten um 17:25 vollständig im Page Cache haben.

Trollierst du mich gerade? ;) Ich meinte eher: Es ist ein Cache, kein Precache. Dass gleich in einem Spiel das Level zu Ende ist, und das nächste anfängt, und man somit schon mal leise im Hintergrund anfangen könnte, ein wenig vorzuladen, ist durchaus sinnig.

Wenn man also einen grandiosen Cache wie unter Windows hat, ist nicht mehr die Frage, wie man Cachen soll (nämlich mit Memory-Mappings und dem Windows-Cache), sondern was und wann man etwas cachen sollte.

Vielleicht erinnere ich mich auch nur einfach sentimental an die Zeiten zurück, als ich noch in Spielen in sekundenschnelle Speichern und Laden konnte. :(

(Und was soll Windows MI sein? Der ungeliebte Bruder von Windows ME mit Buckelrücken? Schwätz deutlich Junge! ;))

Upps; da hast du völlig recht. Ich bin ein wenig in meiner Ich lade einfach alles auf einmal direkt am Anfang-Philosophie steckengeblieben ;-)

(Und was soll Windows MI sein? Der ungeliebte Bruder von Windows ME mit Buckelrücken? Schwätz deutlich Junge! ;))

Okay, nochmal für alle: Windows hat dann ab Mittwoch nachmittag 17:25 alles parat ;)

Nach wochenlangem Hinauszögern habe ich es endlich geschafft, (m)einen Artikel über Functional Purity in D fertig zu schreiben: http://klickverbot.at/blog/2012/05/purity-in-d/. Sorry für die schamlose Eigenwerbung, aber ich dachte, nach Carmack's kürzlich erschienenem AltDevBlogADay-Artikel könnte das für so manchen interessant sein…

Diskussion auf Reddit und Hacker News. Feedback aller Art höchst willkommen!

OMNOMNOM, endlich kann ich wieder vernünftig arbeiten :D (scnr)

Uff. Was hast du dafür ausgegeben wenn man fragen darf? ;)

Da kann man nur gratulieren. 12 Cores? Was ist das für eine Prozessorkonfiguration, die du hast?

Ich finde es auch sehr schön, dass du die Fensterhöhe exakt und pixel-genau zwischen beiden Fenstern angeglichen hast. Nur leider ist der Rahmen oben fünf Pixel zu klein. Ja ich achte auf sowas. ;)

Artificial Mind hat geschrieben:

i7x6.680gtx.png

OMNOMNOM, endlich kann ich wieder vernünftig arbeiten :D (scnr)

Lächerliche 4 GiB RAM

Ich tippe einfach mal auf einen Sandy Bridge E. Und die 32GiB RAM sehen lecker aus, wobei ich mit 16 derzeit noch zufrieden bin.

Ich frage mich aber immer wieder warum Windows so einen zwanghaften Drang zum auslagern hat. Selbst bei dieser Konfig schiebt der bei dir immer noch Speicher auf die Platte. :?

Lynxeye hat geschrieben:Ich frage mich aber immer wieder warum Windows so einen zwanghaften Drang zum auslagern hat. Selbst bei dieser Konfig schiebt der bei dir immer noch Speicher auf die Platte. :?

Das habe ich auch bemerkt, darum habe ich die Auslagerungsdatei komplett deaktiviert.