Sollen sich Objekte selber zeichnen oder nicht?

[rapso]

Ishildur schrieb:

@rapso
Ich bin über deinen Eintrag ein wenig verwirrt...
Wenn es nur ums Rendern geht OK, dann pflichte ich deinem Eintrag bei, aber wir haben ja auch noch ein KI System, ein Collision Detection System, ein Missions System sowie ein Scripting System, welche allesamt auf den Scenegraphen zugreifen müssen. Wir hatten uns das so gedacht, dass die "logische Welt" in einem SceneGraphen abgebildet wird.

ich hatte dir das fuer transforms, culling, rendering geschildern, ich kann es weitertreiben fuer sound, collision, scripting etc.
alles was scriptable ist, wird beim scriptingsystem regestriert. natuerlich nicht jeder stein und jede wand, wieso auch? trigger boxen, ai-areas usw. schon, die braucht auch nur das scripting system. natuerlich darf das scriptingsystem auch mal selbst in dem container der entities nach "goldschatz" suchen duerfen um den dann bei sich zu regestrieren. aber wozu sollte das scriptingsystem jeden einzelnes objekt in der welt, nur weil du einen einzigen scenegraph hast, durchtraversieren? oder sollten die objekte selbst sogar scripte haben? was wenn es mehrere gibt, fuer sound, on-click etc. scripte? jedes objekt mit eigener scripting logik?
Collision detection? da regestrierst du am besten nur die meshes+transformation. also auch die die nicht geraendert werden (invisible walls anyone?), dabei kannst du statische objekte sehr optimiert orginisieren und die dynamischen darin testen.
Mission system? dem kann 99.9% von dem im transformation graph egal sein.

Würdest du denn vorschlagen, dass all diese Systeme einen eigenen Scenegraphen oder was auch immer benutzen sollten?

ich schlug vor einen simplen container zu nutzen falls es fuer das system ausreicht. und falls nicht, etwas optimales fuer das system.

std::...<entity*> renderable.

Ich finde ja auch, dass mit einer solchen Liste Spiellogik und Rendering auch nicht mehr getrennt ist...

das entity als datencontainer ist natuerlich shared.
beim trennen spricht man allgemein vom programcode, nicht so strikt von den daten, denn die daten kann man abstrakt halten sofern es nicht spezialisierten code gibt.
als beispiel kann dein entity ein material haben das "dachpappe" heisst. was bedeutet dachpappe? Fuers soundsystem ist es vielleicht dachpappe.wav, fuer physics bedeutet es dass soein objekt zerbrechen kann. fuers rendering dass es den dachpappe.pixelshader und dachpappe.bmp nutzt. was bedeutet es fuer das entity? garnichts, des es gibt keinen spezialisierten dachpappe code im entity.

das ist _meine_ sicht was trennung bedeutet.

wenn du sowenig zeit hast, wundert mich dass du so knapp davor mit diskusionen ueber grundlagen deiner software anfaengst.

Ja dumm ich weiss...

das sollte eher ein arschtritt sein dass du jetzt wie ein wilder fleissig loscodest
Am ende wirst du eh unzufrieden sein und "beim naechsten mal mach ich alles besser" sagen. programmierer krankheit.

[Ishildur]

OK, ich sehe, dass ist ein ganz anderer sehr interessanter Ansatz. Ich hatte mehr eine Art MVC Pattern im Auge, sprich der SceneGraph sollte das Model sein, die verschiedenen System (Collision, Mission, Scripts) die Controls und der Renderer das View.

Sehe ich dass aber dann richtig, dass sich bspw. jedes abgefeuerte Projektil (100erte) sich dann beim Rendergraphen, sowie beim AudioGraphen und dem Physikgraphen registrieren müssen?

Ich hatte eben mehr so eine Art Layersytem im Kopf. Bei deiner Architektur erscheint mir das mehr so wie eine Art Client-/Server System, (Projektil ist ein Client, der sich bei mehreren Servern registriert, die dann die Daten verarbeiten). Oder habe ich das komplett falsch verstanden?

wenn du sowenig zeit hast, wundert mich dass du so knapp davor mit diskusionen ueber grundlagen deiner software anfaengst.

Hehe, nein die Frage ist natürlich schon berechtig. Ja wir hatten einfach mal angefangen mit sehr allgemeinen Dingen wie Errorhandling, Logging, Datenstrukturen, Mathlibrary und dem Resourcenmanagement (Laden von Texturen, Meshes, Fonts usw). Natürlich hatten wir uns bereits ganz am Anfang wochenlang den Kopf darüber zerbrochen, wie wir alles machen wollen, aber irgendwann hatten wir gesagt, "Wir müssen jtzt einfach mal anfangen, sonst sind wir in 4 Monaten immer noch am überlegen, wie wirs genau machen wollen und haben einfach nichts"

[rapso]

Ishildur schrieb:

OK, ich sehe, dass ist ein ganz anderer sehr interessanter Ansatz. Ich hatte mehr eine Art MVC Pattern im Auge, sprich der SceneGraph sollte das Model sein, die verschiedenen System (Collision, Mission, Scripts) die Controls und der Renderer das View.

Es ist im gewissen sinne noch ein MVC (sogar staerker als wenn du das objekt sich selbst rendern, abspielen usw. lassen wuerdest).

Du hast aber dedizierte container in denen objekte organisiert sind, dadurch sparst du dir quasi beim visitor einen filter zu haben. ein visitor, z.b. "frustum" in einem "culling system container" wird vom container gegen die objekte evaluiert. das kann jedes einzelne entity sein oder die hierarchy eines octrees, das resultat von dem "visitor" (ich glaube das heisst, anders, visitor ist ein aktiver part, das einhaengsel hatte noch nen anderen namen auf den ich nicht komme) ist eine verfeinerte liste von objekten. (eventuel auch transformiert, z.b. in drawjobs).

Sehe ich dass aber dann richtig, dass sich bspw. jedes abgefeuerte Projektil (100erte) sich dann beim Rendergraphen, sowie beim AudioGraphen und dem Physikgraphen registrieren müssen?

jap, du wirst auch schnell sehen "100erte" sound kann kein system ertragen, behalte nur die 16 nahesten bzw lautesten. waehrend "100erte" particle locker gehen.

Ich hatte eben mehr so eine Art Layersytem im Kopf. Bei deiner Architektur erscheint mir das mehr so wie eine Art Client-/Server System, (Projektil ist ein Client, der sich bei mehreren Servern registriert, die dann die Daten verarbeiten). Oder habe ich das komplett falsch verstanden?

das stimmt schon, deines ist wie eine datenbank mit einer zentralen table in der alles pro entry vorhanden ist. Ich schlage quasi mehrere tables vor die auf einzelne eintraege mit spezialisierten keys indizieren. das "ubersystem" waere dann natuerlich das mit der ID und jede table hat fuer sich die daten, das waere vermutlich aus datenbanksicht eine saubere normalisierung.

leg dich nur nicht zu extrem auf ein system fest, nichts ist pefekt fuer alle bereiche ;).

[Ishildur]

Nun bleibt die Frage, wer registriert diese Entitäten?

Ich habe mal ein Spiel gemacht, da lief das folgendermassen. Jede Entität hatte einen Zeiger auf die Welt, in der es sich befindet. bspw...

void PlayerShip::Update(float32 Time){
 if(Services::GetService<InputService>("Input")->IsKeyDown(DIK_SPACE)){
  this->wpnAct->Fire();
 }
}

void LaserWeapon::Fire(void){
 if(this->heat < MAX_HEAT){
  this->GetWorld()->Add(new LaserBeam());
  Servies::GetService<AudioService>("Audio")->Play(this->snLaser);
 }
}

Der Vorteil von sowas ist halt, dass ich jederzeit neue Objekttypen hinzufügen kann, ohne dass ich an der Engine was rumbasteln muss, da diese Entitäten selbständig mit den verfügbaren Services kommunizieren und die Welt manipulieren.

Wie würde sowas nun mit der von dir vorgeschlagenen Architekur aussehen? Eben bspw. ein Ship will in seiner "Update" methode einen Schuss abfeuern (Die Spielengine hat keine Ahnung, was das Teil tut, sondern ruft eifach einmal pro Frame die "Update" Methode auf) Oder ist das auch bereits der falsche Ansatz?

[abc.w]

Ich verstehe von der Diskussion wenig bis gar nichts, aber ein Leerzeichen für die Einrückung von Code tut meinen Augen wehe. Aus dem Code wird nix

[Ishildur]

Aus dem Code wird nix

Noch so ein Ding... Augenring...