[Projekt] CyberDive (MARPG)

[Zudomon]

Kurzupdate: die Control-Klasse ist bei 640 Zeilen ... das passiert halt wenn man ein vernünftiges Event-System macht

BAD PROGRAMMING!

[Artificial Mind]

Kurzupdate: die Control-Klasse ist bei 640 Zeilen ... das passiert halt wenn man ein vernünftiges Event-System macht

BAD PROGRAMMING!

Selber! xD
Aber was geh ich auch auf nen "Bad programming" Kommentar von nem Delphi-programmierer ein *silly me*

2be honest:
Das meiste davon sind Kommentare. Es sind viele Deklarationen und sehr wenig Funktionen (bis jetzt). Ich will das GUI eh im Endeffekt opensource machen, deswegen gebe ich mir besonders bei der Grundklasse mühe.

[Artificial Mind]

Hm ich bin momentan echt unsicher wie ich das GUI weitermachen will...

Ich will das GUI-System sowohl für C++ als auch C# benutzen können und ich weiß nicht wie ich das anstellen soll, ohne dass ein widerliches C-Interface dabei rauskommt...
Hat jemand da ne gute Idee?

[joggel]

Kann man das evtl. unter Windows über diese COM-Schnittstelle lösen?

[Artificial Mind]

Hm ja da gibt es Möglichkeiten, nur das ist weder einfach, noch unkompliziert, noch hat es einen angenehmen Workflow.

Wir (mein Kumpel mit dem ich das GUI zusammen entwickel) machen das jetzt erstmal in C#, dann kann man das sehr einfach in C++/CLI verwenden, das muss erstmal tun. Später kann man das System immer noch portieren wenn die Algorithmen stehen und in C# entwickelt es sich wesentlich angenehmer.

[Artificial Mind]

Falls ihr euch wundert, weswegen es gerade so ruhig bei mir ist, dann liegt das nicht nur am neuen Semester:
Für die Uni mache ich ein Projekt in welchem ich eine Grafikengine schreibe, die auf C++ und OGL 3.3 basiert und viele fortgeschrittene Techniken benutzt. Wie ich im IRC schon ein wenig gezeigt habe, läuft bereits das Deferred Shading, das HDR mit Bloom, das Parallaxmapping und ich habe die drei Beleuchtungsmodelle Phong (Gips bis Plastik), Cook-Torrance (Metall) und Oren-Nayar (Stein, Tapete, rauhe Oberflächen) bereits implementiert. Dazu ein kleines Framework für prozedurale Geometrie und Texturen (von denen Fractal Noise bereits läuft und Cellular Textures so halb).
Je nachdem, was meine Betreuer sagen, kann ich die auch hier vorstellen, während ich sie entwickle (und nicht erst nach der Benotung), aber da ich noch keine Rückmeldung habe, kann ich auch noch nichts offiziell posten

Was für CyberDive dabei rausspringt, ist genau dieses Framework bzw. dessen Struktur (von C++ nach C# porten ist nahezu kein Problem, wenn man eh Templates größtenteils vermieden hat, um das Compilen und die Abhängigkeiten klein zu halten).

Der große Vorteil (von Mogre weg zu kommen): Wenn ich mich nicht irre, sollte es dann trotz C#-Natur auf Linux laufen. Als Physik-Engine wollte ich mir dann mal Bullet angucken bzw. die Linux PhysX Treiber

[Artificial Mind]

So, YADC ist abgegeben und ich will wieder voller Energie und Euphorie an CyberDive weiterschreiben!

Ich bin also gerade dabei, die Engine von YADC quasi als zweite Iteration in C# zu implementieren und die Ecken und Kanten die die erste Iteration hatte etwas abzuschleifen. Das Ganze läuft nun mit OpenTK als C# OGL 3.3 Port und sollte damit prinzipiell auch unter Linux laufen, wenn ich alle WinForms-Debug-Fenster rausnehme.

Das erste neue "Convenience-Feature" ist Shader-HotSwap.

Debug Fenster mit Shader HotSwap

Ich kann nun Runtime den Shadercode bearbeiten (in dem rechten Debug-Fenster), ihn neu kompilieren lassen, mir die Compile-Errors angucken und dran rumwerkeln. Der Compiler ist so schnell, dass man es kaum merkt. Außerdem wird der HotSwap immer genau zwischen zwei Frames gelegt, ohne irgendeinen Zustand zu korrumpieren.
Ein super praktisches Feature, dass mir sicher später viel Ärger ersparen wird.

[Artificial Mind]

So die neue Engine ist in vielen Punkten flexibler, C# programmieren macht schon spaß

Deferred Shading, Transparenzen und HDR

Es funktioniert wieder das Deferred Shading, Transparenzen und HDR Rendering mit Bloom. An der Seite sieht man diesmal im Debug-Window eine genaue Performance-Anzeige mit den CPU Zeiten und den OpenGL Zeiten (sprich Timer Queries), sodass ich auch die Grafikkartenzeiten gut sehen kann.

Transparenzen werden hier erstmal Objektweise sortiert, das muss erstmal reichen. Sobald ich mir Gedanken über meine Weltrepräsentation gemacht habe, wir hier sicherlich eine Art kd-Tree landen, der die Objekte beinhaltet und damit in O(n) nach Kamera-z sortieren kann.
Alternativ nehme ich eine Art SmoothSort (sortiert in O(n) bei vorsortierten und nahezu O(n) bei nahezu vorsortierten Daten) und eine moeglichst lockere Halbordnung (sowas wie Objekt 1 < Objekt 2 nur dann wenn sich die Bounding Volumes von den beiden Objekten nach Projektion auf Image Plane schneiden und Objekt 1 hinter Objekt 2 liegt, wenn sich die Volumes nicht schneiden ist die relative Ordnung von den beiden Objekten egal). Damit sollte dann pro Frame nicht allzu viel Sortieraufwand entstehen.

[Jeason]

Verwendest du die Standard OpenTK Math Klassen? Welche OpenTK Version verwendest du? Hattest / Hast du irgendwelche besondere Probleme beim portieren?

[Artificial Mind]

Ja ich benutze die Standard OpenTK Math Klassen, die sind auch soweit ganz ok, leider nicht ganz so umfangreich wie GLM. (Ich vermisse z. B. Matrix3 oder Matrix3x2)
Ansonsten ist OpenTK super, endlich Exceptions wenn man was falsch macht in OpenGL, keine 10.000 GL_XYZ Definitionen mehr, sondern schön immer die richtigen Werte als Enum für die Methoden.

Eine Sache, auf die man recht schnell reinfallen kann, ist, dass man, wenn man Texturen benutzen möchte und ein Vector4[,] data Array hat, dann muss man das mit data[y,x] addressieren, einfach wegen des Speicherlayouts.

Als OpenTK Version habe ich mir die aktuelle Nightly gezogen, da die offizielle OpenTK 1.0 Version noch kein OpenGL 3.3 unterstützt, sondern erst bei OpenGL 3.2 ist. (Die Nightly kann sogar OGL 4)

Achja ein anderer netter Pitfall: der OpenGL Context ist Threadabhängig. Sprich: Wenn man in einem Destruktor OpenGL-Ressourcen freigibt, kriegt man eine NullReferenceException weil der Context im GC-Thread natürlich nicht gültig ist.

[Artificial Mind]

So nun gibt es eine zweite Rendering-Pipeline (Eine Engine = ein Context, jede Engine kann mehrere Pipelines enthalten), die für prozedurale Inhalte, die auf der Grafikkarte erstellt werden sollen, verantwortlich ist.

Procedural Content Pipeline

Zu sehen ist die gleiche Szene wie im letzten Update, nur dass diesmal ein Textured Quad in der Mitte ist, der nach 5 Sekunden mit dem Inhalt der aktuellen Szene (vor Postprocessing) gefüllt wird.

Diesmal zeigt das Debug-Fenster am Rand den Aufbau der aktuellen Rendering Engine mit Pipelines und Passes. Klickt man auf eine Pipeline, werden alle Shared Textures (Texturen, die zwischen verschiedenen Passes geshared sind) angezeigt und man kann diese per Klick anzeigen lassen (dazu werden die von der Grafikkarte geladen und als Bitmap angezeigt und koennen auch direkt ins ClipBoard kopiert werden)
Hätte man auf einen Render Pass geklickt, so hätte man Einstellungen zu diesem Pass (z. B. Wireframe) verändern können.

Ich hoffe das ich die meisten Texturen einfach per Shader "backen" kann, da dies auch die Performance von C++ um längen schlagen sollte

[RazorX]

Sieht echt faszinierend aus was du da mit C# zusammen baust. Das bringt mich ins grübeln ob ich das nicht auch mal versuchen sollte (finde C# deutlich umgänglicher als C++, wenn auch in manchen Situationen deutlich langsamer je nachdem wie viele Exceptions man nutzt). C# dürfte vorallem was das SceneManagement mit dem Reflections Bereich sehr interessant werden, wodurch States direkt am Objekt manipuliert werden können ohne die GUI extra darauf auszulegen.

[Artificial Mind]

Ja, C# programmiert sich echt Größenordnungen angenehmer als C++...
Was die Geschwindigkeit angeht, so sollte man halt wissen, was in C# schnell ist und was nicht. Exceptions sollte man normalerweise nicht im Programmfluss haben (sprich: es sollte im Schnitt 0 Exceptions pro Frame geben ).
Datenlastige Operationen, wie z. B. prozedural Texturen/Geometrie erstellen oder soetwas ist natürlich in C# langsam, aber man kann ja C++ Module relativ bequem und performant einbinden.

[RazorX]

Mal kurz zum Verständnis: Verstehe ich das richtig das du dann pro "Engine" einen Thread erstellst, die jeweils einen OpenGl Context erstellen und unabhängig von einander agieren? Wie transferierst du dann Resourcen des einen auf den anderen Context? (hab was OpenGl angeht wenig Erfahrung, ist jetzt nur etwas was mir ins Auge sticht).

[Artificial Mind]

Ja, pro Engine müsste ein Thread erstellt werden mit je eigenem Context. Transferieren würde man dann wohl über CPU machen müssen (Buffer read -> Buffer write). Mehrere "Engines" werde ich allerdings selten brauchen, wenn, dann wahrscheinlich als Zusatzoption für mehrere Grafikkarten, dass High Quality Texturen auf der ungenutzten Karte gerendert werden können und die dann gespeichert werden.