Hi zusammen,

mich würde mal interessieren wie Ihr es so geregelt habt alles zu Managen...
derzeit versuche ich für jeden Part eine Manager-Klasse zu schreiben (Material Manager, Texturmanager, Schader Manager(der bereitet mir noch etwas kopfzerbrechen)) auch wie ihr Eure Objekte in diesem zusammenhang am besten Managed damit nicht zu oft zwischen Material/Textur und Shader gewechselt wird...

// War mal so frei den Titel anzupassen. Horazont.

_________________

Wow. Das was du meinst heißt Software-Architektur nicht Programm Management (das ist die Koordination von Mehreren Entwicklungsprojekten und hat was mit Projektmanagement zu tun bzw ist die Stufe oben drüber )

Ich war auch immer sehr interessiert daran die Architektur der complexen und recht aufwändigen Effekte zu kapieren die hier in Projekten wie GAEL oder ProjektW verwendet werden. Da gibt es ja die verschiedensten sachen zu beachten. Man muss seine Daten strukturieren, Sichtbarkeiten kennen, eventuell eine Physik-Engine ankoppeln, Schatten berechnen, PostRendering Effekte koordinieren usw.

Wenn es dir um den generellen Aufbau eines Projektes geht und du mit Pascal arbeitest dann ließ dir unbedingt mal das Bomberman Tutorial durch. Sascha wird mittlerweile sicher nicht mehr genau so arbeiten. Aber mit der Vorgehensweise hat er mehrere Projekte erfolgreich umgesetzt.

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

Ja, da könnt ich vieles zu erzählen, aber in dem Bereich gibts ja keine Regeln an die man sich halten muss, da mach ich auch sehr viel intuitiv aus dem Bauch heraus, und dank Refactoring kann man grobe Schnitzer im Softwaredesign leicht wieder geradebiegen.

Solche Manager nutze ich auch, aber natürlich nur wenn sie Sinn machen, und v.a. wenn man sie wiederverwenden will. Einen Shadermanager und einen Texturenamanager hab ich natürlich auch, die gabs aber schon vor ProjektW.

Allerdings entwickle ich ja inzwischen auch beruflich mit Delphi und arbeite da an Projekten die sehr viel komplexer sind als Projekt "W" (mehrere Millionen Zeilen Quellcode, dutzende Packages, hunderte Units, etc.), und da sieht die Sache schon ganz anders aus. Da sitzt man mal gerne etwas länger mit mehreren Entwicklerung zusammen und denkt drüber nach wohin eine neue Klasse soll, wie sie heisst, was sie kann, welchen Unitnamen man nimmt, wo dieser verwendet wird, etc.

Im Hobbybereich ist das ganze nicht so dramatisch. Ich denke hier sollte man nicht zu viel Zeit damit verschwenden ein möglichst modulares System zu bauen und nur wirklich dann "Manager" zu nutzen wenn man diese Programmteile auch irgendwo anders verwenden will. Ansonsten gelten halt die allgemeinen Grundlagen, also aussagekräftige Bezeichnernamen, größere Klassen in eigene Units (hatte zeitweis ne Klasse mit 150+ Funktionen und 200+ Variablen in PjW, die hab ich dann aufegdröselt) etc.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Prinzipiel ging es mir in erster linie darum mir einiges zu vereinfachen um nicht immerwieder zig zeilen zum binden, laden, setzen irgendwelcher GL Operationen und mir auch verschiedene Möglichkeiten offen zu halten da ich mir über das eine oder andere einfach noch nicht so recht (auch mangels ausreichender Erfahrung mit OpenGL) im klaren bin. Ein ObjektManager kann ich zB derzeit nicht weiterschreiben weil ich mich noch nicht so recht für ein Dateiformat entscheiden konnte...
Beim Textur- und Material Manager hab ich unter anderen bis jetzt vorsorglich darauf geachtet das ich ein und die selbe textur/material nicht immer wieder lade, falls ich die Texturinformation mit zu den Objektdaten schreibe ect...
Ein Terrain habe ich testweise mal mit einem Quadtree benutzt was auch prima funktionierte, nun aber doch zu einem Octree ausgewichen bin da ich mir gern die Möglichkeiten von kleinen Höhlen oder ähnliches (wie in Gothic 1 zB) offen halten wollte...
vieles muss ich demnächst noch versuchen... Schatten und evtl wasserspiegelung... liegt also noch einiges vor und erhoffte mir ein paar gute tipps und ratschläge von euch etwas erfahreneren Leutchen hier
Neben den vielen tutorials die ich nebenher schon lese und probiere

_________________

Ah. Dann bau das ganze doch einfach so, dass du dir eine Klasse baust, die ein Modell lädt und deinem Programm in dem für dich optimalen Format zur verfügung stellt. Hinter die Methoden kannst du dann beliebige Modelloader setzen, ggf. mit ein bisschen Konvertierung. Und das lässt sich vorallem einfach erweitern um mehrere Modellformate zu unterstützen.


Also ich kann mal ein paar Worte zu dem Design sagen, das wir in PyUniverse anstreben. Erstmal ist das da sowieso was besonderes, da nur der wirklich Performancekritische Teil in C++ liegt, der Rest liegt in Python. Dank boost::python sind die Klassen aber sowieso transparent in beiden Ökosystemen verwendbar, also ist das hier denke ich schon sinnvoll.

Zugrunde liegt erstmal ein einfaches virtuelles Dateisystem. Darüber kommen wir an die Dateien. Bisher kann man hier nur echte Ordner einbinden, später sollen auch Tarballs und ähnliches verfügbar gemacht werden.

Wir haben einen globalen Resourcenmanager. Der hat eine Methode require, in der man den VFS-Pfad zu einer Resource angeben kann und welcher Art die gelandene Resource sein soll (oder man lässt sich von der zurückgegebenen Klasse einfach überraschen ). Wenn man einen Typ angibt, wird der auch überprüft und es werden Fehler geschmissen (← Klare Fehlerstrukturen sind wichtig! Nutze Exceptions wo sie angebracht sind (also wenn es wirklich ein Zustand ist, wo weitermachen in der Methode keinen Sinn hat), Rückgabewerte sonst) wenn der Typ nicht passt.

Beim Start registrieren sich die einzelnen Loader, deren Basisklasse ein definiertes Interface hat. Über dieses Kommunizieren die Loader an den Manager, welche Resourcen sie zur Verfügung stellen können. Optional können sie das Caching-Verhalten überschreiben, aber per Default werden alle Resourcen anhand ihres VFS-Pfades gecacht.

Dann baut René uns einen Scenegraphen, der sich verhält, wie sich ein Scenegraph zu verhalten hat . Dort hängen wir also unsere Objekte mit ihren Transformationen rein, erweitern das ganze noch um Kameras und bauen so unsere Szene zusammen. Im sog. „Rendergraphen“ (name change pending; hat sich herausgestellt, dass der Name schon reserviert ist für andere Dinge) stellt man dann ein, wie die Szene gerendert werden soll. Beispielsweise wäre eine Node des Rendergraphen “Deferred Shading”, bei der man ein paar Puffertexturen sowie die Scenegraphkamera angibt, aus deren Perspektive gerendert werden soll. Dann können darein beliebige weitere Nodes geschachtelt werden, die mit den Pufferdaten des Deferred Shaders arbeiten. Dann wird die UI drüber gelegt und fertig ist die Szene.

Während der Entwicklung nutzen wir ein ganz nettes Werkzeug, das mir schon vor längerer Zeit nahegelegt wurde, das ich aber in Ebenezer'scher Art als Humbug abgetan hatte. Das stellte sich als grober Fehler heraus, denn mit Unittests macht alles viel mehr Spaß. Idealerweise sollten sie schnell zu schreiben sein (Beispiel: 19 Unittests in 134 Zeilen) und einfach zu testen (bei uns reicht ein `./unitest.py` im Projektverzeichnis für den verlinkten Output unten). Man darf sich nicht durch 10 Menüs klicken müssen. Die Ausgabe sollte klar sein und man sollte möglichst viele Informationen erhalten, wenn ein Test abbrennt (→ so sieht unser Output aus).

Die muss man dann regelmäßig überprüfen um festzustellen, ob irgendwo eine Regression aufgetreten ist oder sich etwas nicht mehr so verhält wie erwartet. Wir haben das für uns sogar automatisiert. Für einen Push nach devel müssen sich alle Tests so verhalten wie geplant (man kann also auch einen Fehler als „Ja, ich weiß, dass da was schief läuft, aber ich kümmere mich drum“ markieren und trotzdem pushen), wenn man nach master pusht darf kein Test fehlschlagen (sonst verweigert Git die Annahme der Daten).

Ein anderer verdammt wichtiger vorteil von Unittests ist: Sie migitieren das Motivationsproblem bei Low-Level-Arbeit! Man hat da ja meist so ein Gefühl dass man nicht vorran kommt, weil man halt einfach keinen wirklichen Output sieht, wenn man 2000 Zeilen Gamelogic geschrieben hat. Lösung: Die Logic mit Tests abdecken! Jeder passende test ist ein fettes, grünes ok auf dem Terminal, was ungemein motivierend ist. Wenn die Testanzahl dann schnell zwei oder dreistellig wird, dann hat man trotzdem das Gefühl was geschafft zu haben (ist ja auch so).


Im Prinzip setzen wir auf ein möglichst modulares Layout, trotz dass es sich nur um ein Hobbyprojekt handelt. Das ist uns auch schon stark zugute gekommen, als wir nach ein paar Wochen festgestellt haben, dass Pyglet nicht ausreicht für unsere Zwecke. Das war der Punkt, wo wir unsere eigene C++-Library für I/O und OpenGL geschrieben haben. Da wir vieles abstrahiert hatten, konnten wir vieles auch recht schnell austauschen. Um das Zeichnen der UI von OpenGL auf cairo umzustellen, musste garnicht viel geändert werden. Die Geometrie wurde schon vorher von nur einem Klassenbaum (also „Füller“-Klassen (wie in Flutfüllung, nicht wie in Kugelschreiber)) erzeugt, das Zeichnen fand nur in einer Methode statt. Diese beiden angepasst ergab sich schnell Rendering mit Cairo, das man auch in unserem ersten offiziellen Screenshot bewundern kann.

Wo ich gerade von Git redete. Versionskontrolle ist etwas, mit dem man sich unbedingt auseinander setzen sollte. Das hat zwei Vorteile. Andere können von Anfang an die History zurückverfolgen und mitentwickeln, und vorallem kann man in einem Branch was ausprobieren, feststellen dass es nicht klappt und zum Master zurückkehren, ohne, dass man alle Änderungen manuell rückgängig machen muss.

Vielleicht ergänze ich das noch. Nun erstmal Quantenmechanik.

//Edit:
Ahje, schon gehts los. Ich habs ja mehrfach verlinkt. Dokumentation will man natürlich. Such dir ein System aus, wie du deinen Code dokumentierst und dann zieh das möglichst konsequent durch. Fällt schwer, aber wenn's mal nicht so direkt klappt ist auch nicht schlimm. Es gibt immer diese Phasen wo man keine lust zu Programmieren hat und lieber Dokumentation schreibt. Ich persönlich würde einfach mal Sphinx für alles, was mit Python oder Doxygen-Kompatiblen Sprachen zu tun hat, empfehlen. Man kommt sehr schnell zu ansehnlicher Dokumentation (siehe Links auf docs.pyuniverse.org). Die offizielle Python-Dokumentation ist ebenfalls mit Sphinx gemacht. Ich finde Sphinx Dokus um längen übersichtlicher als dieses Doxygen-Zeug, und das beste: mit breathe frisst sphinx auch doxygen-output.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Darin lag ja mein Problem, ich wusste noch nicht recht wie ich mir ein für mich optimales eigen-format aufbaue, was sich (zumindest für static meshes) aber immerhin schon einmal geändert hat, hab nun mein eigenes Format und auch ein einfachen Wavefront OBJ loader/konverter geschrieben.
Wo ich ganz nebenbei schon dabei bin eine Frage ganz nebenbei ohne neuen Thread:
Ich habe einige (Bone) Animierte Meshes , leider nur in DirectX .x Format, habe bisher noch kein programm gefunden mit dem ich diese richtig laden und nach möglichkeit in ein (für OpenGL) 'brauchbareres' Format konvertieren kann. Kennt da jemand etwas nützliches?

Einzelne Klassen und Funktionen zu testen gestaltet sich derzeit noch als schwierig und Zeitaufwendig und im nachhinein immernoch ohne Garantie, denn derzeit prüfe ich lediglich auf fehler im code und prüfe ein paar debug und test variablen auf korrekte Ausgabe...
Viel Zeit kostet es auch alle einzelnen Klassen und Funktionen so abzustimmen das sie mit und unter einander 'arbeiten' können...

Habe daher inzwischen überlegt erst einmal mit einem Editor anzufangen um neue Funktionen direkt darin zu testen um gleich etwas 'sichtbares' zu haben...

_________________

Das mit dem Editor finde ich gut, so hab ich das auch gemacht. Dann hat man ne gute Testumgebung und den brauchst du früher oder später soweiso um kontent zu erschaffen, zumindest wüsste ich nicht wie man ohne auskommen soll.^^

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,

Ist zwar n bissl älter das ganze aber evtl hilft dir das hier auch ein bissl. Ich werd mich allerdings etwas kürzer halten da es sonst wahrscheinlich zu lang wird,
wenn jemand fragen zu einen bestimmten Punkt hat einfach Stellen :

Zunächst einmal habe ich mir eine Klasse für OpenGL Objekte gebaut welche Reference Counting implementiert. Richtig auf die GPU geladen werden sie aber erst
wenn sie das erste mal genutzt werden um zu gewährleisten das Unload immer vor dem Load aufgerufen wird. Das hat schlicht und einfach den Vorteil das während
der Laufzeit sehr schnell bestimmt werden kann welche Texturen,Shader und Buffer nicht mehr benötigt werden.

Texturen und Buffer sind hierbei ziehmlich einfach gestaltet da sie lediglich über eine Methode zum Zeichnen verfügen welche einen Delegate erwartet. Für Shader kommt
noch eine Funktion hinzu um Uniforms zu binden. Sprich:


Beim "richtigen" Content wirds nun etwas komplizierter. Grundsätzlich ist hier jedes Objekt ein sog. GameEntity, diese werden einmal in Script und einmal in RenderObjekt
unterschieden. Außerdem besteht die Möglichkeit ein beliebiges GameEntity als Parent zu setzen wodurch 1:Many Relationen entstehen können. Jedes RenderObjekt verfügt
dabei noch über ein oder mehere konvexe Volumen, wodurch wiederum 2 weitere 1:Many Relationenen zu anderen RenderObjekten entstehen (ObjectsInside und ObjectsOutside).
ScriptObjekte übernehmen dabei eine Beschreibung der Renderobjekte, Sounds verschiedenen Eventhandler, sowie deren Erzeugung. Renderobjekte selbst sind Einheiten die
einmal eine Translation/Rotation relativ zu ihren Parent speichern und sich in Betrachter, Emitter und/oder Körper unterteilen. Eine besondere Form des Contents stellen
Materialscripte dar, da diese direkten Einfluss auf Renderobjekte haben (so kann z.B. ein Körper durch ein Material auch gleichzeitig ein Betrachter [z.B. Wasser] und/oder
Emitter [z.B. Lava] werden).

Grundsätzlich gilt das Betrachter ein SetupDraw Event besitzen welches es erlaubt Objekte in FBOs zu Cachen, dabei ist der Default:

DrawCached überprüft dabei ob sich die Objekte im Array geändert haben und zeichnet ggf. in ein FBO für den Identifier des Betrachters.
Für alle RenderObjekte gilt außerdem wieder das Reference Counting um zu bestimmen ob sie noch innerhalb eines ObjectsInside liegen
und ob ein Cache der sie enthält/enthielt erneuert werden muss. Ein Betrachter kann außerdem die Shader seines Parents überschreiben/mutieren
und hat Zugriff auf den Stencilbuffer.

_________________
Meine Homepage