[Projekt] Upvoid

[Artificial Mind]

Hallo liebe Community,

wie bereits in einigen anderen Posts ein wenig angekündigt, habe ich zusammen mit einigen Kommilitonen ein Entwicklerteam gegründet.
Nach langer und gründlicher Namenssuche sind wir nun Upvoid Studios.

Zu unserem Team:
Wir sind eine Gruppe von Informatikstudenten der RWTH Aachen.
Nachdem wir ca. ein Jahr lang im Rahmen der Game Programming AG (SPAG) ein Arcade Game entwickelt haben und damit sogar auf der Gamescom unseren Lehrstuhl vertreten haben, wollten wir mit dem nächsten Projekt etwas Größeres entwickeln.
Wir haben also ein Büro angemietet und sind seid ca. Mitte Januar aktiv am Entwickeln.

Unser erstes Projekt trägt den Codenamen "Genesis":

Screenshot aus dem alten Prototypen

Ziel ist die Entwicklung einer kompletten Game-Engine, die auf super-dynamische Welten mit veränderbarem 3D Terrain spezialisiert ist.
Wir haben das auf unserer Webseite so formuliert, dass man sich unser Vorhaben als Mischung zwischen Minecraft, Garry's Mod und Skyrim vorstellen kann.
Abgesehen von der Engine wollen wir gegen Ende des Jahres anfangen, ein größeres RPG auf Basis der Engine zu schreiben.

Wichtig ist uns ebenfalls eine gewisse Community und ein Netzwerk von Kontakten aufzubauen, da wir uns jetzt als Indies sehen und uns die Atmosphäre der Indie-Szene sehr gefällt.

Begleitend zur eigentlichen Entwicklung wollen wir auch eine Reihe von technisch orientierten Artikeln veröffentlichen. Die Themen sind vielfältig und meist etwas, mit dem wir uns selbst auseinandersetzen mussten und einfach unsere Erfahrungen teilen wollen.
Wir haben auch bereits zwei solcher Artikel fertig:
Open-Source Library Licenses: http://upvoid.com/devblog/2013/02/library-licenses/
Choosing a Scripting Language: http://upvoid.com/devblog/2013/02/choos ... -language/

Ich hoffe, dass ich Euch ein wenig neugierig machen konnte.
Bei Fragen zögert nicht, hier im Thread zu antworten oder einen Kommentar auf unserer Seite zu hinterlassen.
Wenn nichts dagegen spricht, würde ich hier auch regelmäßig kleine Updates posten.

Cheers
Mind

[Schrompf]

Ich mag das Bild immernoch sehr, in dieser runterskalierten verweichten Version sieht das Gras phantastisch aus. Der ganze restliche Text klingt ein wenig, als hättest Du ihn aus dem Englischen übersetzt :-) Ich würde gern weitere kleine Details des Projekts lesen.

[Artificial Mind]

Der ganze restliche Text klingt ein wenig, als hättest Du ihn aus dem Englischen übersetzt :-)

Da sowohl der OP des Threads als auch unser erster Post auf der Webseite als Einführung in das Projekt gedacht ist, ist es relativ schwierig die beiden Texte super verschieden zu machen ;)

Ich mag das Bild immernoch sehr, in dieser runterskalierten verweichten Version sieht das Gras phantastisch aus

Vielen Dank :) ist ja auch mittlerweile sehr gepolished und von seiner Schokoladenseite aus photographiert.

Vielleicht ist unser aktueller Stand und der nähereZeitplan von Interesse.
Wir sind momentan dabei einen neuen Prototypen von Grund auf zu schreiben. Das soll auch kein Wegwerf-Prototyp sein sondern nachher in die richtige Engine weiterentwickelt werden.
Als interne Deadline haben wir uns den 1.3. gesetzt. Dabei soll mindestens der Stand vom letzten Prototyp erreicht sein, allerdings eben bereits mit der neuen Architektur.
Bevor wir mit dem neuen Prototypen angefangen haben, haben wir erstmal eine ganze Reihe von kleinen Mini-Projekten gemacht, um verschiedene Techniken zu testen.

Zum Beispiel habe ich mich mal an Stereoscopic Rendering versucht:

Stereoscopic Rendering - Red-Cyan-Mode

Das funktioniert auch ziemlich gut. Der Rot-Cyan-Modus ist sogar derjenige, der am meisten Leistung frisst (ca. doppelt so viel), da dort beide Bilder in voller Auflösung gerendert werden müssen.
Außerdem funktioniert Side-by-Side und Top-Bottom splitting, welche auch von den meisten gängigen 3D-Fernsehern unterstützt werden.
Interessanterweise ist der Performance-Overhead nur ca. 10-20%, obwohl die gesamte Geometrie doppelt durch die Pipeline muss (Aber es bleibt halt die gleiche Anzahl an Pixeln). Meiner Erfahrung nach ist man sowieso meistens Fragment-limitiert.

[Artificial Mind]

Mono ist als Scripting-Engine eine echt angenehme Sache.

Ich hoffe damit kann man alle Modder zufriedenstellen. Laut http://www.mono-project.com/Languages sind viele große Sprachen unterstützt: C#, Java, Scala, Lua, Python, JavaScript, PHP.
Auch wenn die Doku ein vielen Stellen dürftig ist (also die Doku, wie man Mono als Scripting-Engine anbindet, nicht die .NET-Doku ;) ), so funktioniert es doch relativ gut. Auch soetwas wie .NET Strings auf "const char *" marshallen funktioniert automatisch.

Hier mal ein kleines Codebeispiel:
C#-Seite:

Code: Alles auswählen

[DllImport("__Internal", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl, EntryPoint="API_Scripting_RegisterUpdateFunction")]
public static extern void RegisterUpdateFunction(string _namespace, string _class, string _function, float _timestep, float _maxaccum);

C++-Seite:

Code: Alles auswählen

extern "C"
{
void GENESIS_API API_Scripting_RegisterUpdateFunction(const char *_namespace, const char *_class, const char *_function, float _timestep, float _maxaccum);
}

Also abgesehen davon, dass auf der C++-Seite die C-ABI genommen werden muss, geht das gut. Ist auch super schnell. Der Aufruf einer C#-Funktion aus C++ heraus kostet in unserem Benchmark 160ns. Als Vergleich: Auf dem gleichen System kostet die Auswertung von 3D PerlinNoise 300ns.

[Artificial Mind]

Unser erstes Weekly Update ist draußen: http://upvoid.com/news/2013/02/weekly-updates-1/

Ich glaube ich hatte bisher von dem Destructible Terrain Prototypen ja nur Bilder gezeigt, richtig? Wir laden gerade ein kurzes Video davon hoch und bereiten einen kleinen Blogpost vor, sodass man den Prototypen mal "in Echt" sieht ;)

[Artificial Mind]

Das versprochene Video ist da:
[youtube]XOByaP8ZwHk[/youtube]

Hier der Link zum Post: Destructible Terrain Prototype

[CodingCat]

Immer wieder beeindruckend, was du über die letzten Jahre hinweg alles mal eben testweise implementiert hast. Wenn jetzt noch das Verstecken des Nachladens klappt, kann eigentlich nicht mehr viel schief gehen. ;)

[Artificial Mind]

Vielen Dank :)
Ich hab in den letzten Wochen immer mal wieder das LOD-System angefasst, aber das Scheduling ist in meinen Augen noch nicht optimal. Hoffentlich komme ich in den nächsten Wochen auf eine befriedigende Lösung. In diesem Post hier ( http://upvoid.com/news/2013/02/weekly-updates-1/ ) sind zwei WIP-Screenshots vom aktuellen Stand (des LOD-Systems. Der dritte Screenshot ist von der Physik-Integration). Das Terrain ist dabei im Nahbereich auf (0.5m)³ aufgelöst, während man durch LOD eine Sichtweite von ca. 5-10km hat. Bei ca. ner halben Million Dreiecke. Ich hab mir auch schon auf meine Issue-Liste (wir nutzen ein Redmine) geschrieben, dass ich innerhalb der Chunks ohne Probleme Mesh Decimation ausführen kann, was auf geraden Flächen nochmal viel bringen sollte.
Mein Ziel ist, dass man im Endeffekt vom Laden nicht mehr sieht, als dass das Terrain glatter wird. Im Optimalfall ja nichtmal das (wenn alle Dreiecke immer auf 10-20 Fragmente kommen, sollte man Übergänge kaum noch sehen).

[Jonathan]

Ja, sieht ziemlich cool aus. Eine Sache interessiert mich allerdings gerade besonders: Ich bin derzeit auch dabei, Gras in mein Spiel einzubauen und finde, dass euer Gras schon ziemlich hübsch und vor allen Dingen dicht ist. Wie habt ihr das im groben umgesetzt? Meine Idee ist derzeit einzelne Büscheln mit Instancing zu zeichnen und evtl. im Vertex-Shader zu animieren. Für das Culling benutze ich dann größere Grasgebiete (Größenordnung 5x5 Meter oder so) so dass ich einen guten Kompromiss aus "möglichst viel auf einmal Rendern" und "Nicht alles Rendern müssen" habe. Zusätzlich dachte ich noch daran, mehrere dieser Grastiles übereinander zu legen, so dass in Kameranähe das Gras sehr dicht ist, etwas weiter weg dann weniger dicht wird.

[Artificial Mind]

Ich bin noch nicht vollends zufrieden mit unserem Gras. Es ist mMn sehr gut für mittlere LOD-Stufen geeignet, also die Bereiche, wo man Silhouetten braucht und Bewegung sieht, aber man noch nicht super nah dran ist.

Wir haben das mit einem Geometry Shader umgesetzt. (Obwohl ich das noch nicht gegen Instancing getestet habe, denke ich, dass man die Technik auch mit Instancing machen könnte und das günstiger wäre)
Es wird einfach nochmal die komplette Geometrie vom Terrain (bzw. alles was nah genug dran ist) durch einen Geometry Shader geschoben. Dieser nimmt dann die ganzen Dreiecke und macht daraus bis zu drei Quads (die "Büschel"). Im Nahbereich sind es drei, diese faden aber nach hinten zu einem Quad und schließlich ins Leere aus. Die Positionierung der Quads muss (und sollte) nicht entlang der Dreieckskanten sein. In meiner Version habe ich von jedem Eckpunkt des Dreiecks aus eine Kante zu einem zufälligen (aber konsistenten) Punkt auf der gegenüberliegenden Kante gezogen und diese Kante dann entlang der Dreiecksnormalen extrudiert um den Quad zu bilden. Dann halt noch ein wenig Wind-Animation über die obere Quad-Kante.
Achso, wichtig hierbei: Die Grastextur ist ja teilweise transparent. Aber man kann das Gras schlecht sortieren. Ich habe also erstmal mit strikten Alpha-Test nur alles das gezeichnet, was voll Opaque vom Gras ist und damit auch den z-Buffer geupdatet. Danach habe ich normales Alpha-Blending aktiviert und das z-Write deaktiviert. Wenn man alles Gras was man zeichnet ein wenig vorsortieren kann (z. B. auf Chunk-Basis), dann sieht man kaum noch Artefakte vom Blending. Selbst ohne ist es nur selten richtig sichtbar.

[Artificial Mind]

Ja, sieht ziemlich cool aus. Eine Sache interessiert mich allerdings gerade besonders: Ich bin derzeit auch dabei, Gras in mein Spiel einzubauen und finde, dass euer Gras schon ziemlich hübsch und vor allen Dingen dicht ist. Wie habt ihr das im groben umgesetzt? Meine Idee ist derzeit einzelne Büscheln mit Instancing zu zeichnen und evtl. im Vertex-Shader zu animieren. Für das Culling benutze ich dann größere Grasgebiete (Größenordnung 5x5 Meter oder so) so dass ich einen guten Kompromiss aus "möglichst viel auf einmal Rendern" und "Nicht alles Rendern müssen" habe. Zusätzlich dachte ich noch daran, mehrere dieser Grastiles übereinander zu legen, so dass in Kameranähe das Gras sehr dicht ist, etwas weiter weg dann weniger dicht wird.

Ich habe einen Artikel über das Gras in unserem Devblog geschrieben: http://upvoid.com/devblog/2013/02/prototype-grass/
Vielleicht kann dir das ja etwas weiterhelfen.

[CodingCat]

Sehr schön und überraschend, auf wie wenig Distanz es schon nicht mehr auffällt, dass die Quads alle auf Dreieckskanten liegen.

[Artificial Mind]

So, es gibt erfreuliche Neuigkeiten: Wir haben langsam den Stand des alten Prototypen überholt! (Weekly Update #3)

Von der technischen Seite her ist das LOD-System mittlerweile so weit, dass die Übergänge keine Löcher mehr haben. Die Normalen werden noch nicht ganz korrekt berechnet, aber wenigstens hat man jetzt eine sehr hohe Sichtweite.
Im Screenshot oben sind die Berge im Hintergrund ca. 5km entfernt während der Nahbereich eine Volumenauflösung von (0.5m)^3 hat.
Hier sind ein paar Test-Screenshots von einem LOD-Übergang wenn als Featurepunkte vom Dual Contouring immer der Voxelmittelpunkt genommen wird (Blocky/Minecraft-Style):

Blocky mit LOD

Blocky mit LOD (Wireframe)

Blocky mit LOD (Farbige Chunks)

[Artificial Mind]

Hab mal aus Spaß das Wasser wieder eingebaut: (noch nicht simuliert, einfach nur als "translucent terrain material")

[Thoran]

Ich habe einen Artikel über das Gras in unserem Devblog geschrieben: http://upvoid.com/devblog/2013/02/prototype-grass/
Vielleicht kann dir das ja etwas weiterhelfen.

Sehr schöner Artikel, danke. Das Gras hat mich auch interessiert. Die Frage die offen bleibt ist, wie das Grass auf dem Terrain verteilt wird, also wie du festlegst auf welchen Stellen Grass wächst und wo nicht? Über die Terrainsteigung? Über Vertexfarben als Trigger?

[Artificial Mind]

Also unser Terrain hat verschiedene Materialien und nur auf den "Gras"-Materialien wird der Shader ausgeführt. Mit der Steigung wird das Gras ausgeblendet aber es gibt noch eine Noise-Textur, die angibt, wo sich Gras befinden soll. Ist dann aber ein rein optischer Effekt. Wir werden wohl über kurz oder lang auf Vertex-Attribute umsteigen, damit man das Gras auch verändern kann.

[Artificial Mind]

So wir haben ein neues Video!
[youtube]YUSMX53OL9U[/youtube]

Hier nochmal ein paar statische Versionen:

Wir haben den kompletten Code vom vorherigen Prototypen neu geschrieben.
Unsere aktuelle Architektur ist stark multi-threaded (bereits über 30 unabhängige logische Threads + beliebig viele für Terrain, natürlich auf die verfügbaren Kerne gescheduled).
Ich kann euch sagen, es macht kein Spaß seine Architektur auf so viel Parallelität auszulegen, aber es ist den Aufwand in unserem Fall wert. Netter Nebeneffekt: man denkt über viele Entscheidungen zehnmal nach und hackt nicht einfach in seiner Engine rum ;)

Die God-Rays bzw. das Volumetric Light Scattering sind übrigens hiervon inspiriert: CPU Gems 3, Chapter 13.
Empfehlung: Berechnung nur auf halber Auflösung, dann kann man viermal so viele Samples machen wie auf voller ;)

[RazorX]

Sehr schöne Bilder, wie immer! Auf dem dritten Bild sind die rechten Strahlen sehr stark gefächert, ist das gemäß der Standardimplementierung oder ein spezielles Feature? Sieht fast so aus, als würde das das Lens-Flare sein!?

[Artificial Mind]

Achso ne, die Gefächerten, die man dort sieht, sind ein super schlechter Starburst-GIMP-Versuch. Steht auch schon im TODO vom Polishing.
Trotzdem können auch die Godrays so ausfächern, z. B. bei Graskanten.

[Jonathan]

Sieht sehr cool aus. Allerdings hätte ich es schön gefunden, wenn das Video kommentiert gewesen wäre. Am besten natürlich mit Sprache, aber ein paar Texteinblendungen, welchen Effekt man gerade sieht, wäre auch schon gut gewesen. So hat man einfach nur 5 Minuten durch die Luft fliegen und erkennt vielleicht gar nicht, was man da so alles sieht.

[Schrompf]

Technologisch beeindruckend. Wie verteilt, synct und scheduled ihr die Tasks?

Ich mag die God Rays nicht. Und der Wassershader könnte einen simplen Tiefen-Nebel brauchen.

[Artificial Mind]

@Jonathan:
Ja, haben wir auch echt überlegt, aber es hat so schon 5h gedauert, das Video zu produzieren. Wahrscheinlich müssen wir uns einfach eingewöhnen und dann kriegen wir auch eine kommentierte Production zeiteffizient hin.

@Schrompf:
Was stört dich an den God Rays? Einfach generelle persönliche Meinung oder haben wir zu dick aufgetragen oder ist einfach ein Screenspace-Ansatz grundsätzlich zu schlecht?
Wenns persönliche Meinung ist: Ok, ist halt Geschmackssache. Wir haben auch jemanden im Team der grundsätzlich keine Lens Flares mag und die egal wo überflüssig findet. Kann man ausschalten und dann ist's gut ;)
Das Wasser ist meiner Meinung nach auch noch zu unruhig, aber Tiefen-Dreck ist auch ne gute Anmerkung.

Zum Schedulen:
Ein Task hat im wesentlichen drei Einstellungen: TimingMode, CpuLoad und Responiveness.

• TimingMode: As fast as possible (AFAP ;) ) oder FixedTimestep
  - gibt an, wie oft der Task asugeführt werden soll
• CpuLoad: Light, Heavy oder Unpredictable
  - gibt die zu erwartene Last an (z. B. Light für Inputbehandlung, Heavy für die Terrain Generierung und Unpredictable für Netzwerk-Empfang)
• Responsiveness: Immediate, Continuous oder Don't Care
  - gibt an, wie man Rückmeldung vom Thread haben will/muss (z. B. Input ist Immediate, Physik ist Continuous und Terrain Generierung ist Don't Care)

Dann gibt es noch ein besonderes Flag bei Tasks, wenn sie im UI Thread laufen müssen (z. B: Rendering oder auch Geometry-Upload)
Mit dieser Kategorisierung von Tasks können wir nun für alle non-UI Tasks echte Threads erstellen:

1. Jeder Immediate-Task bekommt einen eigenen High-Prio Thread (z. B: Input, Netzwerk)
2. Jeder Continuous-Task bekommt einen eigenen Normal-Prio Thread (z. B: Physik, Weltlogik, Skriptlogik)
3. Anzahl der Kerne minus Anzahl Continuous-Threads minus 1 (UI) ergibt die Anzahl der "Heavy-Threads" (mindestens jedoch einer). Alle noch nicht zugewiesenen Tasks kommen in einen Task-Pool, aus denen sich jeder Heavy-Thread fröhlich bedient und ausführt.

Die Continuous-Tasks haben meistens einen Fixed Timestep und wissen deswegen wann sie das nächste Mal ausgeführt werden müssen, sodass der Thread für die Zwischenzeit sleepen kann.

Die Aufteilung der Tasks auf Threads hat noch Optimierungspotential:
Man kann Continuous-Tasks auf einen Thread legen, wenn beide ihr Scheduling einhalten können, auch wenn sie sequentiell ausgeführt werden.
Man könnte alle Light-Tasks in einen Pool werfen und sie bei allen anderen Threads "piggybacken".
Aber generell hat die bisherige Aufteilung schon dafür gesorgt, dass es auch auf schwachen Notebooks wieder gut läuft.

[Schrompf]

Danke für die Ausführungen, ich finde das sehr interessant! Eine letzte Frage dazu aber: nutzt ihr TBB, die neuen C++11-Features oder was eigenes? Ihr werdet ja neben Tasks zumindest auch Mutexe, Atomics und Lockless Queues brauchen.

Was stört dich an den God Rays? Einfach generelle persönliche Meinung oder haben wir zu dick aufgetragen oder ist einfach ein Screenspace-Ansatz grundsätzlich zu schlecht?

Zum Einen ist Screenspace dafür meiner Meinung nach ungeeignet. Es ist ein sehr präsenter Effekt, der dann aber mit hoher Frequenz erscheint und verschwindet, weil sich ja bei jeder Kamerabewegung die Ausgangslange ändert. Unschön. Und ihr habt ja mit dem Voxel-Feld tatsächlich die Daten da, um echte Volumen-Lichtstreuung zu berechnen. Aber ich vermute, das hat Zeit bis viel später.

Und zum Anderen ist der Effekt sehr scharf abgegrenzt. God Rays sind für mich eher eine subtile Sache, mit beleuchteten Partikeln, die langsam zwischen Hell und Dunkel hin- und herschweben. Etwa so hier (der Effekt wurde bereits per Nachbearbeitung verstärkt, glaube ich) Ich gebe aber zu, dass das echt schwer zu erreichen ist - gleichzeitig eine gute Auflösung zu bewahren und einen weichen Look hinzubekommen.

Das Wasser ist meiner Meinung nach auch noch zu unruhig, aber Tiefen-Dreck ist auch ne gute Anmerkung.

Das ist im Orginal ein Deferred Renderer, oder? In dem Fall reicht ja im Wasser-Shader ein schlichtes

Code: Alles auswählen

output.a = 1.0f - exp( -TiefeDesFragments / SuchDirWasAus);

Hm... aber nur, wenn dann in der Farbe auch was Passendes drin steht. Ok, ist wohl doch nicht so einfach.

[mnemonix]

Wow, saubere Arbeit. Gefällt mir! Bin immer wieder überrascht, wie schnell du neue Sachen umsetzt (ist fast wie Magie). Hast ein gutes Problem-Lösung-Denken und programmierst dazu noch schnell. ;D

Könntest du noch kurz was über die verwendeten Bibliotheken und APIs sagen, die ihr in eurem Projekt nutzt (Grafik: Direct3D/OpenGL (EXT-Loader), Mathe, Physik, Audio, Laden von Bildern, Netzwerk, Input, GUI, ...)?

Was noch cool wäre, wenn du eine kleine Wasser-Simulation drin hättest (evtl. über kleine grobe Wasserkügelchen (Metaballs)). ;D Sieht irgendwie komisch aus, wenn das Wasser wie durch Magie festgehalten wird und nicht abfließt, aber sonst alles recht realistisch aussieht. Eventuell ist das jedoch nicht umsetzbar, weil schon etliche andere Sachen im Hintergrund laufen.

[Artificial Mind]

@Schrompf:
Vielen Dank für die Erläuterung.
Also wir sind etwas in den C++11-Features eingeschränkt, da wir momentan noch VS 2010 unterstützen (müssen) und dort vieles noch nicht geht.
Wir nutzen Qt für GUI, Threads, Filesystem und Unicode-Strings.

Ja, das mit den Screenspace Godrays ist echt ein Problem. z. B. scheinen die Berge auch in den Vordergrund, was eigentlich Quatsch ist. Durch das Volumen könnte wir das natürlich ausrechnen, aber halt nur auf der Volumen-Auflösung und das ändert sich ja auch mit dynamischen Objekten und unterschiedlichem Sonnenstand. Ich kann mir auch gut vorstellen das von Meta-Daten abhängig zu machen (z. B. Höhlen-Ausgänge).
Mal gucken wie gut man das hinbekommt, ich find den Screenspace in den richtigen Situation allerdings schon ziemlich ansprechend ;)

Zum Wasser: Wir haben keinen Deferred Renderer.
Wir nutzen einen hippen Z-Prepass, dann einen Opaque und dann einen Transparent+Distortion+Glow (quasi die "transluzenten" Passes).
Wasser besteht aus Transparent + Distortion und hat Zugriff auf die Opaque Depth.
Wir müssen das btw. aus Sortierungsgründen mit ins Transparente nehmen, damit das funktioniert.

@mnemonix:
Also wir nutzen folgende APIs:

• Grafik: OpenGL mit Glew
• Physik: Bullet
• Mathe: GLM (weil es wie GLSL-Mathe ist)
• Qt für Filesystem, Gui, Threads, Unicode-Strings, Netzwerk
• Audio: OpenAL-Soft, ogg
• Cooleres Mathe: Eigen (für SVD und so)
• Debug: AntTweakBar
• Testing: Googletest
• Assets: Assimp ;)

Das Wasser soll später über mehrere Stufen simuliert werden. Weit entfernt über Heightmaps, näher dran Voxel + Partikel.

[Schrompf]

Nochmal Danke für die Antwort und die Auflistung! Keine weiteren Fragen, Eurer Ehren :-)

[LONy]

Sieht wieder sehr cool aus, danke für die ständig neuen Infos :) Als E-Techniker steig ich da leider nimmer ganz durch, hatte mit OpenGL noch nichts zu tun :lol:

Was euer Video noch einen Tick besser machen würde, wäre wenn die Kamerabewegung nicht so abgehackt wäre sondern wenn die Bewegungen weicher wären... Aber es ist ja kein Verkaufsvideo sondern nur ein Zwischenstand was eure engine kann.... Daumen hoch! :D

[Jeason]

Soweit ich das aus eurem Blog rauslesen konnte plant ihr Mono für Scripting einzusetzen.
Habt ihr schon eine konkrete Vorstellung wie ihr eure Klassen an Mono anbinden wollt?
Zum Beispiel: Schwarze Magie oder "C-API" Wrapper selber schreiben?

[Artificial Mind]

Soweit ich das aus eurem Blog rauslesen konnte plant ihr Mono für Scripting einzusetzen.
Habt ihr schon eine konkrete Vorstellung wie ihr eure Klassen an Mono anbinden wollt?
Zum Beispiel: Schwarze Magie oder "C-API" Wrapper selber schreiben?

Also das funktioniert bereits. Der einfache Kugel-Character-Controller, den man im Video erahnen kann, ist aus einem C#-Mod heraus erstellt.
Wir nutzen die "Embedding Mono"-API, um aus C++ heraus .NET Code auszuführen.
Von C#-Seite aus kann man einfach DllImports von der Dll "__Internal" machen und kriegt damit Funktionen, die aus unserer C++-Binary exportiert werden.
Also ja, wir haben quasi ne "C-API". Man kann allerdings structs direkt in Mono nutzen (wird per value oder per reference genutzt) und damit können wir z. B. glm::vec2 und glm::vec3 ohne Probleme übergeben. Strings werden gemarshallt und so weiter, eigentlich relativ komfortabel. Ein Problem sind noch unterschiedliche Calling Conventions unter Windows und Linux, aber auch das lässt sich lösen.

Btw: gestern hat ein Mitstreiter eine PHP.NET-dll erstellt und die geladen, geht auch wunderbar.

[mnemonix]

@mnemonix:
Also wir nutzen folgende APIs:

• Grafik: OpenGL mit Glew
• Physik: Bullet
• Mathe: GLM (weil es wie GLSL-Mathe ist)
• Qt für Filesystem, Gui, Threads, Unicode-Strings, Netzwerk
• Audio: OpenAL-Soft, ogg
• Cooleres Mathe: Eigen (für SVD und so)
• Debug: AntTweakBar
• Testing: Googletest
• Assets: Assimp ;)

Das Wasser soll später über mehrere Stufen simuliert werden. Weit entfernt über Heightmaps, näher dran Voxel + Partikel.

Cool, danke. Eins hab ich vorhin noch vergessen zu fragen. Welche Schattentechnik habt ihr implementiert?