Laden...

Seeing# - Multimedia-Framework mit Fokus auf 3D-Rendering

Erstellt von Roland_K vor 8 Jahren Letzter Beitrag vor 8 Jahren 4.364 Views
Roland_K Themenstarter:in
37 Beiträge seit 2014
vor 8 Jahren
Seeing# - Multimedia-Framework mit Fokus auf 3D-Rendering

Hallo zusammen,

ich möchte hier ein OpenSource Projekt vorstellen, an dem ich jetzt seit mehreren Jahren nebenbei arbeite und in vielen meiner Apps verwende. Es nennt sich Seeing# und ist im Kern eine Multimedia-API mit starken Fokus auf 3D-Rendering. Hier direkt ein paar Features:

  • Integration in Windows.Forms, WPF und Windows Store Apps (bzw. Universal Apps)
  • Support für Windows 7 (mit Platform Update)
  • Support ansonsten ab Windows 8 und Windows Phone 8.1
  • Komplett Multithreaded (alle Berechnungen und Rendering in Background-Threads)
  • Ansteuerung mehrerer Grafikkarten gleichzeitig
    (pro View kann unterschieden werden, welche Grafikkarte diese rendern soll)
  • Beliebig viele Views parallel
  • Ein paar Postprocessing Effekte
  • 3D-Rendering basiert auf Direct3D 11
  • Volle Unterstützung für den Software-Renderer (WARP)
  • Integration von Direct2D
  • Integration der Media Foundation (Videos lesen / erzeugen)
  • Dann noch so Sachen wie XBox-Controller, Audio-Unterstützung usw.

Der Quellcode liegt auf GitHub und ist unter LGPL (kann also auch kommerziell verwendet werden, ABER: Änderungen am Quellcode müssen ebenfalls unter gleicher Lizenz veröffentlicht werden):
https://github.com/RolandKoenig/SeeingSharp

Projekte und Beispiel-Apps findet ihr auf meiner Homepage (www.rolandk.de/wp). Zusätzlich hab ich mittlerweile auch eine Beispiel-App im Store von Windows 10 (Link zum Windows Store)

Ich veröffentliche das Projekt hier, um den ein oder anderen Interessentan an dem Projekt zu finden. Auch für Ideen, in welche Richtungen man so etwas weiterentwickeln kann, bin ich immer offen.
Aktuell stehen zum Beispiel folgende Sachen auf meiner TODO-Liste:

  • Import von 3D-Modellen aus verschiedenen Formaten
  • Skelett-Animationen

Viele Grüße
Roland

742 Beiträge seit 2005
vor 8 Jahren

Ich habe absolut keien Ahnung, was die Zielgruppe deiner Bibliothek ist. Das ist viel zu oberflächlich und unspezifisch, zumal es für spezielle Aufgaben ja immer Alternativen gibt.

z.B.
2D Rendering: Win2D
3D Rendering: Game Engines ggf.

Teilweise verstehe ich auch nicht, wieso es manche Komponenten gibt. Wieso braucht man bspw. ein Input Wrapper wenn ich auf allen Plattformen mit DX arbeiten kann?

Ich bin verwirrt

Roland_K Themenstarter:in
37 Beiträge seit 2014
vor 8 Jahren

Eine berechtigte Frage, bei der ich auch etwas weiter ausholen muss.

Zunächst, warum ich Seeing# entwickle:
Beruflich mache ich überwiegend (3D-)Simulationssoftware, privat bastle ich viel im Gaming Bereich rum. Mit Seeing# hatte ich im Ursprung nie das Ziel, es als Library zu veröffentlichen, es war mehr eine Art Experimentier-Projekt. Anfangs für Direct3D 10, danach für Direct3D 11. Step by Step habe ich es dann auch für eigene kleine Spiele-Projekt verwendet, wobei diese mehr den Fokus hatten, bestimmte Sachen für meine beruflichen Tätigkeiten auszuprobieren. Die Features, die ich einbaue und an denen ich arbeite, entstehen aber mehr aus den Bedürfnissen aus dem beruflichen raus. Das merkt man auch sehr schnell, denn wer braucht im Gaming z. B. einen Softwarerenderer oder Unterstützung für WPF. So typische Gaming-Sachen wie der XBox Controller sind eher die Ausnahme... ^^

Thema Zielgruppe
Mittlerweilse ist aus dem granzen Projekt schon eher was geworden, was man gut Library nennen kann, daher auch die Veröffentlichung hier. Die Zielgruppe ist für mich weniger das Gaming - wenn, dann eher wie bei mir zum Experimentieren. Die Zielgruppe sind eher professionelle Anwendungen, die die gebotenen Techniken benötigen. Ein Blick auf die Features offenbart das auch:

Klar, du kannst Direct2D oder die anderen Punkte auch anderweitig mit anderen Libraries haben. Aber schau mal zum Beispiel auf das Feature, dass du beliebig viele Views über beliebig viele Grafikkarten verteilen kannst. Hintergrund davon ist, dass du z. B. einen Visualisierungs-Rechner hast, der > 4 Monitore mit verschiedenen Views der 3D-Welt versorgt.

Ein anderer Punkt ist die Unterstützung des Software-Renderers. Das sorgt dafür, dass alles, was Seeing# bietet, auch ohne Probleme auf virtualisierten Umgebungen läuft. In der Vergangenheit (vor zig Jahren) hab ich da z. B. mit WPF3D bzw. dem HelixToolkit rumgespielt, und genau hier hatte ich damit Probleme.

Das Thema MediaFoundation hat z. B. das Ziel, die Frames aus einer beliebigen View direkt in eine Video-Datei (z. B. mp4) mitzuschreiben.

Und nicht zu unterschätzen ist das Thema Multithreading. Spätestens wenn du große 3D-Szenen hast, ist das extrem wichtig. Alles, was du mit Seeing# machst, läuft in Hintergrund-Threads. Und das auch auf jeder unterstützten Platform.
Wer schon einmal versucht hat, Direct3D Inhalte in WPF einzubinden, weiß, dass das nicht so trivial ist.

Mein Ziel mit Seeing#
Nun wieder zurück, was ich damit eigentlich will. Das Thema OpenSource habe ich deswegen gemacht, um evtl. den Einen oder Anderen zu finden, der daran ebenfalls Interesse hat und das Projekt auch ein Stückchen mit treibt. Weiterhin kann der Quellcode auch Inspiration für andere sein, die an der einen oder anderen Stelle ähnliche Probleme haben, wie ich sie hatte.

edit:
Noch eine ganz wichtige Unterscheidung zu anderen Engines ist, dass Seeing# von Anfang an dafür gedacht war, sich in die Oberflächen-Frameworks einzubinden. Egal ob ich jetzt in Win.Forms, WPF oder im Windows Store unterwegs bin. Ich zieh 1 bis X RenderPanels rein, und die 3D-Engine rendert da rein. Alles andere an UI Logik wird über die normalen Steuerelemente gemacht. Weiterhin gibt es verschiedene Mechanismen, um die Logik innerhalb des Renderings/der 3D-Welt mit der Logik der UI zu synchronisieren.
Gaming Engines dagegen sind nach meiner Erfahrung häufiger primär darauf ausgelegt, dass du eine große View hast, in der gerendert wird und bauen darin ein eigenes UI-Framework nach.

Irgendwo kann man den Ansatz von Seeing# auch mit dem HelixToolkit vergleichen. Zwar ist die Integration mit Xaml/WPF lange nicht so stark, aber auch das HelixToolkit zielt eher auf professionellen Einsatz als auf Games.

742 Beiträge seit 2005
vor 8 Jahren

Also hast du noch keine direkte Richtung oder? Finde es aber sehr interessant, und auch der Code schaut sehr nett aus 😃

Ich würde mir irgendeine Kernfunktion suchen, vll. sogar mit einem griffigeren Begriff als Multimedia und daran herum deine Library aufbauen, vll. sowas wie NVidia Scene Graph (jetzt Scenix?).

Und alles andere rausschmeißen oder in externe Repositories auslagern. Wenn man das dann in Layer aufbaut, z.B.

Device-Management
Layering
3DRendering
3DScenegraph

dann kann man ja auch einen tieferen Einstieg nehmen, falls man das braucht oder sich selber seine Komponenten integrieren, beispielsweise dürfte man auch Win2D in deinen 2D Layer integrieren können, denke ich.

Auf jeden Fall hätte man dann einen leichte Botschaft, die man vermitteln kann: "Seeing# ist ein High Performance SceneGraph für Simulationsanwendungen" 😉

Roland_K Themenstarter:in
37 Beiträge seit 2014
vor 8 Jahren

Die Kernfunktion ist klar das 3D-Rendering.
Über ein Aufsplitten des Projekts habe ich auch schon ein paar mal nachgedacht. Der Hintergedanke bei mir ist/war aber ein anderer. Und zwar stört mich etwas, wie viel andere Abhängigkeiten man bei einem breit aufgestellten Projekt mitzieht. Bin da immer wieder am überlegen, wo sinnvolle Grenzen sind. Der Kern-Sachen, also Direct3D und Direct2D, gehören aber schon direkt rein. Vor allem Direct2D ist hier sehr interessant, da man damit direkt ohne großartige Zeitverluste den Inhalt von Texturen umzeichnen kann.

Sollte ich aber eine Win2D Integration bauen, wäre das für mich schon eher in einer eigenen Assembly drin. Was ich auch schon länger am überlegen bin, ist ein Renderer für Html-Inhalte direkt in Seeing# zu machen. Hintergrund ist, kleine Benutzeroberflächen auf Texturen zu klatschen - was man damit dann relativ einfach hinbekommen würde. Auch hier wäre es eine eigene Assembly.

Thema Win2D: Einen Hinweis darauf hab ich schon ein paar mal bekommen, habe mich selber aber noch nicht viel damit beschäftigt. Es müsste sich eigentlich sehr einfach integrieren lassen, allerdings nicht für den Desktop-Build, da Win2D ja meines wissens nur für Store Apps ist.