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

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

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

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

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.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Sommer; Sonne; Sonnenschein
… zumindest in Massive Universe Online. Die letzten beiden Wochen haben wir uns mit einem weiteren Feature unserer Engine beschäftigt und zwar mit LensFlare und LightScattering Effekten. In folgendem Video können die Effekte bewundert werden.


Mit diesen beiden Effekten ist die Grundfunktionalität der Engine erst einmal abgeschlossen. In den nächsten Tagen werden wir uns noch einmal mit der Optimierung der Engine befassen, da bei der Demo ersichtlich wurde, das da noch einiges getan werden muss. Danach geht es dann endlich an die Implementierung der eigentlichen Spiel-Inhalte. Da der Grundstein dafür auch schon größtensteils mit der Engine gelegt wurde, rechnen wir da relativ schnell mit vorzeigbaren Resultaten.

Man darf gespannt bleiben,
euer BitSpace-Team

zum Video
zum Blogpost

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Hey Leute,

fast hätten wir es vergessen: Massive Universe Online wird 3 Jahre alt!

Schon wieder ein Jahr mehr, so schnell vergeht die Zeit und für Außenstehende sieht es immer noch so aus als ob nix passieren würde. Wenn man sich einmal an den Anfang zurück erinnert, wo geplant war nach 2 Jahren eine vorzeigbare Beta zu haben, dann könnte man auch fast glauben das wir nicht viel geschafft haben, aber im Gegenteil. Es sind viele kleinere Projekte entstanden die wir im Hinblick auf Massive Universe Online umgesetzt haben. Zum einen ist eine komplette Deferred Engine zum rendern atemberaubender Space-Szenen entstanden. Einen Teil dieser Engine haben wir sogar zur freien Verfügung gestellt um Neulingen den Einstieg in die OpenGL Entwicklung zu erleichtern. Unser Framework umfasst aber nicht nur die Engine selbst, sondern auch sonst alles was wir irgendwann einmal für die Entwicklung von Massive Universe Online benötigen könnten. Zusätzlich zur Framework gibt es einen umfassenden Editor zur internen Verwaltung von Materialien, Texturen, Modellen, und und und. Wir haben einen weiteren Editor bzw. Generator für BumpMaps geschrieben mit dem wir unsere Modele noch detaillierter gestalten können. Dieser Generator kann ebenfalls von allen kostenlos genutzt werden. Zu guter Letzt gibt es einen PreCompiler für glslCode dessen Quelltext – genauso wie viele der anderen keinen Projekte – kostenlos zum Download bereit steht. Ihr seht also dass wir nicht untätig sind und kontinuierlich am Projekt weiterarbeiten. Natürlich geht es nicht so schnell voran wie man sich das wünschen würde, aber da das Ganze immer noch – Betonung liegt auf noch – ein Hobby-Projekt ist, bleibt das neben der normalen Arbeit eben manchmal auf der Strecke liegen.

Soviel zum letzten Jahr und zum aktuellen Stand. Was bringt die Zukunft? Ich hab lange überlegt, ob ich etwas dazu schreiben soll, aber am Ende wird es doch wieder anders. Wie oft haben wir schon gesagt das wir uns jetzt um den Game Content kümmern? Wie oft ist etwas anderes, wichtigeres dazwischen gekommen? Deshalb sag ich heute mal nur so viel: it’s done when it’s done. Einen kleinen Ausblick in die Zukunft will ich aber trotzdem geben. Wir haben in letzter Zeit gehäuft darüber nach gedacht das Projekt zu forcieren und evtl. mit Hilfe von Kickstarter oder einem Sponsor ein Gewerbe damit aufzubauen. Bis jetzt ist nichts entschieden. Wir werden sehen was die Zukunft bringt…

Euer bitSpace-Team.

zum Blog-Post

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.