spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich bin gerade eine neue Rendering Engine für BoB am schreiben.

Nach dem was ich bei nVidia und MS gelesen habe, favorisieren die eher einen großen VB, zumindest für die statischen Daten. Grob gesagt scheint deren idee zu sein, beim start (des Spiels/einees Levels) Riesen VB/IB von Platte laden und dann halt jeweils die Bereiche ansprechen, die man braucht. Dann wird auch nichts verschoben und auch der Memory Manager der GraKa wird möglichst wenig benutzt und kann nicht plötzlich auf die Idee kommen, die GraKa für längere Zeit zu sperren. Wenn man dadurch mehr als 64 k hat, kann man den Offset in DIP benutzen, sodass die indices selber unter 65536 liegen (also 16 bit sind).

Ich werde von BoB (mindestens) zwei Versionen machen, eine für langsame und eine für schnelle rechner. Daher kann ich bei letzterer dann z.B. 64MB GraKa Speicher verlangen. Zur zeit sind alle 3D modelle zusammen nur so ganz ungefähr 5MB und ich denke, als VB/IB wird es spogar noch etwas kleiner sein. Zum Notfall kann ich also einfach ALLES am Anfang hochladen }>

Ich werde definitv eine Klasse haben, die alles für das 3D Modell nötige kapselt und die auf den VB/IB verweist. Es ist klar, dass diese maximal einmal im Speicher ist.

Einziges Haar in der Suppe bisher ist, dass 3D Modeller dann Aufwand haben Ihr Model zum testen in die eine "VB/IB auf Platte" Datei zu bekommen und bei der nächsten version die alte zu löschen, die neue rein etc. Insbesondere können sich dann auch offsets ändern und wenn die Datei mit den Modeldaten (Texturnummern, verwundbarkeit etc etc) nicht mit der VB/IB Datei zusammenpasst, gibts Knatsch. Insofern bastele ich die VB/IBs jetzt in die 3D Dateien rein und BoB muss beim starten alle abklöappern und sich daraus den VB/IB im Speicher zusammenbauen. Wenn das zu langsam ist, kann ich später beides zulassen, d.h. es gibt eine Hauptdatei und da wird alles weitere beim Starten drangehängt.

Die Dateien werden jeweils von PrettyPolyEditor (PPE) geschrieben. PPE ist GPL, also frei veränderbar. Es kann viele Formate lesen, sodass 3D Modeller in Ihrem Lieblings-Editor arbeiten können. PPE muss dann unterscheiden können was Statisch und was Dynamisch ist. Der statische Teil wird dann in einen statischen VB/IB auf Platte geschrieben.

Die dynamischen Vertices werden als Poly Suppe verarbeitet. Z.Z. macht BoB aus allem eine Poly Suppe, insofern ist das eine sehr comptible Änderung: Alles was aus welchen gründen auch immer in dem statischen Buffer nicht (jetzt) geht, wird in die Suppe geschmissen. Dadurch bruacht man ausser dem "Statischen Renderer" nur einen renderer, der alle "spezial" Polys bearbeiten kann, egal, wo sie herkommen.

Es wäre sehr unklug für jedes Primitiv eine Textur zu setzen. Ist auch gar nicht nötig. Wenn du mal nachdenkst merkst du schnell das sich deine Frage der zugehörigkeit schnell klären wird.
Deine Modellklasse verbindet die Vertice mit den Texturen. Das einzige was du machen must ist, das du alles zum Schluss nach den Texturen sortierst, damit du mehrmaliges setzen ein und der selben Textur verhinderst.

Ich mache das über eine Renderliste, die meine Render Unit bekommt. Diese hat keine Infos darüber was dargestellt werden soll. Sie sammelt nur die Vertice mit den Effekten und Texturen. Dann sortiert sie alles und fängt dann in der Prpgrammschleife an zu Rendern. Natürlich gibt es viele Optionen die gesetzt werden können
Da du aber noch am Anfang stehst, ist es besser wenn du dir eine Render-Funktion bastelst in der du einfach ein Modell nach dem anderen Modell renderst und die Sortierung praktisch Manuell vornimmst. Deine Modelleklassen bekommen einfach eine Methode IModell::Render(), oder so. Die wird dann einfach in der Renderfunktion aufgerufen.
wie gesagt, den zusammenhang zwischen Texturen und Vertice übernimmst du. Ein Vertex bekommt keine ID zu einer Textur. Auch wenn dies möglich wäre.

Die 64KB sind keine grenze. Ein VB kann so groß sein wie es gerne hätte. Nur die anzahl der Vertice die gleichzeitig gerendert werden können wird von der Hardware bestimmt.

Wie schon gesagt, differenziere zwischen Modell und Game Objekt (z.B. Monster oder Fahrzeuge). Der Engine selber ist es egal welche Eigenschaften z.B. ein Monster hat (Health, Inventar, etc.). Diese Infos brauch nur die Spiellogig.
Wie genau du dann alles Aufbaust must du dir selber ausdenken.

Tipps:
- Nimm dir einen Block und schreib einfach mal auf was du haben willst und was du brauchst. Aber nicht übertreiben
- Dann überlege dir wie du dieses Ziel erreichen kannst. Beginne mit einfachsten Dingen, wie das einfache Darstellen von Drahtgittermodellen. Ich habe meinen Kompletten Renderer so aufgebaut. Die Klassenhirarchie ergibt sich so fast von selbst und Stück für Stück baust du deine Graphic Engine aus.
- Wenn du mit allem durch bist, kannst du dich an das Programmieren begeben.
- Schreibe vieleicht das eine oder andere kleine Test App um die eine oder andere Sache kurz zu testen.

Das mit den Interfaces ist ganz einfach. Ich habe eine Abstrakte Basisklasse IVertexBuffer. Mit dieser Klasse Arbeitet der User. Davon mach ich einfach zwei Versionen.

1) Für den Manager [CManagedVertexBuffer : public IVertexBuffer]:
Diese speichert dann nicht den eigentlichen VertexBuffer sondern nur den Bereich im VB Array.

2) Normalen VB [CNormalVertexBuffer : public IVertexBuffer]:
Dieser arbeitet dann wie die meisten Kaspelungen von VB's. Z.B so wie es David gemacht hat.

Durch die Schnittstelle (Interface), ist die Benutzung immer gleich und man kann mit nur einer Konstante entscheiden welche Version nun benutzt werden soll. Das ist in sofern Vorteilhaft, das man schnell Testen kann welche Version schneller ist, für das jeweilige Objekt.
Das war auch schon alles

Zitat

Wenn man sich nun einmal die Beispielklassen CBufferManager, CModel, CTextureManager vorstellt, was für Methoden sollten diese dann so bieten?

Ein bischen must du schon selber nachdenken. Wir können dir ja nicht alles vorsagen. Dann kannst du auch gleich eine fertige nehmen. Der Effekt ist der selbe.

Zitat

Wäre es ok, wenn man mit CModel ein Model lädt, und die CModel Klasse "intern" den Buffer Manager sowie den Texture Manager aufruft, um einen neuen VertexBuffer sowie Surfaces für Texturen zu erhalten? So könnte ich mir die Hirarchie gut vorstellen.

Na wenn du dir diese Hirarchie so gut vorstellen kannst, was spricht dagegen wenn du diese Hirarchie einmal weiter denkst, um zu sehen ob sie sich auch zukünftig bewehrt. Auch hier muss ich dir sagen, ein bischen selber nachdenken.

Ich hab allerdings nur mein eigenes Konzept und es würde nicht viel bringen es dir zu geben. Es würde auch den Rahmen dieses Forums sprengen. Bei den anderen ist das sicherlich auch so.

Was für Methoden deine Klassen haben werden ergibt sich zudem daraus was du von der Klasse verlangst und wie sie sich in deine Engine einfügen soll. Du must dich fragen was will ich von der Klasse und dann must du das in Methoden fassen.
Es ist zudem sehr Sinnig wenn der Manager (z.B. der Textur Manager) die Objekte erzeugt. Also eine Methode bietet die dies ermöglicht. Als Ergebnis wird dann das fertige Objekt geliefert. So erleichterst du dir das hinzufügen eines neuen Objektes und die suche nach einem bestehenden Objekt. Die Initialisierung des Objektes kann nur das Objekt selber vornehmen. Man kann diese Aufgabe auch dem Manager auftragen. Allerdings um weiterhin flexibel zu bleiben, muss man bei einem neuen Objekttyp auch eine Building class hinzufügen, die dann für den Manager das Objekt erstellt. Reichlich kompliziert. Also überlassen wir die Initialisierung dem Objekt selbst.

All das beeinflust die Methoden die eine Klasse später haben muss, damit das zusammenspiel klappt.

Du solltest m.E. außer den "Managern" zwei Klassen haben für ein 3D Modell (z.B. Flugzeug). Eine, von der es nur eine Instanz pro Typ gibt, mit Informationenen wie: Wo sind die Waffen, wo kommt Rauch raus etc etc. Also 3D Eigenschaften, die nicht aus dem VB/IB kommen.

Und eine mit einem C++ Objekt pro wirklichem 3D Objekt, z.B. mit den individuellen Markierungen, Beschädigungs Zustand (z.B. rechter äußerer Tragflügel fehlt), Animations Zustand (z.B. Fahrwerk ist ausgefahren) etc.