In den letzten Tagen hatte ich wieder Zeit, an der 3D-Engine SeeingSharp 2 weiterzuarbeiten. Diesmal ging es darum, allgemein das Arbeiten mit Texturen zu verbessern. Genauer geht es um das Texture sampling. Texture sampling bezeichnet den Prozess, wie Farbinformationen aus Texturen gelesen werden. Direct3D bietet hierbei eine lange Liste von Einstellungen. So kann etwa beeinflusst werden, nach welcher Logik Texturen auf einer Fläche gekachelt werden sollen. Auch die Art, wie die Farben zweier benachbarter Pixel auf einer Textur vermischt werden, kann konfiguriert werden. Letzteres ist dann relevant, wenn eine Textur am Monitor mehr oder weniger Pixel beansprucht, als in der Textur selbst zur Verfügung stehen. Insgesamt hat SeeingSharp 2 bis jetzt nur ein Standard-Set an Einstellungen mit Anisotroper Filterung [1] unterstützt. Passt dieses Standard-Set nicht, so hatte man bis dato keine Möglichkeit, das Texture sampling zu beeinflussen.
SeeingSharp 2
RingBuffer in C#
In .Net existiert eine Vielzahl von Klassen zur Auflistung von Objekten oder Strukturen. Ein einfaches und häufig verwendetes Beispiel ist die Array. Die List<T> ist ebenso stark verbreitet. Daneben gibt es eine Vielzahl von Klassen, welche diverse Spezialfälle abbilden. So etwa für parallelen Zugriff mit den Klassen aus dem Namespace System.Collections.Concurrent. Einen Spezialfall hätte ich allerdings schon häufiger vermisst: Den RingBuffer (oder auch Circular Buffer [1]). Ein RingBuffer dient dazu, eine fortlaufende Liste mit einer maximalen Länge abzubilden. Wenn über die maximale Länge hinaus geschrieben wird, so werden einfach die ältesten Elemente überschrieben. Gehen wir von der max. Länge von 100 aus. Wenn das 101. Element hinzugefügt wird, fliegt das erste Element raus. Dieses neue Element ist dann aber nicht der neue Start der Liste. Der Start der Liste ist immer das älteste Element. Wo benötigt man so ein Verhalten? Ein gutes Beispiel dazu habe ich in der 3D-Engine SeeingSharp. Zur Berechnung der durchschnittlichen FPS (Frames per Second bzw. Bilder pro Sekunde) wird der aktuelle FPS Wert je Sekunde berechnet und an einer Liste angehängt. Nachdem diese Liste eine bestimmte Länge erreicht hat, wird mit jedem neuen Wert der älteste Eintrag entfernt. Die durchschnittlichen FPS ergeben sich anschließend mittels des Durchschnittswerts aller Elemente in der Liste. Mit einer List<T> könnte man dieses Verhalten per Add und RemoveAt(0) relativ einfach abbilden, bei einem RingBuffer dagegen steckt dieses Verhalten bereits im Add. Dazu gibt es beim RingBuffer noch weitere Vorteile aus Sicht der Performance, doch dazu im Verlauf dieses Artikels mehr.
Worklog SeeingSharp 2: Getting Started für WinUI 3
Bisher gab es in SeeingSharp 2 zwei GettingStarted Projekte: Einmal für Windows.Forms und einmal für WPF. WinUI 3 hat nun zusammen mit dem WindowsAppSdk 1.1 einen recht guten Entwicklungsstand erreicht. Somit wird es Zeit, ebenfalls für WinUI 3 ein GettingStarted Projekt bereitzustellen. Das Projekt zeigt, wie SeeingSharp 2 in ein WinUI 3 Projekt eingebunden und verwendet werden kann. Im Ergebnis wird ein dreidimensionaler Würfel erzeugt, welcher sich in einer endlosen Animation um seine eigene Y-Achse dreht. Unter [1] ist das Coding des Projekts verfügbar.
Worklog SeeingSharp 2: Unterstützung für WinUI 3 Desktop
Im März 2021 wurde die erste stabile Version von WinUI 3 zusammen mit Project Reunion 0.5 veröffentlicht. Vorher gab es bereits mehrere Preview-Releases von WinUI 3, welche einen ersten Blick auf das Framework ermöglicht haben. Nun aber durch das erste stabile Release ist ein guter Zeitpunkt zur Umsetzung der WinUI 3 Desktop Unterstützung in SeeingSharp 2 erreicht. Mit WinUI allgemein beschäftige ich mich schon länger, so basiert die Beispielapplikation von SeeingSharp 2 für die Universal Windows Plattform (UWP) bereits auf Komponenten von WinUI 2 [1]. WinUI 2 ist allerdings noch auf die UWP beschränkt, mit WinUI 3 entfällt diese Abhängigkeit. Mit der neuen Version des Frameworks ist es nun möglich, WinUI Komponenten direkt in einer Desktop-Applikation zu verwenden.
Worklog SeeingSharp 2: Neuer Anstrich mit WinUI
Die Beispielapplikation von Seeing# 2 für UWP Apps habe ich jetzt schon länger nicht mehr angerührt. Vorher habe ich die App sehr ähnlich der Beispielapplikation für WPF gestaltet. Hat an sich gut funktioniert, hat aber auch nicht viel mit UWP zu tun. Um die App etwas moderner wirken zu lassen, habe ich einige Controls aus dem WinUI 2 Projekt integriert und auch einige Elemente des FluentDesigns mit aufgenommen. Allem Voran das NavigationView Element, wie man es im Screenshot schon sieht. Insgesamt sind die neuen Funktionen recht leicht anzuwenden, einige blöde Fallen gibt es aber leider…
Worklog SeeingSharp 2: Styling für ModelViewer
Dieses Wochenende ist für mich der ModelViewer von Seeing# wieder in den Fokus gerückt. Grund war ursprünglich, dass ich mehrere Detailinformationen zum geladenen 3D-Modell anzeigen wollte (z. B. Anzahl Polygone). Da ich dazu ein neues Fenster gemacht habe, habe ich bei der Gelegenheit auch das Styling des ModelViewers etwas überarbeitet. Für mich zunächst leichtes Neuland, da ich sonst eines der großen kommerziellen UI-Frameworks für WPF gewohnt bin. Nach etwas Recherche in der OpenSource-Welt und ein paar kleinen Testprojekten bin ich aber sehr positiv überrascht, wie gut und schnell man hier auch mit OpenSource-Komponenten zum Ziel kommt.
Worklog SeeingSharp 2: Memory Management
In den letzten zwei Monaten habe ich mich intensiver mit Speicher-Management in .Net beschäftigt. Auslöser dafür war das Buch Pro .Net Memory Management von Konrad Kokosa [1]. Anhand der Erkenntnisse daraus habe ich verschiedene Stellen von Seeing# dahingehend angepasst, dass während der zyklischen Rendering- und Update-Logik insgesamt sorgsamer mit der Erzeugung von Objekten umgegangen wird. Grundsätzlich habe ich das Thema zwar schon immer beachtet, allerdings etwas unterschätzt – vor meinen Änderungen wurden im Kern von Seeing# pro Schleifendurchlauf locker 50-100 Objekte erzeugt, was bei ca. 60 Frames pro Sekunde 3.000 bis 6.000 Objekte bedeutet, um die sich der Garbage Collector kümmern muss. Und das auch ohne, dass der User irgendetwas macht (z. B. 3D-Kamera bewegen o. Ä.). Hier im Artikel stelle ich einige Anpassungen vor, die ich in den letzten Monaten gemacht habe.
Worklog SeeingSharp 2: Rolle rückwärts
Eineinhalb Jahre ist es nun her, als ich mit Seeing# 2 begonnen habe. Mit einigen Pausen-Zeiten dazwischen hat sich in der Zwischenzeit einiges verändert. Damals habe ich mir zum Ziel gesetzt, die Abhängigkeit auf SharpDX nicht mehr zu verschleiern und damit dem Nutzer von Seeing# mehr Flexibilität zu geben. Heute ist es aber leider so, dass SharpDX nicht mehr weiterentwickelt wird [1] und somit früher oder später durch eine andere Alternative ersetzt werden muss. Aus diesem Grund habe ich mich hier für einen Mittelweg entschieden.
Worklog SeeingSharp 2: Nugetpakete erstellen und veröffentlichen
Bei Seeing# ist es langsam so weit, dass ich die ersten Nuget-Pakete hochladen möchte. Früher im alten Seeing#-Projekt habe ich dazu noch eine separate VisualStudio-Erweiterung verwendet. Im neuen .csproj-Format ist nun die Möglichkeit eingeführt worden, dass man standardmäßig direkt aus dem CSharp-Projekt heraus auch die Nuget-Pakete erstellen kann. Genau dieses Features wollte ich hier auch direkt ausprobieren. Insgesamt hat das auch recht gut funktioniert, mit Ausnahme der Projekte für die Universal Windows Platform (UWP), doch näheres dazu unten im Artikel.
Worklog SeeingSharp 2: Start
Für das Projekt Seeing# habe ich bereits sehr viele Stunden investiert. Begonnen mit dem 3D-Rendering ist das Framework über die Jahre sehr in die Breite gewachsen, etwa mit der Unterstützung für Video mit der Media Foundation oder einfachen Funktionen zur Wiedergabe von Musik und kurzen Sounds. Zudem habe ich öfters allgemeine Infrastruktur-Themen wie einen kleinen DI-Container, Übersetzungsfunktionen, etc. integriert. Der ursprüngliche Fokus auf 3D-Rendering ist dabei zum Teil stark verwässert. Aus diesem und anderen Gründen (siehe unten) habe ich mich dazu entschieden, einen größeren Breaking-Change zu machen und die Library grundsätzlich zu überarbeiten. Das Projekt befindet sich auf Github im Repository: https://github.com/RolandKoenig/SeeingSharp2. Bis Seeing# 2 aber die gleiche Funktionalität wie vorher Seeing# bietet, ziehen noch einige Wochen ins Land.