Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 13:22

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 3 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: GLife
BeitragVerfasst: So Okt 12, 2003 15:48 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Sozusagen als Nachtrag zu der Diskussion von 10.10 hat mich die Lust gepackt tatsächlich mal zu versuchen Conways Life als OpenGL Applikation umzusetzen. Ich finde es ja wirklich faszinierend, wie aus simplen zellulären Automaten komplexe Muster und "Lebewesen" entstehen, die sich tatsächlich fortbewegen, andere "Lebewesen" produzieren oder etwas "essen" können.

Herausgekommen ist übers Wochenende GLife:
Bild
http://mcad.delphigl.com/GLife/GLife.zip (Downloadgröße 1,57 MB)

Ich würde mich ebenfalls freuen, in der Projektesektion mehr kleinere Projekte zu sehen - es müssen ja nicht immer die Megaprogramme sein, deren Entwicklung sich über Monate und Jahre hinzieht, so kleine Demos und Minispielchen sind ja auch immer witzig (und inspirieren ungemein).

GLife ist kein Spiel im eigentlichen Sinn (obwohl Life oft als Spiel des Lebens bezeichnet wird), das simple Regelwerk kann jeder im Google unter "Conways Life" nachschlagen, im Internet finden ebenfalls auch sehr viele Life-Simulatoren, die teils Welten gigantischer Größe berechnen können (allerdings habe ich keinen grafisch so opulenten wie GLife gefunden :D )

Die Bedienung des Simulators ist recht einfach, interessant ist wahrscheinlich vor allem die Möglichkeit .lif Dateien, die es zuhauf im Internet gibt, laden zu können (dies sind fertige Zellkonstellationen, die sich meist auf besonders interessante oder witzige Weise entwickeln).
Da eine solche .lif Datei oft viele Konstellationen beeinhält, muss nach dem Laden noch die jeweilige Konstellation in der entsprechenden ComboBox ausgewählt werden, bevor der Inhalt der "Welt" geändert wird. (Bei GLife sind bereits beinahe 200 .lif Dateien dabei, sodass dem Forschergeist nichts mehr im Wege steht :wink: )

Mit der rechten Maustaste können in der Minimap jederzeit neue Zellen hinzugefügt werden, die anderen Optionen sind selbsterklärend: es kann eingestellt werden, wie groß der gerenderte Bereich ist, wie weit der Betrachter vom "Boden" entfernt ist, wie genau die Zellen tesseliert werden, usw. (steht eh alles auf dem Formular)

Es kann zwischen zwei Textursets umgeschaltet werden (flesh und plants), vor allem deswegen, weil "flesh" eventuell ein bissel obszön aussieht :shock: .

Die Anzeige der FpS ist insofern nicht besonders exakt, als die FpS nur jeweils pro "Lebenszyklus" berechnet werden, bieten also eher einen Durchschnittswert, als die tatsächlich zwischen letztem und aktuellem Frame verstrichene Zeitspanne zu repräsentieren.

Ich würde mich freuen, im Feedback Forum zu hören, was ihr so davon haltet, evtl. könnte man sogar ein "richtiges" Spiel draus machen, so eine Art Strategiespiel, in der versucht werden muss, Zellautomaten zu generieren, die vom eigenen Sektor in den gegnerischen Sektor wandern, und das "Leben" dort zu vernichten (oder auch einen leeren Weltbereich zu besiedeln) - unterschiedlichen Zellen könnten dann unterschiedliche Regeln mitgegeben werden, was dann schon sehr komplexe Welten ermöglichen würde.
Eure Meinung (und evtl. Vorschläge) zu so einem Spiel würde mich auch interessieren, meine Hauptbedenken sind allerdings, dass so etwas evtl. so komplex wäre, dass niemand mehr mitkommt, was da eigentlich geschieht (obwohl z.B. Maxis SimLife im Prinzip auch nix anderes ist).
Jedenfalls wäre dies eine Spielidee, die man tatsächlich selbst umsetzen könnte, die geistig herausfordernd wäre (eher ein Spiel für Tüftler) und bei der es in naher Zukunft auch keine kommerzielle Umsetzung großer Spielefirmen geben wird.

________________________________

Zum Programm:

GLife berechnet die zellulären Automaten nach der Bruteforce Methode, was bei nur 4096 Zellen das kleinste Problem ist. Andere Lifesimulatoren, die teils Weltgrößen von mehreren Millionen oder Milliarden Zellen zulassen, müssen hier optimieren, sodass große "leere" Zellbereiche gar nicht erst berechnet werden. Da so eine große Welt im OpenGL Fenster aber ohnehin nicht dargestellt werden könnte, ist mir das ziemlich egal.

Die Hauptschwierigkeit war natürlich die Zellen so zu rendern, dass halbwegs biologisch aussehende Gebilde dabei herauskommen - ich habe dafür MetaBalls verwendet (dabei habe ich mich grob an einem Artikel von Tom Nuydens über den marching cubes Algorithmus orientiert - meine Umsetzung ist allerdings schneller als Nuydens Beispielcode, kann marching cubes in Gittern mit unterschiedlicher XYZ Ausdehnung berechnen, die Anzahl der gerenderten Metaballs ohne Zeitverlust verändern und unterstützt auch die Generierung von Normalen und Texturkoordinaten).
Die flexible XYZ-Ausdehnung des marching cube Grids ist für GLife besonders wichtig, als sich das "Leben" vor allem in der XY-Ebene abspielt, die Z-Ausdehnung kann daher verringert werden, was eine starke Verringerung der benötigten Rechenoperationen (über 50%) ohne Qualitätsverlust ermöglicht.

Wen die genaue Umsetzung des Algorithmus interessiert: der vollständige Source ist in der ZIP dabei, die MetaBall Klasse kann auch als Beispiel dafür dienen, wie Ogl sehr einfach um eigene Objektklassen erweitert werden kann, die mit Mcad überhaupt nichts zu tun haben

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Okt 12, 2003 22:26 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Tja und schon gibt's das erste Update:

Die Berechnung der FpS war nur dann korrekt, wenn als Zykluszeit eine Sekunde eingestellt war. Jetzt sollte Sie immer stimmen (auch wenn Sie aufgrund der internen Berechnungslogik bei längeren Zykluszeiten genauer sein sollte, da zur Berechnung der FpS die Anzahl der dargestellten Frames pro Zyklus verwendet wird).

Damit sich der Upload überhaupt lohnt, gibts noch folgende Änderungen:

- Die Voreinstellungen sind nun so justiert, dass das Programm ohne sichtbaren Qualitätsverlust ca. 30% schneller läuft (die Z-Achse konnte ohne Weiteres um ein Drittel gröber tesseliert werden, da der Beobachter immer in Richtung Z-Achse auf das Szenario schaut)

- "sterbende" Zellen versuchen jetzt wann immer möglich, in überlebende Zellen/Zellhaufen hineinzukriechen, vorher schrumpften sie immer und verschwanden dann. Jetzt verschwinden Zellen nur noch dann, wenn es keine überlebenden Nachbarn gibt. Dies erhöht den Eindruck von lebenden Organismen, da Strukturen nun eher darauf bedacht sind, eine einheitliche Form zu bilden

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Okt 15, 2003 01:13 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Das zweite Update dürfte wahrscheinlich auch das letzte Update von GLife sein - soll heißen, wenn ich tatsächlich dran weitermache, wird ein neues Projekt draus.
Es gibt nun zwei Arten von Lebewesen, differenziert durch unterschiedliche Texturen. Zur Zeit verhalten sie sich genau gleich, sie können allerdings ihre "DNA" weitervererben, sodass neue Zellen ein Gemisch ihrer Elternzellen darstellen, was auch visuell sichtbar ist. In einer ausgebauten Simulation, bzw. einem Spiel könnte man neben der Textur natürlich auch Regeln(Verhaltensweisen) weitervererben, oder aber auch für Mischtypen völlig neues Verhalten definieren.

Der Link zu GLife hat sich nicht verändert (http://mcad.delphigl.com/GLife/GLife.zip), der Source ist auch dabei und darf natürlich auch eingesehen werden, allerdings möchte ich darum bitten, diesen nicht einfach weiterzugeben oder per Copy&Paste in eigene Programme zu kopieren, da ich Teile davon eventuell für ein anderes Projekt weiterverwenden möchte - und es ziemlich blöd finden würde, wenn jemand zeitgleich mit etwas Ähnlichem antanzen würde. (Die andere Möglichkeit wäre natürlich gewesen, den Source nicht mitzuliefern, was mir aber ebenfalls nicht gefällt, zumal das Projektforum hier ohnehin nur für DGL Mitglieder einsehbar ist). Dies betrifft eigentlich nur die Unit MetaBall, der Rest (außer den Ogl Bibliotheken) ist ohnehin eher ein Hack, mit dem wahrscheinlich niemand so recht was anfangen könnte :D .

Nachdem die erste Version aufgrund der Metaballs doch ziemlich langsam war - und die Berechnung der Alphakanals für die Texturen ebenfalls recht aufwendig ist, habe ich die kritischen Routinen in Assembler handoptimiert, was tatsächlich einen Geschwindigkeitsschub von 30 bis 50% schafft, sodass die neuen, komplexeren MetaBalls nun schneller sind, als in der Vorversion (ein e durchschnittlich komplexe Szene wird auf meinem Notebook nun in ca 20-40 Frames dargestellt, während es vorher 9 bis 25 waren).

Texturkoordinaten können nun auf drei unterschiedliche Arten generiert werden, Hintergrundtextur und die Zelltexturen können jederzeit geändert werden (zumindest solange es sich um 32 Bit TGA-Dateien oder im Cubemapgenerator (bei Mcad dabei) erstellte Cubemap-Texturen handelt).

Die Skybox im Hintergrund wird nun beim Bewegen im "Level" mitbewegt, ein Feature, das ich in der Vorversion schlichtweg vergessen hatte.

Mich würde nun interessieren, ob das GLife auf älteren Rechnern (als Mindestkonfiguration sage ich mal ein 1GHZ Duron mit OpenGL 1.3 Graka) halbwegs flüssig läuft, sowie ob ihr Chancen seht, dass ein Spiel auf Basis einer solchen Life-Simulation tatsächlich mehr als ein paar Leute interessieren könnte.

Vorschweben würde mir Folgendes:
es gibt unterschiedliche Welten(Level in verschiedenen Größen) mit unterschiedlicher Grafik und Regelsets, in denen mit zunehmender Schwierigkeit Aufgaben folgenden Typs bewältigt werden müssen: mit einer Zelle einen bestimmten Punkt erreichen, einen bestimmten Teil der Karte zu besiedeln, einen bestimmten Anteil (prozentmäßig) der Karte zu besiedeln, einen Teil oder alle gegnerischen Zellen zu vernichten.
Es gibt fest vorgegebene Hindernisse und Fallen, sowie natürlich die gegnerischen Zellen, die in späteren Levels die eigenen Zellen gemeinerweise infizieren und ebenfalls zu Feindzellen umwandeln können.

Die Steuerung erfolgt über ein Ressourcensystem, in dem man am Anfang einen gewissen Anteil von Zellplasma hat, mit dem man eigene Zellen erstellen kann, oder aber Regeln definieren darf (evtl. könnte man Regeln in einem Forschungssystem "entdecken" und darf sie, sobald sie da sind, anwenden). Lebende Zellen produzieren Zellplasma, mit dem man eventuell auch unbelebte Objekte (wie eben Mauern und Fallen unterschiedlichen Typs, oder, wie von SOS vorgeschlagen, Spezialzellen(Attraktoren), die Zellen in einem bestimmten Umkreis entweder anziehen oder abstoßen) bauen kann, oder aber neue Zellen auf die Karte setzen, die allerdings nicht zu weit von bereits existierenden Zellen entfernt sein dürfen.
Außerdem gibt es Boni, wie etwa den DNA-Boost, mit dem eine gewisse Zeitspanne lang, eigene Zellen Feindzellen bei Körperkontakt umwandeln können, solche Boni können entweder gefunden oder mit sehr viel Zellplasma gekauft werden.

Das Ganze sollte dann noch in eine Story eingebunden werden, die spannend genug ist, dass man Interesse dran hat, wie es nun weitergeht (die aber natürlich nicht in einem menschlichen Universum spielt - aber z.B. sehr wohl den Mensch als Universum sehen könnte :wink: )

So, das langt erst mal als potentieller Entwurf, jetzt kommen noch ein paar Anmerkungen zum tatsächlich existierenden GLife:
__________________________________________

Eigentlich ist es verwunderlich, dass Assemblercode so viel schneller läuft, als normaler Delphicode (ist aber bei C++ sicher nicht anders), da der Kompiler den Delphicode ja optimieren sollte - bei Fließkommaberechnungen scheint das allerdings nicht so recht zu klappen (evtl. wegen der Stackstruktur der Register etwas schwierig). Na ja, so etwas zeigt halt, dass man als Programmierer den Kontakt zu der Maschine, auf der man arbeitet - trotz toller IDE und allem - doch nicht verlieren sollte (und ist ein gutes Argument gegen die diversen managed Code Kompiler). Ausserdem macht es einem Delphi ja wirklich sehr leicht, Assemblercode einzufügen.
Übrigens muss ich während der Aufrufe der entsprechenden Routinen die Codeoptimierung kurzfristig abschalten (ein paar Zeilen lang), da Delphi ansonsten Fließkommawerte in den Registern zwischenspeichert, ich aber alle acht Register des FPU Stacks benötige, um mit möglichst wenigen Speicherzugriffen auszukommen (erst war der Schreck groß: beim Debuggen lief alles einwandfrei, sobald ich Debugmodus und Codeoptimierung ausschaltete, schmierte das Ganze grausam ab - na ja, die Lösung war dann schnell gefunden)

Überraschend schwierig war es auch, die Texturen korrekt überzublenden - während ich recht bald eine Möglichkeit gefunden hatte, den Alphakanal eines Schnittpunktes aus den Metaballs zu berechnen, brauchte ich die längste Zeit (und Herumprobieren in Mcad) bis ich Parameter fand, die den Alphakanal für die Überblendung zweier Texturen weder aus der Texturumgebung, noch aus der Textur selbst sondern aus dem Alphawert der Schnittpunktfarbe holten. Im Nachhinein ist natürlich wieder alles logisch...
Jedenfalls war ich schon nahe dran, das Ganze in Vertex- und Fragmentprogrammen zu machen, was mich allerdings schon etwas gestört hätte, da diese Erweiterungen halt doch noch nicht so sehr verbreitet sind.
Wenn es übrigens bedingte Sprünge in Vertexprogrammen gäbe (die Anzahl der Kugeln in einem Metaballobjekt ist leider nicht Konstant - zumindest nicht in GLife), könnte man sogar die Metaballs selbst (oder zumindest deren Normalvektoren) mit der Videokarte berechnen, was einen ordentlichen Leistungsschub gäbe.


Dateianhänge:
Dateikommentar: Ein Screenshot der "neuen" GLife Version
newglife.jpg
newglife.jpg [ 47.54 KiB | 4821-mal betrachtet ]

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/
Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 3 Beiträge ] 
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 30 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.072s | 19 Queries | GZIP : On ]