Direct3D 11 direkt in ein WPF D3DImage zu integrieren ist nicht ganz so einfach – das ist jedem bekannt, der das schon einmal probiert hat. Im Fall meiner 3D-Engine SeeingSharp gehe ich sogar noch etwas weiter: Das Rendering erfolgt komplett verteilt auf dem ThreadPool. Weiterhin werden so Kleinigkeiten wie Kantenglättung unterstützt, die die Integration in WPF auch noch etwas schwieriger machen. Nun habe ich es schon vor einer ganzen Weile geschafft, dass das auf allen getesteten Desktop-Rechnern gut funktioniert – aber irgendwie trifft man immer wieder auf neue Fälle. Neulich habe ich mir das neue Surface Pro 3 gekauft und siehe da… dort gibt es Probleme.
Direct3D
Portierung einer 3D-Engine auf Windows Phone #3
Vor einigen Wochen habe ich meinen 3D-Renderer auf Windows Phone 8.0 stabil zum Laufen bekommen und bin dabei auf die eine oder andere Hürde gestoßen. Da mittlerweile das Windows Phone 8.1 SDK verfügbar ist und auch SharpDX die entsprechenden Funktionen implementiert, konnte ich nun also einen neueren Weg ausprobieren – die Universal Apps. Vorteil: Dieser Weg verspricht, dass das Coding zwischen WinRT auf normalen Windows PCs und Windows Phone fast komplett identisch ist. Auch SharpDX verspricht, dass dieser Weg damit bereits gut funktioniert und nebenbei eine ganze Liste Nachteile der vorherigen Lösung ausbügelt.
Performance-Optimierung #1
Performance-Optimierung ist immer und überall ein Thema, welches viel Zeit und starke Nerven fordert. Zudem wird gerne an Stellen optimiert, welche für die Gesamtperformance letzten Endes nicht wirklich ausschlaggebend sind. Ich persönlich bin deswegen überwiegend der Meinung, während der Entwicklung selbst weniger auf Performance zu schauen und sich von Optimierungen nicht unnötig aufhalten zu lassen. Dort wo es hackt, kann im Nachhinein nachgebessert werden. Im Prinzip bin ich genauso bei der Entwicklung von SeeingSharp (Arbeitstitel für 3D-Engine) vorgegangen. Das Grundgerüst ist zunächst so aufgebaut, dass es aktuelle Anforderungen daran gut abdecken kann. Für künftige Aufgaben bin ich gerade dabei, an der Einen oder anderen Stelle zu schrauben, um so die nötige Leistung aus dem System zu bekommen. Die Schritte dazu und erste Ergebnisse erkläre ich kurz in diesem Beitrag.
Laden von Texturen auch auf Windows Phone
DirectX auf Windows Phone hat zwar zu einem großen Teil die gleiche API, wie auf dem Desktop, drum herum ist es aber z. T. stark eingeschränkt. Neben den Punkten aus den letzten Blog-Beiträgen (z. B. fehlendes Direct2D) hatte ich zusätzlich das Problem, dass ich bis jetzt fast durchweg png Dateien als Texturen verwendet habe. Grundsätzlich ja kein blöder Gedanke: Ein einfaches Dateiformat, welches man auch mit jedem Bildbearbeitungsprogramm bearbeiten und auch problemlos in eigenen Programmen verwenden kann. Auf dem Windows Phone funktioniert das aber nicht, da hierfür ausschließlich Texturen im dds Format zulässig sind. Daraus entstanden für mich im Wesentlichen zwei Probleme: Wie werden andere Dateiformate in dds konvertiert und wie können diese Dateien im Programm geladen werden?
Portierung einer 3D-Engine auf Windows Phone #2
Heute kam ich endlich einmal dazu, die Portierung auf Windows Phone wie im letzten Post beschrieben weiter zu machen. Kurzum: Das Ergebnis sieht mittlerweile sehr gut aus. Hürden gab es neben der zuletzt genannten zum Glück keine größeren mehr. Das einzig wirklich negative ist die Tatsache, dass die Synchronisierung zwischen Xaml-Rendering und Direct3D-Inhalt am Phone (natürlich) wieder anders ist, als auf allen anderen Windows Plattformen. Ich verwende den Weg über das DrawingSurface wie hier auf Msdn beschrieben.
Portierung einer 3D-Engine auf Windows Phone
Heute habe ich mich damit beschäftigt, eine 3D-Engine auf Windows Phone (8) zu portieren. Im Prinzip handelte es sich schon vor dieser Aktion um relativ viele Klassen, welche sauber auf Windows Desktop und WinRT laufen (auch ARM). Ich wusste zwar schon, dass die Phone-Plattform noch einmal deutlich eingeschränkter ist, als etwa die WinRT-Plattform für Tablets, das ich so viel rumbasteln muss, hätte ich aber nicht gedacht. Hier eine kurze Sammlung der Punkte, auf die ich gestoßen bin.
Shader debuggen mit Visual Studio 2012
Aktuell bin ich dabei, verschiedene Shader-Effekte wie z. B. Blur, Grayscale, Pixel-Lightning usw. zu entwickeln. Schwierig ist dabei eigentlich immer, Fehler in den Shadern zu finden. Was macht man als Anfänger? Man geht her, programmiert den Shader in Visual Studio, kompiliert diesen und bindet ihn in das Programm ein. Das Ergebnis ist dann meistens erst einmal nicht das, was man erwartet. Und dann? Tja, im Hlsl-Coding nach dem möglichen Fehler suchen, ausbessern, wieder kompilieren und dann wieder schauen. Und so geht das eine ganze Weile weiter.. dabei kann man diesen Ablauf in Visual Studio mittlerweile wesentlich produktiver gestalten.
ConstantBuffer Updates sind nicht trivial
Ein Thema, was mich zurzeit sehr beschäftigt, ist der korrekte Umgang mit dem ConstantBuffer in Direct3D 11. Der Constant Buffer wird dafür verwendet, um einem Shader fixe Parameter zu übergeben. Diese Parameter sind bei Mosaic Snake 3D etwa die aktuelle Transformation, die Lichtfarbe, die Lichtstärke und noch ein paar andere. Der Ansatz, neue Werte in den ConstantBuffer zu schreiben, ist bei Mosaic Snake 3D dabei relativ primitiv: Es gibt einen CosntantBuffer über das gesamte Programm. Jedes Mal, wenn ein Objekt (z. B. ein Teil der Schlange) gezeichnet wird, wird der ConstantBuffer vorher mit den aktuellen Informationen überschrieben und danach wird gerendert. Bei diesem Spiel hat der Ansatz auch sehr gut funktioniert, allerdings ergeben Tests in einem anderen Szenario ein ganz anderes Bild…
Inhalt der RenderTarget-Textur in ein Bitmap kopieren
Im Moment beschäftige ich mich damit, ein kleines Unittest ähnliches Tool für eine 3D-Engine zu schreiben. Funktionsweise ist relativ einfach: Es wird eine Textur angelegt, in die ganz normal gerendert werden kann. Nach Abschluss des Render-Vorgangs soll der Inhalt der Textur in den Hauptspeicher, z. B. als normale Bitmap geladen werden (ob jetzt WPF oder System.Drawing ist egal..). Dieses entstandene Bild kann man jetzt nutzen, um zu prüfen, ob diverse Render-Schritte korrekt funktioniert haben. So weit, so gut, dass soll dann gar nicht weiter Teil dieses Beitrags sein. Mit was ich mich hier beschäftigen will, ist der Weg, wie man den Inhalt einer Textur von der Grafikkarte in den Hauptspeicher bekommt.
Initialisieren von Direct3D und mehrere Grafikkarten in einem PC
Messezeit ist fürs erste rum, die meisten der Prüfungen sind geschrieben. Jetzt wird es Zeit, hier wieder einige Themen zu diskutieren. Neulich stand ich wieder vor der Frage, wie man bei einer „frischen“ 3D-Engine Direct3D initialisiert bzw. ganz allgemein die Device-Instanzen verwaltet. Mittlerweile ist die API zwar einfacher, das Thema meiner Meinung nach aber komplexer geworden. Hat man ein Windows.Forms Control als Render-Ziel, so hat man i. d. R. keine großen Probleme. Steckt man aber etwa in einem Szenario, in welchen man 3D-Grafik eines Direct3D 11 Renderers in WPF einbinden möchte, so muss man schon Ressourcen von Direct3D 9 und Direct3D 11 verwenden, da WPF selbst nur Ressourcen von Direct3D 9 einbinden kann. Will man jetzt noch per Direct2D direkt auf Texturen zeichnen, so sind – aber auch nur auf der Windows 7 Plattform – zusätzlich Ressourcen von Direct3D 10 notwendig.