Open-Source 3D Engine PixelLight Veröffentlicht

[AblazeSpace]

Hier Screenshots vom Deferred Renderer der gerade veröffentlichten PixelLight 3D Engine. (in der Entwicklung seit 2002)




PixelLight ist ein in C++ geschriebenes, Open-Source, Cross-Platform 3D Anwendungs-Framework. Derzeit unterstützt es Windows und Linux, ein Port für Maemo 5 (Mobile Endgeräte) ist im Prototypenstatus. PixelLight ist hochgrading Plugin basierend mit Plugins für zahlreiche Third-Party Middleware für Sound, Physik Engines, Eingabegeräte usw. Es besitzt einen modernen Deferred Renderer und unterstützt derzeit OpenGL und OpenGL ES 2.0.

Hier einige technische Details was auf dem Screenshot zu sehen ist:
- OpenGL Renderer (OpenGL 1.1 + Erweiterungen)
- Horizon Based Ambient Occlusion (HBAO)
- HDR Rendering mit Reinhard Tone Mapping, automatischer Helligkeitsanpassung und Bloom
- Gammakorrektur
- Shadow Mapping
- Volumetric Light Scattering (sieht man auf diesem Screenshot allerdings fast nicht) und Tiefennebel
- Material Features wie Diffuse and Opacity Mapping, Normal Mapping, Parallax Mapping, zweiseitige Beleuchtung, Specular und Gloss Mapping, Emissive Mapping, Glow Mapping, Fresnel Reflection, Environment Mapping... im Grunde das übliche Zeug was eine moderne 3D Engine heute so mitbringen muss.

Auf http://www.pixellight.org befinden sich Videos, Herunterladbare Demos, ein SDK für Windows und Linux und natürlich die URL unseres öffentlichen Git-Repositories.


Ps. Sorry wenn jemanden aus dem alten Developia Forum diesen Text bereits kennt, war mein erstes Posting seit etlichen Jahren... und scheinbar sehr unglückliches Timing da gerade zu diesem Zeitpunkt Developia als eigenständige Seite ihren letzten Atemzug machte.

[CodingCat]

Tut mir auch sehr Leid um deine Projektvorstellung, und ich finde es gut, dass du sie hier nochmal postest. Ich bin mal so frei, deinen Thread zu rekonstruieren.

Extrem toll!!
Videos sind sehr Toll!!

Nehme mir mal vor, die Engine etwas genauer anzuschauen!

Wirklich sehr beeindruckend, Respekt!

Ein kleines Detail: Die Animation der flackernden Schatten im Dungeon Demo ist zu regelmässig und langsam.

Warum sehen die Spalten zwischen den Brettern vom Tisch teilweise so verpixelt aus, obwohl besonders der Boden so cool aussieht?

Und wieso sieht der boden so cool aus? Ist das eine hochauflösende Textur oder sind das die Mapping Features, die du aufgeführt hast? Ich muss zugeben, dass ich mich schon 3-4 Jahre nicht mehr richtig mit 3D Programmierung beschäftigt hab...

Ich hab das Video nicht gesehen, aber woran liegen diese pixeligen Kanten? Kein Anti Aliasing?

Dieser Demo verwendet Deferred Rendering (Image Based Rendering), hier ist bekannermaßen Anti-Aliasing nicht ganz Trivial (... selbst aktuellste Spiele haben damit hier und da schonmal noch probleme...). Derzeit ist ein einfacher Anti-Aliasing Post Processing Effekt drinnen der allerdings nicht alle Kanten richtig erkennen kann. Auf die Dauer werde ich sicherlich hier noch etwas besseres hinbekommen.

Der großteil der zu sehenden Grafik ist Coderart, da unser Grafiker leider nur wenig Zeit hatte. Der Boden verwendet das übliche Normal & Parallaxmapping das überall in diesem Demo zum Einsatz kommt, der Effekt kommt beim Boden zufälligerweise besser rüber. (wie gesagt, *richtige* Grafiker bekämen das alles sicherlich deutlich besser hin als ich als Programmierer der das mal schnell so nebenbei mitmacht)

[CodingCat]

So, und jetzt noch mein Kommentar. ;-) Ich weiß noch, wie ich vor vielen Jahren "Blibs" und "Softgames the Game" bewundert habe, du warst damals ein großes Vorbild. Ich habe inzwischen mal die Dungeon Demo angeschaut, und muss sagen, du erfüllst deine Vorbildfunktion auch weiterhin. :mrgreen: Die Technik ist beeindruckend, nicht zuletzt wegen der großen Featurefülle. Wie setzt du das Scatteriung um? Vmtl. auch als volumetrischer Nebel im Beleuchtungspass? Wie verwaltest du die Shader-Permutationen? Du hast ja eine ganze Fülle an Materialeigenschaften implementiert, wobei natürlich mit Deferred Shading einen Vorteil bei der Gelenkstelle zwischen Geometrie und Beleuchtung hast. Welche Art von Deferred Shading hast du implementert, wie realisierst du Materialien, die sich im Beleuchtungsverhalten unterscheiden? Durch Material-IDs?

Anti-Aliasing ist natürlich eine harte Nuss im Zusammenhang mit Deferred Shading. Crytek z.B. wählt da ja den hammer aufwändigen aber scheinbar sehr effizienten Weg von Anti-Aliasing durch Reprojektion vorangegangener Frames bei leichtem Jittering, kombiniert mit Blur in der Nähe. Super-Sampling dagegen haut natürlich extrem auf die Performance. Naja, vielleicht bekommst du das auch einfach noch mit etwas Tweaking am Edge Blur hin.

Alles in allem Thumbs Up! 8 Jahre Entwicklungszeit sind gigantisch für ein privates Projekt, und das Ergebnis zeigt, dass wirklich viel Arbeit da rein geflossen ist, dein Durchhaltevermögen ist außerordentlich.

[AblazeSpace]

Danke für dieses sehr nette Kommentar. Als "Projekt" kann man PixelLight sicherlich nicht mehr ganz korrekt bezeichnen, laut Definition hat ein Projekt einen fest definierten Start- und Endpunkt - PixelLight ist für uns im Team mittlerweile eher eine Lebensart. *g*

Die richtig Interessanten Features von PixelLight finden sich unter der Motorhaube, der Grafische Teil ist eher kleiner (auch wenn das leider praktisch immer das ist, was die Leute zuerst sehen). Mein Kollege, Stefan Buschmann, hat durch das RTTI usw. beispielsweise eine Basis geschaffen, durch die PixelLight mehr als eine reine Pixel-Schleuder ist.

Das wir seit 8 Jahren bereits daran Arbeiten hat natürlich seinen Grund... zum einen nebenbei Studium, oder mal kommerzielle Firmenprojekte auf PixelLight basis erstellen + irre viele Refactoring Iterationen weil wir ständig unzufrieden mit der eigenen Arbeit sind (das wird wohl auch Dauerhaft so bleiben :/). Ich habe z.B. etliche Jahre benötigt um das Render-System so zu haben wie es nun ist - es besteht immer der Zwang alles total universell und flexibel zu realisieren so das es auf Jahre hinweg Erweiterbar bleibt. Da sich allerdings im Grafischen Sektor alles ständig ändert (auch wenn die theoretischen Grundlagen natürlich weniger sprunghaft sind), war das natürlich nicht so einfach. Mittlerweile bin ich bei einem richtigen Compositing-System angelangt, und denke das sich diese stetigen Veränderungen im Grafik-Sektor und die ständig wachsende Komplexität eigentlich nur so zu bewältigen ist. Wenn man sich viele Jahre mit Grafikprogrammierung beschäftigt, kristallisiert sich ein immer halbwegs gleichbleibender Ablauf heraus - den man in einzelne Layer zerteilen kann (wie bei Bildbearbeitung :). Der erste Layer löscht den Bildinhalt, ein weiterer Layer zeichnet z.b. im Hintergrund eine Bitmap oder nen netten Himmel, der nächste Layer füllt z-Buffer oder zeichnet nur mit Ambient oder füllt einen GBuffer oder... danach kommen meist Beleuchtungsschritte, danach weitere Effekte wie Nebel, eventuell noch verschiedenste Debug Informationen drüber-blenden, dann noch ein paar Post Processing Schritte, eventuell ein GUI (oder das GUI als Hintergrund? :).

Durch das RTTI und Plugin-System von PixelLight konnte ich dann genau diese Layer im Compositing-System als eigenständige Komponenten realisieren die sich relativ frei Anordnen, Konfigurieren und Erweitern lassen. Im Dungeon Demo sieht man es zwar nicht (im Making-Of kann man es höchstens Erahnen), aber jeder Compositing-Layer hat etliche RTTI-Attribute über die man von außen die ganzen Features ein/ausschalten kann. Weitere Layer-Implementationen für weitere Render-Techniken, Effekte etc. hinzufügen ist natürlich dann auch kein Problem mehr da alles nur Plugins sind die "eingeklinkt" werden können. Damit hat man folglich halbwegs ordentlich handhabbare Komponenten - die zudem ausschließlich für das Zeichnen verantwortlich sind. Sichtbarkeitsbestimmung wird von einer anderen Komponente durchgeführt so das im Compositing-System im Grunde nur noch Sichtbares ankommt. (was schon mehr als genug an Arbeit für eine Komponente ist :/)

Innerhalb eines Compositing-Layer kanns allerdings dann schonmal etwas heftiger zugehen, vorallem wenn sich ein Schritt nicht weiter zerlegen lässt, gerade z.B. beim füllen des GBuffers oder wenn man klassisches Forward-Rendering durchzieht. Um flexibel zu sein, muss man natürlich alle Ansätze drinnen haben, ja, sogar klassisches Fixed-Function Rendering, wenn ein Kunde ein Ururalt System hat, aber trotzdem zu mindestens noch was sehen will. Das man heute derart viele Material-Attribute unterstützen muss, macht das natürlich nicht einfacher. Daher bin ich vor ein paar Jahren dazu übergegangen ein Material nur noch als eine "Oberflächenbeschreibung" anzusehen, die dann von einem jeweiligen Compositing-Layer interpretiert werden muss. Es hat sich herausgestellt, dads dies auch den Grafikern entgegen kommt - Shader selbst schreiben, oder in irre komplexen Shader-Node Editoren herum fummeln wollen die meist nicht. Durch eine reine Material-Attribute Interpretation sind die Daten dann natürlich auch relativ zukunftssicher - z.B. könnte man irgendwann Composting-Layer schreiben die Raytracing nutzen und...

Shader-Permutationen sind natürlich ein Problem, noch bevor ich wusste das man so etwas heute "Über-Shader" nennt, kam ich irgendwann auf die Idee einen Shader zu schreiben der alle nötigen Features besitzt, und dann über, eher unschöne, #ifdef-Schalter nur die gerade für ein Material nötigen Features rein nimmt. Ohne so etwas wäre das ein noch größerer Alptraum, vorallem in Sachen Fehlerauffindung und Behebung. Einen Shader der alles kann, auch wenn ein Material gerade nur eine Diffuse-Farbe besitzt, ist Füllraten mäßig indiskutabel. Mittlerweile habe ich einen kleinen Programm-Generator drum herumgebastelt den man Shader + Schalter übergibt, und am Ende dann sein passendes Programm herausbekommt. Die Permutationen halten sich am Ende scheinbar dann doch in Grenzen (auch wenn ich an einer Stelle mittlerweile bei 32 Schalter bin...) - eventuell schon allein deswegen, weil jeder Composting-Layer eine eigene fest definierte Teilaufgabe hat.

Beim Deferred Rendering geh ich momentan einen recht klassischen Weg - auch wenn das momentan ziemlicher Overkill in Sachen Datenmengen darstellt. Ziel war es ersteinmal ein System hinzustellen das möglichst viel kann - für ganz konkrete Projekte kann man das dann als Ausgangsbasis für eigene Compositing-Layer nehmen die ausschließlich das beinhalten was benötigt wird. Beispielsweise sind 16 bit pro Albedo Kanal im Grunde zuviel, außer man will HDR-Texturen nutzen (darum lieber erstmal Universell). Material-IDs, habe ich derzeit keine im GBuffer, eventuell kommt so etwas in der Art allerdings noch, ein paar Bits hab ich noch übrig. Im Augenblick komme ich allerdings auch gut ohne zurecht. In der "PLScene.pdf"-Dokumentation im PixelLight SDK habe ich einen Abschnitt über das aktuell implementierte Deferred Shading verfasst, noch eher stichpunktartig, aber man kann dort das GBuffer-Layout nachschaun, welche Effekte auf welchen Literaturquellen basieren. Ich habe hier noch xx Grafik-Effekte die ich hinzufügen will und im Grunde auch weis wie sich diese am besten Einfügen lassen, hatte mich dann allerdings erstmal zurückgehalten da wir sonst PixelLight nie veröffentlicht hätten. *g*
Im Augenblick befasse ich mich Hauptsächlich mit Performance Optimierungen innerhalb von Compositing-Layer Implementationen - da lässt sich noch sehr viel herausholen da erstmal eine saubere und überschaubare Implementation im Vordergrund stand. Vielleicht finden sich auch irgendwann Grafiker so das sich die Technik auch vernünftig nutzen lässt - das ist immer etwas frustrierend, wenn man weiß es könnte deutlich besser aussehen, man als Programmierer allerdings eher nur beschränkte Grafische Fähigkeiten besitzt, und gute, frei nutzbare 3D Modelle mit Diffuse, Normal, Height, Specular etc. Map eher selten bis gar nicht zu finden sind. :/
(schon gar keine ganzen Szenen mit solchen Daten)

Aber wie erwähnt, der Grafische Teil macht bei PixelLight eher reinen kleinen Teil aus.

Hoffentlich entwickelt sich eine aktive Community um PixelLight herum, wir selbst haben noch sehr viel vor, allerdings wären so Dinge wie ein DirectX 10/11 Renderer oder ein umfangreicher Editor nett - bei einem 2 Mann Team muss man allerdings irgendwo einen Schlusstrich ziehen (auch wenn dies total schwerfällt) und sich auf das wesentliche Konzentrieren.

Ok, nun weiß ich wieder wieso ich mich von Foren etc. meist eher fernhalte... ich schreibe zuviel. *g*