@ Simulation :
Erstmal Gratulation zu der mehr als gelungenen Life-Simulation.Muss echt sagen,das ich bisher noch keine bessere Visualisierung gesehen hab,und mich eine Life-Simulation bisher noch nie so gefessalt hat.
Die Metaballs verleihen dem Ganzen dann noch das gewisse etwas an organischem Aussehen und machen das Zuschauen echt zu nem Erlebnis.
Ganz nebenbei sieht man auch mal was in recht geringer Zeit (wenn man denn die Kenntnisse besitzt) so alles mit Delphi und OpenGL möglich ist.

@ Spielidee :
Auf Basis der Conway-Lifesimulation liesse sich sicherlich ein interessantes unt unterhaltsames Spiel aufbauen.Ich denke da evtl. an ne Simulation die z.B. zwei Zellkulturen gegeneinander antreten (z.B. sowas wie ne Bakterienkultur,die der Spieler mit seiner eigenen Kultur vor dem Eindrigen in wichtige Organe stoppen muss) lässt,und wo der Spieler verschiedene Möglichkeiten hat seine Zellkulturen zu verändern.Er könnte da z.B. an bestimmte Position Nährzellen setzen,zu denen sich benachbarte Zellen hingezogen fühlen und er so seine Zellkulturen quasi bedingt "lenken" kann.War nur mal so ne Idee am Rande,die man natürlich noch stark erweitern könnten,die aber auf jeden Fall bestimmt für jede Menge Kurzweil sorgen würde.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

@Simulation: Ja, stimme SOS zu. Definitiv einer der best-visualisiertes "Life", die ich bisher gesehen habe. Gibt doch gleich viel mehr her als ne schäbiges Java-Applet *g*. Allerdings scheinbar auch ziemlich zu lasten der Geschwindigkeit. Ich bin mir nicht ganz sicher, woher das kommt, aber auf meiner Geforce4TI wuselt er beim Start bei 7-8 FPS rum und des beim etwas neueren Rechner :-/

Sollte man also SOS-Spielidee aufgreifen (die ich übrigens auch ziemlich interessant finde), sollte da noch das eine oder andere getan werden. Habe mir den Source nicht angesehen, vermutte aber, dass die gesamte Map gerendert wird und nicht nur ein Teil davon? Ansonsten würde das sicherlich ein recht "unverbrauchtes" Spiel ergeben können!

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Also erstmal danke für positive Feedback.

@Speed: es wird nur der sichtbare Kartenausschnitt berechnet(bzw. kann im Abschnitt "Computed Size" eingestellt werden, wie groß der berechnete Ausschnitt tatsächlich ist).
Wenn das ganze Spielfeld berechnet werden würde (64x64 Felder mit max 4096 Metaballs in ausreichender Auflösung in Echtzeit gerendert), kämen wir in einen Bereich an Rechenleistung, den so wahrscheinlich nicht mal Großrechner zur Verfügung stellen (zumindest nicht in der iterativen Form, der Algorithmus ließe sich allerdings recht einfach parallelisieren).

Das "Problem" sind die Metaballs selbst, bei denen ja in jedem Frame das Mesh erstellt werden muss (sichtbar im Wireframemodus). Obwohl GLife ziemlich optimierte Metaballs kreiert (es wird Vieles im Voraus berechnet), können in einen Frame doch 64 Metaballs oder mehr einfließen. Es hat schon seinen Grund, dass in den meisten Demos nur zwei oder drei Metaballs zu finden sind, da nämlich jeder Metaball jeden anderen beeinflußt (theoretisch), hat der Anstieg des Rechenaufwandes mit zunehmender Anzahl auch eine exponentielle Komponente.
Aus diesem Grund ist GLife eher CPU als GPU-lastig. In den Felder XRes, YRes und ZRes kann die Auflösung des Grids für die marching cubes heruntergeschraubt werden, sodass (auf Kosten der Bildqualität) GLife schneller abläuft (auch hier muss berücksichtigt werden, dass die "doppelte" Auflösung in allen drei Feldern den achtfachen Rechenaufwand nach sich zieht (umgekehrt die "halbe" Auflösung natürlich auch nur ein achtel Rechenzeit benötigt)).

Ein möglicher Optimierungsweg wäre, innerhalb des Grids für die marching cubes, einen Octree aufzubauen, um Gridelemente, die garantiert nicht von den MetaBalls beeinflußt werden, von vorneherein auszuschließen, das bringt aber genau dann nichts, wenn die Metaballs langsam sind, nämlich wenn sehr viele Metaballs berechnet werden.
Eine andere Optimierung, die ich einem Spiel, das auch auf älterer Hardware laufen soll, einbauen würde, wäre ,dass sich nicht alle Metaballs beeinflussen können, sondern nur diejenigen, die ein oder zwei Felder benachbart sind - da alle Metaballs ungefähr gleich groß sind und sich nicht allzusehr überschneiden, sollte dies auch nicht allzusehr auffallen.

Es steckt aber schon noch genügend Optimierungspotential drin, da die Metaballs in GLife ja hauptsächlich an festen Positionen liegen, meine MetaBall Klasse aber MetaBalls an frei definierbaren Positionen verwaltet.
Durch die geschickte Wahl von Perspektive und Texturen (damit gröbere Geometrie nicht so auffällt), sowie ein Beleuchtungsmodell, das keine Berechnung von Normalen benötigt (die Berechnung ist auch etwas aufwändig, da die Ableitung der MetaBall Oberfläche ja wieder von jedem MetaBall beeinflusst wird), lässt sich dann auch noch einiges drehen, sodass als Mindestkonfiguration für eine auf den Spezialfall von GLife optimierte Version ein Pentium III mit 600 Mhz und Grafikkarte mit Unterstützung von Cubemaps ziemlich sicher flüssig und mit ansehnlicher Geometrie laufen würde.

@Spielidee:
So etwa hätte ich es mir auch vorgestellt - es ließen sich auch unterschiedliche "Zelltypen" mit unterschiedlichen Texturen versehen, die bei einer Verschmelzung übergeblendet werden (würde sicher gut aussehen), man könnte auch andere Objekte als "MetaBalls" einfügen als Kugeln (z.B. Zylinder, eigentlich alle Oberflächen, die sich parametrisch beschreiben lassen, natürlich sind Kugeln am Einfachsten).

Also wenn das Ganze noch etwas konkretisiert wird, und auch andere als ich Interesse an so etwas haben (ich kenne meine Grenzen, und weiß z.B. dass ein von mir entworfenes User Interface ziemlich technisch, um nicht zu sagen phantasielos, aussehen würde ), bin ich gerne bereit in der Hinsicht auch etwas zu machen.

Wer also Vorschläge bezüglich eines konkreten Spiels hat, bzw. auch bereit ist selbst etwas beizusteuern (Vorschläge für Codeoptimierungen, Ingame-Grafiken, Sounds, Musik, Leveldesign, eine Hintergrundstory möge dies hier posten, vielleicht schaffen wir es ja tatsächlich, etwas Vorzeigbares (und Spielbares) auf die Beine zu stellen (Ansonsten bin ich mit GLife auch so zufrieden, wie es ist).
Ich denke so etwas ließe sich mit absehbarem Aufwand realisieren, zumal man, neben einem guten Spielprinzip, grafikmäßig tatsächlich nur ein User Interface und Texturen erstellen müsste, das extrem aufwändige Design von Spielfiguren würde entfallen.
Um die KI müsste man sich auch nicht allzugroße Sorgen machen, da sich diese aus dem zellularen Regelwerk automatisch ergibt - um so größer ist aber die Anforderung an den Leveldesigner, herausfordernde und lösbare Aufgaben zu stellen. Wenn das Ganze noch in eine tolle Hintergrundstory verpackt wird, hätte man etwas, das ich mir z.B. ohne zu Zögern im Laden kaufen würde (und sei es nur, weil es wirklich mal was ganz anderes ist).

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

Interessantes Programm und durch die Metaballs sind die Quadrate nicht nur einfache Punkte sondern lebende Zellen, die pulsieren und atmen. Die beiden Texturesets Fleisch und Grün machen auf jeden Fall Sinn, weil es ich ja auch um Pflanzenzellen handeln könnte. Für 2 Tage ist das auf jeden Fall eine Menge. Hast du die Metaballs auch so schnell gemacht? In der Datei steht jedenfalls das Datum von gestern.
Die Idee mit den Zellkulturen als Spiel ist gar nicht schlecht, weil es das in der Form noch nicht gibt. Vielleicht muß man sich da nicht strikt an das Original halten, sondern könnte auch mal Zellen in einem dreidimensionalen Netz ausprobieren.
Eine andere gute Verwendung wäre vielleicht ein Bildschirmschoner, der das Wachsen und Sterben der Zellen darstellt.

Die MetaBall Klasse habe ich gestern geschrieben - das war allerdings keine so große Leistung, weil ich mich, wie gesagt, an folgendem Artikel und Beispielcode von Nuydens orientiert habe:
http://www.delphi3d.net/articles/printarticle.php?article=metaballs.htm (der übrigens seinerseits wiederum irgendein anderes Programm zur Vorlage hat ).
Es blieb mir aber nicht erspart, mich dennoch mit der genauen Funktionsweise der marching cubes auseinanderzusetzen, weil Nuydens Code weder perfomant noch flexibel ist (was bei Beispielcode aber kein Manko ist, der soll vielmehr leicht verständlich sein) und ich auch die Option haben wollte, korrekte Normale generieren zu lassen.
Eigentlich gebührt die "Ehre" für den verwendeten MetaBall Algorithmus Paul Bourke (glaube ich), dessen vorberechnete Edge- und TriTable Tabellen dem marching cubes Algorithmus erst Beine machen (die Normale an einem bestimmten Punkt der Oberfläche zu berechnen ist kein Problem, diesen Punkt zu erhalten hingegen schon - deswegen werden die marching cubes überhaupt erst benötigt).

@Bildschirmschoner: prinzipiell kein Problem, wenn ich mich recht besinne, sind .scr Dateien ja ganz normale .exes. Ob der Bildschirm (und die CPU) allerdings tatsächlich geschont würde, bleibt zu bezweifeln (bei mir geht der Monitor immer in den StandBy Modus).
Ich werde das aber auch mal im Auge behalten, prinzipiell könnte man ja auch auf zufälliger Basis Bilder aus dem Windows Verzeichnis als Texturen laden und alle paar Minuten die "Welt" neu kolonisieren.
Ich müsste mich allerdings erst kundig machen, wie die Schnittstelle zwischen Windows und Bildschirmschoner genau funktioniert, schließlich sollte er ja auch in den Bildschirmeigenschaften konfiguriert werden können

@Dreidimensionales Netz: ein sehr interessanter Vorschlag, allerdings würde dies bedeuten, dass noch mehr Objekte verwaltet werden müssen - auch stellt sich die Frage, wie man am zweidimensionalen Monitor den Überblick über das Ganze behält.
Ich erinnere mich noch gut an Homeworld (gigantisch gutes Spiel), die "echte" 3D-Steuerung war am Anfang für mich ziemlich gewöhnungsbedürftig (obwohl sie nach einer Weile richtig intuitiv wird), hier bestand aber ein Großteil des Levels aus leerem Raum, bei einem Life Spiel, wäre dieser mit Zellen befüllt - ich hätte dann das Problem, dass man irgendwie den Überblick über die ganze Welt behalten müsste.

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

@GLife :
Ich muss mir erstmal den Sabber vorm Mund wegwischen bevor ich hier was schreiben kann
Mit dem Texturenblending und der mitwandelnden Skybox sieht das Ganze jetzt ja noch ne Ecke besser aus und der Preis für die graphisch am besten ausgearbeitete Life-Simulation dürfete dein Programm garantiert einheimsen.Schneller laufen tuts auf meinem Rechner jetzt auch,der liegt allerdings über den Minimalanforderungen.

@Spielidee :
Die Spielidee ist auf jeden Fall interessant und auch wert umgesetzt zu werden und ich würde es auf jeden Fall spielen.Denn zusammen mit den pulsierenden Metabällen und den ineinander übergehenden Zellen würde am Ende eine so dynamische Spielumgebung stehen,wie man sie bisher in Spieletiteln eher selten zu Gesicht bekommt.
Die Schwierigkeit dabei besteht dann allerdings darin,den Spieler NICHT zu überfordern,was besonders bei großen Zellkolonien schwierig werden dürfte.Da wäre es evtl. gar keine so schlechte Idee die Zellen des Spielers mit einer KI zu auszustatten,die insofern autark ist als das sich die Zelle ohne "Aufpasser" nicht direkt in den Tod stürzt.
Die Sache mit den Boni ist auch sehr gut und kann das Spiel im richtigen moment noch umstürzen.Was auch noch ein toller Bonus wäre,wäre z.B. sowas wie ein Antiobiotikum,das einige Zellen für kurze Zeit unverwundbar macht,so dass diese quasi für einen schnellen Vorstoss genutzt werden können.Auch in Sachen Forschung kann man bei einer solchen Spielidee recht viel machen,u.a. härtere Zellhaut,verbessertes Wachstum,stärkere Attraktoren,usw.
In Sachen Story könnte man auch was tolles basteln.Wie wärs z.B. wenn das Spiel in einem von Krankheiten befallenen Körper (ob Mensch oder Tier ist egal) spielt (und dann könnte man evtl. sogar das Innere des Menschen als Skybox nehmen) und der Spieler am Anfang nur kleine Wunden vor dem Eindringen von Bakterienkulturen beschützen muss und sich langsam zu den wichtigen Organen hocharbeitet,wodurch auch die Level komplexer werden.Am Ende findet dann quasi der "Endkampf" mit dem Bakterienboss im Herzen statt.
Kurz gesagt : Aus GLife lässt sich garantiert ein interessantes Spiel machen und ich wäre definitiv eine der Personen die es Spielen würden.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Bei mir ist es auch um einiges schneller geworden. Die Idee mit den mehrfarbigen Zellen ist gut. Ich konnte beobachten wie eine blaue Zelle eine grüne Zelle angegriffen hat und daraufhin von einer anderen grünen Zellen aufgefressen wurde. Gut zu wissen, daß Assembler an den richtigen Stellen immer noch so viel bringen kann. Im NV_vertex_program2 gibt es bedingte Sprünge. Beim normalen Vertex Program könntest du eventuell immer die 4 direkten Randpunkte mit angeben und daraus die Normale berechnen.

Zum potentiellen Spiel:

@Spielidee: ich würde ein Spiel auf Basis einer völlig dynamischen Welt auch interessant finden - allerdings möchte ich sicher gehen, dass ich nicht gerade 'nen Tunnelblick habe, weil ich mich grad mit der Thematik beschäftige, und dann viel Arbeit in etwas investiere, das dann höchstens von akademischem Interesse ist.

@KI: ja, insbesondere in den ersten Levels, würden automatisch Regeln angewendet werden, bei denen eigentlich nicht viel schiefgehen kann.
Nach und nach ist dann der Spieler (geschlechtsneutral zu verstehen ) gefordert, für "seine" Zellen eigene Regeln zu entwickeln (bzw. aus den "erforschten" auszuwählen), mit denen die konkrete Aufgabenstellung gelöst werden kann. Wenn er das geschickt macht, spart er sich viel Plasma (für neue Zellen oder Boni), das dann insbesondere in den harten Endlevels dringend benötigt wird .

@Komplexität: das wird wahrscheinlich eine anspruchsvolle Aufgabe, die Lernkurve nicht zu steil anzusetzen - und dennoch immer etwas "Action" zu haben.

Tja, dann weiß ich wenigstens was ich machen kann, sollte mir in der nächsten Zeit langweilig werden (ist ja nicht so, dass ich sonst nix zu tun hätte...).
Zuerst mal werde ich einen Welteditor schreiben, bei dem Regeln, Modifikatoren und Spezialobjekte frei definiert werden können (muss ja selbst erst herausfinden, was interessante Aufgabenstellungen sein können). Dann muss das konkrete Spiel designt und in eine Story integriert werden (evtl. gibt es in den nächsten Wochen einen literarischen Erguss von mir in der OT-Sektion , hab' da auch schon eine Idee).
Zum Schluss brauchts dann noch ein nettes UI, Texturen, Sounds (die können in diesem Fall ohnehin synthetisch erzeugt werden) sowie evtl. Musik (weiß noch nicht, wie ich die realisiere - evtl. kann ich mit einigen stimmigen Ambient-Geräuschen Atmosphäre schaffen).
Die Story wüde ich gerne im Comicstil erzählen (eigentlich Bilder, die mit großen Textblöcken unterlegt sind) - da meine Zeichenkünste allerdings eher gering sind, sollte ich mich wahrscheinlich eher auf Ingamesequenzen beschränken (ist sicher auch lustig, diverse Zellhaufen als Akteure auftreten zu sehen ).

Die "Engine" (ja, ja...) dürfte dann ja eigentlich schon stehen (ein paar Sachen könnte ich evtl. noch optimieren, wenns "schnell genug" läuft, reicht das aber eigentlich - hier wäre noch Feedback benötigt), das Problem ist nun (wie immer) was Sinnvolles draus zu machen (immerhin brauche ich meine rudimentären Artistenfähigkeiten nicht allzusehr für Ingamegrafiken zu malträtieren, ein paar tilefähige, zellähnliche Texturen bekomme ich in einem Bildbearbeitungsprogramm grad noch zusammen - vielleicht schreibe ich auch einen Plasmagenerator, dann wären sogar animierte Texturen möglich)

Für zusätzliche Vorschläge bezüglich Spielelementen (Boni, KI, Grafik, Story) bin ich natürlich weiterhin offen (übrigens danke für die bisherigen Anregungen).


Zur Technik

@Vertexprogramme:
Die Idee ist gut - allerdings berechne ich die Normale nicht über Interpolation, sondern direkt aus der ersten Ableitung der Oberflächenfunktion.
Zuerst habe ich auch mit interpolierten Normalen herumgespielt - die sehen aber gar nicht gut aus, insbesondere reflection maps verzieht es dann grausam.
Außerdem erlaupt es mir die direkte Berechnung der Normale, die Oberfläche in Z-Rechnung viel gröber zu tesselieren, da die Z-Auflösung nun fast egal ist (die Welt wird ja direkt in Z-Richtung betrachtet), die Normale wird auf Grund der höher tesselierten X- und Y- Werte dennoch fast Vertexgenau berechnet, was den Eindruck glatter Oberflächen verschafft.
(Schalt mal den Wireframemodus ein, dann siehst du, dass die Metaballs aus gar nicht so vielen Dreiecken zusammengesetzt sind).

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