spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wegen Speicherverwaltung - kommt einfach auf die Situation an, also ich komme ganz gut ohne klar

Wegen Klassen - habe erst neulich wieder alles umstrukturiert, weil mir bei einer Sache auffiel, dass ich Daten redundant vorhanden hatte und dies zu hässlichen Fehlern führt. Auch hatte ich mehr Klassen als nötig, was ebenfalls zu Einbusen führte. Ich gebe zu das es mir eigentlich wichtiger ist, dass was auf den Bildschirm zusehen ist und ich daher von dem Optimierungs"wahn" nicht viel halte. Ich mache nur dann was wenn es wirklich nötig ist, denn was nützt mir eine super schnelle Renderklasse, wenn ich dafür keine Zeit für andere Gebiete habe.

zu 3ds:

ich weis, alle welt verwendet 3ds.
ich persönlich finde 3ds ist, vor allem für spiele, ein ziemlich ungeeignetes format, weil:

• afaik keine offiziellen spezifizierungen vorhanden -> jede 3ds datei kann anders sein, fast kein 3ds importer kommt mit absolut jeder 3ds datei zurecht.
  
• unterstützt afaik keine skeletale animation

ich persönlich verwende das *.ms3d format (Milkshape3D format <- unser modelling tool) oder je nach anforderung ein eigenes format mit import/export plugin bzw. converter.

zur optimierung:

die auf heutiger hardware üblichen optimierungsstrategien sind:

• Vertex/Index Buffer verwenden, auf DrawPrimitiveUP() & CO verzichten
  
• möglichst selten textur bzw. shader und sonstige states (material) umstellen (nach textur/material sortiert rendern)

batch minimierung:

• möglichst viel geometrie in einem einzigen draw aufruf rendern

busverkehr minimieren:

• möglichst wenig daten zwischen GPU und CPU herumschicken
  
• nur das zur graka was sie auch braucht (vertex attribute die zum eigentlichen rendern nicht relevant sind auch nicht schicken; z.b. smoothingGroupIndex etc.)
  
• nach möglichkeit daten die im vram liegen niemals anfassen (zusätzlich gefahr eines pipeline flush, d.h. buffer->lock() is evil )
  lieber noch eine kopie der daten im ram (z.b. vertices/indices)

cache optimierungen:

• alles so oft verwenden wie möglich
  
• triangle strips anstatt von triangle lists
  
• indices so ordnen, dass dreiecke die die gleichen vertices verwenden möglichst hintereinander kommen (vertex cache ausnutzen)

ich denk das sollte normalerweise schon für sehr gute performance reichen.
wenn du noch detailliertere infos über optimierung haben willst, dann schau dir mal den GPU programming guide auf developer.nvidia.com an...

btw: BSP trees sind schon etwas betagt, für indoor levels gedacht, und werden heutzutage oft nurmehr zur kollisionserkennung zwischen level und objekten eingesetzt.

man kann mit tricks eine trianglelist in einen trianglestrip umwandeln.
das funktioniert über sog. stopvertices.
du sortierst so, dass möglichst viele dreicke hintereinander in einem strip gezeichnet werden. irgendwann geht das natürlich nicht weiter, du musst zu einem anderen vertex springen. dazu zeichnest du 2x den gleichen vertex und zeichnest an der anderen stelle weiter.
das führt logischerweise dazu, dass zwischen 2 getrennten trianglestrips einfach ein unsichtbares dreieck (2x der gleiche eckpunkt -> keine ausdehnung) gezeichnet wird. das triangle setup der grafikhardware ist im normalfall intelligent genug solche sog. degenerierten dreiecke zu ignorieren, und wenn nicht isses auch egal.

tipp: vergiss am anfang aber einfach mal das ganze optimieren und konzentrier dich aufs wesentliche, nämlich dass es funktioniert. wenns dann zu langsam ist, kann man sich auch im nachhinein noch ans optimieren machen