Das deutsche QBasic- und FreeBASIC-Forum

[Caran]

Hei!
Mein Spiel an dem ich schon eine Weile programmiere, wird leider immer komplexer (gemeint ist die Szenenkomplexität). Das Ganze führ dazu, dass es relativ langsam ist (schätzungsweise 20 - 30 FPS). Nun, pro Frame werden etwa 30000 - 50000 Vertices gerendert. Die Modelle werden mit der Milkshapemodel.bi gezeichnet, in die ich Frustum-Culling miteingebracht habe. Jedoch zeigen sich dadurch nur geringe Unterschiede. Gibt es noch mehr möglichkeiten die Performance zu steigern?
Es sollte jedenfalls auf meinem PC* mit mind. 35 FPS laufen.

*Celeron D 3.06 GHz, Intel(R) 82915G/GV/910GL Express Chipset Family Graka, 512 MB RAM

MfG Caran
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.

[Heizi]

Na du könntest die Auflösung optional einstellbar machen,
dann kann jeder die AUflösung so einstellen das dein Game
noch optimal läuft.
Noch ne andere Möglichtkeit ist einfach die Anzahl der Vertices
zu reduzieren. In Milkshape gibt es da glaub ich so nen extra
Alghotytmus dafür. Dar Ergebnis sieht dann halt nicht mehr aus wie das Original.

[Caran]

Ich hab da eher so an Culling gedacht. Die Auflösung ist jetzt auch schon variabel einstellbar. Aber dieser Algorhytmus aus Milkshape würde mich mal interessieren. Ich habe schon länger nach dieser Möglichkeit gesucht, aber bin nie fündig geworden. Wo, in welchem Menu kann man das mit Milkshape machen?

MfG Caran
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.

[Heizi]

hmmm kann auch sein dass ich mich geirrt habe.
der hier ist ein sehr guter 3d Modeller und unterstützt
die Funktion die du brauchst unter Objects->Reduce Polygons:
http://www.metaseq.net/english/index.html
MfG

[RatsDevSoftware]

1) http://wiki.delphigl.com/index.php/Backface_Culling
2) http://wiki.delphigl.com/index.php/glCullFace
3) http://wiki.delphigl.com/index.php/Tutorial_Octree
Also wenns dann nicht flüssig läuft...
_________________
visit our Homepage!
shift ist verschwendung...
...o gott - ich fang schon wieder an zu spammen...

[RatsDevSoftware]

[Caran]

Hallo
war ja ne Zeit lang nich mehr hier. So wie's aussieht war Frustum Culling wohl doch nich so das Wahre. Was ich gerne machen würde wäre was mit Occlusion Culling. Hab da so was kleineres übersetzt, was die Geschwindigkeit des Progs eher runterzieht, da es auf den depth-Buffer zugreift. Weis jemand ne bessere Methode? Und nur um das mal hier anzumerken bin ich nich so der Fan von Octree.
Übrigens Backface Culling hab ich auch schon drin.

Danke und MfG, Caran
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.

[RatsDevSoftware]

Dann nimm ne andre methode zur raumpartitionierung... octree ist da noch das einfachste....

alle culling-verfahren beeinflussen eigtl. kaum die füllrate -> fps steigen fast nich

während beim octree deine x-tausend polygone gar nich erst zur grafikkarte wandern, um verworfen zu werden.... weil die extrem schnelle berechnung ruck-zuck von der cpu durchgeführt wird, und erst überhaupt das nötigste übertragen wird zur graka....

... deswegen, culling liefert insg. 1-5 % mehr perfo, während octree methodik ~50-200 % mehr gibt (je nach szene)

ahja, mal nen kleinen tipp, wie du deine fps bekommst:

du dimst ne variable als double, und bei jedem glClear(...) (also am anfang der renderschleife) setzt du variable=timer
dann bei glFlush(), ScreenSync, Flip machste fps=1/timer-variable
zack

dann meinetwegen (wenn du kein fontsystem hast) per windowtitle inne fensterleiste pagn.
_________________
visit our Homepage!
shift ist verschwendung...
...o gott - ich fang schon wieder an zu spammen...

[marzec]

ich kann die meinung meines vorredners leider gar nicht teilen.

culling, sei es backface- oder frustumculling beeinflußen die performance enorm. sie wirken sich direkt auf die füllrate aus, vor allem backface culling, da diese vor der rasterization stage ansetzt die weitaus komplexer und rechenaufwändiger ausfällt als die vertex processing stage.

octrees, bsp-trees oder pvs haben einen anderen stellenwert als die oben genannten culling methoden. neben visibility determination werden zumidest die ersten beiden ach oft zur kollisionsdetektion eingesetzt. weiters erlauben sie durch geordnetes rendern das lösen von transparenz problemen. so partitionierte geometrie sollte bereits in der setup phase zur graka geschickt werden. wurde für die einzelnen partitionen die sichtbarkeit determiniert muß der graka nur noch mitgeteilt werden welhe bereits auf der graka abgelegten geometrien gerendert bzw. welche texturen verwendet werden sollen.

p.s. dem delphi wiki würd ich im übrigen auch niht alles glauben...

200% performance zuwachs klingen gut, ohne angabe des referenzwertes aber ziemlich sinnlos.

bei 50000 vertices über mehr als backface culling und frustum culling nachzudenken ist eher overkill. hier ein paar grundlegende tipps.

1. geometrien auf die karte auslagern und nicht jedes frame mit glvertex und konsorten von neuem übertragen. verwende stattdessen displaylists, vertex arrays oder vertex buffer objects, je nachdem was dein system bietet.

2. vermeide unnötige statechanges. auch wenn manche leute im netz meinen das sei bei neuer hardware unnötig. ich habe im letzten jahr für eine partnerfirma eine engine auf scenegraph basis erstellt zur prozessvisualisierung. dabei werden bis zu 50000 objekte die wiederum aus 10-20 unterobjekten bestehen, mit jeweils eigenen eigenschaften (transformationen, materialien, teilweise unique textures und geometries ) dargestellt. rendert man solcherlei szenen geht meine gf8800gtx selbst mit all den möglichen culling und visibility determination algorithmen in die knie. ds kann jedoch vermieden werden in dem man state changes (matritzen, texturen, materialien, lichter) auf ein minimum beschränkt. dazu sollten objekte nach mölichkeit nach ihren eigenschaften sortiert und gruppenweise gerendert werden. im vergleich zur variante ohne lazy state changes konnte ich so die performance von 10 auf 70fps auf meinem system heben. solltest du nicht die fixed function pipeline verwenden gibt es noch andere dinge zu beachten. dies würde aber den rahmen hier sprengen und mein stylus raucht schon.

befolgst du diese zwei einfachen regeln sollte sich die performance deines programms deutlich steigern. auch solltest du evaluieren ob du nicht auf der cpu dinge rechnest die die performance drücken.

hth
_________________
Yagl - yet another gameprogramming library

[Caran]

Hey,
ich habe mir jetzt mal ganz durchgelesen wie man so ein Octree verwendet. Dabei viel mir auf dass ich so etwas ähnliches auch schon hab:

[Caran]

Falls es noch interessieren sollte: ich komme jetzt auf etwa 2.000.000 Dreiecke pro Sekunde, bei meiner Billig-Grafikkarte. Sind solche Zahlen schon viel (Vergleich mit richtigen Games) , oder sollte man noch etwas mehr draufpacken?

MfG Caran
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.