Das hört sich ja auch vernünftig an, mein Problem ist nur leider eben genau diese JobQueue. Wie sieht diese aus? Steht da nur drin, "Render Objekt 1", "Render Objekt 2", ... Oder sind diese Jobs viel weiter aufgespalten? In der Form: "Erstelle Shader", "Buffere Geometry", "Binde Shader", "Binde Geometry", "Render Geometry".

Fall 1
Wenn ersteres der Fall ist: Wie krieg ich die Anweisungen zum erstellen von Shadern, Rendertargets, ... in den Renderthread? Da fällt mir nur sowas ein:

RenderJob Klasse:


Also in jedem RenderJob immer wieder nachgucken ob die Geometry gepuffert ist, evtl. ob sie aktualisiert werden muss, ob das Program erstellt ist usw. usf. Das ist irgendwo ja auch unsinniger overhead für jeden RenderJob, da meistens ja alles schon erstellt ist und einfach gerendert werden kann.

Fall 2
Wenn die RenderJobs weiter aufgespalten sind gibt es enorm viele, würde dann wie folgt aussehen:

BufferGeometryJob


CreateShaderJob


BindGeometryJob


DrawJob


Der zweite Fall gefällt mir besser, weil man dadurch dann beliebige Jobs an den Renderer geben kann, man muss eben nur verdammt viele Objekte erzeugen und hat sehr viele Method Calls im Renderer.

Ich werde jetzt vermutlich erstmal die zweite Variante benutzen/umsetzen und schauen wie das Skaliert wenn die Szene mal größer als nur ~100 Test Objekte wird.

Ich würde das ganze eher über ein callback machen du hast ein object z.B. schader das implementiert ein interface ILoadable oder so, dann kannst du einfach einen load job schreiben und muss nicht so viele kleine klassen schreiben die alle ähnliches tun vorausgesetzt das passt zu deine OOP kapslung bzw. diese ist überhaupt vorhanden.

mfg FrenK

Eigentlich tust du sehr grobe Befehle verwenden und nur für spezielle Anwendungsfälle, schreibst du zusätzliche jobs, die dann optimierungen darstellen.
Also loadTexture, generateRendertarget, loadMaterial oder endFrame.
LoadTexture würde nur eine Textur im renderer anlegen, uploaden, evtl. MipMaps generieren.
Das ist ein low level command, den wird man allerdings brauchen.
Üblicher weise wirst du ein loadMaterial verwenden, welches, shader, texturen lädt, objekte erstellt(z.B. fbo) und übliche fehlerbehandlung.
Du solltest so viel wie möglich in ein Command packen und bei bedarf weitere bauen, die nur ein teil davon machen.

Ich würde z.B. ein initForwardRendering, load/drawCharacter, start/endFrame anfangen.
Nun würde ich zuerst im renderer ein batching fähigkeit hinzufügen und erst wenn die performance nicht mehr reicht weiter gehen, z.b. neben load/drawCharacter noch load/drawStaticObject einbauen. Nun kann ich entsprechend dynamische und statische objekte trennen, gucken ob es sich lohnt statische objekte zu instanziieren, zusammen zu legen und so weiter.
Die commands sollten nicht einfach rein geprügelt werden, in der hoffmung, man wird sie brauchen, sondern die einbauen, die performance probleme lösen.

Der renderer ist keines wegs ein dummer wrapper, das ist viel mehr ne intelligentes framework, welches wissen über geometry, kartenspezifische features und einiges mehr hat.
Occlusion query, frustum culling sind sachen, die ich dort unter bringen würde, erst ohne commands, alles nur hinter der API versteckt und bei bedarf kann man es nach aussen legen.

Ein praktisches Beispiel wäre Animationen, solange du kein rigid body hast, kannst du die animationen auf renderer seiter verwalten, key-frame interpolation machen, updates und so weiter. Solltest du aber rigid body haben wollen, dann spielt die physik animation ab, also brauchst du eine Möglichkeit nun die Bones zu updaten, dafür brauchst du nun mindestens Command, der über das load/drawCharacter hinaus geht. Es liegt immer noch alles auf der renderer seite, du kannst ledeglich mehr rein fummeln.

Kleiner tip zum absetzen der Befehle.
Das hoch laden von ressourcen dauert sehr lange, pack diese immer an den anfang eines frames, dann die drawcommands und als letztes endframe.
Ideal wäre es vieleicht sogar die load commands auf den nächsten frame zu verschieben und damit verbundene draw calls zu verwerfen oder halt 2 stufen.
Dann kannst du besser im hintergrund optimieren.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004