ZFX + Developia

Das Gebastel geht weiter
http://launix.de/raumschiff/client.html


Jetzt mit WASD-Steuerung. Das Raumschiff kann man selbst erweitern und eigene Tastenkombinationen zum Steuern festlegen.

I smell Konkurrenz :D ... aber Weltraum geht halt auch immer.
Die Waren im Raumschiff sehen irgendwie heiß aus.

Planeten rendern und nahtlos bis auf die Oberflaeche zoomen, mit Baeumen, Gras und Blumen (so jedenfalls die Idee). In WebGl, 1. Prototyp. Erstmal nur als dem Weltall weil alles andere noch nicht gut aussieht.

Ehrgeiziges Ziel. Ich bin neugierig, wie weit Du damit kommst.

wo sind die Sterne

Irgendjemand hat vor einigen Jahren dafuer gesorgt, dass die Messlatte fuer Sterne viel zu hoch geworden ist :-)

Ausserdem, keine Geoshader in WebGL. Aus Performancegruenden mache ich auch kein HDR - jedenfalls nicht aus dem Orbit heraus.

Irgendwelche Punkt-Sprite Sterne in weiss wird es aber sicher geben.

Ich bin sehr gespannt bzgl. dem Ziel Planet aus dem Weltraum bis aus Grasnarbe :-)
Arbeite ja nach wie vor an dem gleichen Thema (prozedurales Universum), und das ist schon nicht ohne.
http://zfx.info/viewtopic.php?f=10&t=3075&start=30

Mir macht bei nahen Planetendistanzen nach wie vor das parsen des Quadtree (in meinem Ansatz) sowie damit verbunden ein gutes Split/Merge und die Performance und Speicherlast Probleme, sowie ein noch nicht sauber funktionierendes Horizon Culling. Alles Sachen an denen ich mich noch austobe.

Würde mich freuen wenn es bei dir weiter geht und man sich ggf. ab und an mal austauschen kann.

Sehr gerne! Ich habe allerdings nicht vor, das Thema sonderlich weit auszuweiten und ein komplett prozedurales Universum zu basteln. Ich will eigentlich nur eine huebsche WebGL-Demo machen :-)

Dank guter Hilfe vom lieben Aramis mein erstes HTML5-Projekt:

Klicken für volle Ansicht ;)


Ja, ich werde das 2D-RPG von weiter oben jetzt in HTML5 umsetzen, als Übung und weil es auch mehr Sinn macht von Gameplay usw...

Inspiriert von diesem wunderbaren Artikel zur Visualisierung verschiedenster Algorithmen (unbedingt anschauen!): Zufällige Abtastung ist wirklich ein wunderbares Werkzeug bei der Generierung organisch angehauchter ("unregelmäßiger zellulärer") Strukturen. Kurzexperiment mit zufällig in der Ebene platzierten Samples eine simplen Höhenfunktion und Delaunay-Tringulation:

Das geht auf jeden Fall auch noch bedeutend schöner (z.B. Abtastpunkte gleichmäßiger mit im Artikel gezeigten Bridson’s Algorithmus platzieren!).

Sehr schick! Etwas pastellig für meinen Geschmack :-)

Ich geh jetzt mal den Artikel lesen...

CodingCat hat geschrieben:Inspiriert von diesem wunderbaren Artikel zur Visualisierung verschiedenster Algorithmen (unbedingt anschauen!):

Wirklich toll, und ein Bisschen vertraut. Ich habe auch gemerkt, dass meine Produktivität sich vervielfacht, seitdem ich alle Probleme zu visualisieren versuche statt Bytes im Debugger hin- und herzuschieben.

Zufällige Abtastung ist wirklich ein wunderbares Werkzeug bei der Generierung organisch angehauchter ("unregelmäßiger zellulärer") Strukturen.

Was der Artikel nicht erwähnt, ist Penrose-Parkettierung. Aber die ist für den Zweck wahrscheinlich auch zu aufwändig zu erzeugen.

Habe den Abend lang schön mit den Jungs das vierte Schlachtfeld besucht und viele viele Leute erschosssen. So ganz lies mir der OpenGL-Kram dann aber doch keine Ruhe. Und jetzt geht alles, was ich in der Demo drin haben wollte: statische und dynamische Geometrie, Instancing, Texturen, Shader und Rendertargets.
Der Matrix-Kram ist zwar immernoch rätselhaft, aber beherrschbar.

Drüben bei Driver Madness haben wir in letzter Zeit große Fortschritte gemacht, auch die Driver 2-Levels zu extrahieren. Insbesondere hat SOAP einen OBJ-Export geschrieben, mit dem man die als massive Testdaten benutzen kann (ich wollte ursprünglich meine Global Illumination dran testen; aber die Zeit …). Sind ja immerhin ganze Städte, wenn auch 13 Jahre alt.
Ich merke, dass ich langsam merkwürdig werde: Ich nehme uralte Videospielwelten, seziere sie, und stecke sie unter Käseglocken. Da steckt bestimmt irgendwas Unverarbeitetes aus der Kindheit hinter.

Aber cool sieht's schon aus. Von daher: möchtest Du darüber reden?

Es ist wieder etwas zu viel zum Aufschreiben, aber:

Die Städte in Driver 2 enthalten ungefähr doppelt so viel Information wie die in Driver 1 zwei Jahre zuvor. Um das in die 2 MiB RAM der PlayStation 1 zu quetschen wurden die Städte erneut in Blöcke von ungefähr einem Kilometer Kantenlänge unterteilt. Die Daten liegen wieder in zwei Klassen vor:

• Globale Daten, die an jedem Ort benutzt werden: Himmel; Autos; Figuren; Straßen. Die werden zu allererst geladen und liegen ständig im RAM. Sie benutzen eine primitive Kompression um die Ladezeit ein Bisschen zu verkürzen.
• Lokale Daten, die nur beim Betreten eines Blocks geladen werden. Die Anordnung ist, um die Suchzeiten des CD-Laufwerks zu minimieren, ziemlich exotisch: Man muss ein zentrales Verzeichnis (immer im RAM) entschlüsseln und die Daten aus an 2048 B ausgerichteten Blöcken zusammensuchen. Diese Daten sind nicht komprimiert; wahrscheinlich hatten sie parallel zum Spiel einfach keine Rechenleistung dafür übrig.

Dabei wurden die üblichen Schweinereien gemacht, wie: Modelle bringen nicht ihre eigenen Vertices mit sondern benutzen die Vertices eines anderen Modells, das schlimmstenfalls weiter hinten in der Datei steht.

Man merkt, dass sie an allen Ecken und Enden gespart haben. An vielen Stellen haben sie die Grenzen nicht nur ausgereizt, sondern überschritten.Ich habe auch viel „Dreck“ in den Dateien gefunden:

• die Namen aller Modelle und Texturen stehen im Klartext drin, obwohl sie für das Spiel ohne jeden Nutzen sind
• man findet in der Leere unerreichbare Blöcke mit nur einem vergessenen Modell als Inhalt, die aber in der Datei fast ein Megabyte verschwenden
• sie haben selbst für die winzigen Multi-Player-Levels vollständige Karten im Spiel untergebracht, weil sie nach dem Copy-Paste aus den Single-Player-Levels nicht aufgeräumt haben
• etliche nutzlose Texturen
• etc pp

Der Projektleiter sagte damals, dass sie noch ein paar Wochen für’s Feintuning gebraucht hätten, aber schnell zum Weihnachtsgeschäft ausliefern mussten. Das ist auch mein Eindruck. Das Spiel wird auf 2 CDs geliefert und die unterscheiden sich nur in wenigen MiB; wären sie mit dem Aufräumen fertig geworden, hätte alles auf eine CD gepasst und die oft kritisierten FPS-Einbrüche wären sicher ausgeblieben.

Gegenüber dem 1. Spiel haben sie technisch enorm aufgerüstet:

• beliebig gedrehte Modelle
• beliebig gedrehte Straßen mit weiten Kurven und Autobahnkreuze
• Brücken, die Straßen kreuzen (im 1. Teil wurde die Fahrphysik noch komplett durch eine Heightmap beschrieben, konnte also keine echten Brücken)
• etwa die doppelte Menge Polygone und Texturen

Wenn man es mit dem 1 Jahr später erschienenen GTA III vergleicht, ist GTA deutlich detaillierter und freier (obwohl seine Spielwelt viel kleiner ist). Dafür hatte es aber auch 300 MHz und 32 MiB RAM zur Verfügung, während Driver 2 mit 34 MHz und 2 MiB auskommen musste und nicht einmal Z Buffering kennt.

Ich finde es sehr beeindruckend wie du die Daten extrahierst. Du hast auch alle Interpretationen der Daten raus gefunden. "Du bist einfach der Beste".

Nein; wie schon beim ersten Teil hat mir Someone972 sehr viel geholfen. Ich kam tatsächlich nicht mehr weiter bis er mit der Kompression eingesprungen ist. (Ich glaube, dass der alles allein gemacht hätte, wenn man ihm einen Monat Zeit gegeben hätte.) SOAP kam dazu und hat Strukturen entschlüsselt, für die ich niemals die Gedult gehabt hätte.

Der beste Beweis für die Teamarbeit ist, dass jeder von uns dreien mit einem eigenen Programm anfing, und dass nun alle drei auf fast identischem Niveau sind weil wir jede Entdeckung sofort geteilt haben.

Krishty hat geschrieben:Der beste Beweis für die Teamarbeit ist, dass jeder von uns dreien mit einem eigenen Programm anfing, und dass nun alle drei auf fast identischem Niveau sind weil wir jede Entdeckung sofort geteilt haben.

Ein "Team" lebt von den Fähigkeiten seiner Mitglieder. Auch wenn Someone972 und SOAP viel geholfen haben, ich hätte mich gar nicht erst ran gewagt. Mir gefallen diese Levels sehr.

Krasse Scheisse .. das ist einfach nur krasses Frickeln! Ich liebe es! :-) :-)

Bin beeindruckt!

Ach du liebe Güte … da habe ich den Paeth-Filter meiner PNG-Optimierung doch glatt auf LSD implementiert :?

Ich würds so lassen :) Zumindest optional.

Ein Tool zum visuellen Erstellen von CG-Algorithmen, Shadern, ...
Kann im Moment nur das Dargestellte, aber der Weg ist bereitet:

Kleines Update: Man kann mittlerweile eigene Shader schreiben und über einen simplen Shader-Filter anwenden. Zudem habe ich "Action Slots" hinzugefügt, damit man zum Beispiel Bilder in groß anzeigen kann oder Resultate speichern.
Update Screenshot

Coole Sache, ich hatte noch nie ein Tool, das sowas kann, beeindruckend 8-)

Dynamic Planet Generation:

Das sieht nicht aus wie Diamond Square oder Perlin Noise. Was ist es? Das Voronoi-Dingens?

Zerschnittene Kugel, ein bisschen Simplex Noise und ein relativ komischer (sprich Copy/Paste) Hydraulic Erosion Filter...

Die zerschnittenen Kugel sind wirklich eine coole Idee. Wieder so eine ganz einfache Vorgehensweise, die tolle Dinge erzeugen kann.

Ja auf jeden FalL!
Wobei "tolle Dinge" und eine glatte Oberfläche erst bei so 150k Iterationen entstehen. Und das braucht selbst mit OpenCL eine Weile bei 2 Mio Pixels

Hier mal wieder etwas neues von uns.
Der Mapeditor wurde nun um einige Einstellungsmöglichkeiten erweitert.
So lassen sich jetzt Texturensets, Lichtverhältnisse so wie die Wasserattribute definieren.
Beim ersten herumspielen sind folgende Bilder herausgekommen.
Ein paar Partikeleffekte hier und da sollten der Szene noch mehr Atmosphäre verschaffen, aber dazu später mehr ;)