Servus,

Wie implementiert man sauberes Resourcen Management in einem Spiel bzw. in einer 3D Engine.
Mit Resourcen Management meine ich folgendes:

Man hat ein Spiel.
Ein Spiel benötigt viele Daten (Texturen, Shader, Meshes, etc).
Einige dieser Daten werden zur Laufzeit gewechselt z.b. Shader und Texturen.
Manche Daten werden sogar direkt in den Grafik Speicher gepackt (VBO, PBO, FBO).
Der Grafikspeicher ist immer begrenzt.
Der Arbeitsspeicher ist immer begrenzt.
Spiel informationen werden Dynamisch geändert.
Zugriff auf Objekte per Name.

Wie bekommt man all diese Punkte unter einen Hut?

Ich habe da schon von einigen Sachen gehört:

- Geometrie / Mesh Sortierung (per Material, per Object ?)
- Scene Graph
- Streaming
- State erkennung
- Actors
- Hashtable
- Resource Sharing
- Virtual File System

Aber ich werde bei keinem wirklich schlau. Mir geht es nicht um die Programmierung sondern um die Theorie.

Hätte da gern mal ein bischen klarheit.

Danke,
Final

Also eine Faustregel für sowas gibt es leider nicht, aber vielleicht hilft dir sowas wie Gang-of-Four weiter. Das sind Design-Patterns, die für viele verschiedene Anwendungsfälle grobe Mustervorschläge machen. Evtl. ist da etwas bei, was dir weiter hilft.

Um Rescourcen zu laden und zu verwalten würde ich das Observerpattern vorschlagen, damit kann man relativ flexibel auf Zustandsänderungen von Objekten reagieren. Also ein Manager, der die Daten beobachtet und auf Anfrage referenzen darauf zurück gibt und diese zählt. Gibt es auf ein Objekt keine Referenz mehr, kann man sich von ihr trennen.

Des Weiteren kann man das Flyweight-Pattern gut benutzen um auf Modelle oder Texturen zuzugreifen. Man hat die Daten einmal im Speicher und hat ein referenzierendes Objekt (das flyweight), dass nur variable Zusstände speziell für dieses Objekt merkt. Alle Gemeinsamkeiten liegen im referenzierten Objekt im Rescourcenmanager.

Für Shader/Material wechsel bietet sich eine Baumstruktur an (Chain of Responsibility), bei der alle Materialien (ich rede dabei größtenteils von Texturen) sich ihren Shadern unterordnen und diesen wiederrum die DrawCalls für die Meshes untergeordnet werden. So aktiviert man jeden Shader und jede Textur nur einmal und zeichnet alles auf einmal.
Ein Baum der sich nach dem Prinzip sortiert sollte nicht allzu schwer implementiert sein (nennt man sowas schon einen Rendergraph?)

Shader, Materialien und Meshes sind auch nur flyweights, die auf die bestehenden Daten im RescourcenManager zugreifen. Mesh-flyweights haben dahingehend die spezielle Eigenschaft einen Drawcall für ein VBO durchzuführen.

Den beschriebenen Rendergraph kann man nach oben hin noch um Projektionsmatrizen erweitern, so dass man am Anfang des Baumes die Rendereinstellungen hat (glenable(xyz); glClearColor(); glPerspective();) , darunter folgen dann Shader>Material>Mesh

Wäre meine Idee an so etwas heranzugehen.

_________________
Klar Soweit?

@Gang-of-Four / Design-Pattern:
Es ist natürlich allgemein praktisch wenigstens die wichtigsten Pattern zu kennen.


Ich verweise mal auf:
http://www-users.rwth-aachen.de/martin. ... Engine.php

Ich behaupte nicht das diese Lösung perfekt ist oder sonst was, es ist nur ein Ansatz. Insbesondere wurde das nie in der Praxis umgesetzt.

Allgemein rate ich dir einen Mittelweg zu gehen: Versuche nicht das NonPlusUltra-Resourcenmanagement zu implementieren. Das ist zwar machbar, aber dann kommst du zu nichts anderem. Andererseits ist es natürlich extrem geil wenn man im Spiel einfach "R" drücken kann um z.B. Shader neu zu laden.

_________________
Yeah!

Klasse danke, der letzte post ist richtig interessant.
Habe mir das mal durchgelesen und finde die lösung gut.

Ich werd wohl jetzt mal versuchen, ein "ähnliches" schema zu erstellen.
Gut zu wissen das es auch ein gutes UML tool für windows gibt.
Sowas hab ich ebenfalls schon gesucht.




Nicht desto trotz hab ich noch weitere fragen:

Wenn ich ein Mesh habe, das besteht z.b. aus 10 Objekten jeweils 12 Faces, also 10 Würfel. Der Einfachheit halber.
Jeder Würfel hätte ein eigenes Material (Shader / Texturen).
Das wären dann 10 VBO´s die ich rendern müsste und 10 Shader / Texture changes somit 10 Drawcalls.

Aber was ist wenn z.b. jede Würfelseite eine unterschiedliche Texture hat (Worstcase) ?
Dann wären das ja 12 * 6 = 72 (Texture changes) und somit dann auch 72 Drawcalls.



Ich errinnere mich das ich mal eine Demo gebaut habe, damals noch in C++ (um in C++ rein zu kommen)
In der ich meine Meshes nach Materialen sortiert habe, und dann einfach die Indices neu generiert habe und per VBO gerendert. Das generieren der indices ist bestimmt nicht schnell passiert, weil da keinerlei optimierung dahinter war.

Dazu kam noch ein Forward Renderer der noch zuzüglich Licht und Parallax mapping per Shader umgesetzt hatte (Ohne schatten). Die demo war trotz Octree auf sehr vielen System unanguckbar (5-10 fps) bei 40 Lichtern.

Ob des am forward renderer oder am indices generieren liegt, keine ahnung. Effektiv kann ich mit dem projekt eh nix mehr anfangen.



Ich will diesmal auch verhindern das mit das mit meinem nächsten Projekt passiert.
Das sollte durchgehend flüssig laufen, deswegen brauch ich da die best mögliche optimierung.

Habe von einer Technik gehört die sich Megatexture nennt, wo man eigentlich nur noch sehr selten Texture changes macht, und alles in einer grossen 40k x 40k texture liegt (Aufgeteilt in mehrere) und man nur noch mit Offsets arbeitet.

Wäre in so einem fall wie oben besser ?

Du solltest deine Objekt so erzeugen das du pro Objekt nur eine einzige oder wenige Texturen hast. Bei Shadern solltest du überlegen ob du nicht doch irgendwie mehrere Shader in einem kombinieren kannst.


Der Vorteil von Megatextures liegt vor allem in der Speicherverwaltung. Man bekommt dann nämlich quasi gratis die Option nur einen Teil der Textur im Speicher zu halten und ständig im Hintergrund von der Festplatte nachzuladen. Trotzdem, Megatextures sind aufwendig in der Implementierung, also gut überlegen ob du das wirklich brauchst.....du kannst unmöglich alleine eine Unreal3 Engine o.ä schreiben...


Wenn du den UMLSculptor unter Windows nutzt hat der einen nervigen Bug das Pfeile nicht immer korrekt gespeichert werden. Wenn man UMLSculptor via Wine unter LInux laufen lässt ist dieser Bug aus mir unerklärlichen Gründen behoben, dafür gibt es ein paar andere weniger schlimme.
Ich bin mittlerweile auf Umbrello umgestiegen, was aber nur unter Linux richtig läuft.

_________________
Yeah!

Ressourcenverwaltung läuft über einen SceneGraph.
SceneGraph sind total unterschiedlich strukturiert und das hat teilweise auch seinen Sinn.
Zu abstrakte SG sind langsamer, zu Spezielle zwar schnell aber schwer nutzbar für weitere Projekte.

Der trend in größeren Spielen geht zu Datenbanken, hierbei nimmt man eine Lokale Datenbankstruktur oder sogar eine echte(sqlite) und packt dort alle datensätze rein. Views erlauben das reduzieren der Datenmassen auf spezielle notwendige Datenauszüge wie z.B. ActiveObjectView(wo man nur die IDs drin hat, wo "SELECT ID FROM Physic_DynamicObjects WHERE Active=true") für Physikberechnung oder ShaderView("SELECT ID,Type,Data,FileURI,Status FROM Resource WHERE Type=SHADERID"). Der Vorteil, man spart sich ne menge arbeit mit Hashtables, Hashfunktionen und so weiter, es ist skalierbar, portierbar, bietet noch schicke möglichkeiten wie Savegames(einfach die temporäre sqlite file kopieren und umbenennen).

Wer wirklich absolute Performance braucht benutz typesave/nicht typsichere(man sollte wissen was man tut) signals(oder auch als events bekannt) sigc++ ist hier der schnellste typsichere und die signals aus meinen Radon Framework code sind nicht vollständig typ sicher aber nochmal 10x schneller als sigc++ und damit das schnellste was ich bis dato finden konnte.
Signals/Events sind absolut wichtig sobald es komplizierter wird. Man Fügt eine Resource in sein SG, darauf hin ändert sich natürlich irgendwo eine liste intern und das löst ein signal aus, welches z.B. Views und andere Listen aktualisiert.
Der Vorteil ist, man braucht keine Loop mehr und dinge wie Physik, KI, ResourcenManagment regelt sich dann von selber.

Ich hatte damit mal ein bischen experimentiert und mit LinkListen, Signals und struct ein kleines SG aufgesetzt.
Das arbeiten war ein Traum, da Datenbanken Logisch sind und ich hab dann eine View Dynamische Objekte gehabt, welche alle möglichen Objekte enthielt, die überhaupt sich Physikalisch verändern können, daran hab ich eine View gepackt, die nur aktive Objekte anzeigt, daran eine view, die eine Octree drüber legt und anhand einer Positionsangabe und Radius alle aktiven Objekte in meiner Spielerumgebung(OctreeNode) gegeben hat. Die Physik kann nun sich die View mit allen aktiven Objekten nehmen und diese durch berechnen, neu positionieren und velocity anpassen. Wenn dann z.B. velocity 0 wird, dann gibs ein event und fällt aus den views raus. Threads können dann auch eingesetzt werden und damit wird es schick schnell. Was immer begleitend mit kommt sind Hashfunktionen, ich empfehle aktuell murmur2 hash. Wörter, Wortketten, Scripte und so weiter kann man durch Hashes auf z.B. 64Bit zusammen fassen und schnelle lookups ermöglichen.
Das schöne daran ist, dass man sich auf das Wissens von Datenbankentwicklung und betreuung stützen kann

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Oha wäre nie auf die Idee gekommen eine Datenbank für Spiel-Daten zu nehmen ausser in einem RPG.
Da hätte ich zumindest SQLite benutzt. Werd ich mir mal im hinterkopf behalten.

Tak aber was meinst du in deinem letzteren Post mit "View" ?

Datenbanken nutzen Views um die Anzahl von Datensätzen zu reduzieren.
Dabei wird ein SQL SELECT Befehl benutzt, der die Datenmenge verkleinert und als Ergebnis eine art virtuelle Tabelle darstellt.
Neben einer Tabelle mit Userdata gibt es oft dann Views, die z.B. nur ID, E-Mail und Passworthash aus der Userdata Selektiert.
Views sind im Prinzip Caches und reduziert die zeit beim Parsen der SQL Befehle(bei SceneGraph mit DB Anbindung total uninteressant) und die Anzahl der angefassten Elemente ist wesentlich geringer und damit kann die Anfrage viel schneller durchgeführt werden. Views können je nach Datenbank gecached und Eventbasiert aktualisiert werden. http://de.wikipedia.org/wiki/Sicht_%28Datenbank%29

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

TAK, was du da schreibst ist etwas was ich im Studium nie gelernt habe, aber extrem wichtig ist.
Ich fände es extrem sinnvoll, das was du da schreibst mal in einem "Bomberman-Like" Tutorial abzufassen.
Ich denke viele die hier anfangen, wissen schnell wie man die ein oder andere Sache implementiert. Aber wie man alle Sachen zusammen nimmt und daraus das Kernframework für seine Anwendung schmiedet, das ist nochmal etwas ganz anderes.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Genau so gehts mir, ich versteh die Teile Einzeln, aber wenns dann drum geht alles zusammenzuführen scheiter ich
Versuche übrigens gerade eine SceneGraph implementierung -.-