ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4396697
Jetzt (Chat):
19 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-
"Neues von den Splitterwelten" von Thomas Schulze (Schrompf)


Da sich technisch wie grafisch in letzter Zeit einiges am Projekt getan hat, wird es mal wieder Zeit, auch neues Material davon zu präsentieren. Auf dem Bild sieht man eines der weniger knuddeligen Monster, einen Cruhl. Der Cruhl ist das Werk von Christian, einem Teil unserer inzwischen erfreulich angewachsenen Grafiker-Schar. Der Cruhl besteht aus 7500 Dreiecken und einer 2048er Normal Map, die ursprünglich aus einem 1,5Millionen-Poly-Mesh berechnet wurde. Eigentlich bevorzugt er nasse und dunkle Höhlen, aber für diesen Screenshot haben wir ihn mal ans helle Sonnenlicht gezerrt.

Splitterwelten macht weiterhin stetig Fortschritte. Die Jägerhütte links im Bild besteht aus 21.000 Polys und ist das Werk von Alex, einem anderen unserer Helden der Grafik. Für den mönströsen Polycount der Szene ist aber primär der neue Bewuchs verantwortlich, für den unser Leitgrafiker Michael die Instancing-Fähigkeiten der Engine ausgenutzt hat. Diese Szene rendert aber zu meiner Überraschung selbst auf älteren Grafikkarten noch erstaunlich schnell. Einzig die CPU-Belastung für die Mengen an DrawCalls bereitet uns noch Sorgen.

An der Programmiererfront hat sich neben dem üblichen Schwung an Bugfixes, Detailverbesserungen und Optimierungen inzwischen auch einiges an Gameplay ergeben. Neben der Fähigkeiten der letzten Veröffentlichung, Dinge einzusammeln, Türen zu öffnen, mit Leuten zu reden und Quests zu lösen, ist seitdem auch ein vollständiges Inventar hinzugekommen, in dem man Gegenstände umstapeln, anwenden oder mischen kann. Zudem werden nun die Charakterwerte mitgerechnet und die Anfänge des Kampf- und Bewegungssystems erlauben es, harmlose Wusons zu verdreschen, zu vergiften oder mit dem Testzauberspruch die Landschaft leerzufegen.

Zum Schluss noch eine schlechte Nachricht: die für Ende diesen Jahres angedachte Demo werden wir wieder mal nicht halten können. Da wir seit neuestem auch richtige Projektplanung betreiben, wissen wir leider sehr genau, woran es hängt: Charaktergrafiken. Falls jemand von Euch Interesse hat, einem wachsenden Rollenspiel zum Leben zu verhelfen, und uns bei der Erstellung von Charakter-Modellen und -Animationen unterstützen kann, möge er/sie sich bitte bei mir melden. Wir würden eure Hilfe wirklich zu schätzen wissen.

Vielen Dank für eure Aufmerksamkeit.






Von Aramis am 07.10.2008, 10:50:30 Uhr
Juhu! Es gibt ein neues Bild des Milleniums :-) Kommentar zum Bild ist wohl überflüssig, sieht klasse aus. Leicht störend ist imho der Himmel, aber das hörst du ja nicht zum ersten Mal. Ebenso kennst du auch meine Meinung zum Cruhl und zu Teilen seines Körpers schon ...

Gruß,
Alex

Von Godhand am 07.10.2008, 10:55:48 Uhr
Ganz großen Respekt für diese Leistung!

Allerdings entdeckt der geschulte Grafikprogrammiererblick sofort die Artefakte bei der Shadowmap am Bauchbereich des Monsters ;)

Der Himmel sieht schon ganz gut aus, aber für die Verhältnisse zu blau. Eventuell helfen dir dabei die (mittlerweile zahlreich) gewordenen Paper bzgl. Athmospheric Rendering und Krishtys Sternrenderingartikel weiter ;)

Die Szene wirkt noch zu wenig plastisch, eine SSAO-Implementierung könnte da möglicherweise Wunder wirken! Außerdem ist da ein optischer Widerspruch zwischen (relativ) dunklem Himmel und (relativ) hell beleuchteten Vordergrundobjekten zu sehen.

Macht weiter mit der guten Arbeit! ;)

Von Krishty am 07.10.2008, 11:22:27 Uhr
Also, das sieht super aus. Wenn noch ein HUD dabei wäre würde ich mich sofort wie in S.T.A.L.K.E.R. fühlen :D

Ganz besonders der Content begeistert mich. Vertexdetails sieht man heutzutage viel zu selten, allzu oft wird alles auf die Normalmaps geschoben. Und das hasse ich wie die Pest. Polygone ftw!

Der Bodenbewuchs ist erstklassig. Kann locker mit Crysis mithalten, ganz im Ernst!

Nun zu dem was mich stört: Ich dachte das würde nur ich so sehen weil ich mich ziemlich intensiv mit der Thematik beschäftige, aber meine Vorredner haben es jetzt auch schon angesprochen: Der Himmel passt einfach nicht. Sterne sieht man am hellichten Tag nicht, der Himmel ist zu dunkel und die Wolken müssten bei solchem Sonnenschein fast ausschließlich grellweiß sein, sind aber mittelgrau.

Und dann noch zwei Dinge zur Bildqualität: Ich weiß nicht was für Hardware zur Verfügung stand, aber wenn ich Screenshots mache drehe ich Antialiasing und anistrope Filterung voll auf. Gerade die Texturen der Bäume und Büsche werden dann auf Distanz nicht undurchsichtig und die Texturen wirken nochmal eine Klasse besser.

Und bitte fang an deine Screenshots als PNG zu speichern, (ich weiß nicht ob das dein Fehler war oder der der Admins, aber) die Bildqualität gerade bei so hochfrequentem Bildinhalt wie Bewuchs bleibt dann voll erhalten.

So, auch wenn die Kritik von der Textlänge her überwogen hat (ist ja leider meistens so), noch zum Abschluss, dass mein Eindruck sehr positiv ist. Wenn ein Team so weit gekommen ist und das Projekt nicht wie 95% der anderen seit der Terrainrendering-Demo flach liegt und dazu noch so gut aussieht ist das was worauf man stolz sein kann!

Von Schrompf am 07.10.2008, 13:56:40 Uhr
Danke für die netten Worte :-) Es ehrt mich auch, nach wievielen Jahren jetzt wieder das erste IOTW zu sein, aber es kommen sicherlich bald weitere.

Der Himmel sieht in der Tat ziemlich fad aus. Das ist uns bewusst und auch momentan in Arbeit. So, wie er momentan aussieht, ist er im PixelShader entstanden. Eine korrekte CubeMap mit sinnvollem Sternenhintergrund und dem Splitterwelten-eigenen Content rundrum wird noch folgen. Der ursprüngliche Gedanke war ja, dass das Gesamtsystem der Splitterwelten wie der Saturn aussehen sollte: in der Mitte ein Gasriese und rundherum Ringe, davon in unserem Fall manche bewohnt. Demzufolge ist die Athmosphäre unten viel dichter und nach oben sieht man auch tagsüber Sterne. Ist allerdings bisher bei den Testbetrachtern nicht so gut angekommen, weswegen wir wahrscheinlich auf eine normale erdähnliche Atmosphäre ausweichen werden.

Und ja, der Cruhl hat im Buchbereich Schattenprobleme. Wir streuen die PCF-Samples pseudozufällig anhand der Texturkoordinaten, weswegen es zu solchen Moiree-Mustern kommt. Das wird noch verbessert.

Das "Terrain" ist übrigens keine Height Map, sondern ein segmentierter Freiform-Mesh. Kann man z.B. auf dem Spinnen-Screenshot erkennen. Den und noch ein paar mehr Bilder gibt aus auf unserer Webseite unter http://www.dreamworlds.de

Was die Qualitätseinstellungen angeht, haben wir da wirklich was verpasst. Anisotropische Filter würden an einigen Stellen hier Wunder wirken. AntiAliasing wird allerdings noch nicht mal unterstützt... ich habe mich noch nicht an das Thema rangetraut :-) Ich brauche irgendeine AA-Umsetzung, die auf jeder PS2-Hardware ohne Hacks funktioniert und nach Möglichkeit HDR unterstützt... ich dachte an ein 16Bit-Festkomma-Rendertarget, aber ausprobiert habe ich es noch nicht.

SSAO ist eventuell angedacht, aber wenn, dann sehr viel später. Unsere Aufgabenliste ist jetzt schon sehr lang :-) Genauso würde ich gern den SH-Lookup in den PixelShader schieben und dem Terrain Per-Vertex-SHs geben... das könnte das indirekte Licht deutlich interessanter machen. Aber auch das sind grafische Spielereien, die erstmal warten müssen, bis das Gameplay in trockenen Tüchern ist. Und das wird noch ein paar Monate dauern :-/

Nuja, Danke nochmals für die Kommentare. Wir melden uns wieder, wenn es was Spielbares gibt.

Von Krishty am 07.10.2008, 19:22:33 Uhr
Zitat von Schrompf:
Der Himmel sieht in der Tat ziemlich fad aus. Das ist uns bewusst und auch momentan in Arbeit. So, wie er momentan aussieht, ist er im PixelShader entstanden. Eine korrekte CubeMap mit sinnvollem Sternenhintergrund und dem Splitterwelten-eigenen Content rundrum wird noch folgen. Der ursprüngliche Gedanke war ja, dass das Gesamtsystem der Splitterwelten wie der Saturn aussehen sollte: in der Mitte ein Gasriese und rundherum Ringe, davon in unserem Fall manche bewohnt. Demzufolge ist die Athmosphäre unten viel dichter und nach oben sieht man auch tagsüber Sterne. Ist allerdings bisher bei den Testbetrachtern nicht so gut angekommen, weswegen wir wahrscheinlich auf eine normale erdähnliche Atmosphäre ausweichen werden.
Das Problem ist ja nicht dass die Atmosphäre nicht dicht genug ist, sondern dass die Sterne viel zu hell sind. In Wirklichkeit sind sie einige tausend mal schwächer als der Taghimmel und es bedarf einigem Tonemapping, dass sie nachts erkennbar sind und tagsüber nicht. Das lässt sich aber sehr leicht faken, indem man die Helligkeit des Hintergrundes mit dem Tagesablauf regelt, so dass er tagsüber komplett schwarz ist. Wenn man von Mond zu Mond reisen soll, kann man die Höhe des Betrachters miteinkalkulieren. Dabei sollte man aber beachten, dass der Mutterplanet mit voller Intensität angestrahlt wird und weiterhin tausendmal heller leuchtet als die Sterne. Wenn man es genau nimmt, muss man ihn fast wie eine zweite Sonne, nämlich als Lichtquelle behandeln.

Noch ein Wort zum Realismus: Monde können nur in einer gewissen Distanz kreisen, wenn sie diese unterschreiten werden sie üblicherweise durch die Gezeitenkräfte zerrissen und ihre Trümmer zu Ringen. Darum sieht es in der Nachbarschaft von Gasriesen garnicht mal sooo spektakulär aus. Hier ein Mond mit erdähnlicher Atmosphäre bei Sonnenuntergang, der Jupiter in etwa in Ios Distanz umkreist:
http://img227.imageshack.us/img227/162/20080724jupiter1qf1.th.png
Diese Science-Fiction-Bilder mit Planeten die von Ringen umschlossen werden sind also immer hoffnungslos übertrieben. Soll natürlich nicht das Konzept kaputt machen oder so, aber ich wollte es mal sagen weil es ganz interessant zu wissen ist :)

Von Schrompf am 07.10.2008, 19:41:45 Uhr
Du hast aber schonmal Bilder vom Saturn gesehen, oder? :-) Natürlich hast Du Recht, dass es in der Realität kein solches Szenario geben kann. Allein die Luftreibung der Splitter in der Atmosphäre würden dafür sorgen, dass die Objekte bald abstürzen. Aber das ist uns erstmal Schnitte :-) das Szenario gibt eine Menge cooler Situationen und Ansichten her. Die physikalischen Schwächen kitten wir dann mit dem ultimativen Grund "Magie".

Von Krishty am 07.10.2008, 21:00:16 Uhr
Zitat von Schrompf:
Du hast aber schonmal Bilder vom Saturn gesehen, oder? :-)
Ja, aber ich hatte hier gerade nur Jupiter rumliegen und abgesehen von den Ringen und ein paar Atmosphärenschichten sind sie ja fast gleich ^^

Sry wegen dem Realitätsfanatismus, der rutscht mir halt manchmal einfach so raus, auch dahin wo er nicht hingehört. :-)

Von DomiOh am 08.10.2008, 00:14:05 Uhr
Auf was für einem System läuft das ganze mit 51.77 FpS?

Von Schrompf am 08.10.2008, 13:01:18 Uhr
CPU ist ein Core2Quad mit 2,8GHz, Graka ist ATI Radeon 4870. Wobei obige Szene auch auf einer Geforce 7800GT noch mit 25fps läuft... wir sind nach wie vor praktisch überall CPU-begrenzt.

Von Kimmi am 08.10.2008, 13:23:33 Uhr
Sieht toll aus, freue mich auf die erste Demo. Vor allem sieht man dem ganzen Projekt eine sehr intensive Liebe zum Detail an. Und man merkt, daß da Leute am Werk sind, die ihr Handwerk verstehen :-).

Gruß Kimmi

Von JaCell am 09.10.2008, 15:23:12 Uhr
Ich finde das wirklich sehr gelungen!!!
Wie macht ihr das allerdings mit dem riesen Terrain? Verwendet ihr da Clipmapping oder so?
Oder verwendet ihr mehrer Quadtrees die dynamisch (per Thread) nachgeladen werden?
PS: Der Schattenartefakt am Monster ist mir auch noch ein Dorn im Auge. :D

Von Schrompf am 10.10.2008, 12:15:25 Uhr
Keine Height Maps, keine Clip Maps, einfach ein riesiger Freiform-Mesh. Segmentiert in momentan 25m^3 Stücke, die für sich jeweils ein Rudel Detailstufen haben und dabei die Kanten zu den Nachbarn konsistent halten. Diese Stücke sind dann hierarchisch zusammengefasst, wo jeweils ein Terrain-Patch dann die detailreduzierten Stufen aller Kinder übernimmt und damit ein größeres Stück auf einmal rendern können. Mit dieser Methode können wir sehr angenehm einige Kilometer Sichtweite machen, allerdings drieselt dann der Schatten sehr auf. Die Materialien werden dann mit Splatting gemischt, wobei jedes Material auch individuelle Texturkoordinaten haben kann.

Die Benutzung eines Freiform-Meshes gibt ungeahnte Freiheitsgrade... Überhänge und Höhlen kann man einfach mit in die Landschaft reinmodellieren. Man kann beliebig fein unterteilen an den Stellen, wo es gebraucht wird. Wenn ich einen Bergpfad in den Hang ziehen will, ist das nicht mehr als ein Schwung mit dem Senken-Brush, dann alle Kanten unterteilen lassen, bis es gut aussieht, dann ein Schwung mit dem Materialbrush, Projektion Y, Maximalwinkel 30°. Sehr nützlich. Eine richtige Terrainmodellierung fehlt allerdings noch... momentan arbeitet alles nur auf existierenden Punkten und Segmentierungen, größere Veränderungen würden die Hierarchie nach und nach degenerieren. Für ein richtiges Volumenmodelling wie aus den Crysis-Videos bekannt fehlt uns allerdings die Zeit. Das wäre dann ne richtig tolle Erfindung.

Die Detailreduktion des Ganzen war ehrlich gesagt das Übelste, was ich in meiner Laufbahn bisher geschrieben habe. Die Splitter sind zum Beispiel an der Unterseite schlechter tesseliert als an den betretbaren Stellen. Außerdem nimmt der Landschaftsgenerator noch nicht wirklich Rücksicht auf die Topologie bei der Segmentierung. Das führt zu allen möglichen seltsamen Teilsegment-Meshes... mehrere separate Teilstücke, manche Ecke besteht nur aus ein paar wenigen Flächen, an exotischen Stellen wird die Oberfläche gelegentlich noch einander durchdringend generiert... und wenn es scherbelt, steht man vor ein paar Hundert MB Daten und muss nun Schritt für Schritt nachvollziehen, warum es zu dieser unmöglichen Topologie kommen konnte. Das war mühsam, und es war gehirnwindungen-verdrehend. Gut, dass jetzt größtenteils alles läuft, wie es soll. Weiterführende Pläne hat man natürlich immer, aber die ganze Terrain-Erzeugung, -Bearbeitung und -Anzeige ist inzwischen stabil und fehlertolerant.

Ach ja, und gestreamt wird das Ganze auch. Die maximale Landschaftsgröße ist in jeder Richtung eigentlich nur durch die Festplattengröße begrenzt. Eine grobe Unterteilung in Zonen mit jeweils eigenem Koordinatensystem sorgt dafür, dass auch bis zum Horizont keine Fließkomma-Ungenaugkeiten auftreten. Das war aber ehrlich gesagt der einfachere Teil. Eine Spielmechanik zu schreiben, die damit klarkommt, ist der kniffligere Teil.

Bye, Thomas

Von Krishty am 10.10.2008, 17:57:00 Uhr
Zitat von Schrompf:
Eine grobe Unterteilung in Zonen mit jeweils eigenem Koordinatensystem sorgt dafür, dass auch bis zum Horizont keine Fließkomma-Ungenaugkeiten auftreten. Das war aber ehrlich gesagt der einfachere Teil. Eine Spielmechanik zu schreiben, die damit klarkommt, ist der kniffligere Teil.
Dafür habe ich mich schon immer interessiert, kennst du zufällig Artikel zu dem Thema? Oder zumindest Stichwörter, mit denen ich danach suchen kann?

Von JaCell am 11.10.2008, 12:52:17 Uhr
Nice!
Danke für die tolle Info!
Wir haben nämlich auch vor so eine ähnliche Terraintechnik zu verwenden, da wir so ein 3D-Race-Shoot'em up machen wo man mit seinen Jets auch durch Höhlen durchfliegen darf. Und da eignen sich Heightmaps sowieso nicht.

Da würde ich mich gern meinem Vorposter anschließen... Habt ihr irgendwelche Tutorials/Papers zu der Technik?

Vielen Dank!

PS: Habt ihr da euren eigenen Terrain/Placementeditor geschrieben oder einfach per Maya/3DS Max rausexportiert?

Lg, Michael

Von Schrompf am 12.10.2008, 12:18:05 Uhr
Das hier (http://www.drizzle.com/~scottb/gdc/continuous-world.htm) ist das einzige, was ich dazu schriftlich kenne. Ich denke aber nicht, dass es dazu irgendein Kochrezept gibt. Der grundlegende Trick ist schlicht, die Welt in Gebiete mit jeweils konsistentem Koordinatensystems aufzuteilen und die einzelnen Koordinatensysteme dann auf eine verlässliche Art untereinander zu verbinden.

Ein kleines Post Mortem dazu von den Splitterwelten:

Erster Versuch: ZoneObjekt, ein ganz normales Objekt im Szenegraph wie jedes andere auch, aber kennt die berührenden Nachbarzonen und das Koordinatenoffset zu ihnen. Ursprünglich war das sogar ne Offset-Matrix, weil wir alle möglichen Visionen von sich drehenden begehbaren Splitterwelten hatten, zwischen denen man gucken und latschen konnte, aber der Aufwand hat sich als mühsam herausgestellt. Aber auch so lief eine Koordinatenumrechnung von einer Zone zur nächsten meist auf eine rekursive Suche durch die Nachbarzonen hinaus, was mühsam und fehleranfällig war. Und speziell im Editor kam es zu allen möglichen Zwischenzuständen, wenn man an der Welt rumbaute, die so in einem intakten Szenegraphen nicht vorgekommen wären. Das machte sowohl die Arbeit am Editor als auch den Bau der Engine sehr mühsam.

Zweiter Versuch (der aktuelle): Wir haben uns irgendwann mal zwei Tage Zeit genommen und das Zonensystem umgebaut. Die Welt hat jetzt ein sogenanntes Zonenraster, ein mit 3D-Integern adressierbares Feld, wobei in jedem Element eine Zone steckt. Jede Zone hat damit jetzt eine korrekte Position in einem globalen Koordinatensystem und kennt ihre eigene Position im Zonenraster. Keine rekursive Suche mehr nach Nachbarn, keine, immer eine Anlaufstelle für Koordinatenumrechnungen (die Welt) und vor allem hatte man jetzt eine globale Positionsbeschreibung, die auch ohne Zugriff auf das Mutter-Zonenobjekt ging. Allerdings sind Zonen jetzt auf einen gewissen räumlichen Bereich festgelegt, den sie jetzt erfüllen müssen. Und die Welt verlässt sich bei Volumenabfragen darauf, dass die Zonen diesen Bereich nicht allzu weit überschreiten. Das macht wiederrum den Umgang mit großen Objekten in der Szene knifflig. Das 40m lange Händler-Luftschiff zum Beispiel strapaziert diese Grenzen stark. Momentan haben wir einfach den Berechnungs-Sicherheitsbereich ausreichend groß dimensioniert, aber eigentlich ist das schon ein Hinweis darauf, dass das System stinkt.

Dritter Versuch (kommt evtl. noch): Auch wenn das aktuelle System nun schon seit einem Jahr prima funktioniert, gibt es doch noch eine Menge an Wünschenswertem. Die eben genannte Festlegung der Zonen auf feste Bereiche ist ein ärgerlicher Aspekt. Theoretisch könnte man ja auch ein Raster wie einen Octree erfinden, der mittels Integer-Indizes und einer gewissen festen Auflösung angibt, welche Zonen das Segment mit ihren Koordinatensystemen berühren. Auf die Art könnte man zum Beispiel das Händlerschiff zu einer eigenen Zone erklären und bekäme wahrhaft freie Bewegungen zwischen den Welten. Dann hätte man zwar wieder Probleme mit Mehrdeutigkeiten, weil sich Zonenkoordinatensystem-Zuständigkeiten überlappen können, aber bewegende Zonen wären ja die Ausnahme und könnten schlicht als solche markiert werden. Aber auch allgemein stört mich das Konzept der in den Szenegraph eingebundenen Zonen immer mehr. Das bedeutet zwar eine Menge Einsparungen, weil man für das komplette Parent-Child-Management, AABBs, Lichteinfluss- und Sichtberechnungen usw. einfach die existenten Fähigkeiten des Szenegraphs nutzen kann. Allerdings bedeutet das auch, dass man für alle Arten von bewegenden Objekten immer manuell die Zuordnung im Szenegraph nachführen muss. Die Physik im Spiel zum Beispiel macht das souverän, das ist unkritisch. Der problematische Teil ist eher der Editor und die Menschen, die ihn benutzen. Wenn man sich mal eine Hütte schnappt und die woanders hinschiebt, muss man danach halt von Hand auch der korrekten Zone zuweisen. Die Grafiker vergessen das ganz gern und wundern sich dann über Objekte, die bei bestimmten Blickwinkeln verschwinden, ihren Schatten dalassen, was öfters zu panischen ICQ-Offlinebotschaften führt.

Aber wenn ich jetzt gerade darüber schreibe, fällt mir auf, dass man das ja auch schlicht im Editor regeln könnte. Die Alternative ohne Zonen wäre zwar auch verlockend, aber dann könnte theoretisch jedes Objekt ein Wurzelobjekt sein und müsste eine Rasterposition mitführen. Man könnte zwar mit einem Rudel asserts an alle Ecken absichern, dass nur Rootobjekte jemals eine Rasterposition haben, aber die zusätzliche Zonenoffset-Mathematik in jedem Objekt mitzuschleppen gefällt mir auch nicht. Alles nicht ganz einfach, fürchte ich.

Der ganze Mathekram ist da übrigens noch der harmlose Teil... der braucht einfach nur viel Sorgfalt und Ausdauer bei der Bugjagd. Die Spielmechanik darauf anzupassen ist der knifflige Teil. Die Physik läuft momentan über sogenannte Physikbereiche, also würfelförmige Zonen der Aktivität in der Welt. Der Spieler trägt eine davon mit sich rum, weitere können erstellt und z.B. an Kameras geheftet werden. Der Umgang mit physikaktiven Objekten in der Welt funktioniert dann zweistufig: bei Annäherung zuerst Physik-Erstellung im eingefrorenen Zustand, dann ~10m später Aktivierung und Zuweisung der letzten bekannten Geschwindigkeiten, dann ist das Objekt aktiv, und wenn es wieder den Bereich verlässt, wird es zuerst eingefroren und die Geschwindigkeiten gespeichert und dann wiederrum ~10m später die Physik gelöscht. Funktioniert bis jetzt ganz gut, aber die 10m darin geben wiederrum quasi hardcoded die maximale Größe von physikaktiven Objekten an. Alles, was größer ist, würde in einem Stapel evtl. seine Umgebung durchdringen, weil es in Bereiche ragt, indem andere Objekte evtl. bereits komplett abgeschaltet wurden. Wenn man dann wieder näher ran geht und der Stapel wieder physikaktiv wird, explodiert die Szene, weil alle Objekte tief ineinander drinstecken. Knifflig, aber momentan zum Glück noch unproblematisch. Ein weiteres Detail an Physik in großen Welten ist übrigens, dass man das Koordinatenzentrum regelmäßig umziehen lassen muss, sonst bekommt man wieder Fließkomma-Ärger. PhysX hat dazu meine Anfragen im Forum ignoriert (bzw. sogar gelöscht), daher benutzen wir jetzt oben beschriebene Physik-Aktivbereich-Mechanik, um die Physik eines Gebietes komplett zu plätten und neu zu erstellen. Sind wiederrum ein paar Millisekunden Pause, aber momentan zum Glück noch unkritisch.

Gleiches gilt übrigens dann auch für die KI und alles, auf das sie zugreifen will. Momentan haben wir zum Glück überhaupt keine Probleme damit, weil der KI-Programmierer überhaupt nichts tut. Aber wenn das irgendwann mal kommen sollte, wird es eine ganz eigene Freude werden, dass die KI nur in der Nähe des Spielers überhaupt Kollisionsmeshes unter den Füßen hat. Entweder abschalten und bei Wiederkommen des Spielers neu aktivieren, was eine robuste Implementation von Tagesablauf, Kampfmechanik und wasweißichnoch erfordert. Oder weitermachen lassen und nur entlang des Wegenetzes bewegen (was wir für echte Unendlichkeit eigentlich auch streamen müssten), aber dann gibt es Ärger mit Kämpfen oder überhaupt mit Interaktionen mit der Umwelt... ach menno, alles gar nicht so einfach.

Als Zonengröße benutzen wir übrigens 250m. Der Gedanke dahinter war, dass ein float 23Bit Mantisse hat. Wenn wir zuverlässig 4 Nachkommastellen haben wollen, brauchen wir mindestens 14 Bit Nachkomma-Anteil (entspricht einer Nachkommaauflösung von 16000). Bleiben 9 Bit Vorkomma-Anteil übrig, also 512m. Macht genau die Ausdehnung zweier benachbarter Zonen, das erschien mir sicher genug. Wir müssen übrigens demnächst unsere Spielmechanik auf eine feste Zeitbasis stellen. An den Rändern der Welten, wo praktisch nix mehr im Bild ist, rendert die Engine auf meinem Monsterrechner inzwischen *zu* schnell. Die Positionsdifferenzen in der Bewegung von z.B. dem Spieler sind bei 500fps so klein, dass die Addition im Fließkomma-Rauschen verschwindet... man bleibt hängen. Sicht drehen, so dass man über den ganzen Splitter schaut, plötzlich sinds nur noch 100fps, schon kann man sich wieder sauber bewegen. Was für ein Ärger. Gleiches Problem haben wir aber auch an ganz anderen Ecken wie z.B. den Charakterwerten. Wenn da das Vergiftungslevel langsam wieder auf Null sinken soll, stockt es bei hohen Frameraten genauso, weil die Differentiale zu klein werden. Grmpf.

Zur letzten Frage noch, trotz des bereits romanlangen Beitrags: wir haben einen eigenen Editor dazu geschrieben. Der kann schon ne Menge, auch zur Spielmechanik, war allerdings ein ordentlicher Packen Arbeit. Evtl. hätte man dafür eine schlauere Methode entwickeln können. Die Landschaft ist aber nicht direkt im Editor modelliert. Der Editor kennt ein spezielles Szenegraph-Objekt namens Landschaft, das quasi ein kleines Modell der zukünftigen Landschaft abbildet. Das baut man ganz schlicht mit den Editor-Mitteln zur Meshbearbeitung. Dann erzeugt man Landschaftsmaterialien, die den Unterteilungsgrad, die Bodenmaterialien, die Rauhheit, Rundheit usw. des Bodens und die Objektverteilung darauf beschreiben. Mit den Landschaftsmats kann man auf dem Mesh (vertexbasiert) rummalen. Dann drückt man das Ding dem Landschaftsgenerator in die Hand, der es großskaliert, unterteilt und formt wie gewünscht, auf Zonen aufteilt, die Terrainhierarchien erzeugt, Texturkoordinaten für alle Terrains verteilt, die ganzen Objekte darauf spawnt usw. Als Bearbeiter muss man danach noch Sonne und Himmel einfügen, den Bewuchs einstellen und erzeugen lassen und einmal "Welt überprüfen" drüberlaufen lassen, was unter anderem z.B. die LODs der Terrains berechnet. Wenn man dann richtig Zeit hat, kann man danach die indirekte Lichtberechnung anwerfen. Die blockiert den Rechner dann für ein paar Stunden, aber danach ist unter Fichten dann der Boden korrekt abgedunkelt und das Ambient Light in Höhlen sieht ordentlich aus.

Hoffentlich liest das überhaupt noch wer :-) Sonst hab ich grade den längsten Spam aller Zeiten produziert.

Von Godhand am 12.10.2008, 14:57:36 Uhr
"Die Positionsdifferenzen in der Bewegung von z.B. dem Spieler sind bei 500fps so klein, dass die Addition im Fließkomma-Rauschen verschwindet... man bleibt hängen. Sicht drehen, so dass man über den ganzen Splitter schaut, plötzlich sinds nur noch 100fps, schon kann man sich wieder sauber bewegen. Was für ein Ärger. Gleiches Problem haben wir aber auch an ganz anderen Ecken wie z.B. den Charakterwerten. Wenn da das Vergiftungslevel langsam wieder auf Null sinken soll, stockt es bei hohen Frameraten genauso, weil die Differentiale zu klein werden. Grmpf."

Intern mit doubles arbeiten und gut ist ;) Dementsprechend für die Anzeige, etc. auch noch Float-Getter zur Verfügung stellen, oder am besten gleich fast alles (bis auf den Renderer) auf double umstellen. Dies ist sicherlich viel sauberer als die gute alte Framebremse.

Von Schrompf am 12.10.2008, 22:30:08 Uhr
Wenn Du mir Ageia PhysX auf doubles umschreibst, gern. Charakterwerte könnten wir in Doubles rechnen. Aber da merkt auf jeden Fall niemand, ob die nun 100 oder 500 mal pro Sekunde berechnet werden.

Von JaCell am 13.10.2008, 18:54:52 Uhr
Vielen Dank für den ausführlichen Post! ;)
Also das klingt recht vielversprechend, aber ich denke wir werden den "Crysis-Ansatz" versuchen.
Sprich wir erzeugen das Terrain per Heightmap und fügen anschl. per Voxel (Marching Cubes) Tunnels und Höhlen hinzu. Dürfte denke ich auch nicht schlecht sein, denn für die Designer ist recht toll wenn sie Tunnels/Höhlen einfach "reinzeichnen" können. Und damit das ganze "continuos" wird, werden wir auch mit Terrain-Tiles arbeiten, die wie bei euch, gestreamt abhängig von der Sichtweite nachgeladen werden.

Von Stefan Zerbst am 21.10.2008, 09:43:12 Uhr
Hi,

ist ja eigentlich schon alles gesagt worden. Ich wäre auch für ein bisschen Bloom bzw. Weichzeichner und angepasste Beleuchtung entsprechend der Tageszeit und einen schöneres Himmel :)

Ansonsten kan ich nur sagen: *Neid* *Neid* *Neid* *Neid* *Neid* *Neid* *Neid* *Neid* *Neid* ...

Von Schrompf am 23.01.2009, 22:37:10 Uhr
*Petition für neues IOTT gründ*

Na kommt, Leute. Ich werd doch nicht der einzige sein, der ein paar Bilder einer Engine oder eines Spieles zeigen kann.