spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das kommt drauf an. Wenn dein Model nicht optimiert wird und sehr groß ist (also zum Beispiel ein Level, dass nicht in Portals oder einen Tree aufgeteilt ist) dann würde sich zerhacken auf jeden Fall lohnen! Bei der Tribase wird Quadtree allerdings schon unterstützt, falls du die benutzt. Andererseits ist dein Modell verhältnismäßig klein (Größe immer in Bezug darauf, wie viel davon durchschnittlich gleichzeitig in der Kamera zu sehn ist, ein sehr kleines wäre also immer ganz im Bild) und hat nur wenige Dreiecke, dann würde das Aufteilen in verschiedene Buffer entweder Speicher oder Rechenzeit oder beides kosten. Für ein Level würde ich dir immer ein optimiertes Model empfehlen. Da du ja im Moment an der Durchsichtigkeit deiner Wände werkelst kann es aber durchaus sein, dass das Aufteilen für dich mehr Vorteile bietet.. Man müsste allerdings auch n Algorithmus entwickeln können, der die Dreiecke aus einem einzigen Model testet, obwohl mir so auf Anhieb nur zeitintensive Lösungen einfallen würden..

Klar, Du hast eine kleine "Batchsize", d.h. wenige Polys per Objekt.

Früher gab es im wesentlichen zwei Sachen die man klein halten musste:
- Zahl der Pixel"bearbeitungen". Also z.B. jede Wolke oder Rauchsäule am Himmel mit 100 Polys hintereinander mit Alphatexturen zu machen kostet fps.
- Zahl der Polys. Also z.B. nichtsichtbare möglichst früh ausfiltern, LoDs etc.

In DX9 (wahrscheinlich auch vorhergehende DX Versionen) ist auch die Zahl der Objekte entscheidend. BF2 z.B. benutzt gerade mal 200! Mit Objekt meine ich alles was in einem DrawIndexedPrimitive gemalt wird. Meine eigene Erfahrung ist, dass der dritte Flaschenhals (Objektzahl) wichtiger sein kann als die beiden ersten zusammen.

Zähl einfach mal mit, wie viele Draw* Befehle Du pro Frame absendest.

Es ist klar, dass es auch einen Nachteil hat, de ganzen Level in ein einzelnes Objekt zu packen, nämlich werden dann grosse Teile ausserhalb des Frustums gerendert. Wie immer muss man optimierte Algorithmen anwenden und muss einen Kompromiss finden.

Ich glaube den neuen Quellcode bekommt man echt nur mit der 2. Auflage zusammen.. Blöd für uns

Wieso? Selbst ist der Mann

Ach man muss nich alles selber machen
Nebenbei: Octree muss nicht unbedingt besser sein, da die Rechenzeit größer ist je mehr Zweige man hat. Das kommt halt drauf an, wie klein die untersten Modellteile sind und was genau man machen will. Sonst wäre ja ein 64-Zweige Baum noch besser...

edit: Ein klassischer BSP-Tree hat zB nur zwei Zweige.

für ein labyrinth würde sich vermutlich ein quadtree oder bsp anbieten...