[Projekt] CyberDive (MARPG)

[CodingCat]

Die Frameworks, die ich kenne, bieten in irgendeiner Weise eine separate Font-Metrics-Komponente, die sowohl dem Rendering als auch dem Layouting Informationen über die Ausmaße von Buchstaben / Zeichenketten bereitstellt. Ansonsten ja, UI-Entwicklung ist anstrengend, quäle mich gerade selbst durch (und ich nutze dabei schon ein fertiges Framework ). Sieht auf jeden Fall gut aus und hört sich gut an, was du da machst; über Ingame-UI will ich eigentlich gar nicht nachdenken. Aber diese Distance-Field-Geschichte wollte ich auch schon immer mal implementieren, schön, dass sie auch bei dir gut funktioniert.

[Artificial Mind]

Ja, ich bin über die Signed-Distance-Fields auch echt positiv überrascht, die lassen sich auch für nahezu alle anderen 2D-Formen benutzen.

Wenn meine Ingame-UIs nachher alle in 3D bedienbar sind, bin ich eigentlich an meinem Ziel. Leicht futuristische Welt mit 3D-Overlay-Glow-GUIs, das passt einfach. (*hust* Ghost in the Shell *hust*) Wenn man in nen Laden reinkommt und keinen vernünftigen Spam-Schutz hat, dann "ploppen" überall so kleine 3D-Werbefenster auf und wollen einem irgendwas andrehen oder so, da lässt sich viel Unsinn mit treiben

Eine Font-Metrics-Klasse hört sicht super an, da kann ich dann auch in hübsch Zeilen-Wrapping, Alignment usw. implementieren.

[Schrompf]

Ich habe bei meiner GUI dasselbe Problem... der Renderer ist getrennt von der GUI, demzufolge kann die GUI manche Eingabeereignisse nicht so genau interpretieren. Das gleiche Spiel ja auch bei automatischem Layout - zur Erklärung: ich bin einer der vollkommenen Idioten, von denen Du so charmant vorhin gesprochen hast, die die größte Sünde überhaupt begehen: ich baue meine GUI im Code zusammen. Sind vielleicht zwei drei Zeilen pro Komponente, das Layout passiert automatisch. Jede Komponente hat eine Minimalgröße und optional einen Wachstumswunsch, und das Layout ordnet nach diesen Vorgaben die Komponenten untereinander an. Nur wär es halt manchmal doch praktisch, die Kenntnisse des Renderers da zu haben, um z.B. zu bestimmen, wie groß eine Textbox sein müsste, um allen Text darin darzustellen.

Ich werde das wahrscheinlich per Callback-Interface lösen. Immerhin ist ja üblicherweise eine GUI an einen Renderer gebunden, Austausch zur Laufzeit passiert nur selten. Und wenn, kann man halt einfach das automatische Layout nochmal anstoßen. Mit dem Interface könnte dann die GUI bequem Textbreiten, -größen und -positionen abfragen, ohne sich selbst die Hände mit Layout-Details schmutzig zu machen. Bisher bin ich aber ehrlich gesagt komplett ohne ausgekommen... die GUI sollte gleichermaßen per Tastatur, Maus oder Gamepad bedienbar sein, da ist die genaue Positionierung des Cursors im Eingabefeld das kleinste Problem.

[edit] Das Callback-Interface wär ja quasi die Font Metrics... am Ende reden wir doch alle vom Gleichen

[Artificial Mind]

Ich habe selbst auch schon genügend GUIs per Hand gecoded und mich ab und zu nichtmal geschämt. Die Screenshots deiner GUIs sahen aber auch nach Konsolen-GUIs aus (also GamePad-kompatibel wie du sagtest), da ist ein lineares Layout und einfache Struktur ja quasi Rahmenbedingung. Dort ist auch der GUI-Code nicht so unübersichtlich. Meine GUIs haben allerdings absolute Positionierungen und sollen auch für komplexere GUIs benutzt werden können. Und wenn ich mir mal den Characterscreen von einem handelsüblichen MMORPG angucke (ja, ich wähle hier ein Extrembeispiel, aber ARPG Char-Screens sehen meist nicht allzu viel weniger komplex aus), dann möchte ich die 100 Labels, 30 Images, 50 Buttons in Kreuz-und-Quer-Anordnung nicht per Hand coden müssen. Ich denke für dein Spiel ist dein GUI genau richtig, aber ich glaube nicht, dass ich bei meinem Spiel mit so einfachen Layouts und Bedienungen auskommen werde.
Dazu kommt, dass ich das Gefühl habe, dass die meisten Spiele mittlerweile (oder immernoch) die GUI-Bedienbarkeit nicht durch gute Technik lösen, sondern durch Trivial-GUIs. Wenn ich mir z. B. Skyrim angucke, dann muss ich sagen, dass das GUI dort grauenvoll ist. Nicht nur, dass es ein Konsolen-GUI auf den PC portiert ist, es ist auch noch schlecht portiert und die Maussteuerung im GUI hat sicher der Kopier-Kaffee-Praktikant in der Mittagpause geschrieben.
Ich plane für mein Spiel, dass viel Wert auf Information gelegt wird und da brauche ich einfach ein solides GUI für. Insbesondere Strg-C/Strg-V sollte bei nahezu allen Texten funktionieren. Es ist auch ein kleines "Internet" im Spiel geplant, für dass ich dann noch einen dezenten HTML-Converter in mein GUI-Format schreiben werde.

[edit] @Schrompf: Ja, dass das Callback-Interface die Font-Metric-Klasse repräsentiert ist mir auch eben aufgefallen^^ Um ehrlich zu sein habe ich die strikte Trennung von Rendering und Logik im GUI von dir abgekupfert, weil ich die Idee so gut fand, als du das in deinem Thread geschrieben hast

[dot]

Ich bin immer noch am überlegen wie ich für TextBoxen einbaue, dass die Cursor-Position richtig gesetzt wird, wenn man reinklickt. Denn die komplette Rendering-Logik ist von der GUI-Logik getrennt (also die GUI-Logik ist sogar eine eigene dll), die einzelnen Buchstabengrößen kann aber eigentlich nur der Renderer kennen ... Vielleicht muss ich da irgendwie nen ekligen Feedbackweg einbauen, der dann das schöne Public-Interface der Klasse beschmutzt. Oder hat jemand einen besseren Vorschlag?^^

Ich weiß nicht wie dein Font-Rendering genau abläuft, aber machs doch so wie DirectWrite: Trenn das Layouting vom Rendering ab. Dann hast du eine eigene Komponente für das Text-Layout, die dir zu String und Layout-Box ein Objekt liefert, das einen fertig gesetzten Textblock repräsentiert. Und das kann dir eine Methode hitTest() bieten oder sowas...

[Artificial Mind]

Ich weiß nicht wie dein Font-Rendering genau abläuft, aber machs doch so wie DirectWrite: Trenn das Layouting vom Rendering ab. Dann hast du eine eigene Komponente für das Text-Layout und die kann dir einen HitTest für Textblöcke liefern.

Ja, diesen Job soll die Font-Metrics-Klasse bzw. dass Callback-Interface übernehmen.
Allerdings kann das nicht komplett vom Renderer entkoppelt werden, weil ja z. B. nur die Font (die mit in der RenderEngine-dll ist) wirklich weiß, wie groß die einzelnen Buchstaben sind. Ich werde also gucken, dass ich in meiner GUI-dll die Font-Metrics-Basisklasse habe und in der RenderEngine-dll die Signed-Distance-Font-Klasse die entsprechenden Metriken zur Verfügung stellt.
Ich muss allerdings noch gucken wie ich so allgemein wie möglich im GUI eine "Font" angeben kann, egal wie die im Endeffekt realisiert ist. Allzu lose Kopplung ist halt auch problematisch. Ich denke ich werde im GUI sowas wie eine "Wunsch-Font" angeben und der aktuelle Renderer muss dann gucken wie den Wunsch so gut wie möglich erfüllen kann.

[Artificial Mind]

So, ich habe nun eine Font-Metrics Klasse.
Damit werden jetzt alle 9 Text-Aligns richtig unterstützt und AutoSize von Labels funktioniert.
Außerdem funktioniert Text-Selektion, inklusive multi-line Selektion.

Text-Selektion

Hier sieht man einen selektierten Textblock aus einem etwas längeren Text, der sowohl horizontal, als auch vertikal zentriert ist.

[Artificial Mind]

So es hat sich wieder ein bisschen was getan (wie gesagt, einfach schreien wenn ich zu viele kleine Updates raushau, ich werd mich dann zusammenreißen)

• Neues Control: PictureBox, Renderer wieder als signed-distance (für den Rahmen) implementiert
• Login-Logik geht wieder
• Ressourcensystem
  
  • Virtuelles Ressourcendateisystem (Pfadtrennung über beliebige Menge an Trennsymbolen, momentan einfach / und \ )
  • Verschiedene Ressourcenprovider können an verschiedene "Nodes" im "Ressourcen-Baum"/"Ressourcen-DAC" eingehängt werden, die ab dort die Auflösung des Ressourcenpfades übernehmen
  • Filesystem-Node für normale Filesystem-Zugriffe mit jeweils eigenem Basispfad
  • Link-Node für "symbolische" Links innerhalb des Ressourcensystems
  • Ressourcen werden asynchron geladen
  • C#-Generic-und-Reflection-Wizardry

Login - City Karte

Ich erzähl mal kurz die Geschichte dahinter, wie das Bild geladen wird:

• Client stellt dem RessourcenManager eine Anfrage nach "DynamicContent/Images/citymap.png"
• DynamicContent ist ein FileSystem-Node mit Basispfad "Content/Dynamic/" und löst die Ressourcenanfrage also nach "Content/Dynamic/Images/citymap.png" auf
• Die Datei ist allerdings nicht vorhanden, also wird das OnMissing-Event von der Ressourcenbeschreibung aufgerufen
• Bei Erstellung der Anfrage wurde dort hinterlegt, dass im Falle OnMissing der Server nach der Ressource gefragt werden soll
• Es wird also eine Nachricht an der Server verfasst, dass man doch bitte die Datei "Images/citymap.png" haben möchte (ich benutze den Node "DynamicContent" für Content, der vom Server kommt)
• Der Server erhält die Anfrage, dass ein User-Client Content haben will und übersetzt den Pfad in "UserContent/Images/citymap.png"
• UserContent ist ein Link-Node und enthält momentan eine einfache Übersetzungstabelle von Pfaden
• Dort steht "Images/citymap.png" (der relative Pfad von UserContent aus gesehen) als Link nach "FileSystem/WorldSave/Cities/citymap.png" drin
• FileSystem ist ein FileSystem-Node mit Basispfad "" (also relativ zur Working Dir)
• Es wird also die Datei "WorldSave/Cities/citymap.png" aus dem Dateisystem geladen
• Dieses Bild wird (momentan noch unkomprimiert) an den Client als Antwort gesendet
• Der Client bekommt also seinen Content und speichert diesen erstmal ab (einfach ins Dateisystem), damit das nächste Mal der Server nicht gefragt werden muss
• Daraufhin wird der Ressource beim Client gesagt, dass das Laden nochmal versucht werden soll
• Datei ist nun da, also wird das Bild geladen, OnLoad getriggert und das Bild als Image für die PictureBox gesetzt

Natürlich gibt es da noch dran zu feilen, aber so wird relativ transparent eine Ressource vom Server geladen.
Der Grund, warum "UserContent/Images/citymap.png" als Link implementiert ist, ist der, dass zum einen die Ordnerstruktur auf Server und Client anders ist und zum anderen, damit der Client nicht unbeschränkten Zugriff auf das Dateisystem des Servers hat. (Über diesen Link-Node lässt sich sehr gut filtern, was geladen werden darf und was nicht, ohne das eigentliche Laden doppelt schreiben zu müssen)

[Artificial Mind]

Direction Dependent Transparency

Solange man sich nicht innerhalb oder dicht an diesem transparenten Objekt befindet, werden die Transparenzen aus allen Kamerarichtungen richtig gezeichnet, ohne, dass ich pro Frame 260.000 Indices sortieren muss.

Ich habe das einfach mal "Direction Dependent Transparency" getauft.
Anstatt in meinem Mesh einen Vertex Buffer und einen Index Buffer zu haben, habe ich einen Vertex Buffer und mehrere Index Buffer, wobei jeder Index Buffer einer Richtung entspricht. Man kann dann einfach eine beliebige Anzahl von Richtungen angeben und das Mesh errechnet für jede Richtung einen Index Buffer. Dies mache ich einfach, indem ich alle Mittelpunkte der Faces auf die Gerade Objektmittelpunkt + lambda * Richtung projeziere und jeweils den gerichteten Abstand (sprich positiv für "in die Richtung" und negativ für "entgegen" der Richtung) zum Objektmittelpunkt ausrechne. Das ist mein Sortiertkriterium für die Indizes zu dieser Richtung. Im Bild habe ich das z. B. für 4 Richtungen (die 4 Diagonalen der xz-Ebene, y ist Oben) gemacht. Beim Rendern muss ich dann einfach nur noch die Richtung auswählen, die den kleinsten Winkel zur Kamerarichtung (Richtung vom Objekt zur Kamera) hat, den entsprechenden Index Buffer binden und rendern. Und 4 mal Punktprodukt ist einfach weniger Aufwand als 260k Indizes zu sortieren
Das Verfahren versagt halt, wenn man sich zu dicht am Objekt befindet, weil dann die Projection auf die Kamerarichtung eine sehr schlechte Approximation zum Kameraabstand ist. Ich denke auch für nicht-Heightmaps (im Bild ist das ja nur eine Heightmap) sollte man mit 8 Richtungen gute Ergebnisse erzielen.

Und nun darf jemand mir verraten, wie das Verfahren wirklich heißt, denn ich hab mir das zwar ausgedacht, aber dass muss es ja schon irgendwie geben

Ist auf alle Fälle eine sehr gute und kostengünstige Variante zum "Alle-Faces-Sortieren", solange man halt einige Rahmenbedingungen erfüllt hat. (Natürlich gibt es Fälle, wo Sortieren alleine nicht reicht, aber in allen anderen sollte meine Approximation aus sicherer Entfernung funktionieren, notfalls muss man mehr Richtungen testen) Achso, man bezahlt natürlich auch mit VRAM, aber ich hoffe, die Indexbuffer sind nicht allzu groß

Edit: man könnte in die Versuchung geraten und behaupten die Transparenzen im Bild seien falsch, weil ja ab und zu irgendwas "abgeschnitten" aussieht, aber das ist richtig so, weil dort die Krümmung für eine "Doppellage" sorgt. Es geht ein bisschen der 3D-Eindruck dadurch verloren, dass ich noch keine Beleuchtung für transparente Objekte habe.

[Artificial Mind]

Hm, ein einfacher Fresnel-Term macht das ganze schon etwas besser

Transparenz mit Fresnel-Term

[Andre]

Das ist eine ziemlich coole Idee.

Sieht man das umwechseln der IndexBuffer sehr stark? (Wenn ich das richtig verstanden habe)

[Artificial Mind]

Wenn du nicht zu nah am Objekt bist, sieht man das gar nicht, weil die Dreiecke dann immer richtig sind.
Wenn du nah dran bist, gibt es halt Artefakte, weil einige Dreiecke in der falschen Reihenfolge gezeichnet werden und diese Artefakte springen im Allgemeinen, wenn der IndexBuffer gewechselt wird.

[Artificial Mind]

So ich habe wieder ein kleines Update.
Der Client hat jetzt Zugriff auf Ressourcen zu den einzelnen Städten.
Außerdem gibt es eine neue Rendering Pipeline, die "Basic Rendering Pipeline", die einen einfachen Forward Renderer ohne weiteren Schnickschnack (allerdings inklusive Transparenzen und optional HDR, also RGBA16) implementiert. Dieser ist für das Offscreen-Rendern kleinerer Szenen gedacht, wie z. B. eine transparente Version der Heightmaps der Städte. (Die Höhenskalierung ist allerdings wieder überproportional, da die einzelnen Stadtumgebungen 300km x 300km umfassen und man "normale" Höhendifferenzen sonst gar nicht sehen würde )
Die Heightmaps werden dabei in ein neues Control, die sogenannte "TextureBox" gerendert. Das ist quasi ein Control für ein Rendertarget bzw. eine beliebige Textur.

City Preview - weit

Erwähnenswert ist außerdem, dass die Heightmaps in der TextureBox mit 2-fach Supersampling berechnet werden, indem sie einfach in der doppelten Größe gerendert sind

City Preview - nah

Video zu den Transparenzen (sieht in bewegt auch viel eindrucksvoller aus)

(Die Ruckler sind halt fraps, wie man das nunmal kennt ...)

[LONy]

Ich find deine ausführliche Berichterstattung klasse, so wie es mit deinem Projekt weiter geht da bekommt man richtig lust selbst wieder was zu machen! weiter so, ich verfolg die Entwicklung gerne...

[Artificial Mind]

Ich find deine ausführliche Berichterstattung klasse, so wie es mit deinem Projekt weiter geht da bekommt man richtig lust selbst wieder was zu machen! weiter so, ich verfolg die Entwicklung gerne...

Danke, sowas motiviert beide Seiten

Kurzupdate:
Beim Generieren meiner prozeduralen Meshes (wie z. B. Heightmaps), habe ich bei vier Vertices, die im Prinzip ein Viereck bilden, ja zwei Möglichkeiten daraus zwei Dreiecke zu bilden (ich habe die Freiheit die Richtung der Diagonalen zu wählen). Vorher hatte ich immer eine feste Richtung eingebaut, was dazu führte, dass bei niedriger Gitterauflösung teilweise sehr sichtbare Artefakte (in Form von "Zacken") entstanden. Nun prüfe ich beim Generieren welche Diagonale welchen Approximationsfehler zur Oberfläche macht (jedenfalls eine Abschätzung dieses Fehlers ) und wähle die Diagonale mit dem kleineren Fehler.

Edge Flipping in Procedural Mesh Generation

Im Bild: Oben: Worst-Case, Unten: korrigierte Variante. (Beide Bilder haben die gleichen Vertices und damit die gleiche Meshauflösung)