R
WirrWar2850 schrieb:
rapso schrieb:
echt? also wenn ich mir z.b. Quake anschaue, hab ich da keinen scenengraphen, 99% sind brushes in einem cullingtree und dazu ein paar wenige actors die in einem array sein koennten.
Nun gut, aber funktioniert das auch noch so gut, wenn man außer den Spielern auch noch andere Entities auf der Map hat? Dann werden die Arrays wahrscheinlich recht groß und unhandlich werden .
was waere bei einem scenegraph anders? du hast ne root node und darunter dann die entities alle auf einer ebene. ein scenegraph hilft dir erst weiter wenn du wirklich eine hierarchy hast, doch das kann jedes entity fuer sich auch haben, bzw. sagen wir den worstcase, ein rts.
1000 einheiten, die haben geschuetztuerme und 10 andere kleine attachments pro einheit. da diese dinge spielrelevant sind, haellt der gamecode eh eine representation davon. der scenegraph kann in diesem fall das medium sein um daten zwischen gamecode und enginecode zu transferieren, aber welchen vorteil hat das dass die engine die hierarchy kennt? genau so gut koennten alle objekte nur in einem cullinggraphen liegen, ohne logische hierarchy.
Sinn mach der scenegraph dann erst wenn du nicht fuer die logik relevante, aber fuer die engine wichtige dinge hast. wenn in deinem strategiespiel eine windmuehle ist deren windrad sich dreht, dann will das spiel eventuell garnicht wissen ob es ein windrad etc. gibt. es ist da und dreht sich.
ein kraftwerk stoesst rauchpartikel am schornstein aus, das muss das spiel nicht wissen, aber die engine muss irgendwo einen emitter fuer den rauch haben.
in dem fall macht ein scenegraph eventuell sinn. vielleicht aber auch kein globaler, sondern hilfs scenegraphs pro objekt.
sagen wir, du machst ein sims spiel, du kannst ein frosch in den mixer legen, du kannst den mixer auf ein tisch legen, du kannst den tisch auf ein schlauchbot und das wiederrum in den pool legen. in diesem fall wuerde ich sehr auf scenegraphen legen.
rapso schrieb:
und ich schaetze dass diese aussage void ist, wenn man sich nicht auf ein konkretes beispiel bezieht ;), ansonsten sage ich "ich schaetze die vorteil von raytracing ueberwiegen klar"
Ich wollte damit eigentlich nur sagen, dass die Szene über einen Scene Graph wahrscheinlich deutlich einfacher zu verwalten ist (klar mein ich keine Szenen, in denen bis auf den Spieler alles statisch is!) und dass die Performance eines der wenigen Mankos ist, die man ausmerzen muss.
und ich wollte sagen, dass das so nicht grundsaetzlich gesagt werden kann. in einem spiel wie quake wuerde ein scenegraph nichts einfacher machen, es waere nur ein overhead der alles aufwendiger macht. was zwar nicht sonderlich schlimm ist, aber auch nichts nuetzt.
Was die Bälle betrifft:
Wenn ich die Bälle alle in einem Raum hab und weiß, dass alle auf einmal rumfliegen, würd ich sie mit einem Group Node gruppieren und allen die gleichen Render-Settings zuweisen (Rendern? Updaten? Schlafen?).
du hast also eine root node, darunter die groupnode und dann darunter in einer ebene die baelle die alle durch die gegend flitzen. ich sehe nicht was die groupnode da bringt, ich sehe auch nicht dass sleep irgendwas optimieren wuerde.
andererseits, stell dir vor du hast nen scenegraph in dem zu 99.9% statische objekte sind, dann waere dein sleep auch suboptimal, weil du bei unmengen von objekten immer nur sehen wuerdest dass der sleep auf unendlich steht. in dem fall koennte eine liste mit nodes wo wirklich was passiert sehr viel effizienter sein.
deswegen ist optimieren bevor ein problem ueberhaupt besteht nicht das sinnvollste;)
Aber ich schätze mit dem Profiling hast schon recht... ich mach mir wahrscheinlich viel zu viele Gedanken die ich nachher sowieso net alle berücksichtigen kann .
ja, das wollte ich auch damit sagen. implementier es erstmal, wenn es dann an einer stelle nicht so ist wie du es willst, kannst du es optimieren. wer weiss, vielleicht zieht dein ganzes update nur 1%, klar ist das gut wenn du es auf 0.01% optimieren kannst, aber es wuerde mehr bringen wenn du das rendering das 99% zieht optimiert haettest in der zeit.
also erstmal implementieren, dann weiterschauen
Absolut! Mein erster Gedanke war eigentlich z.b. die Karte in verschiedene Zonen einzuteilen und diese als extra Nodes in den Scene Graph einzufügen, welchen dann der Inhalt angehängt wird. Dann hab ich bspw. einen Node "Zone1" dem alle Objekte unterliegen, die sich in Zone1 befinden, und wenn Zone1 den/das(?) View Frustum nich kratzt, muss gar nich weiter in die Tiefe gegangen werden, was das Durchlaufen meines Graphen deutlich verschnellern würde. Wenn solche Nodes dann nach ihrer World Matrix gefragt werden, geben sie einfach die ihres Parents zurück und schon machen sie keine Faxen mehr. Dass könnten dann zum Beispiel die ersten 2 oder 3 Ebenen des Scene Graph sein.
ist ne moeglichkeit. alternativen zu zones im scenegraph sind zones die z.b. durch portale verbunden sind, oder die in einem grid liegen. wer will schon 1024*1024 zone nodes in ein scenegraph stecken, wenn zur selben zeit vielleicht nur 9 aktiv sind.
rapso schrieb:
das nennt man dann frustum culling, ist sehr gaengig, dabei evaluiert man aus allen vorhandenen objekten die sichtbaren und dann arbeitet man sie im renderer ab.
Das is mir auch klar . Es geht eher um das WIE statt um das WAS . Ich könnte auch bei meinem ganzen SG die Draw() Funktion aufrufen und innerhalb der Funktion entscheiden, ob der Node gezeichnet wird oder nicht, was eben eine recht lange Beschäftigung mit dem Renderer mit sich brächte. Was ich aber will, is eine Funktion im SG Manager, die mir eine Liste mit allen Objekten erstellt, die gezeichnet werden KÖNNEN oder die eben noch einer genaueren Kontrolle bedürfen. Sodass der Renderer nur noch die Nodes bekommt, die auch wirklich was zu zeichnen beinhalten. Blah blah -.- ... ich red mich hier nur um Kopf und Kragen ^^ aber ich weiß was ich mein, also lass mers mal lieber .
gibt noch viele andere wege das problem zu loesen, wenn es mal auftaucht
du kannst auch noch alles multithreaded machen, damit es schnell ist, und du koenntest streaming integrieren, synchronisation uebers netzwerk und...
aber wenn du erstmal einen basic SG machst der sauber funzt, waere es gut
