spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mit dem Vertex-Cache muss man einem auch nicht belasten.

Hier mein Vorschlag:
Man erstellt für ein Grafikobjekt immer ein Modell-Objekt. Dieses wird dann entweder Manuell oder eben aus einer Datei mit Daten gefüllt. Ein Modell hat immer ein Material (Textur, Lichtinformationen, etc. ) und einen Satz Vertice. Du kannst die Klasse ja auch BasicModell oder Mesh nennen. Das ist vieleicht besser, wenn jemand ein Grafikmodell hat das aus verschiedenen Materialien besteht.

Die Klasse bekommt dann eine Render-Methode. Die dann auf seiten des Users das Grafikobjekt rendert. Intern ist es jedoch erst einmal nicht so. Intern wird dann eine Liste mit allen zu rendernden Objekten erstellt. Die Render-Methode hängt das Objekt also in eine Liste ein, die für jeden Frame neu erstellt wird.

Du hast ja BeginScene und EndScene. Die Methode BeginScene löscht die Aktuelle Liste und stellt alles zurück. EndScene verarbeitet dann die neu erstellte Liste.

Verarbeitung der Renderliste:
Als erstes wird die Liste nach Transparenten Objekten sortiert. Nur die Transparenten Objekte werden dann nach der Z-Achse sortiert. Für den Rest ist das ja nicht so schlimm. Mit z.B. IsTransparenceObjekt kannst du das ja abfragen.
Die nicht Transparenten Objekte werden dann am besten nach dem Material sortiert. Dann hast du es später einfacher mit dem Vertex Cache und weitere Performance vorteile.
Nach der Sortierung werden die Objekte dann gerendert. Mit z.B. der Methode ActivateMaterial wird das Material (Textur, etc. ) aktiviert und mit z.B. DrawVertice werden dann die Vertice des Objektes gerendert. Diese Methode füttert dann den Vertex Cache mit Daten. Da du nach den Materialien sortiert hast brauchst du keine Listen im Vertex Cache für die Materialien und musst pro Frame jedes Material nur einmal setzten. Wenn der Vertex Cache dann voll ist werden die Daten erste richtig gerendert. Wenn du dann das Material wechselt rufst du vorher noch FlushVertexCache auf, um eventl. noch vorhandene Vertice zu rendern.


Intern wird viel gemacht. Für den User sieht das dann etwa so aus:

Du kannst auch eine Basis-Klasse machen. Die dann z.B. RenderObject heißt. Diese besitzt dann alle obigen Methoden.

klingt nach viel arbeit.. aber das konzept hört sich gut an, muss ich sagen

Bringt das wirklich so große Vorteile?
Ich meine, das klingt ziemlich zeitaufwändig, wenn man das alles sortieren muss... Wenn ich mir vorstelle, ich habe eine recht komplexe Szene mit vielen einzelnen Objekten und Materialien - wenn ich beim Rendern nun jedes Mal alles erst durch nen Sortieralgorithmus jagen muss, das is ja schrecklich

Zitat von »"gombolo"«

stell dir vor du renderst ein Objekt mit einer Textur A. Danach eine mit Textur B und danach wieder Textur A. Jetzt hast du einmal die Textur umsonst gesetzt. Du hättest beide Objekte mit Textur A rendern und danach das Objekt mit Textur B rendern können.

Ja schon, aber dauert es nicht länger, lauter Listen aufzustellen, da Objekte reinzuknallen und die dann auch noch nach verschiedensten kriterien zu sortieren? Und das auch noch Frame by Frame...?

Was du bei den Listen natürlich nicht machen darfst, ist std::vector oder etwas ähnliches nehmen. Dann haste ein Problem. Die Liste sollte sich in der Größe einmal aufbauen und dann einfach so bleiben. Dann wird lediglich in den ersten beiden Frames neuer Speicher für die Liste angefodert. Danach ist sie groß genu für alle Objekte.

Die Transparenten Objekte muste sowieso sortieren. Da du dabei gleich alle Objekte abfragen must ob sie Transparent sind, kannst du sie auch gleich nach deren Materialien sortieren. Die Transparenten Objekte sind dann statt Material nach der Z-Achse sortiert.

Aber wenn du die Sortierung nicht machen willst, brauchst du das auch nicht. Nur bei den Transparenten Objekten ist es ein muss. Du kopierst ja auch nur Pointer. Das sind 4Byte pro Objekt. Für eine 32Bit CPU nun wircklich kein Zeitaufwand. Es kostet viel mehr Zeit wenn man ein Material 5 oder mehr mal pro Frame setzt. Es sind ja nicht nur Texturen die man dann mehrmal setzt. Dazu kommen dann nicht die States oder auch Shader Programme und die D3D-Materialien (für's Licht).


Wenn du die Liste nicht sortierst, must du natürlich deinen Vertex Cache entsprächend aufsetzen, das er mehrere Listen führt. Eben eine pro Material.

Ah, ja klar xD
Ich hatte irgendwie gemeint, man müsste komplett alle Objekte in jedem Frame neu sortieren, aber bei allen, die kein Alpha-Blending brauchen, ist das ja gar nicht nötig
Okay, klar, danke
War mein Denkfehler

Zitat

Eigentlich müsste man doch die Liste nur am Anfang sortieren.

Dieses Modell verfolge ich zur Zeit bei meiner Engine. Jedoch ist dieses Modell sehr Statisch, da alle Objekte von begin an fest stehen müssen. Zwar ist es schneller als wenn man die Liste immer zur Runtime sortiert, man hat dann aber ein kleines Problem.

Bestes Beispiel sind hier Projektile. Nehmen wir einen Shooter. Auf dem Feld sind 5 Spieler. Alle 5 Spieler können entweder gar nicht schießen oder mit ner Flag ganze batterien abfeurern. Sprich die Zahl der Projektile ist sehr unterschiedlich, von Frame zu Frame.

Daher bin ich grad am überlegen wie man die Vorteile des vorsortierens mit der dynamischen Anzahl an Objekten überein kommt.

Zitat

-Wo kommen die Materialien am besten hin?

Wie meinst du das, wo sie hin sollen? Wenn man nach den Materialien sortiert, stellen die Materialien natürlich den Knotenpunkt dar. Zwischen dem Vertexprozess und den Vertice.

Zitat

-Wie ermittle ich am besten die optimale Cachegröße?

Durch ausprobieren.

Zitat

-Und wie läuft es ab wenn der Cache voll ist?

Der Inhalt des Cache wird gerendert und dann gelert um platz für neue Vertice zu schaffen