Massive Universe Online

[Teekeks]

Hey Leute,

zwei Freunde (einer davon ist Bergmann89 aus dem delphi-forum, der andere heißt Akaikee) und ich hatten die Idee für ein neues Gemeinschaftsprojekt. Das ist jetzt ca. 4 Wochen her und wir haben schon einiges geplant und auch teilweise schon implementiert. Und jetzt suchen wir Verstärkung für unser Team, also wollte ich das Projekt hier mal vorstellen.

1. Projekttitel
   Massive Universe Online (MUO)
   
2. Projektbeschreibung
   Massive Universe Online soll ein Online-Clone der beliebten X-Reihe werden. Grundlegend soll es natürlich so aufgebaut sein wie X. Aber wir haben auch teilweise einige neue Ideen, die das Spielen miteinander etwas interessanter gestalten. Hier mal ein grober Überblick über unsere Ideen: Mindmap, Wirtschaft.
   Das Projekt ist in 4 Stufen eingeteilt:
   • Implementierung eines Editors zur Modellierung der Spielobjekte (Items, Schiffe, Stationen, Sektoren, ...)
   • Implementierung der Spiellogik (Client)
   • Implementierung der Spiellogik (Server)
   • Implementierung des Grafiksystems (Client)
   Zur Zeit entwickeln wir am Editor, der ist auch schon zu ca. 70% fertig gestellt.
   
3. benötigte Software
   Wir haben bis jetzt darauf geachtet, dass die genutzte Software als Freeware zur Verfügung steht. So kann jeder am Projekt mitarbeiten.
   • Entwickelt wird mit FPC/Lazarus (unter 32bit und 64bit).
   • Für die Mindmaps haben wir xMind
   • Modelle können mit jedem Editor entwickelt werden. Wir bevorzugen Blender. Die Modelle werden dann als OBJ-Datei zur Verfügung gestellt
   • Als Versionsverwaltung haben wir ein GIT bei bitbucket.org eingerichtet. Clientseitig benutzen wir SmartGit
4. Lizenz
   Über eine Lizenz haben wir uns noch keine Gedanken gemacht, weil da noch recht unerfahren sind (aber wir sind für jeden Tipp dankbar). Prinzipiell soll das Spiel als Freeware zur Verfügung gestellt werden. Wir haben aber auch über eine Art Premiumitemsystem nachgedacht, dass wir evtl später einführen wollen, um die Servermiete und dergleichen bezahlen zu können. Sollte das Projekt irgendwann Geld einbringen, dann wird der Gewinn je nach Arbeitsanteil unter den Teammitgliedern aufgeteilt.
   
5. voraussichtliche Projektdauer
   Spätestens im Sommer 2013 wollten wir eine Alpha releasen, in der die grundlegenden Funktionen implementiert sind. Diese Alpha soll dann auch zum Test auf einem Public Server laufen. Die Beta, in der dann alle Funktionen implementiert sein sollen, wollen wir Ende 2013 releasen. Das Finalrelease soll Sommer 2014 erscheinen. Dieser Zeitplan ist relativ straff, aber ich denke mit etwas Begeisterung und Motivation ist der zu schaffen
   
6. Aufgaben, benötigte Fähigkeiten der Team-Mitglieder
   Zur Zeit haben wir 2 Programmierer (Bergmann89 und mich). Der dritte im Bunde (Akaikee) kümmert sich um Modelle, Logos und den Blog bzw. die Website. Also benötigen wir noch 1-2 Entwickler. 4-5 Leute die sich um Texturen und Modelle kümmern. Die Hauptarbeit ist und bleibt das erstellen der Modelle und Texturen, deshalb sind wir für jedes Modell und für jede Textur die ihr uns zuschicken könnt dankbar. So könnt ihr auch am Projekt teilhaben, ohne ein fester Bestandteil des Teams zu werden. Natürlich wird jeder der am Projekt mitwirkt namentlich erwähnt (sofern erwünscht).
   
7. Organisation innerhalb des Teams
   Die Kommunikation im Team erfolgt hauptsächlich über Skype. Entscheidungen werden gemeinsam getroffen und vorher diskutiert. Das Schlusswort haben aber immer noch Bergmann89, Akaikee und ich.

Wichtige Informationen zum Design Ich möchte noch ein paar Worte zum Design der Modelle und der Texturen verlieren, sodass das ganze auch ein wenig einheitlich aussieht. Deshalb beschreib ich jetzt mal kurz unsere Vorstellung zu den einzelnen Rassen:

• Janaru (menschenähnlich) - Die Stationen und Schiffe dieser Rasse sollen sich etwas an der Realität orientieren (Bsp.: Spaceshuttle, Jagtflieger, ISS, ...). Die Farbe der Rasse soll weiß sein, also sollten die Modelle hier und da ein paar weiße Akzente haben.
• Tambinor (fischähnlich) - Passend zu der Rasse sollen die Modelle aussehen, wie Unterwasserstationen/-schiffe, also rund und dynamisch.
  Die Farbe der Rasse ist blau.
• Bendalir (Lavagolems) - Diese Rasse soll mächtige, klotz- oder geröllartige Modelle besitzen. Stellt euch ne Art fliegenden Stein vor ^^ Die Farbe ist natürlich rot.
• Cogadh (echsenartig) - Hier sollen die Modelle spitz, eckig und kantig sein. Wie ne Art Kaktus, oder andere Gewächse der Wüste. Farbe der Rasse ist grün.

Da jeder andere Vorstellungen hat suchen wir dringen Konzeptzeichner. Sodass alle die ein Modell bauen wollen ein einheitliches Bild haben.
Weiterhin haben wir die Modelle so konzeptioniert, dass man möglichst viele Teile des Modells in anderen Modellen wiederverwenden kann. Also achtet beim Bau der Modelle darauf, das ihr die Meshs in Gruppen zusammen fast. Damit wollen wir dann eine Art Datenbank aufbauen, wo man sich aus z.B. mehreren Antrieben einen aussuchen kann. Damit wird nicht nur der Speicherplatz optimiert, sondern es dauert auch nicht so lange die Modelle zu bauen.

Wichtige links:
Entwickler-Blog
Massive Universe Online auf Twitter


Soweit zum Projekt, ich hoffe ich konnte euch ein wenig dafür begeistern. Wenn ihr Interesse daran habt, ein Teil des Projekts zu werden, oder einfach nur eine Frage habt, dann schreibt uns eine Mail an [e-mail].
Hoffentlich bis Bald

Bergmann89, Akaikee, Teekeks.

Crosspost zum DF: http://www.delphiforum.de/viewtopic.php?t=107827
Crosspost zum lazarus Forum: http://www.lazarusforum.de/viewtopic.php?f=11&t=5498
Crosspost zum DelphiGL-Forum: http://delphigl.com/forum/viewtopic.php?f=13&t=10173
Crosspost zum Offiziellen X-Forum: http://forum.egosoft.com/viewtopic.p...733837#3733837

[Bergmann89]

Hey,

heut hab ich mal was für's Auge. Immer nur doofen Text lesen is ja auch nich immer das wahre^^ Deshalb: Film ab...

und hier noch der Link zum Post auf unserem Blog (für die, die doch etwas lesen wollen ^^): Sneak Peek Video: Jump Gates over Terra

MfG Bergmann89

[nuclearping]

Sehr schön.

[ensaron]

Schick Freue mich schon auf mehr

[Luckie]

Erdähnlich ist gut. Irgendwie scheint er die gleichen Kontinente zu haben wie die Erde. Und was mir noch aufgefallen ist, die Wolken bewegen sich viel zu schnell. Wahrscheinlich dürfte man so gut wie gar keine Wolkenbwegung sehen.

[Phoenix]

In den Kommentaren zum Post stand drin, dass da ein Zeitraffer drin ist.
Der Flug dauert ca. 3,5 Stunden und das Video wurde auf 1,5 Minuten beschleunigt. Deswegen die schnellen Wolken.

[ensaron]

Zitat von Phoenix:

In den Kommentaren zum Post stand drin, dass da ein Zeitraffer drin ist.
Der Flug dauert ca. 3,5 Stunden und das Video wurde auf 1,5 Minuten beschleunigt. Deswegen die schnellen Wolken.

3,5 Minuten, nicht Stunden

[Bergmann89]

Hey Leute,

Weihnachten steht vor der Tür und wir wollten euch mal wieder einen kleinen Abriss des aktuellen Stands geben. Tagesthemen heute: die neu entwickelte Universums Übersicht, neue und alte Modelle und die Überarbeitung der Schiffsmodule. Alles weitere wie immer auf unserem Blog.

euer BitSpace-Team.

[Bergmann89]

Hey Leute,

wir haben lange nichts von uns hören lassen, deshalb gibts jetzt mal wieder ein mehr oder weniger großes Update. Alle Infos wie immer auf dem MassiveUniverseOnline Blog. Thema des heutigen Eintrags ist der Großumbau der bisherigen Projekte und die weitere Zukunft des Projekts. Viel Spaß beim lesen

MfG Bergmann.

[Bergmann89]

Hey Leute,

heute wollen wir euch die Features unserer neuen Deferred Shading Engine zeigen. Die neuen Funktionen der Engine beinhalten ein Shading-Model welches auf realer Physik basiert um eine Szene einfacher und vor allem realistischer zu beleuchten. Anstatt das mehr oder weniger verbreitete Licht-Model mit Ambient-, Diffuse- und Specular-Werten zu beschreiben, geben wir die physikalischen Eigenschaften der Oberfläche direkt an (wie z.B. die Rauheit). Mit Hilfe dieser Werte wird die Brechung des Lichts auf der Oberfläche berechnet. Die meisten Eigenschaften sind mapbar, sodass verschiedene Bereiche auf ein und demselben Material verschiedene Effekte haben können. Anschließend findet ihr ein kurzes Video mit den neusten Funktionen der Deferred Shading Engine.

Bis bald,
euer BitSpace-Team.

zum Video
zum Blogpos

[Bergmann89]

Heute mal ein paar Infos zur Lichtberechnung in unserer Engine: Zum Blog

Neben all den neuen Technologien, die in modernen Games und Game Engines genutzt werden, hat ein Konzept aus der guten alten Zeit überlebt: Materialien und Light-Shading.
Doch die heutige Hardware ist zu sehr viel besseren Techniken in der Lage. Wir haben eine Technik entwickelt (bzw. erweitert) die auf den physischen Grundlagen der Lichtberechnung basiert. Diese Technik kommt jetzt in unserer bitSpaceEngine zum Einsatz.

Stand der Technik
Obwohl es einige Verbesserungen in der Vergangenheit gab (speziell bei Light Attenuation und atmosphärischen Effekten), hat sich das zugrundeliegende Konzept nie geändert: Eine Lichtquelle strahlt drei Arten von Licht ab und das Material reagiert entsprechend auf diese 3 Lichtarten.

• Ambient: ungerichtetes Licht, das immer vorhanden ist
• Diffuse: gerichtetes Licht, das vom Winkel abhängt mit der es auf eine Oberfläche trifft
• Specular: Licht das Highlights erzeugt, wenn es in das Auge des Betrachters reflektiert wird
• Emissive: Licht das vom Objekt selbst abgegeben wird

Jede Lichtquelle ist durch vier Farbwerte (RGBA) definiert und jedes Material besitzt entsprechend vier Farbfaktoren (RGBA) und einen zusätzlichen Wert die shininess welcher die Größe der Highlights angibt, die vom Specular Licht erzeugt werden. Dieses System hat einen sehr großen Vorteil gegenüber allen Anderen: mit ihm kann man die meisten reellen Licht Szenarien abbilden und es ist sehr einfach auf der Hardware zu implementieren, welches ein großer Vorteil in den Anfängen der 3D-Computergrafik war, als die Lichtberechnung eines Fragments noch der rechenintensivste Teil der gesamten Render-Pipeline war.
Wie auch immer, es ist sehr schwer für jemanden eine Szene zu beleuchten, da man für eine Lichtquelle und ein Objekt 8 (bzw. 17 da Farben RGBA sind) verschiedene Parameter einstellen muss. Umso schwerer ist es die gesamte Szene korrekt zu beleuchten und alle Materialen naturgetreu darzustellen. Das setzt viel Erfahrung voraus. So viel Erfahrung das es für einen guten Entwickler oder ein gutes Tool unabdingbar geworden ist, eine komplette Materialiensammlung von den bekanntesten Materialien zu erstellen.
Außerdem ist es für einen untrainierten Entwickler (wie den Autor dieses Posts) sehr schwer die geeigneten Parameter für ein gegebenes reelles Objekt zu finden.

Auf Physik basiertes Shading
Das auf Physik basierende Shading nutzt die stark angewachsene Power aktueller GPUs, bzw. deren leistungsstarke Fragment- und Pixel-Shader sowie die schnellen Fließkomma-Operationen. Die grundlegende Idee dahinter ist, anstatt die Lichtquellen und Materialien mit ihren vier Farben und den Faktoren zu beschreiben, definiert man die physikalischen Eigenschaften des Objekts. Den Rest erledigt die brachiale Rechenleistung der GPU, die die finale Farbe des Fragments aus den gegebenen Werten errechnet.
Neben uns, ist uns noch eine andere namenhafte Softwareschmiede bekannt, die dieses Verfahren nutzt: Crytek mit ihrem XBone Release Titel “Ryse – Son of Rome”. Crytek hat ebenfalls einen guten Artikel auf Making Games über das Verfahren veröffentlicht. Der geht zwar nicht allzu sehr ins Detail (irgendwo muss eine Firma ja auch konkurrenzfähig bleiben) aber er gibt einen guten Überblick über die abgewendeten Techniken und hat den Autor dieses Beitrags darin bestätigt, dass seine Idee {Ja, ich hatte diese Idee schon sehr lange, aber war der Meinung “Wenn es gut ist, warum zur Hölle nutzt das keiner?!”} wirklich funktionieren könnte. Der Artikel auf Making Games geht hauptsächlich auf die Generierung der Cubemap ein, deshalb wollen wir uns in diesem Artikel etwas mehr mit unserer Implementierung auseinander setzen.

Grundlegendes Konzept
Wenn man Lichtberechnungen beschreiben will, ist es eine gute Idee bei der Quelle des Lichts zu beginnen. In unserem Fall ist das die reelle Lichtquelle (z.B. eine Glühbirne). Dabei blenden wir zunächst alle Möglichkeiten die mit dem normalen Lichtmodel möglich wären, aber kaum Anwendung finden aus. Es gibt einfach keine Lichter mit rotem Ambient Licht, grünen Diffuse Licht und blauen Specular Licht.
Das einfachste Beispiel dafür, wie wir eine Lichtquelle modellieren, ist eine farbige Glühbirne.
Bild

Wie ihr wissen solltet, gibt eine Glühbirne Licht ab, indem sie einen dünnen Wolfram Faden zum glühen bringt. Bei farbigen Glühbirnen wird das entstehende (annähernd weiße) Licht durch die Färbung der Glühbirne gefiltert. In unserem Model haben wir diese beiden Arten von Licht getrennt:

• primäres Licht, ist das Licht welches vom Wolfram Faden erzeugt wird. Im Normalfall ist das sehr hell (annähernd RGB(1, 1, 1)) und ist der Teil des Lichts welches in Reflektionen sichtbar wird
• sekundäres Licht, ist das Licht welches von der Farbe der Glühbirne bestimmt wird. Es ist nicht ganz so hell wie das primäre Licht und hat unter Umständen auch eine komplett andere Farbe. Im Normalfall ist das das Licht welches vom beleuchteten Objekt reflektiert wird.

Es gibt kein Ambient Licht für jede Lichtquelle, es ist einfach ein Teil der Szene (bzw. des globalen Lichts), welches an der selben Stelle wie das globale Shadow Mapping konfiguriert ist. Die Definition der Materialien hat sich weitaus mehr verändert, als die der Lichtquellen. Nachfolgend sind die Attribute aufgelistet, die ein Material jetzt definiert: die Farbe, die Emissive Farbe, die Normalen, die Rauheit und der Brechungsindex. Die Farbe und die Emissive Farbe sind, wie schon vom alten Model bekannt, ein mapbarer Fragmentwert, welche normalerweise aus einer Textur gelesen werden oder für das ganze Objekt festgelegt werden. Das selbe gilt für Normalmaps, welche für BumpMapping genutzt werden. Das erste zusätzliche Attribut wird Rauheit genannt, dass – wie der Name schon sagt – eine Einheit dafür ist, wie rau die Oberfläche eines Objekts ist. Es reicht von perfekt polierten (0,0) bis hin zu komplett rauen Oberflächen (1,0).
Bild

Licht, das von einer perfekt glatten Oberfläche reflektiert wird, hat keinen diffusen Anteil, sodass das Material aus jeder anderen Richtung schwarz wirken würde und nur ein Highlight vom primären Licht reflektieren würde, wenn es aus dem richtigen Winkel betrachtet wird. Im Gegensatz dazu würde ein komplett raues Material keine Highlights und die selbe Helligkeit von allen Seiten haben (wenn das betrachtete Objekt eine flache Ebene ist). Weiterhin gibt es noch eine Art von Materialien: Die meisten steinartigen Materialien, wie z.B. Marmor können sehr glatt poliert sein und haben trotzdem einen diffusen Lichtanteil, wenn man aus einem anderen Winkel auf das Objekt sieht. Der Grund dafür ist Licht, welches unter der Oberfläche reflektiert wird, ähnlich wie bei Subsurface Scattering. Dieser Effekt wird bei uns durch den Brechungsindex gesteuert. Der Brechungsindex gibt an, wie viel Licht vom Objekt aufgenommen wird, eh es reflektiert wird.

Die Engine
In unserer Deferred Rendering Engine speichern wir zunächst all diese Werte in einem Textur-Buffer ab, um sie dann im Licht-Render-Pass zum finalen Licht zusammen zu rechnen. Eine spezielle Eigenschaft der Engine ist, das die Normal-Map zusätzlich einen Kanal für die Rauheit besitzt, so können verschiedene Lichteffekte für ein und das selbe Mesh erzeugt werden. Im finalen Licht-Render-Pass wird das globale (bzw. das Ambient Licht) mit dem Diffuse und Specular Licht kombiniert, welches aus der der Position der Lichtquelle und des Blickpunktes des Betrachters berechnet wird. Außerdem wird das Emission Licht mit einbezogen, wenn dieses aktiviert ist. Die Berechnungen arbeiten dabei mit den Parametern, die im Bild oben beschrieben wurden.
Bild

Das Ergebnis
Mit diesem neuen Model, können wir sehr einfach alle Effekte modellieren, die es bei reellen Materialien und reellen Lichtquellen gibt. Natürlich unterliegt dieses Model auch einigen Einschränkungen, aber für die Effekte die nicht von dem Model unterstützt werden, kann jederzeit ein spezieller Shader implementiert werden, der diese Funktionalität nachreicht.
Bild, Bild

Es nicht der schnellste Weg sich eine eigene Engine von Grund auf selbst zu bauen, aber wie ihr sehen könnt ergeben sich dadurch Möglichkeiten und Freiheiten die man bei einer fertigen Engine nicht hätte. Mit diesem Model haben wir jetzt ein System, das uns ein schnelles und einfaches Modellieren von beleuchteten Szenen ermöglicht und zusätzlich noch kompatibel zu unserem Toolset ist. Außerdem sieht es jetzt realistischer aus als vorher – speziell die Reflektionen von metallischen Gegenständen fallen beim auf Physik basierten Shading direkt ins Auge.

Wir wünschen einen guten Start ins Jahr 2014,
euer BitSpace-Team