Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
nach einiger Zeit mal ein kurzes Lebenszeichen von der ZFXCE2. Ich probiere immer noch fleißig mit Multithreaded-Rendering herum. Mittlerweise läuft das auch ganz ordentlich. Der folgende Ansatz hat sich bisher in meinem Kopf und im Code durchgesetzt:
Es gibt einen separaten Render-Thread, der alles API-spezifische macht.
Dieser Renderthread bekommt eine einfache Liste mit Zeichenkommandos, sogenannten RenderCommands, die in einem RenderCache abgelegt werden.
Diese Liste wird bei Änderungen aktualisiert, und zwar vom RenderFrontend.
Ich habe für die RenderCommands ein Double-Buffering vorgesehen, welches Aktualisierungen immer in dem RenderCache vornimmt, der gerade nicht gezeichnet wird.
Zur Zeit benutze ich als Synchronisationspunkt genau ein OnRenderFrame-Signal, hier werden die Caches umgeschaltet.
Das Frontend besteht aus einem Scene-Graphen, der die Modelle, Animationen und anderen Dinge, die dargestellt werden, verwaltet.
Hier werden auch Aktualierungen in den Transformationen vorgenommen.
Beim Update der Nodes wird das Changeset für die Rendercommands zusammen gestellt und diese in den RenerCache eingearbeitet.
Das funktioniert soweit aus ganz gut. Man kann geladene Modelle frei mit der Maus drehen. Auch lassen sich Renderstrategien recht schnell im RenderCache einarbeiten. Somit ist das Anbieten von so etwas wie verschiendene Render-Pfade mit keinem so tiefen Eingriff in das Rendern verbunden, wie es bisher bei all meinen vorherigen Versuchen der Fall gewesen ist.
Offene Punkte gibt es noch einige:
Animationen: Noch nicht da
Beleuchtung: Noch nicht da
Schatten: noch nicht da
Beliebiges sinnvolles Feature einfügen.
Dynamische Bufferzugriffe: sind gerade noch sehr teuer, da zwar Double-Buffering für die Commands benutzt wird, allerdings die Resourcen nur einmal da sind.
Was habe ich in den letzten Monaten gelernt:
Das größte Problem mit Kind ist die Zeit, ich kann an keinen Problem wirklich mehr als 1 Stunde drann bleiben ( das meist nach 23:00 Uhr ).
Assimp 3.0 Release bremst andere Entwicklungen :) ( Jammern auf hohem Niveau, ich weiß )
Separater Render-Thread bringt Vorteilel, wenn man CPU-intensive Dinge im Mainthread macht und das Rendern nicht.
Tasks / Threading ist ein sehr spannendes Thema. Dinge wie ThreadSafe-EventQueues oder Double-Buffering für Commands bringen viel Verständnis für die auftretenden Probleme.
Das Minimieren von Locks durch Mutexes ist esistenziell für die Performance.
Haltet so viele Daten wie möglich Thread-lokal.
Alles dauert viel viel länger, als man denkt.
Ich bin zu faul, eine vernünftige Demo auf die Beine zu stellen :).
To be continued...
Den aktuellen Stand kann man sich wie immer bei Sourceforge ansehen. Ich überlege, mal ein erstes Source-Only Package freizugeben. Vielleicht kriegt man ja etwas Feedback.
Kimmi
Ich baue gerade ein kleines Projekt mit dem bestehenden Sourcen, ist aber noch nichts wirklich Zeigbares dabei. Immerhin kann man schon Modelle mit wenig Code laden. Hier habe ich viel in Richtung Benutzbarkeit der ZFXCE2 gedreht, um mir das Leben einfacher zu machen.
Ich habe die Performance des dynamsichen Array's etwas getuned.
Der Renderthread benutzt nun Transformation-Groups, die untereinander eine Hierarchie bilden können. Somit liegen die Transformationen in einem Transform-Controller, der diese als Array einmal durch-aktualisieren kann. Das heißt, weniger Cache-Misses.
Das Laden von Resourcen baut sich nun selbstständig einen Dependency-Baum auf. Erst wenn alle Daten geladen sind, ist das Modell fertig. Dummerweise ist hier auch noch ein Bug: wenn eine Resource nicht geladen werden konnte, hängt das Ganze. Dazu mach ich den Update, ob das Modell fertig geladen ist, per Polling. Und das ist noch nicht so, wie ich das gerne hätte.
Der Modell-Loader rotiert und skaliert freuding vor sich hin.
Ich habe angefangen, einen DX11-Renderer zu bauen. Zur Zeit basiert das Ganze noch auf einem kruden D3D9-Renderer, der auch nur in einem Renderthread laufenb kann. Dinge wie Deferred-Contex sind damit nicht möglich und ich habe auch keine Ahnung davon. Außerdem ist das ein ganz guter Test, wie gut man Interafecs geschnitten hat. Ich kann berichten: es erfordert an manchen Stellen Nachbesserung.
Da ich zeitweise recht viel unter Linux arbeiten musste, habe ich etwas in OpenGL machen wollen,was aber zur Zeit auf Hold steht.
mal wieder ein kurzes Update leider ohne neuen Screenshots ( ich muss mal eine Demo-Szene bauen, damit das Ganze nicht so langweilig ist ) :
DIe Dependencies beim Modell laden als Baum zusammengefasst und diesen aufgelöst. Ein Job hat dabei einen Dependency-Counter, der alle Tasks zählt, auf die er aufgrund nicht aufgelöster Dependencies noch wartet. Erst wenn diese == 0 sind, wird auch er als fertig signalisiert.
Ein wenig mit D3D11 herumgespielt und die komplett shader-basierende Architektur "wahrgenommen".
Umstellung der Transformationen auf Shader-Parameter, um endlich ein besseres Konzept im Renderer implementiert zu haben. Damit habe ich gerade richtig viel Arbeit.
Shader unter D3D9 funktionieren, allerdings die ganze Transformationslogik noch nicht vollständig.
Der bisherigen Direc3D9-Renderer hat aufgrund seines verwachsenen Interfaces mir mehr Ärger als Nutzen gebracht und wurde deswegen gelöscht
Der neue Renderer baut auf OpenGL4.3 und wird auf dem Render-Thread als Backend genutzt.
Alle, die rendern wollenl, können das über eine Fassade names RenderBackendServer tun. Die Daten werden von dort auf den RenderThread gesended und auch nur dort mit dem BAckend gerendert. Somit Sieht man als Anwender nicht, welche Technologie dahinter steckt.
Geometrie, Material-Beschreibungsn und Parameter werden via Event an den RenderThread gesendet. Somit ist die Renderei per Protokoll implementiert. Als Anwender kriegt man von diesen Dingen nichts mit.
Das Ganze läuft dank SDL2 momentan unter Windows und Linux.
Alle platform-spezifischen System-Calls und Interfaces sind in einer eigenen Komponente gekapselt. Diese wird je nach Platform beim Start einer Anwendung hochgefahren. Darin enthalten sind Threading-API ( wenn C++11 gerade nicht da ist ), Windows-Handling, OS-spezifische Event-Handler, RenderContext und High-Resolution-Timer ( UNter VS2013 ist der C++11 timer nämlich nur bedingt high-resolution ). Man muß dann für eine neue Plattform auch nur eine Komponente portieren, der Rest ist portabel.
Weil eine lauffähige Linux-version für mich selbst ein Milestone war, habe ich das Ganze nun mal als Release v0.1.0 betaggt.
Vorwärts ist anbetracht der Tatsache, wie lange ich da schon rumpuzzel, vieleicht etwas übertrieben. Aber ja: ich mache mal Fortschritte. Nun sogar auf Linux :). Und das Testen gegen Refenzbilder war auch eine Idee. Aber Obacht: gegen Jitter sollte man die Anzahl von Mismachtes gegen einen grenzwert testen. Wir machen hier so etwas in der Art und da hat man wirklich viele false-positives, wenn der treiber mal neue Laune vom Hersteller verpasst bekommt.
