ZFX + Developia

_ _ _ _ _ ___________________________________________________________________________________________

• What is Stonequest?

Stonequest will become a game like Minecraft.
_ _ _ _ _ ___________________________________________________________________________________________

• How can you help me?

Like Stonequest on Facebook and tell your friends about it. :D
_ _ _ _ _ ___________________________________________________________________________________________

• How can I play?

___Please note_____________ _ _ _ _
You use this software at your own risk! I do not take any responsibility for damage to data or hardware!
When you install the game, a random number (DNA) will be generated. This will individualized your copy
of Stonequest. The game will update themselves automatically at startup. To do this, the DNA will be
transferred and stored. Use StoneQuest only if you agree!




You can download it from the StoneQuest HP


If you have problems to install or start this game and you match the requirements please send an email to info@stonequest.de
_ _ _ _ _ ___________________________________________________________________________________________

Tja, nun ist es wirklich soweit... ich habe es ja hier des öfteren angekündigt, neu anzufangen, habe es aber dann doch nicht getan. Aber diesmal werde ich es konsequent auch tun... nach nunmehr über 2,5 Jahren... die letzte Engine-Iteration habt ihr ja von Anfang miterlebt...
Und da es mir extremst an Motivation mangelt, schreibe ich jetzt hier, um wenigstens irgendwo das Gefühl zu haben, dass da jemand ist, der auf mich zählt und den ich nicht enttäuschen möchte.

Es ist echt mist... früher, vor Ausbildung und Studium, da war ich so frei, was das programmieren angeht... ich habe konsequent alles so gemacht, wie ich es mir dachte und kam auch immer gut vorwärts... aber nach und nach habe ich mich immer mehr davon verleiten lassen, bei jedem Schritt zu überlegen, macht es Sinn, ist es auch in Zukunft wartbar und sinnvoll...
Wie auch immer... das hier ist heute abermals der Anfang... und nach bald 12 Jahren würde ich noch weniger davon ausgehen, dass es fertig wird, was auch nicht gerade motiviert...

Ich werde diesen Thread nutzen, um euch auf den laufenden zu halten... vielleicht komme ich ja diesmal weiter...

Viele Grüße

PS: Diesmal weder Klassen (außer wo ich es wirklich brauche), Patterns, oder sonst irgendwelche komischen Dinge... und diesmal werde ich auch nichts versuchen, polymorphisch zusammenzuziehen ( was ich eh ohne klassen nicht kann ) sondern alles schön per Hand proggen und dann mal sehen, was da raus kommt...
Und Anfangen tue ich mit der größten Bestie, die mich dann das letztemal getötet hat... MULTITHREADING!!!

Ja, ich freue mich darauf, die letzten Bilder sahen schon recht gut aus.
Ich kenn das, wie es ist, wenn man ständig von vorne anfängt und sich vornimmt, es diesmal wirklich durchzuziehen. Ich glaube, manchmal muss man einfach mit dem zufrieden sein, was man aktuell hat und damit das Projekt zuende stellen, sonst wird man nie fertig :D

Oje. Wozu brauchst du eigentlich Multithreading?

Soweit ich das mitbekommen hatte, war die Geometrieerzeugung (und vor allem die Glättung der Blöcke) viel zu wechsellaunig was ihren Bedarf an Rechenzeit angeht, um sie im selben Thread wie die Spiellogik durchzuführen.

Also z.B. eine Sekunde pures Rendering, dann kommt ein neuer Block ins Blickfeld und schon muss hart gerechnet werden; zu viel für einen einzelnen Frame; die Arbeit lässt sich nicht gleichmäßig aufteilen, also schwankt die Framerate extrem; die neuen Daten müssen dann auch noch auf die GPU und der Benutzer sollte von alldem am besten nichts mitkriegen.

Eigentlich ein optimaler Einsatzzweck für Multithreading – Delphi unterscheidet jedoch zwischen puren Datenstrukturen und Objekten, und letztere verursachen bei der Erzeugung ein globales Sperren der Anwendung. Dadurch hakte die Anwendung stark, sobald die Geometrieerzeugung loslegte. Nun möchte Zudo es komplett ohne Objektorientierung realisieren, um dieses Problem zu umgehen.

Und in der neuen Anwendung scheine ich das Multithreading in den Griff zu bekommen... auf den anderen Kernen der CPU ( sofern vorhanden ) werden nun Nurbs-Flächen berechnet. Im Hauptthread werden die dann vorsichtig immer in kleinen Schritt in den Vertex- und Indexbuffer übertragen. ( Denn wenn der ganze große Buffer gelockt und die Daten komplett übertragen werden, spürt man wieder ein ruckeln )
Im Moment schlage ich mich mit den Buffern rum, so das die die Daten verwalten. Damals hatte ich ja einfach jedes Objekt in einem separaten VB und IB gepackt. Aber soweit ich weiß, ist ein größere Buffer ja besser. Vor allem muss dann auch nicht zur Laufzeit speicher allociert werden.

Ich gebe zu, es ist gar nicht so einfach, nicht nur soweit wie möglich in den Workerthreads auf Klassen zu verzichten, sondern auch komplett auf dynamische Arrays... aber ich glaube, das bringt im Endeffekt dann auch nochmal gut Speed.

Was bleibt noch? Achja, ich ernenne Krishty zu meinem offiziellen Pressesprecher! Wer so kompetent Antwortet, kann es nur verdient haben!! Danke Krishty! :D

Klingt nach dem Weg in die Hölle.

Ja, schon mal über ne andere Programmiersprache nachgedacht? C++ kannst du doch auch und wenn das keinen Spaß macht gibt's doch bestimmt noch viele andere Alternativen.

Offtopic: Glückwunsch zu deinem 1800. Beitrag, Chromanoid :P

Als eine mögliche Alternative könnte man auch Java (*duck*) verwenden. Vorallem mit den neuen Konzepten und Erweiterungen, die mit Java 7 Einzug gefunden haben.

Tejio hat geschrieben:Als eine mögliche Alternative könnte man auch Java (*duck*) verwenden.

Soweit ich gehört habe, soll der Garbage Collector von Zeit zu Zeit global sperren … kA, ob das in Java 7 noch so ist. Falls ja: Regen => Traufe.

Mein persönlicher Senf: Falls ich Probleme mit dem Erfüllen der Echtzeitanforderung meines Systems hätte, wären die letzten Sprachen, zu denen ich wechseln würde, managed.

Wenn man es klug anstellt sollte man das ohne GC Aufruf hinbekommen. JBullet (Java Port von Bullet Physics ) benutzt zum Beispiel Object Pooling. Mithilfe der Möglichkeit kompilierte Klassen nachträglich zu verändern, hat der Portierer eine einfache bequeme Möglichkeit dazu entworfen. Zum Einen kann man mit Stack.alloc(Klasse) Objekte für die Methode aus einem Objektpool holen und zum anderen mit der Annotation @StaticAlloc alle Variablen einer Methode, die eigentlich mit Stack.alloc geholt werden in statische Variablen umwandeln (für Singlethread Zugriffe). Damit sollte man einen Großteil der Objekte, die so nebenbei anfallen, umgehen können. Aber das ist natürlich trotzdem keine optimale Lösung.
Wie dem auch sei, es sollte so oder so wesentlich seltener stocken, da Objekterstellung nicht wie bei Delphi das komplette Programm behindert. Insgesamt ist Java und Co. ziemlich bequem wenn es um Multithreading geht. Wenn man Java nicht mag könnte man es ja mal in Scala, Groovy oder Clojure probieren. Alle dieser Sprachen erheben den Anspruch weniger Code als Java zu benötigen. Man munkelt, dass Clojure am wenigsten Code benötigt...

C++ ist sonst natürlich auch noch da...

Und es geht weiter!!!!! :D

Der erste offizielle Screen!

Es wird noch nichts im Hintergrund erstellt und die Welt beschränkt sich noch auf diese kleine Höhle...

Irgendwie wird alles immer krasser. Ich bereue nicht, neu angefangen zu haben. :D :D :D

Gratulation :)

Sehr schön! Wie hast du die kontinuierliche Texturierung gelöst? 3D-Textur? Projektion aus mehreren Richtungen mit Normal-abhängiger Überblendung? Oder noch was schlaueres? ;-)
Am Höhlenrand (links und rechts) sieht die Textur in der Vertikalen noch etwas gestreckt aus, hängt das damit zusammen?

CodingCat hat geschrieben:Projektion aus mehreren Richtungen mit Normal-abhängiger Überblendung?

ist richtig

CodingCat hat geschrieben:Am Höhlenrand (links und rechts) sieht die Textur in der Vertikalen noch etwas gestreckt aus, hängt das damit zusammen?

Könnte man das auf einen einfachen Weg in den Griff bekommen? Bei Splitterwelten sind solche Verzerrungen auch zu sehen.

Möglicherweise durch mehr Projektionsrichtungen mit etwas schärferen Übergängen. Damit dir dabei die Texture Lookups nicht hundertfach um die Ohren fliegen, müsstest du allerdings eine schlaue Formel finden, die dir immer nur drei bis vier "benachbarte" (Im Winkelsinne) Projektionsrichtungen zur Überblendung liefert.

CodingCat hat geschrieben:Möglicherweise durch mehr Projektionsrichtungen mit etwas schärferen Übergängen. Damit dir dabei die Texture Lookups nicht hundertfach um die Ohren fliegen, müsstest du allerdings eine schlaue Formel finden, die dir immer nur drei bis vier "benachbarte" (Im Winkelsinne) Projektionsrichtungen zur Überblendung liefert.

Daran hatte ich auch schon gedacht, aber bisher ist mir noch nicht in den sinn gekommen, gezielt bestimmt Richtungen auszuwählen... aber vorerst werde ich das nach hinten schieben... oder stören die Artefakte es so extrem?

Habe gerade noch einen Occlusionfaktor für die Katen eingabaut, so wie man des schon in vielen Clones gesehn hat.

Hier ist mal nur der Lightpass:

Ich halte euch einfach mal hier immer weiter auf dem laufenden...

Im Moment habe ich mir gedacht, ich unterteile das mal in kleine Clusterabschnitte. Dabei fand ich diesen Thread über Voxel sehr interessant.

@Schrompf

Schrompf hat geschrieben:Oder sei es die Anwendung eines gängigen Volumen-Zu-Oberfläche-Algorithmus wie z.B. Marching Cubes. Letzteres tut ja zum Beispiel Zudomon, wenn ich mich recht erinnere.

Mein erster Versuch war mit Marching Cubes. Aber bin dann direkt am ersten Tag noch dazu übergegangen, lieber Boxen zu generieren, die anschließend subdivided wurden.

Interessant finde ich, das bei Minecraft, so habe ich das aus dem anderen Thread entnommen, jeweils immer eine Säule generiert, da die Höhe ja auf 128 Blöcke begrenzt ist.
Das würde auch bei mir vieles einfacher machen. Aber ich weiß nicht ob mir das letztendlich gefällt. Ich mag es, in jeder Richtung schirr Unendlichkeit zu haben.

Es wäre gut, wenn ihr Ideen und Anregungen habt, die ich dann eventuell umsetzen würde, mitteilt. Vor allem jetzt am Anfang sind die Anforderungen ja noch relativ offen.

So siehts bei mir im Moment aus. Die Clusterübergänge werden noch falsch berechnet... darum werde ich mich jetzt kümmern...
PS: Was haltet ihr davon, wenn ich versuche, meinen Thread über das Projekt möglichst aktuell zu halten? Mit Fehler, Ecken und Kanten, nicht nur schöne Final Screenshots? Mich würde das hoffentlich anspornen...

Ich finde es sehr schön, dass du deinen Fortschritt so oft postest. Zu den Säulen: mit etwas mehr Aufwand sollte es doch auch möglich sein, Cluster in beliebige Richtungen (also auch nach oben) aneinanderzusetzen?

CodingCat hat geschrieben:Ich finde es sehr schön, dass du deinen Fortschritt so oft postest.

Ich auch.
Ich fände gut, wenn die Volumenklumpen selbst auch transformiert werden können und wenn möglich natürlich auch tatsächlich gedreht und dann mit anderen Klumpen verschmolzen werden können. Habe ich ja schon in meinem Himmelsinsel-Vorschlag angedeutet... Reines achsenorientiertes verschieben auf Blockebene ist natürlich auch ok.

Okay, das mit den Clusterrissen war dann doch schnell zu finden... wenn man genau hinschaut kann man an ein paar Stellen immer noch Übergänge sehen. Denn es ist schon LOD drin. Und da treffen eben unterschiedliche Detailstufen aufeinander... ich glaube aber, darum werde ich mich jetzt noch nicht kümmern. Vorerst möchte ich, dass die Welt größer wird...
Und mal einmal im Wireframe, da sieht man dann schon ein wenig vom LOD...
Aber ich muss bald was gegen die Steine tun... die machen mich depressiv :(

*Motivierende Zurufe* :D

(BTW: Ich freue mich auch immer wieder wenn ich was neues in diesem Thread lesen kann^^)

Ich weiss nicht genau, wie du die Hoehlen erzeugst, aber bevor ich das Wireframe Bild sah, dachte ich es waeren wesentlich weniger Polys. Seit dem frage ich mich, obs nicht irgendwelche tollen Algorithmen gaebe, mit denen man noch viel coolere Genometrie erzeugen koennte. Momentan siehts naemlich echt etwas nach abgelutschten Minecraft aus. Ansonsten aber wohl schonmal ne gute Technik, aus der man was machen koennte.

TGGC hat geschrieben:Momentan siehts naemlich echt etwas nach abgelutschten Minecraft aus.

Du musst aber beachten, dass ich keine Demo machen möchte, sondern es ein Spiel werden soll. Ich kann mir im Moment nicht vorstellen, was man da anderes machen könnte, als das Blocksystem... außer vielleicht detaillierte Voxel... aber ich komme ja so schon nicht mit der Menge klar... da wäre eine detailliertere Voxelauflösung mein sicherer Tod...

Aber falls dir was einfällt...

Ich fände es schon sehr schön, wenn man weniger von den Blöcken sehen würde. Bei Minecraft war es halt ein minimalistischer Stil, aber bei dir sieht es ziemlich merkwürdig aus, einerseits viele Polygone zu haben, aber andererseits deutlich Würfel erkennen zu können.
Wie wäre es denn, über mehrere Blöcke eine Art Steigung zu berechnen und daraus dann das Highpolymodel zu berechnen? Oder irgendetwas Bezierflächen ähnliches über die Blöcke zu legen. Da müsste man halt etwas experimentieren, dass es einerseits schön rund aussieht, andererseits aber beim modifizieren nicht seltsam wirkt, wenn sich ne ganze Menge drum herum auch ändert.

Ansonsten könnte man vielleicht einen ganz anderen Ansatz wählen. In Red Faction konnte man damals ja auch Höhlen Bomben, eigentlich erstaunlich, dass man das bisher in so wenigen Spielen gesehen hat.

Jonathan hat geschrieben:Ich fände es schon sehr schön, wenn man weniger von den Blöcken sehen würde. Bei Minecraft war es halt ein minimalistischer Stil, aber bei dir sieht es ziemlich merkwürdig aus, einerseits viele Polygone zu haben, aber andererseits deutlich Würfel erkennen zu können.
Wie wäre es denn, über mehrere Blöcke eine Art Steigung zu berechnen und daraus dann das Highpolymodel zu berechnen?

Bei dem alten hatte ich das ausprobiert, die Flächen schön rund zu machen... so, dass man keine Treppenstufen mehr sah. Allerdings wirkt dass dann alles etwas seltsam, sobald man anfängt, da dran rum zu werken. Da man dann keine einzelnen Würfelseiten mehr erkennt.
Vom Stil her gefiel mir das alte eigentlich recht gut. Gerade durch die Stufen. Wobei dass auch nicht so schön ist, sobald man gerade Wände haben möchte, muss ich ja auf die Blockform zurück, außer ich wähle einen ganz anderen Ansatz.

Tja, im Moment weiß ich einfach nicht. Vor allem stelle ich fest, dass ich dieses extreme Detail wohl auf dauer nicht halten kann... aber naja... welches Spiel verwendet zurzeit auch echte Displacementmaps?!

Red Faction, hmm, da sind keine Voxel hinter. Die schneiden NUR (<---- dieses nur hat mich schon Monate an Arbeit gekostet und ich ab es nicht fehlerfrei hinbekommen ) die Geometrie.
Im Moment bin ich etwas ratlos, was der beste Ansatz wäre. Auf jeden Fall muss ich die Welt flacher machen... ^3 wächst einfach zu schnell.

Also mir gefällt der Stil von schon ganz gut so. Und ich denk, wenn das Spiel blockbasiert sein soll, ist es gut, dass man die Blöcke erkennen kann. Ansonsten würde man sich beim Drin-rumgraben wohl sehr schwer zurechtfinden.

Auf technischer Ebene würd ich mal meinen das Spiel ist ein idealer Kandidat für den Einsatz von Tesselation ;)

dot hat geschrieben:Auf technischer Ebene würd ich mal meinen das Spiel ist ein idealer Kandidat für den Einsatz von Tesselation ;)

Da hast du recht. Allerdings gibs Tesselation er ab DX10. Aber ich lass mir schon was einfallen ;)

Nach ner kurzen Nacht ist auch wieder die Motivation da... :D

Ich hatte das Renderfenster beim skalieren beschränkt. Es kann zwar klein und groß gezogen werden, aber das Seitenverhältnis wird immer auf mindestens 4/3 und maximal 16/10 angepasst. Dadurch kommt ein etwas seltsames Verhalten mit der Maus zustande, weil das Fenster, je nachdem wie man es zieht, ja eine unerwartete Größe an nimmt. Wollte so vermeiden, dass beim anderen Seitenverhältnis die 3D-Linse übermäßig groß wird.
Was haltet ihr davon, ohne es nun selbst testen zu können?

Manchmal bin ich erstaunt, wie sich unter bestimmten Bedingungen alles nahtlos aneinander fügen lässt!! :o

Und zwar:
Jeder Fläche eines Würfels besteht aus einer Bezier-Fläche mit 9 Kontrollpunkten... also 3 x 3. Jeder der Kontrollpunkte hat nicht nur eine Position, sondern auch eine Normale. Die ist nötig, um die Bezierflächen vom Licht her nahtlos aneinander zu fügen. Also müssen diese Normalen gesmoothed sein. Also habe ich mir gedacht, erstelle ich ein 3D Array ( später werde ich das auf 1D runterbrechen, zwecks Optimierung ), welches doppelt so groß ist, wie das zu betrachtende Cluster. Hier wird nun jede Fläche, die Sichtbar ist eingefügt bzw. dessen Normale eingetragen. Dies geschieht über einen Integer-Wert ( Bit Operation, da es ja nur 255 Fälle geben kann ). Aus diesem wird später die Normale bestimmt. Das Grid um alle Punkte zu erfassen muss doppelt so groß sein, wie das Cluster ( von der Kantenlänge her ).
Nun dauert es auch recht lange, bei jedem Voxel zu bestimmen, ob ein Block überhaupt existiert. Dazu müssen ja bei einem 64³ Cluster schon 262.144 Voxel ( sogar noch mehr, weil ich Ränder beachten muss ) geprüft werden. Dazu wiederum muss muss ein 3D-Plasma berechnet werden, sprich, da interpoliert ( oh, da fällt mir just in diesem Moment ein, auch das könnte man eventuell noch cachen ), 2 x 2 x 2 = 8 Stützpunkte. Und da bei dem Plasma 8 Oktaven einfließen, wären es dann 262.144 * 8 * 8... also schon 16 Millionen Zufallswerte, die berechnet werden müssen. Jetzt muss aber bei jedem Voxel der betrachtet wird, dessen Nachbarn auch geprüft werden, denn nur wenn diese Luft sind, muss eine Fläche generiert werden.
Dafür hatte ich nun die Voxel gecached. So dass nicht bei jeder Nachbarprüfung gleich wieder alles berechnet werden muss.
Nun nochmal zurück zu den Normalen. Da das Grid doppelte Größe haben muss, kommen auf jeden Voxel, 8 Gitterpunkte. Selbst wenn nun jede Fläche ihre Normalen speichert, so sind nur maximal 7 der 8 Punkte belegt. Eigentlich Effizient genug. Aber dreister weise kann man nun ja den cache Wert für die einzelen Voxel ( für die schnellere Nachbarschaftsprüfung ) genau in diese freie Stelle schreiben.

Also habe ich nun die beiden separaten Arrays miteinander verschränkt und es funktioniert. So sind alle Plätze im Array sinnvoll genutzt. :D

550 ms braucht nun übrigens besagter 64³ Voxelblock. Bevor ich da rumoptimiert habe waren es über 2 Sekunden.