ZFX + Developia

Hier wieder einmal ein neues Update von mir: Autos!
Sie sind voll zerstörbar und lenkbar. Dazu hat jedes Auto eine Turret auf dem Dach, welche man auch benutzen kann.





Durza

Wir arbeiten an den ersten Animationen für unser Projekt AntZeit (Arbeitstitel). Der Charakter "Jessica" wurde gefilmt, während sie auf einem Laufband vor einem Greenscreen lief.
Hier die Projekt-Seite auf FB: https://www.facebook.com/pages/AntZeit/116213511743798

[youtube]PAtV46B6eAE[/youtube]

Steampunk find ich super :) Coole Idee mit den Live-Action Animationen. Habt ihr vor die Farbintensität in der Richtung zu lassen? Mich würde mal eine etwas kühlere blassere Farbgebung interessieren. In den anderen Videos hat das Spiel noch eine andere Perspektive, wird das ganze auch noch mal von oben aufgenommen oder plant ihr einen Perspektivwechsel? Tolle Requisiten übrigens.

In "Farb-Design" haben wir noch gar keine Arbeit gesteckt. Die Charakter-Aufnahmen sind recht neutral gehalten, jetzt kann man damit mal rumspielen. Der Hintergrund ist keine finale Grafik...

Die Perspektive haben wir verändert. Die Tech-Demos sind ja so Diablo-mäßig, das haben wir aber aus mehreren Gründen gekippt. Es geht jetzt in so ne Beat'em'up-Richtung...

Dieses Bild wurde mit einem ASIC erzeugt. Um diesen Detailgrad zu erreichen, sind normale CPUs oder GPUs ungeeignet, da sie zu wenig Rechenleistung haben. Die Wolken sind echt, also kein Skydome. Ebenso das Gras besteht nicht aus Sprites, sondern jeder Halm ist für sich und bewegt sich mit dem Wind. Um diese Masse an Daten verarbeiten zu können, wurde die Logik zum Bildaufbau auf einen Custom-Design-Chip untergebracht. Ich weiß nicht, wieviel FLOPs der ASIC hat, aber das Ergebnis ist beeindruckend. Die Bilder werden nicht ganz in Echtzeit gerechnet, aber vielleicht wird das noch. (Auflösungen von 640x480 sind inzwischen schon in Echtzeit möglich)

Hast du auch 'n Video wo das gezeigt wird?

Sorry, aber das klingt für mich dann doch nach Bullshit. Die Szene in dieser Komplexität in den Speicher zu kriegen, so dass ein ASIC nicht wie alle normalen Prozessoren an der Speicherbandbreite erstickt, ist das eine. Aber spätestens das praktisch perfekte Antialiasing am Schilf hinten sagt mir, dass dort ein Standard-Renderer mit einigen Minuten Zeit am Werk war, oder das es schlicht ein Urlaubsfoto ist.

Schrompf hat geschrieben:Sorry, aber das klingt für mich dann doch nach Bullshit. Die Szene in dieser Komplexität in den Speicher zu kriegen, so dass ein ASIC nicht wie alle normalen Prozessoren an der Speicherbandbreite erstickt, ist das eine. Aber spätestens das praktisch perfekte Antialiasing am Schilf hinten sagt mir, dass dort ein Standard-Renderer mit einigen Minuten Zeit am Werk war, oder das es schlicht ein Urlaubsfoto ist.

Nunja, der ASIC ist so designt, dass die Szene nicht im Speicher liegt, sondern von einer externen Quelle kommt, deshalb auch noch nicht echtzeitfähig.

Viel interessanter wäre doch der Kontext. Woher kommt das Bild, wer forscht/entwickelt gerade daran, welche Ansätze stecken dahinter? Gibt es sinnvolle Vergleiche? Ohne ist das Ganze ziemlich witzlos.

Der hier war besser:
[Projekt] Ultralighting von Zudomon

Und ich gehe davon aus, dass du damit einfach sagen willst, dass du jetzt in den Urlaub gehst oder eine Unix-basierte Digitalkamera gefunden hast (das würde auch fast-Echtzeit erklären).

CodingCat hat geschrieben:Viel interessanter wäre doch der Kontext. Woher kommt das Bild, wer forscht/entwickelt gerade daran, welche Ansätze stecken dahinter? Gibt es sinnvolle Vergleiche? Ohne ist das Ganze ziemlich witzlos.

Diese ASICs gibt es viele und sie werden schon in Consumer-Produkten verbaut. Es sind aber bis jetzt nur wenige dahinter gekommen, dass man damit auch solche Wasser-Wolken-Gras-Szenen rausholen kann.

Langweilig.

Ja, der Punkt geht an Zudomon. Erstens, weil er früher war, und zweitens, weil seine Vorstellung wenigstens einen handwerklichen Hintergrund hatte.
Jetzt mal ehrlich, was soll das getrolle? Du nervst langsam echt...

Fangen wir mal bei der Atmosphäre an... man erkennt in oben in der Mitte des Bildes so eine Art Godray... nun ich glaube, jeder hier, der sich mit Godrays mal beschäftigt hat, sieht, dass das definitiv kein Standardansatz ist, da dort ein unnatürliches rauschen drin zu sehen ist... Perlin Noise? Oder doch nur natürliche Wassermolekühle, die das Licht auf so reale weise scattern?
Hier ist nicht nur eine Wolkenart zu sehen, sondern es ist ein Gemisch aus mehreren... sehr gut umgesetzt... Doch fällt euch dieser etwas dunkle Klecks an Wolke auf? Etwas links von der Bildmitte und über dem dichten Wolkenbergen im Hintergrund... nun, warum sind die Wolken hier so dunkel? Da hat wohl jemand drauf geachtet, dass Wolken unterschiedliche dichten haben können. Auch das finde ich sehr gut umgesetzt...
Mal zu dem unglaublichen Detail... ich frage mich, wo dieses ist... klar ist es detailliert, aber ein Großteil des Bildes besteht aus Wasser.. und das könnten dann zwei Dreiecke sein.
Und schaut mal auf das Wasser... was fällt da auf? Erstens müssen da wohl verschiedene Texturmaps verwendet werden, um die unterschiedlichen Wellen zu erzeugen... das geht mit jeder handelsüblichen Grafikkarte bereits in Echtzeit, aber es wird in diesem Ausmaß nicht gemacht... wage mal zu behaupten, dass diese Wellenformation absolut natürlich sind... im Gegensatz zu allem, was ich bisher künstlich gesehen habe... wenn es nicht unbedingt von Pixar ist. Zweitens, das Wasser weißt verschiedene Partikel auf... vorne schwimmen weiße, da ist auch ein Stöckchen zu sehen... dahinter sind es dann eher dunkle flecken... mal abgesehen von der komplett geskinnten Figur, die da ziemlich mittig im Wasser schwimmt... ob die auch so Hochdetailliert ist?
Also ich glaube, Realismus ist vor allem diese Ansammlung von kleinen Details... :D

Wer will kann sich den Softcube Designer 3.0 Beta von meiner Homepage http://www.gamedevstudio.com downloaden. Die Benutzung ist kostenlos. Ein Handbuch gibt es noch nicht. Kommt aber noch. Das Programm kann erstelle Szenen auch im DirectX Text Format (*.x) exportieren. Auch Texturekordinaten lassen sich erstellen. Die Ladefunktionen sind jetzt deutlich schneller, dank "Very Sleepy". Eigentlich war nur die Splineinterpolation zu langsam.

Ich habe gestern festgestellt, das noch einige Bugs im Designer enthalten sind. Zwar stürzt das Programm nicht ab, aber einige Funktionen haben doch noch nicht das korrekte Verhalten. Wenn es mir zeitlich möglich ist werde ich also nachbessern.

Ich habe in den letzten Tagen an einem neuen Logging-System gearbeitet, was neben der Erfassung von Datei/Funktion/Zeile auch in der Lage ist brauchbare Informationen im Falle einer Exception zu generieren. So gibt es zum einen eine Funktion, die SEH oder auch C++ Exceptions abfängt und entsprechend logt. Es kann aber auch ein Makro manuell genutzt werden, was ein loggen von zu schmeißenden Exceptions vornimmt. SEH Exceptions (Windows/MSVC++) sind Hardware-Exceptions wie z.B. Access Violation, Division by Zero, etc.).
Wenn eine C++ Exception nicht durch einen catch-Block abgefangen wird, so landet diese im SEH-Filter und ich kann diese loggen. Der Typ wird dabei aus der EXCEPTION_POINTERS Struktur hergeleitet, dort befinden sich mehrere type_info Informationen, sodass man sogar relativ zuverlässig einen cast vornehmen kann um an die ursprüngliche C++ Exception zu kommen. Das ist leider auch alles etwas wage da es keine offizielle Dokumentation gibt, letztlich sind das alles Compiler-interne Typen, die zwar vorhanden sind aber von IntelliSense nicht erkannt werden. Nunja das explizite Loggen einer C++ Exception ist dann sinnvoll, wenn diese von einem catch-Block gefangen werden würde. Gemäß der Implementierung des try/catch lässt sich nämlich im catch nicht auf die ursprüngliche Position im Quelltext zurückfinden. Um einen Stack-Trace anzufertigen sind die Kontextinformationen aber wichtig, weswegen das Makro auch ein GetThreadContext() bekommt.

Gespeichert wird das ganze auf XML Basis, am Anfang Informationen über den Ausführungszeitpunkt sowie der Hardware des Computers, dann am Ende die ganzen Events. Als Front-End hab ich mir dafür ein HTML5 Seite gebaut, die mit Javascript/jQuery/XSLT/CSS das ganze in eine präsentable Form bringt, inklusive per Thread-Filterung und Eventtyp-Filterung.
Für den Stack-Trace verwende ich die "StackWalker"-Bibliothek (http://stackwalker.codeplex.com/), hier wäre es sogar möglich noch Informationen über geladene Symbole und co zu generieren.

Hallo, ich wollte mal eine kleine Kathedrale zeigen die ich mit meinem Softcube Designer 3.0 erstellt habe. Insgesamt geht das Modellieren ziemlich flüssig. Die Datei Kathedrale.scd ist 649 KByte groß und wird, wenn ich den Download wieder einstelle, mit dabei sein. 2 kleine Bugs habe ich korrigiert.
Edit: Da sieht man ja die Labels in der ListvIew teilweise nicht mehr. Das tritt manchmal auf seit ich von DX9 auf DX11 umgestellt habe. Wenn man Drag&Drop Technique bei den Pane(-s, -pages ) macht. Hat jemand eine Idee woran das liegen könnte ? In den nächsten Tagen werde ich wieder alles auf meiner Seite anbieten.

Ich habe auf meiner Homepage http://www.gamedevstudio.com eine neue Version als Demo eingestellt. Die obige Kathedrale ist mit dabei. Als Einschränkung hat die Demo nur das nicht alle Cubes als DirectX File gespeichert werden.

Eben habe ich noch 2 Bugs behoben. "Align on grid" funktionierte nicht. Das Schliessen einer angedockten ProjectPage (beim Softcube Designer die Ansicht einer Texture) führte bis eben zum Absturz.

Magst Du nicht einen separaten Thread dazu aufmachen, wenn Du das hier wie ein Devlog führst? :-)

Mache ich doch gerne . Aber erst Morgen. :)

Das New York-Level aus Driver von 1999 – einfach aus Jux und Dollerei.

Mal sehen, wie ich die Texturen reinkriege.

Schon besser: Beängstigend, dass ich heute ohne Culling als nicht-indizierte Triangle List runterrendern kann, was vor 14 Jahren High-End-Rechner brauchte. Bei 200 fps. (Mein Rechner ist schon vier Jahre alt, also eher vor zehn Jahren.)

Beeindruckend ! Vielleicht könntest du schreiben wie die Daten bei Driver vorliegen ? Das würde mich wirklich interessieren.

gdsWizard hat geschrieben:Beeindruckend ! Vielleicht könntest du schreiben wie die Daten bei Driver vorliegen ? Das würde mich wirklich interessieren.

Driver ist ursprünglich ein PlayStation-Spiel, und die Datenstruktur ist dementsprechend angehaucht. Ich habe mich damit beschäftigt, weil ich mit dem Entschlüsseln der Driver 2-Daten, die PlayStation-exklusiv sind, nicht weiterkomme.

Das meiste hiervon hat someone972 für seinen Driver Texture Editor benutzt, auf dem ich im Wesentlichen aufbaue:

Die Städte selber liegen als Sammlung von Blöcken vor (weil Speicher knapp ist und das Bewegen des CD-Lesekopfs langsam). Das New York-Level aus den Schnappschüssen ist z.B. 4×4 km groß, und besteht aus 8×8 Blöcken.

Jeder Block bedient sich aus einem globalen Modellverzeichnis. Das Verzeichnis umfasst für New York 1030 Modelle, die dann an beliebiger Stelle und mit optionaler Rotation um die Y-Achse, aber ohne Skalierung eingefügt werden.

Modelle, die mehr als einen Block bedecken, werden in einem zusätzlichen globalen Block gespeichert. Tatsächlich sind es also 65 Blöcke für New York.

Die Modelle sind immer mit Flächenbeschreibungen ausgestattet; aber nicht zwingend mit Punktbeschreibungen. Das kommt daher, dass sich viele Gebäude nur in Farbe und Textur unterscheiden, aber nicht in Geometrie. In diesem Fall verweisen Modelle auf die Vertices anderer Modelle. Sie haben außerdem Bounding Boxes und Clipping Planes. Außerdem liegen Motion Capture-Daten für Passantenanimation vor und Pfade für Verkehrssimulation.

Die Flächen liegen in einem alptraumhaften Format vor: Als Dreiecke oder Rechtecke; mit oder ohne Texturen; mit oder ohne Vertex-Farben; mit oder ohne Normalen. Davon je nach Shading-Art nur eine, drei, oder vier. Jede Kombination aus diesen Attributen hat ein eigenes Format und erfordert eigenen Code. Warum das gerade auf so schwachen Plattformen wie der PlayStation gemacht wurde, und ob es Obfuscation ist, weiß ich nicht. Es wurde aber für Driver 2 beibehalten.

Weil Driver oft bei Nacht spielt, sind die meisten Flächen mit Normalen ausgestattet. Im Spiel selber bewegt sich nachts eine Punktlichtquelle mit dem Spieler mit.

Die Vertices liegen in der PC-Version als float vor. Die Koordinaten sind aber absolut glatt und außerdem mit 256 vorskaliert. Ich gehe deshalb davon aus, dass in der PlayStation-Version 16- oder 24-Bit-Festkommazahlen zum Einsatz kommen. Winkel und Normalenvektoren sind in 13 vorzeichenbehafteten Bits gespeichert.

Texturen liegen in 8 oder 16 Bits pro Pixel vor. 8-Bit-Texturen sind palettiert, und haben je einen Satz von einer bis acht Paletten für unterschiedliche Tageszeiten und Einsatzzwecke – eine Baumtextur wird z.B. mit anderer, vollschwarzer Palette als Baumschatten wiederverwendet; Autos eines Typs sind gleich nur ihre Palette wird für unterschiedliche Farben durchgewechselt; usw. 16-Bit-Texturen sind RGB oder RGBA oder beides; ich weiß es noch nicht genau.

Alle Texturen sind PlayStation-typisch 256² Pixel groß, und als Sammlung einzelner Regionen (sogenannter Texture Windows) anzusehen. Die Hardware beschränkt beim Zeichnen jegliches Filtern auf diese Regionen, so dass benachbarte Regionen nicht ineinander überbluten. Das nachzubilden ist eine ziemliche Herausforderung und wird mich noch in Schach halten; darum sind die Texturen auf meinen Schnappschüssen auch noch so hässlich.

New York besteht aus ungefähr 70.000 Modellreferenzen mit insgesamt etwa 300.000 Dreiecken. Im Augenblick backe ich alle Flächen in eine 40 Megabyte große Vertex-Liste, in der ich außerdem den Texturindex jeder Fläche vermerke. Die 170 Texturen konvertiere ich zu 24-Bit-RGBX (Transparenz habe ich noch nicht im Griff) und stopfe sie in ein 256×256×170 großes Texture Array (ungefähr 30 MiB). Die Stadt wird als einzelner Draw Call gezeichnet; der Texturindex jeder Fläche wandert aus den Vertex-Daten über den Vertex Shader in den Pixel Shader und wird dort im Texture Array nachgeschlagen.

Die drei anderen Städte (Miami, Los Angeles, San Francisco) haben ähnliche Ausmaße und Datengrößen. Das Apartment aus den Zwischensequenzen ist deutlich kleiner. Das Trainingslevel konnte ich noch nicht laden; da ist irgendwas an dem Format anders.

Hier ist ein kleines Video. Dummerweise war meine Hardware zu langsam für die Aufnahme der hohen Auflösung; tatsächlich läuft es natürlich flüssig.
[youtube]7vJ88-tFQoA[/youtube]

@Krishty: Danke für deine sehr ausführliche Antwort. Der Driver Texture Editor hat dir sicher viel geholfen (ich habe ihn mal überflogen (den source)). Ich finde es gut das Du hier im Forum immer dein Wissen teilst. Nochmals Danke.

gdsWizard hat geschrieben:Der Driver Texture Editor hat dir sicher viel geholfen (ich habe ihn mal überflogen (den source)).

Ja; vor allem die Flächenaufschlüsselung hat mir Tage an Arbeit erspart. Schade, dass ich das Tool nicht eher gefunden habe.

Ich finde es gut das Du hier im Forum immer dein Wissen teilst. Nochmals Danke.

Gern; zumal ich aus offensichtlichen Urheberrechtsproblemen nicht einfach alles zum Download stellen kann.

In der Zwischenzeit:

Ich habe das Transparenzproblem weitestgehend gelöst: palettierte Texturen sind immer deckend; bei 15-Bit-RGB-Texturen sorgt der Color Key (1, 1, 1) für Volltransparenz. Wozu das 16. Farbbit da ist, habe ich noch nicht begriffen. Vielleicht ist es einfach ein Bit Zusatzgenauigkeit für einen der Farbkanäle.

Außerdem führe ich wirklich banale Lichtberechnungen auf den Flächen durch. Die Wirkung ist aber massiv, denn das Shading im linearen Farbraum sorgt dafür, dass der Dunst erst vor schattigen Stellen so richtig zum Tragen kommt.

Nette Arbeit, Krishty. Besonders die Sichtweite macht das schön.

Ist zwar nicht wirklich relevant, aber bin ich hier der einzige dem die Straßenmarkierungen mehr als merkwürdig vorkommen? Wo fangen denn da die Lanes an und wo hören sie auf? Auch wenn ich nach New York Bildern google, kann ich nichts in der Art finden. Irritierend :D

Krishty hat geschrieben:Ich habe das Transparenzproblem weitestgehend gelöst: palettierte Texturen sind immer deckend; bei 15-Bit-RGB-Texturen sorgt der Color Key (1, 1, 1) für Volltransparenz. Wozu das 16. Farbbit da ist, habe ich noch nicht begriffen. Vielleicht ist es einfach ein Bit Zusatzgenauigkeit für einen der Farbkanäle.

Verbreitet sind doch R5G6B5 und A1R5G5B5, aber du meintest ja dass es über nen ColorKey geht, daher würd ich die 1. Variante vermuten oder halt X1R5G5B5, also mit ungenutztem 16. Bit. Gibts ja öfters mal sowas.