Massive Universe Online

[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.

[Komoluna]

Da ich mich sehr für dieses Projekt interessiere und schon lange nichts mehr davon
gehört habe, wollte ich mal fragen, wie denn der aktuelle Stand ist/ob es was neues
zu berichten gibt.

Komoluna

[Bergmann89]

Hey,

sry das ich erst jetzt antworte. Wir arbeiten nachwievor daran. Leider aber nur noch am Wochenende, da wir unter der Woche mit Arbeit bzw. Studium beschäftigt sind. In letzter Zeit haben wir viel Code refaktored und neu strukturiert. Das ist jetzt alles zu ca. 80% abgeschlossen. Wenn das dann beendet ist gibts auch nochma n umfassenderes Update auf unserer Homepage

MfG Bergmann

[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.


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).


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.


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.


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

[Bergmann89]

Hey Leute,

wie schon in diversen Foren angekündigt , wollen wir euch heute die Früchte unserer Arbeit präsentieren und releasen die TechDemo für unserer Deferred Engine. Mehr gibts heut nicht zu sagen, außer viel Spaß beim testen

zum Blog
DeferredEngine TechDemo Win32
DeferredEngine TechDemo Win64
DeferredEngine TechDemo Linux32
DeferredEngine TechDemo Linux64

MfG Bergmann.

[carli]

Code: Alles auswählen

carli:~/Sonstiges/deferred/DeferredEngineTechDemoLinux64$ ./Engine
ATTENTION: default value of option vblank_mode overridden by environment.
TWinControl.UpdateShowing.ChangeShowing failed for :TRenderControl, Showing reset to False
TWinControl.UpdateShowing.ChangeShowing failed for :TRenderControl, Showing reset to False
TWinControl.UpdateShowing.ChangeShowing failed for :TRenderControl, Showing reset to False
TWinControl.UpdateShowing.ChangeShowing failed for :TRenderControl, Showing reset to False
[FORMS.PP] ExceptionOccurred 
  Sender=EutlKeyObjectList
  Exception=key not found
  Stack trace:
  $00000000006C56A3
  $00000000006C51D3
  $00000000004771AA
TApplication.HandleException key not found
  Stack trace:
  $00000000006C56A3
  $00000000006C51D3
  $00000000004771AA
TApplication.HandleException: there was another exception during showing the first exception
  Stack trace:
  $0000003903E75766
**
GLib-GObject:ERROR:gsignal.c:768:emission_pop: code should not be reached
Abgebrochen (Speicherabzug geschrieben)

Umgebung: Linux x86_64, Fedora 20, Gnome3

Edit: Nach einem zweiten Versuch klappt es. Vielleicht ist es eine Race condition? Du erstellst ziemlich viele Threads.

Ich erreiche übrigens 10 FPS. Die Schatten sehen cool aus.

[Bergmann89]

Hey,

10 FPS sin ja nich grad viel. Was für Hardware hast du? Hattest du's im Fenster laufen (standard 800x600) oder Maximiert?

Ich hab auch mal ne Version mit Debug-Symbolen und paar Debug-Ausgaben gebaut. Könntest du damit bitte nochmal versuchen den Fehler zu reproduzieren?
Wenn er sich nocheinmal zeigt bräuchte ich die *.log un die *.heaptrc. Danke. http://files.muo-game.de/Engine-x86_64- ... bg.tar.bz2

MfG Bergmann.

[Christian]

2 FPS aufm Macbook Air 800x600 im Window Mode mit default Einstellungen ist auch nicht gerad n bringer. Alles andere an Spielen läuft eigentlich ganz ok.

[Bergmann89]

Hey,

bei den default Einstellungen is so ziemlich alles an, was man anschalten kann. Aber trotzdem sind 2 FPS zu wenig, da müssen wir nochma optimieren. Hast du das auf dem Mac in ner VM laufen oder hast du da n Linux drauf?

MfG Bergmann.

[Christian]

Nativ laufendes Linux.

[creed steiger]

OpenSuse 12.3 32 bit

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8600 GT/PCIe/SSE2/3DNOW!
OpenGL version string: 3.3.0 NVIDIA 319.32

Code: Alles auswählen

 
Fontconfig warning: "/etc/fonts/conf.d/56-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
The program 'Engine' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 344 error_code 8 request_code 153 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
 

[Bergmann89]

Hey,

der Fehler ist schon bekannt, wir wissen auch ungefähr woran's liegt, nur die Lösung ist noch nicht ganz implementiert. Wenn's da was neues gibt, dann gibt's nochma n kleines Update. Danke für's Feedback.

MfG Bergmann.

[creed steiger]

Kein Problem, wird dann wieder getestet.