[Projekt] CyberDive (MARPG)

[Artificial Mind]

Man Dankt ;)

@Industriegebiete:
es gibt dort keine Verbindung zwischen den Highways, das ist richtig, das darf passieren. Dass es dort allerdings keine Verbindung der Zufahrtsstraßen gibt, ist etwas ärgerlich, das werd ich bei Gelegenheit korrigieren. Momentan sind grade die Straßen in der Stadt dran.

@Serpentinen:
Also prinzipiell können die das, einen Ansatz davon sieht man zwischen dem linken Industriegebiet und der Stadt. Allerdings habe ich momentan die Straßenteilstücklänge auf 2km (nach unten) beschränkt, damit meine Graphen (auf denen ich kürzeste Wege berechne) nicht mehrere tausend Knoten und Kanten haben. Mal gucken, wie ich diese gescheit einbaue.

[Artificial Mind]

Mein Sonntagsupdate ;)

Straßenkarte des Stadtkerns

(Achtung, Auflösung 6k x 6k)
Auch wenn ich noch nicht endgültig zufrieden bin mit der Stadtkarte, so bleibt es das erstmal. Ich möchte mich mal wieder anderen Baustellen zuwenden ;)
Als nächstes werde ich entweder ein eigenes GUI für Ogre implementieren oder eine 3D-Ansicht der Stadtkarte.

Allerdings fängt morgen das Semester an und am Wochenende ist die devmania und die Woche drauf darf ich mich von zwei Weisheitszähnen verabschieden, also wird das nächste Update wohl erstmal ein bisschen brauchen. Vielleicht kann ich zwischendurch was posten, vielleicht nicht.

[joggel]

Als nächstes werde ich entweder ein eigenes GUI für Ogre implementieren oder ...

Was ist eigentich mit CEGUI?
Oder kann man das wegen C# nicht benutzen?
Ansonsten Das?

[Artificial Mind]

Ich habe CEGUI, Miyagi und MyGUI probiert und MyGUI ist das beste imho davon.
Allerdings sind die alle mehr oder minder unschön (programmtechnisch, implementierungstechnisch).

Features die ich sehr vermisse und nicht mal eben nachgepatcht sind:
- Tooltips (ganz wichtig)
- Animationen
- ausgereiftes Event-System

Ich wollte mich prinzipiell an WinForms orientieren, allerdings Rendering und Logik trennen, damit das einfach portiert/angepasst werden kann.

[Tejio]

Was ist eigentlich mit XAML und WPF? Dank Visual Studio und Expression Blend sehr einfach einzusetzen. Dabei hast du gleich Tooltips, Animationen, Trennung von Rendering und Logik dank MVVM und ein Event-System. Nicht wundern, ich arbeite mich momentan in das Thema erst ein. Noch ist alles gut und schön....

[Artificial Mind]

Und das kann ich in 3D-Applikationen benutzen? In Mogre integrieren?
Als tooltips meine ich auch nicht einzeilige Descriptoren oder meinetwegen mehrzeilige Balloons, sondern eigene Controls quasi. z. B. Anzeigen für Items, wo dann potentiell parallel mehrere andere Tooltips aufgehen und einen Vergleich anzeigen und soetwas. Außerdem muss ich das Mouse-Handling selber kontrollieren können wenn z. B. die GUI in die 3D-Welt integriert ist und somit verzerrt/rotiert ist.

[Chromanoid]

http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx / http://www.ogre3d.org/forums/viewtopic.php?t=44263 / http://www.ogre3d.org/addonforums/viewt ... =8&t=14094 evt. interessant, habs kurz gegooglet, weil ich es selbst interessant fand...

[Artificial Mind]

Ich hab grade auch ein wenig background-research betrieben und es scheint ne anstängide Portion von der Performanz zu schlucken, wenn man das WPF GUI in Mogre einbetten will (Und selbst Mogre in WPF eingebettet scheint signifikant zu bremsen). Man müsste wohl über quasi-hacks an die WPF Texturen direkt kommen ...
Und dann steht immer noch das Problem, den Input vernünftig zu mappen.
Eigentlich würde ich gerne WPF nutzen weil es vielversprechend aussieht und ich mich seit längerem mal etwas genauer damit beschäftigen will. Aber ich bin mir nicht sicher ob die Hürden für den produktiven Einsatz in einem Game nicht etwas zu hoch sind.

EDIT:
@Chromanoid:
Die Links behandeln soweit ich das sehe Ogre in WPF und nicht WPF in Ogre.

[LONy]

Hi,
wie geht es dir und deinen Löchern wo vorher die Weißheitszähne waren? :D
Wann gibt es mal einen neuen Screenshot? Jeden Tag schau ich hier ins Forum und warte sehnsüchtig drauf ;)

Gruß, LONy

[Artificial Mind]

Ja mittlerweile geht es wieder etwas besser, danke der Nachfrage ;)

Als nächstes bastel ich mir nen vernünftiges GUI, davon sollte ich auch vernünftig Screenies machen können. Aber ein bisschen musst du dich noch gedulden :)

[FlashbackOwl]

In welcher Sprache programmierst du das eigentlich ?
Das Projekt interessiert mich sehr und ich freue mich drauf neues zu lesen :)

[Artificial Mind]

C# ;) Ja, ich tue mein bestes, ich will auch das das was wird :D

[Zudomon]

lol... guckst du hier jede Minute ins Forum, dass du so eine kurze Responsezeit hast?

[Artificial Mind]

Ich krieg ne mail *g*

[Artificial Mind]

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

[Zudomon]

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

BAD PROGRAMMING! :lol:

[Artificial Mind]

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

BAD PROGRAMMING! :lol:

Selber! xD
Aber was geh ich auch auf nen "Bad programming" Kommentar von nem Delphi-programmierer ein :D *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.