 |
JLI Spieleprogrammierung
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Sören JLI Master Trainee

Anmeldedatum: 26.07.2002 Beiträge: 647 Wohnort: Bonn Medaillen: Keine
|
Verfasst am: 23.07.2005, 23:21 Titel: Hierarchie für Scenegraph |
|
|
Hi,
erstmal vorneweg: Obwohl es um einen Scenegraph geht, bin ich mir sicher das der Thread nicht ins DX/OGL Topic gehört sondern hierher, da es keine GrafikAPI spezifisches Problem ist.
Nun denn: Ich bin gerade dabei alles für den Scenegraph, den ich für meine Engine programmiere, durchzuplanen. Es geht darum, dass im Scenegraph eine Hierarchie aus verschiedenen Nodes erstellt werden soll. Ein Node kann mehrere Childs haben, die wiederrum selber Nodes sind usw. Ich verwende eine Basisklasse, von der ich verschiedene Klassen ableite(zB Node-Klassen für Transformation, Geometrie, Animation usw.).
Nun geht es darum dem Benutzer der Engine, das Erstellen und Ändern dieser Hierarchie so komfortabel wie möglich zu machen. Ich möchte möglichst vermeiden, dass der Benutzer selber umständlich mit Zeigern/ID's usw. hantieren muss, nur um irgendein Node mitten im Baum zu fassen zu kriegen. Leider weiß ich aber momentan keine elegante und einfache Lösung, wäre also sehr nett wenn mir da jemand weiterhelfen könnte.
Grüße |
|
Nach oben |
|
 |
Patrick Dark JLI Master

Anmeldedatum: 25.10.2004 Beiträge: 1895 Wohnort: Düren Medaillen: Keine
|
Verfasst am: 23.07.2005, 23:49 Titel: |
|
|
Hi,
ich glaube scenemanagement definiert jeder für sich selbst Bei mir ist es so, das alles erst sortiert wird (nach Performancekriterien z.B. Texturen) und dann alles was im sichtbarkeitsbereich gerendert wird in einem Abwasch.
Bissel dirty aber funktioniert zur verdeutlichung
CPP: | class scenemanager;
class scene_item
{
public:
// Freundschaft
friend class scenemanager;
// Konstruktor
scene_item (::IDirect3DVertexBuffer9* vb, ::IDirect3DIndexBuffer9* ib,
::D3DMATERIAL9 material,
unsigned long num_vertices, unsigned long num_indices,
unsigned long fvf,
float radius,
array<vector<float>, 2> boundingbox, matrix<float, 4, 4> translation)
:
vb_(vb), ib_(ib), material_(material), num_vertices_(num_vertices),
num_indices_(num_indices), fvf_(fvf), radius_(radius),
boundingbox_(boundingbox), translation_(translation),
invTranslation(translation.invert()) {};
// Destruktor
scene_item (void) {};
private:
// Direct3D spezifische Daten
::IDirect3DVertexBuffer9* vb_; // Vertexbuffer
::IDirect3DIndexBuffer9* ib_; // Indexbuffer
::D3DMATERIAL9 material_; // Material
// Daten
unsigned long num_vertices_; // Anzahl Vertices
unsigned long num_indices_; // Anzahl Indices
unsigned long fvf_; // Flexible Vertex Format (FVF)
// Daten für Sichtbarkeit und Transformation
float radius_; // Kugelradius
array<vector<float>, 2> boundingbox_; // Boundingbox
matrix<float, 4, 4> translation_; // Transformation
matrix<float, 4, 4> invTranslation_;// Inverse Matrix
};
class scenemanager
{
public:
// Bla singleton kram
// Additionsfunktion
inline void addSceneItem (scene_item* item)
{
itemsToRender_.push_back (item);
}
inline void render (void)
{
// Erst BOundingbox-Sichtbarkeitstest machen und eintrag ggf. rauslöschen
// ...................................
// Dann den Stack nach Texturen durchsortieren :) (Performance halt!)
// ...................................
// Dann Rendern und Stack stück für stück abbauen!
// ...................................
}
private:
ttl::stack<scene_item*, 128> itemsToRender_;
}; |
Zuerst macht man bei allen Objekten im Spiel einen sichtbarkeitstest (Sphere), ist dieses dann sichtbar wird sie in den Manager per addfunktion reingestopft. Beim renderaufruf wird dann tiefer getestet per Boundingbox, ist alles ok gehts weiter zum sortieren!
Der ganze stack wird dann z.B. nach Texturen sortiert, da Texturswitches sehr lange dauern. Ist das vollbracht wird der Stack von oben nach unten abgearbeitet bis er leer ist
Diese ganze Scenemanagerverschachtelung halte ich in der heutigen zeit für zuviel Overhead. Wichtig ist heute nur noch das zu rendern was sichtbar ist und dieses dann effizient um wenig Transfer auf dem Bus zu haben. Zuviel verschachtelung beansprucht die CPU ggf. zu stark und die Grafikkarte dreht die däumchen vor langeweile weil die CPU am korkeln ist.
- Patrick _________________ 'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
Nach oben |
|
 |
Sören JLI Master Trainee

Anmeldedatum: 26.07.2002 Beiträge: 647 Wohnort: Bonn Medaillen: Keine
|
Verfasst am: 24.07.2005, 00:08 Titel: |
|
|
Mir gehts jetzt nicht darum, wie das Scenemanagement in der Engine selbst aussieht sondern wie der benutzer von außen möglichst komfortabel Nodes in eine Baumhierarchie hinzufügen und ändern kann(hier ist es halt ein Scenegraph). |
|
Nach oben |
|
 |
xardias JLI Master

Alter: 38 Anmeldedatum: 28.12.2003 Beiträge: 804 Wohnort: Palo Alto, CA Medaillen: Keine
|
Verfasst am: 24.07.2005, 14:07 Titel: |
|
|
MiracleBoy hat Folgendes geschrieben: | Mir gehts jetzt nicht darum, wie das Scenemanagement in der Engine selbst aussieht sondern wie der benutzer von außen möglichst komfortabel Nodes in eine Baumhierarchie hinzufügen und ändern kann(hier ist es halt ein Scenegraph). |
also am einfachsten ist es doch wirklich add und get funktionen zur verfügung zustellen und jedem child eines scenenodes eine eindeutige id zu zuweisen (als string noch einfacher zu handhaben).
Wenn jemand scene nodes verwendet, dann wird er wohl in jedem spielobjekt wie einem spieler einen zeiger auf den scene node des spielers speichern, um darauf zuzugreifen. |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group Deutsche Übersetzung von phpBB.de
|