Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 10:48

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: Karmarama
BeitragVerfasst: Mo Okt 22, 2007 17:45 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Nach dem ich mit mein Projekt Karmarma schon an Version 0.3 arbeite, will ich nun doch mal auf das Projekt hinweisen.

Was ist Karmarama ?
Karmarama ist das Folgeprojekt aus X-Dream.
Die neuauflage zielt auf MMOG(massive multiplayer online games) ab und hat dementsprechend festgelegte Inhalte.
Es müssen z.B. skalierbare Serversysteme, mit sicherer oder schneller Verbindung zur verfügung stehen.
Die Umgebung soll Streamfähig sein und mit hilfe eines SceneGraph optimierung,power und mehr übersicht bringen.
Karmarama setzt auf hardwarenaha und streamfähige Formate und so unterstützt es z.B. DDS mit DXT1/3/5, Ogg und Wav, sowie ein eigenes SceneGraphformat.
Es gibt mehere Datenbankanbindungen(MySQL, Postgresql, SQLite), Windows und Linux Wrapper für Fenstersystem und IO, ein eigene Streamklasse mit registrierbaren Protokollen(z.B. http,file,mem,vfs,...), Materialsystem basierend auf einer Scriptsprache,Shader und Texturen.
Das Ziel ist eine Engine und ein Toolset, um ohne programmieraufwand ein einfaches MMOG zu erstellen und nur programmierung zu müssen, wenn der mitgebrachte Umfang nicht reicht.

Wieso nicht X-Dream weiter machen ?
Die Planung von X-Dream war ne Katastrophe und die Zielstellung war nicht realistisch.
Es wurden dann viele Fehler gemacht und das Team löste sich dann so langsam auf.
Nachdem sich X-Dream festgefahren hat und die Entwickler so langsam aufgehört hatten, war ein Neueauflage unausweichlich.
Aus den Fehlern haben wir gelernt und so hab ich ein neues Projekt mit ganz neuen Ansätzen begonnen.

Inhalt ?
Infos zu den Inhalten von Karmarama kann man unter folgenden Link finden.
Infos
Natürlich sollte man auch in die Roadmap gucken, denn dort findet man in den einzelnen Revisionen die geschaften Aufgaben.
Aktuell(Release 0.2) läuft es auf Windows XP 32Bit-Vista 64Bit sowie Fedora/Gentoo 32-64Bit.

Was ist nun nennenswert anders, im bezug auf X-Dream?
Das wichtigste ist wohl das fest gesetzte Ziel.
Die Engine soll ein MMOG ermöglichen, welches 3D ist, Interaktion mit NPC bietet, freies bewegen auf Planeten,Handel,Kommunikation mit anderen Spielern, erstellen von eigenen Objekten im Spielsystem(Gebäude,Items) und noch ein paar grundlegenden dingen.
Wiederverwendung ist sehr wichtig, so habe ich soviel Code wie möglich aus X-Dream übernommen und setzte, wenn möglich, auf existierende Libs oder Tools. So steht Newton, OpenAL, Alut, OpenGL, Lua, MySQL, Postgresql, SQLite, OggVorbis, XLib, GDI, FireBlade, DDS Loader, Socket, FreeType, XML, Glade(Cross UI Editor) und Blender(Cross 3D Editor) auf unserer Liste.
Im Fall von Glade und Blender mussten natürlich noch anpassungen statt finden, so braucht Glade eine XML Datei mit den GUI Elementen von Karmarama und ich für Blender hab ich ein Interface geschrieben, dass z.B. Karmarama direkt im Blender zum Content erstellen genutzt werden kann.
Wir haben jeden montag ein kurzes Meeting, um dinge zu klären.
Am ersten Samstag,alle 2 monate ist Releasetermin und die Task die ned fertig sind kommen in den nächsten Milestone.
Die Milestones werden in der Roadmap festgehalten und werden neben zuständigen mit Priorität und geschätzter Zeitaufwendung betitelt.
Damit haben wir den überblick, wie weit wir sind und wo noch dinge fehlen.
Der feste Releasetermin ist für Nutzer gedacht, so kann er sicher sein, dass zu diesen Zeitpunkt eine neue Version verfügbar ist und muss nicht jeden Tag in den News gucken. Für die Planung ist dieses auch Hilfreich, da so die Entwickler einen Zeitrahmen haben und die Effektivität gesteigert wird.

Lizens ?
Karmarama ist OpenSource und Freeware.

Wo finde ich die Webseite ?
Karmarama kommt nun mit einer neuen Website http://karmarama.developer-alliance.org.
Dort findet man online doku,roadmap(mit den einzelnen Tasks für die jeweilige Release),svn browser,screenshots,Infos zur Engine und Downloadsection(daily snapshot).

Wie sieht es mit Unterstützung aus ?
Momentan sind wir 2 Personen, mein Kumpel Xenion ist für den ganzen Netzwerkpart und die Wartung des Servers sowie Technischen Problemen zuständig. Er stellt z.B. ein 5Servercluster, jeglich gewünschten Deamon und Tools wie Teamspeak,Mumble... . Er ist im wirklichen Leben Security Administrator beim Staat und kennt sich mehr als gut mit Hard und Software aus. Ich bin die andere Person und kümmer mich um Planung, programmierug der Engine, entwicklung von Unterprojekten, z.B. Blender External Engine Interface und momentan noch um dem Auftritt, nach aussen.
Ich studiere Angewandte Informatik und beschäftige mich nur mit entwicklung und projektmanagment.

Wir würden uns freuen, wenn vieleicht mal wer vorbei schnuppert und seine Hilfe anbietet.
Egal ob programmiertechnisch, Contentpflege, Dokumentation, Tester oder ähnliches.

Hier noch 1-2 bildchen:
http://karmarama.developer-alliance.org/upload/SceneGraph8a.png
Das Bild ist noch recht aktuell und zeigt das SceneGraphformat, an dem ich gerade arbeite.
Inhalte werden Share Nodes,Octrees,Visual trees und ein paar anderen Features sein.

http://karmarama.developer-alliance.org/upload/blenderinterface18.PNG
Hier sieht man eine von mir angepasste Blender Version, die um das BEEI erweitert wurde.
Beei erlaubt das laden von Plugins, um dann z.B. Karmara zur laufzeit in blender nutzen zu können.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Okt 30, 2007 01:27 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
http://karmarama.developer-alliance.org/upload/SceneGraph10.png
In diesem Screenshot sieht man eine ziemlich unscheinbare und ziemlich abstrakte version des Taj Mahals.
Das ist allerdings auch nur ein Fall, von denkst de.
Mein Exporter kann nun die in Blender gebotenden Shared Objects exportieren.
Die Szene ist eigentlich nur 1/4 davon aber durch Instanzen wird auf die orginaldaten zugegriffen und die restlichen 3/4 werden durch Instanzen mit anderer Position,Skalierung und Rotation dargestellt.
So sind die von ~700KB auf 200KB gepurzelt (durch die Instanznodes sind es dann noch ~1/3) und mein SceneGraph lädt diese natürlich genauso effektiv. Er erkennt anhand von Sharepoint Hashes, ob schon daten zu dem Node vorliegen und wenn dann nutzt er diese, sonnst werden sie bei bedarf nachgeladen(dies funktioniert auch über mehere Files hinweg). Die ganze Techdemo verbraucht unter Gentoo ~17MB Ram(szenendaten,gui und ein bischen Karmarama) ein Leeres Karmarama Framework verbraucht hierbei 15MB(~2MB für SceneGraph und GUI Daten).
Wer sich mal mit den neueren Grafikkarten beschäftigt hat, der kennt Instancing und weiß das die Handhabung meines SceneGraph geradezu perfekt dafür geeignet ist. So kann man mit einem Call dann alle Objekte des gleichen Sharepoints zeichnen. Wenn die Hardware ned verfügbar ist, dann muss es ein Software variante machen.

SceneGraph:
-chunks(jedes objekt in blender besitz ein eigenes chunk und eine ID für den Typ)
-trennung von daten und nodes(die nodes der Szene sind am anfang der Datei und werden automatisch geladen, die Daten stehen am ende und werden bei bedarf nachgeladen,streamfähig und sehr niedrige Ladezeiten)
-sharepoints(weniger speicherverbrauch im Ram und VRam,durch instancing mehr renderpower,weniger weniger last durch weniger aufrufe)
-vbo support(uvs,normals,vertice,indices)

Mein nächster Schritt wird das optimieren der Zeichenaufrufe von Sharepoints sein.
Desweiteren werde ich ein Frustumculling und ein Octree einbauen(brutforce mässig alles zu verarbeiten wäre ziemlich gegen das konzept der optimierung).

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 15, 2007 01:30 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Edit:Es gab 3 Bugs unter Windows drum hab ich das Zip neu hochgeladen.
Ich habe mal ne kleine Techdemo zu meinem aktuellen SceneGraph zusammen gepackt.
Ich bin der download.
Der Code ist für Freepascal und kann mit folgender Zeile compiliert werden.
Code:
  1. fpc -Sd -Fi../* -Fu../* karscenegraph.pas

Linke Maustaste gedrückthalten und Maus bewegen ist rotieren.
Linke und rechte Maustaste gedrückt halten und Maus bewegen ist Zoomen.
Auf der Console sieht man die aktuelle FPS.

Zur Demo selber.
Ich habe den SceneGraph in 4 Teile geteilt.
1.Kar_SceneGraph.pas Hier sind alle Grundklassen und der SG selber drin.
2.Kar_SceneGraph_FileFormat.pas Hier wird das laden von Nodes geregelt(nicht das ganze chunk).
3.Kar_SceneGraph_CustomViewer.pas Hier kann man selber seine Views festlegen.
4.Kar_SceneGraph_CustomObjects.pas Hier schreibt man seine eigenen Objekte für die Anwendung rein.

Der SceneGraph funzt wie folgt.
Man erstellt nen SG, registriert seine eigenen Objekte und lädt dann die SG Daten.
Die SG Datein bestehen aus chunks, geteilt in nodeheader und nodedata.
Die Header sind vom SG festgelegt und die Daten werden durch Kar_SceneGraph_CustomObjects.pas vom user festgelegt.
Wenn der SG aufgefordert wird, die Datei zu laden, dann werden nur die Chunkheader geladen.
Dadurch ist der Startup extrem schnell und durch teilen von Chunkdaten(instancing) kann man noch mehr Zeit und ne menge Speicher sparen.
Die Daten werden erst geladen, wenn man sie anfordert(gezeichnet werden müssen).
In meinem Beispiel habe ich das Model mit instanzen gemodelt und daher die endgültige Größe auf über 1/3 reduziert.
Ich habe in diesem Beispiel nur ein Frustum View implementiert.
Views sind dazu gedacht, um die im SG liegenden Nodes zu filtern.
So kann man z.B. eine View für dynamische Nodes, sichbaren Nodes,dynamischen und sichtbaren Nodes, für Ki interessante Node,für Physik interessante Nodes oder was auch immer erstellen. Durch das erstellen von Views kann man die verarbeitung von KI,Physik und anderen dingen wesentlich verbessern, da uninteressante Nodes erst garnicht in die verarbeitungsliste landen.
Hier mal ein Beispiel:
Wir haben einen Ingeneur, der kaputte Fahrzeuge reparieren soll.
Nun könnte man sagen, suche das nächstmögliche kaputte Auto und repariere es aber das wäre ineffizient, da man alle Nodes durchgehen müsste und dann gegenprüfen muss. Was wissen wir über das Auto ? Es ist ein dynamisches Objekt, es gibt ne Position, es besitzt ne bestimmte ID und es hat ein Schaden.
Okey also erstmal können wir ne View erstellen, die unsere Nodes in Octree teilt, denn die können wir für ein effizientes zeichnen nutzen.
Nun erstellen wie noch eine View, die als Source die Octreeview nimmt und unsere ID für Autos filtert. Nu könnte man noch eine View, mit den Status Kaput, anlegen. Nu kann man durch die octreeaufteilung effizient die umgebenden nodes, des Ingeneurs, abfragen. Wir brauchen Nodes im Octree, die weiter weg sind als unser erster treffer nicht mehr berücksichtigen, sondern nur die nodes, die im gleichen Abstand liegen.
Wenn wir nur einen Ingeneur haben ist es natürlich ned wirklich schneller, eigentlisch langsamer, da man noch die 2 sichten anlegen muss aber sobald man mehere hat wird es mit jedem schneller, da wir die sichten schon haben und nicht neu erstellen müssen. Ausserdem haben wir nur ein sehr kleinen bruchteil an Nodes die wir sonnst verarbeiten müssten.

Das meiste in der Demo ist eigentlich nur zur Presentationszwecken nötig, nur ein kleiner Teil ist wirklich für den SG.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 05, 2007 09:40 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Neue Inspiration für den SceneGraph :)

Ich hatte ursprünglich vor, ein Sichtbarkeitsbaum zu verwenden aber das wäre mit Octrees und Streambaren Welten absolut der horror geworden(Dateigröße, Speichergröße, viele Fallunterscheidungen).
Nun habe ich, so glaube ich, eine Lösung gefunden.
Die Szene wird durch ein Octree unterteilt, dadurch minimiert man die zugriffe auf Objekte(aus meheren Tests für Objekte wird 1Test pro Node) und nun kommt Fog hinzu.
Durch den Fog kann man man Objekte, die völlig im Fog sind einfach ohne Materials zeichnen, also schwarz, da der Fog eh die Farbe komplett überschreibt(viele Shaderaufrufe werden gespart). Des weiterem wird dann eine Sichtbarkeitskontrolle geben, die die Ausmaße auf dem Bildschirm beachtet und zu kleine Objekte einfach aus der Zeichenliste entfernt. Sascha hatte vorgeschlagen, die Objekte beim LOD als Billboard darzustellen, dies hat natürlich einige Vorteile, denn man spart die Pixelshader und die vielen Triangle ein. So würden nahe Objekte vollkommen normal gezeichnet werden, Objekte die weiter weg sind werden von Objekt nach Billboard gefadet und Objekte die ganz weit weg sind werden entweder ausgeblendet oder durch das Billboard sehr günstig dargestellt.

Vorteile sind klar die einfachheit des Code, da Billboards nicht wirklich ein Aufwand gegenüber laufzeit LOD bedeuten und den Grafiker das LOD Model erstellen abnimmt.
Man kann dem User somit viel mehr Grafische Freiheit lassen, hat er ne gute Graka, dann kann er die Reichweite einfach nach oben drehen und hat er ne schlechtere, dann dreht er einfach den Regler nach unten. Durch den Fog kann man die verschwindenen Objekte prima verdecken :)

Umsetzung wird bald folgen :)
Last Screenshot
Dort hab ich schonmal mit dem entfernen von Objekten, die nicht groß genug sind, rumgespielt.
Mit den oben genannten erweiterungen würde man es wesentlich performanter machen können.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Jan 28, 2008 14:42 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich habe im Rahmen meiner Projektmanagment Arbeit ein Text über mein Projekt geschrieben und möchte diesen auch hier zur verfügung stellen.
http://developer-alliance.org/index.php?site=Karmarama

Im Karmarama habe ich mitlerweile mein SceneGraph erweitert(exporter und importer um Properties und Entities erweitert), ich hab ein Octree hinzugefügt, experimentiere momentan mit Pappe(Physik), habe eine Scriptbare KI angefangen zu entwickeln und bastel auch an Chat, Authentifizierung und Sessions.

http://developer-alliance.org/index.php?site=007.png
http://developer-alliance.org/index.php?site=006.png

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 05, 2008 17:15 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Wieder ein Meilenstein geschafft, wenn auch nicht richtig ^^.
Die Winterpause, durch Weihnachten und Silvester, sowie Prüfungszeit für dieses Semster haben mir nicht viel Zeit gelassen.

Da ich Spieleentwicklung später mal beruflich machen möchte, habe ich mich entschieden nun den Quellcode auf C++ zu portieren und in C++ weiter zu programmieren. Dabei habe ich mich erstmal wieder in C++ eingearbeitet und angefangen die ersten Units und Klassen zu portieren.
Der wechsel wird einige änderungen mit sich ziehen, so werde ich von der OS API Font auf freetype2 umsteigen, von Pappe wohl auf bullet,ode oder newton und es muss ein neue Klassenanbindung für Lua her. Die GUI werde ich um Sofware renderer erweitern, dafür kommt AGG zum einsatz. Damit kann ich dann meine Tools mit meiner eigenen GUI schreiben und muss nicht auf GTK oder ähnlich zurück greifen, denn die aktuellen GUI Lösungen sind alle sammt nicht meinen Ansprüchen gerecht geworden.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mai 16, 2009 15:48 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich möchte diesen Thread mal wieder auf den aktuellen Stand bringen, da ich lange nichts gepostet habe.
Die Umstellung von Objekt Pascal auf C++ ist erledigt, der ganze Source ist überwiegend portiert oder durch refactoring überarbeitet worde.
Das Projekt benutzt nach langem hin und her nun die frei nutzbare IDE Code::Blocks und entsprechend ist der support für make und MSVS C++ rausgefallen.
Der Quellcode wurde neu strukturiert und in Ordnern, als Kategorien, zusammengefasst(z.B. graphic/..,pattern/.. oder window/..).
Alle Module sind Platformunabhängig und laufen auf Windows, Linux und auf allen Systemen, für die es einen wxWidget support gibt.
Karmarama arbeitet nun über eine Hauptkonfigurationsdatei(karmarama.hpp), in der alle verfügbaren Module definiert sind und an bzw. abgeschalten werden können.
Wird die Bibliothek compiliert, dann wird durch diese Konfigurationsdatei dann entsprechend nur der gewollte Teil verwendet.
Es gibt aktuell 2 verschiedene Grafik Context, OpenGL und OpenGL3. Die verwendung von einem Grafik Context ist recht leicht realisiert, dabei sind Basisklassen vordefiniert(z.B. TKar_Shader, TKar_Mesh und TKar_Buffer) welche dann für den zu implementierenden Grafikbibliothek dann überladen werden.
Da C++ ein sehr schwaches RTTI System verwendet(nur Klassenname), habe ich eine eigenes Reflection System geschrieben.
Aktuell habe ich Netzwerk, Threads, Timer, IO, Logger, Fenstersystem, diverse Pattern und kleinkrams fertig und GUI sowie Grafik sind im Refactorprozess.
Bei der GUI fehlen noch einige Widgets und das Grafikmodul ist das Umfangreichste Modul, da hier dinge wie Scenegraph, Model, Material, Texturen, Shader und die Grafik Context hinein gehören.
Ich habe mich entschieden, dass alte Modelformat nicht weiter zu verwenden und ein "State of the art" Format zu implementieren.
Dabei werden die Modeldaten in eine strukturierte Datei gespeichert(XML bzw. EBML) und durch ein Modelscript Datei erst beschrieben.
In der Modeldaten Datei liegen Buffer vor, welche strukturierte Daten(z.B. Vertex,Normal,Texcoord) oder einzelne Datenstreams(z.B. Indices oder Color) enthalten.
Jeder Buffer erhält einen Namen, über den das Script dann auf die Daten zugreifen kann und bestimmt was nun damit passieren soll.
Der Vorteil in diesem Verfahren ist, dass man nun kein Modelformat in dem Sinne hat, wie bisher, sondern das Format in der Scriptdatei erst geformt wird und daher in unterschiedlichen Engines verwendet werden kann. Das Script hat nun minimale Möglichkeiten die Streams zu lesen und neue zu erstellen, zusammen zu führen oder änderungen vor zu nehmen und dann Buffer für die Engine zu erstellen(bei OpenGL VBO). Desweiterem kann in der Scriptdatei auch wesentlich mehr passieren, z.B. Instancing, Scriptereignisse, Laden von weiteren Ressourcen und so weiter.
Passend zu einem Modeldatei und dem Script, gibt es noch ein Materialscript, Shader und Texturen.
Ein Material wird ebenfalls als Script implementiert und lädt benötigte Shader, Texturen und enthält die Zeichenvorschrift.
Wärend mein altes Materialsystem 3 festgelegte einsprungspunkte hatte(BeginDraw, Draw, EndDraw) benutzt das neue System ein Objekt namens Renderer und dieses bietet Callback Variablen, die zugewiesen werden können(OnZPass, OnShadowPass, OnDrawPass,...).
So wird von der Engine keine Renderpipeline mehr festgelegt, sondern das Material sagt, was zu machen ist.
Das Script hat neben Renderer noch Texture, Shader und Mesh zur verfügung und übernimmt jeden, im Modelscript, erstellten Buffer als Globale Konstante

Konzept Beispiel eines Modelscriptes
Code:
  1. #SCRIPTTYPE MODEL
  2. TModelData ModelData;
  3.  
  4. ModelData.Load("file://media/models/highpolytest.kmd");
  5. for (int i=0;i<ModelData.Faces.Count;i++)
  6.   Owner.Materials.Load("file://media/materials/"+ModelData.Faces[i].Materialname+".kmat");
  7. Owner.Mesh.GenerateIndexBuffer("Index",ModelData.GetStream("Index"));
  8. Owner.Mesh.GenerateBuffer("Vertex",ModelData.GetStream("Vertex"));
  9. Owner.Mesh.GenerateBuffer("Texcoord",ModelData.GetStream("Texcoord"));
  10. Owner.Mesh.GenerateBuffer("Normal",ModelData.GetStream("Normal"));
  11. Owner.Mesh.GenerateBuffer("Color",ModelData.GetStream("Color"));


Konzept Beispiel eines Materialscriptes
Code:
  1. #SCRIPTTYPE MATERIAL
  2. TTexture Tex0;
  3. TShader SimpleShader;
  4.  
  5. Owner.OnZPassDraw=ZDraw();
  6. Owner.OnRenderPassDraw=RenderPassDraw();
  7. Tex0.Load("file://media/textures/test.dds");
  8. SimpleShader.Load("file://media/shader/verttex.frag","file://media/shader/verttex.vert");
  9.  
  10. function ZDraw()
  11. {
  12.   SimpleShader.Bind();
  13.   SimpleShader.SetVariable("ProjectionviewMatrix",Owner.Viewport.GetProjectionviewMatrix());
  14.   SimpleShader.SetVariable("ModelviewMatrix",Owner.Viewport.GetModelviewMatrix());
  15.   Index.Bind();
  16.   SimpleShader.BindBufferAsAttribute(Vertex,"Vertex",3,float,false,0,0);
  17.   Owner.DrawInstance();
  18. }
  19.  
  20. function RenderPassDraw()
  21. {
  22.   SimpleShader.Bind();
  23.   SimpleShader.SetVariable("ProjectionviewMatrix",Owner.Viewport.GetProjectionviewMatrix());
  24.   SimpleShader.SetVariable("ModelviewMatrix",Owner.Viewport.GetModelviewMatrix());
  25.   Index.Bind();
  26.   SimpleShader.BindBufferAsAttribute(Vertex,"Vertex",3,float,false,0,0);
  27.   SimpleShader.BindBufferAsAttribute(Normal,"Normal",3,float,false,0,0);
  28.   SimpleShader.BindBufferAsAttribute(Texcoord,"Texcoord",2,float,false,0,0);
  29.   SimpleShader.BindBufferAsAttribute(Color,"Color",3,float,false,0,0);
  30.   Tex0.Bind(0);//bind on first slot
  31.   SimpleShader.SetVariable("Tex",0);
  32.   Owner.DrawInstance();
  33. }


Der neue Scenegraph wird im Prinzip wie der alte werden, nur das kleine Änderungen bezüglich Material und Modelformat bekommt.
Im letzten SG habe ich ja einen Baum mit Graphenfähigkeit implementiert(wegen instancing) und wie bei Datenbanken Views verwendet.
Eine View ist dabei eine Liste von Nodes, die durch eine fest programmierte Regel im Baum zusammen gesucht wird.
Dank Observer Pattern wird dieser aktuell gehalten und kann so die Vorteile von Bäumen(schnelles ausschlussverfahren) und den Vorteil von Listen(schnelles Iterieren) nutzen.
Eine View kann z.B. Particleemitter, ViewableModels, PhysicObject, ActiveObject oder auch FrustumCulledOctree oder ähnliches implementieren.
Wenn man seine KI entwickelt, ist das Parsen von allen Notwendigen Nodes nicht tragbar und so kann man sich gezielt Views programmieren, die dann z.B. an PhysicObject View eine neue View hängt, die notwendige Nodes aus ein schon kleinen Pool filtern. Aufgrund von Observer wird dies nicht jeden Frame neu gemacht sondern nur, wenn sich ein Node verändert und die Auswirkungen haben würde.
Der SG kann problemlos als Datenbank geladen und gespeichert werden und genau dieses Konzept wird von SG Entwicklern als "Next Gen SceneGraph" betitelt.

Ich habe Karmarama um OpenGL3.x erweitert und habe entsprechend auch geplant, mein Buffer und Mesh Klassen anzupassen, damit ich zwar zu OpenGL1-2 kompatibel bleibe aber OpenGL3 wird ab nun der Standard sein. Durch das Entfernen vieler Funktionalitäten und das reduzieren der Renderpipeline in OpenGL3 ist es nicht wirklich mit OpenGL1-2 Kompatibel.
Ein großes Problem ist hierbei GLSL, wo OpenGL1-2 fixed Renderpipeline Function hatte, muss in OpenGL3 ein Shader gebunden werden, sonnst geht garnichts. Auch die Shader selber haben neue Ansprüche, so gibt es keine Matrizen verwaltung mehr in OpenGL3 und entsprechend muss man dies selber implementieren und dem Shader die selber verwalteten ProjectionView und ModelView Matrizen übergeben. Dies ist in OpenGL1-2 auch nicht notwendig und so treten auf den unteren Ebenen der Implementierung dann starke unterschiede auf, die weiteres abstrahieren nur gelöst werden kann, was allersings einbusen an flexibilität mit sich führt. Durch Model- und Materialscript wird das Flexibilitätsproblem ausgeglichen und der Kreis schliesst sich.

Aktuell werkel ich am Exporterscript für Blender siehe Bild.

edit:
Mir ist noch ein bischen was eingefallen, was ich noch gemacht hab und vieleicht erwähnt werden sollte.
Ich habe z.B. die Roadmap aktualisiert, ein Forum eingerichtet, das SVN mal aktualisiert, eine neue Bilder Gallery geschrieben, ein neues Logo designed und für Code::Blocks ein Application Wizzard geschrieben.
Des weiterem habe ich angefangen die Struktur der Engine in einem UML Diagramm fest zu halten.
Ein VFS durch geplant und diverse Bibliotheken(squirrel, dedupe, ebml, boost, spirit,...) angeschaut, für eventuelle Implementierungen.
Da für Model und Materialscript eine Scriptsprache benötigt wird ich allerdings auch die engine nicht auf eine scriptsprache beschränken wollte, habe ich mir die mühe gemacht und eine Basisklasse für Scripte zu schreiben, welche über Reflection auf Scriptobjekte zugreifen kann. So ist Engine mäßig alles unabhänig zu verarbeiten und nur die externen Scripte müssen entsprechend geschrieben werden.
Da diese aber Content sind und von den späteren Content Designer gemacht werden, geht mich das nichts an und dieser nutzt dann die Scriptanbindung die ihm am besten liegt.
Ein Anfangsplan war erst die Model und Materialsscripte in einer pseudo scriptsprache zu exportieren und dann durch ein Tool für eine bestimmte Scriptsprache zu generieren.
Dies wäre auch nicht so schwer, da alle Elemente bekannt sind(alle Bestandteil der Engine sind nur nutzbar) aber kostet die Entwicklung einiges an Zeit.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Aug 17, 2009 23:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Lange habe ich nichts mehr dazu geschrieben aber ich werkel von zeit zu zeit an dem Projekt.
Ich habe ein kompletten rewrite vom Zaun gebrochen gehabt, da es viele kleinigkeiten gab, die mir nicht gefallen haben.
Die Basis hat sich massiv verändert, so habe ich Garbage Collection, Serialisierung, Reflection, Observer, Factory, Adapter, Plugins als Pattern eingebaut.
Ich habe aufgrund der Problematik von Serialisierung, Multilanguage und dieser lahmen 0 terminierten Zeichenkette eine eigene Stringklasse implementiert, auch Dynamische Array klasse, damit die Pointer ganz aus dem Code verschwinden. Alles was nicht über Referenzen oder direkten Objekten funktioniert wird über Smartpointer gelöst, welche an der Garbage Collection angebunden sind. Das Observersystem von vorher hab ich überarbeitet und nun ist es wesentlich kompakter und flexibler.

Der Datenzugriff nach aussen läuft über ein 3 Stufenprinzip, 1.) Protokoll wie z.B. file oder devices 2.)Codec wie z.B. DDS oder BMP 3.)Ressourcenformat welches die endgültige Datenformat definiert.
Code:
  1.       m_Texture3=m_GC->TextureManager->CreateInstance(S("test3"));//erzeugt eine Textur Resource mit Namen "test3"
  2.       TKar_SmartPointer<TImageInputStream> tis=IInputStream::Resolve(S("unicap:"),AT_IMAGESTREAM);//versucht die URI Adresse aufzulösen und prüft ob der resultierende Streampipeline vom Typ AT_IMAGESTREAM ist
  3.       if (tis)//sind die notwendige Adapter verfügbar und die URI valide dann kann diese verwendet werden
  4.       {
  5.         m_Texture3->SetSourceStream(tis);//weise den stream der Texturressource zu
  6.         m_Texture3->Load();//veranlasst das laden von Daten über den Stream und lädt diese in die ressource
  7.       }

Es ist auch möglich direkt ein Objekt von dem Ressourcenformat zu übergeben, welches im fall von Texturen TImage ist.
TImage kann dann vom Entwickler selber befüllt werden und hat allerdings den nachteil, dass die Ressource nicht neuladbar ist und damit vom Texturmanager nicht verworfen werden kann, um Speicher zu sparen oder bei Zerstörung der Ressource nicht regeneriert werden kann.

Ich habe ein Filewatcher mit eingebaut(bisher nur Linux), welcher es ermöglicht veränderungen in Ordner zu registrieren und Events aus zu lösen. Dies benötiige ich für Tools und Plugins, wenn zur Laufzeit änderungen gemacht werden können so Resourcen neu geladen werden, was man Hot-Asset nennt und in der Entwicklungsphase von Spielen und ähnlichen regen Einesatz findet.

Für den Grafikkontext habe ich noch Ressourcen eingeführt, welche einige Basisfunktionalität wie laden, entladen, neuladen, aktivieren, deaktivieren versehen. So kann der Manager dann einzelne Ressourcen, die schon lange nicht mehr aktiviert wurden zu entladen, dabei wird die Resource nicht vollständig zerstört, sondern nur die Hardwareseitigen Ressourcen. Die Informationen über die Ressource bleiben im speicher, damit man mit der neulade funktion diese wieder reaktivieren kann. Das ist für Speichermanagment nützlich und macht das verwenden von Texturen, Mesh, Shadern und so weiter Einheitlicher.

Ein Pluginsystem erlaubt das laden von externen Codes, welche dann von der Applikation entsprechend aufgelöst und drauf reagiert werden muss.
Das Plugin wird geladen und gibt Informationen was es kann aber der User muss es selber im System registrieren, indem auf das OnPluginLoaded Event vom Manager gesetzt wird und man anhand der Plugininfos dann entscheidet was passieren soll.

Ich habe eine Mathebibliothek eingebaut, welchegebrauch von der GCC Vektorextension macht und somit portablen sse/mmx code erlaubt.
Mein Benchmark hatte bei 1Millionen Matrizen Multiplikationen im knapp 400ms gebraucht und dabei auch nur 1Kern von meinen AMD X2 4200+ genutzt.
Für Vektoraddition lasse ich 10Millionen Operationen laufen, damit es noch mit 51ms messbar ist.
Addition ist langsamer als Multiplikation, da die FPU dies schneller machen kann. Das ganze hab ich mit Float getestet, da Double 2 Durchläufte auf der FPU braucht und Integer auf der ALU läuft und langsamer als Float ist, da die FPU 2 ALU für Mantisse und Exponent hat und somit in der Praxis schneller ist.

Die GC Schnittstelle ist nun so designed, dass sie für OpenGL3 ausgelegt ist.

Codetechnisch hab ich allerdings erst mitten drin angefangen von TKar_. IKar zu T und I um zu steigen und auch sind in den älteren sachen noch keine namespaces verpackt, so sieht der Code recht komisch aus ^^. Refactor aber ab und zu mal diese Teile und passe es an.

Ich habe auch schon Tests mit Mehrsprachensupport gemacht, ein bischen prototyping in Bereich Virtual Texture, Vektor GUI und Vektor Font gemacht.
So soll die GUI später durch angepasste SVG Files mit Zeicheninformationen gefüllt werden und auch die Schrift soll Vektorbasiert und nicht Pixelbasiert sein, damit das ganze Problem mit Symbolpages und so weiter entfällt. Die Technologien sind da, funktionieren und sind sogar schneller, sparsamer und wesentlich höher in der Grafikqualität.

Leider bin ich von der Zeit her stark eingeschränkt, da ich als offizieller Member von Part-Time-Scientists am Google Lunar X-Prize teil nehme und entsprechend viel Zeit und Arbeit hinnein stecke. Aber es gibt ja zum glück auch crossover Punkte, wie z.B. das Pluginsystem, welches ich auch für das PTS brauch.
Des weiteren arbeite ich ja noch an der OpenGL3 Tutorialreihe im Wiki, damit die Leute nicht ewig auf OpenGL2 rum hängen bleiben und mit OpenGL3 den Anschluss in den Stand der Technik von vor 2 Jahren finden.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 29 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.081s | 17 Queries | GZIP : On ]