[Projekt] Upvoid

[Artificial Mind]

Kein Problem ;)
Die Schattentechnik ist Exponential Shadow Maps (ESM). Später wird das noch um mehrere Kaskaden erweitert werden müssen, momentan ist das eine 2048² große Shadowmap.

[Artificial Mind]

Wir machen viel Fortschritt!
Aktuell ist Weekly Update #6.

Hier nochmal ein paar schöne Screenies:

Edit: Hier nochmal das neue Video:
[youtube]ZZAd5avw9MA[/youtube]

[Schrompf]

Das Partikelsystem sieht gut aus! Partikel zu beleuchten ist mutig, aber wenn man die Partikel dicht genug generiert und auf die Fillrate scheißt, sieht das richtig gut aus. Und endlich gibt es Bäume! <3 Die sehen allerdings aus wie generiert - benutzt ihr da irgendeine Lib für?

[Artificial Mind]

Die opaquen Partikel zu beleuchten ist gar nicht wild, die Transparenten sollte man allerdings nur beleuchten wenn man weiter weg ist. Fullscreen durch den ganzen beleuchteten Rauch gucken ist momentan tatsächlich nicht zu empfehlen :D Ich habe auch endlich rausgefunden wie man gute Rauchpartikelsysteme günstig macht: Große, wenige Partikel und fertige Rauchtextur (z. B. soetwas: http://www.cgtextures.com/textures.php? ... 044&page=6 )

Momentan ist das eigentlich nur ein Baum(astwerk), das einer von uns kurzerhand in Blender zusammengeklickt hat. Im Video sieht man kurz den Trick mit den Quads für die Blätter. Ich kann mir sehr gut vorstellen dass man nachher das grobe Astwerk prozedural generiert und dann die Blätter mit dieser Technik rendert. Jedenfalls für "mid-range". "far-range" würde ich zu Billboards übergehen, "super-far-range" schwebt mir die Lösung von diesem Paper vor: http://www.gamedev.net/page/community/i ... rests-r187 (allerdings auch nur die Bäume im Hintergrund. Die im Vordergrund sind quasi mit Lightmaps gerendert und das frisst zu viel Speicher und Performance und unterstützt nur wenig Variation). Im Nahbereich möchte ich dann zu soetwas übergehen: http://simonschreibt.blogspot.de/2013/0 ... trees.html oder wenn es die Grafikkarte zulässt noch irgendeine extremere Tesselation-Lösung. Aber das ist alles noch etwas Zukunftsmusik ;)

[mnemonix]

Wie immer wieder sehr beeindruckende Bilder, Artificial. Gefällt mir alles sehr gut. Bis auf die Unterwasser Bilder, die im Video aber etwas besser aussehen durch die Kompression. ^^ Finde dieses krasse Rauschen nicht so schön. Fände Tiefennebel + ne Art DoF schöner (+ evtl. noch ne Caustics Textur über den Boden scrollen lassen). :D

Edit: Und die scharfen Schnittkanten, wenn du mit ner Kugel ins Volumen reinschneidest, könnte man vielleicht noch glätten, wenn das geht.

[Artificial Mind]

In bewegt sieht Unterwasser eigentlich gar nicht schlecht aus, imho (also in Originalqualität mit dem Rauschen). Aber zugegeben, im Bild kommt das sehr krass rüber, während man im Video kaum noch was erkennt. Bevor wir nicht eine Binary rausgeben kann ich wahrscheinlich auch nicht zeigen wie es in bewegt aussieht.

Was mir richtig gut am aktuellen "Rausch"-Shader gefällt ist, dass er nur zwei Texture-Lookups hat: Einen in eine Random-Map (lässt sich vll noch durch "berechnetes Random" ersetzen) und nur einen in die Farbtextur. Alles was in Richtung DoF oder Blur geht hat gleich wieder super viele Lookups.

Caustics fehlen auf alle Fälle noch, hab ich ganz vergessen. Tiefennebel gibt es schon ins bläuliche, aber da kann man auch noch viel Fine-Tuning betreiben. Mir fehlen auch noch Blubberblasenpartikel ;)

EDIT: Zu den Schnittkanten: das ist ein sehr wichtiges Feature und war auch nicht ganz einfach zu implementieren. Bei den meisten Marching-Cubes-Voxel-basierten Engines kommt halt nur "Organisches" raus, keine harten Kanten. Wir können halt jetzt beides. Jedes Material hat einen Winkel, ab dem die Normale gesmooth'd wird. Es wird nachher noch andere Terrain-Modifikationen als "distance(sphereCenter, position) - radius" geben ;)

[Niki]

Klasse! Wirklich klasse! Da kommt mir doch ein wenig das Sabbern :)

Rein aus Interesse: Wie handhabst du den Übergang von Überwasser nach Unterwasser? Ich hab's noch nie ausprobiert, aber mich schon oft gefragt wie man das am besten bewerkstelligen kann. Ist das einfach nur "Wenn Kamera unter Ebene dann wird alles blauer" oder steck da mehr dahinter? Berücksichtigst Du eventuell sogar Wellen?

[Artificial Mind]

Wasser ist bei uns keine Ebene sondern ein eigenes Material im Terrain. Insbesondere kann man momentan Wasser-Kugeln erstellen und auch durch das Wasser hindurch graben und baut es damit ab ;)

Meine momentane Lösung zum Übergang ist auch eher eine Notlösung: Ich gucke für die aktuelle Kameraposition die 8 benachbarten Materialwerte nach und mache dann lineare Interpolation wenn Wasser dabei ist. Damit sind die meisten Übergänge ok, aber da die Dreiecke sich nicht ganz an die Volumendaten halten kann es halt auch etwas daneben sein. Mal gucken ob man das noch schöner machen muss, erstmal tut es seinen Dienst.
Die momentanen Wellen sind btw. nur ein Fragmentshader-Effekt basierend auf zwei gegeneinander verschobenen Texturen.

[Niki]

Material im Terrain... das gibt mir vielleicht ein paar Ideen sobald ich zur Wassergenerierung in meinem Projekt komme.

Ich habe mir das bei Oblivion mal ganz genau angeschaut, denn da kann man ja tauchen. Vielleicht war ich einfach nur zu ungeschickt, aber ich habe es nicht geschafft das sich die Wasserlinie in der Mitte des Bildschirms befindet. Es sah beinahe so aus als würde die Wasserlinie immer zum oberen oder unteren Frustum-Rand hin-snappen. Vielleicht ist ja jemand anders so geschickt und kann mir das Gegenteil beweisen :D

[Jonathan]

Das selbe ist mir schon bei diversen Spielen aufgefallen. Heutzutage scheint es einfach nicht mehr möglich zu sein, dass die Kamera nur halb im Wasser ist. Früher gab es noch Spiele, da wurde der Unterwassernebel Bildschirmfüllen aktiviert, wenn man unterhalb der Wasseroberfläche war - mit dem netten Nebeneffekt, dass man, solange man nur ein ganz bisschen im Wasser war, dort noch keinen Nebel hatte und ganz normal weit gucken konnte.

[Artificial Mind]

Hier ist unser neustes Video:
[youtube]gvpPdpgDrkY[/youtube]

Dies ist ein Mod, der nahezu komplett in C# geschrieben ist und die Mod-API unserer Engine nutzt.

Andere (technische) News:

• Dank AsmJit werden die Funktionen, aus denen das Terrain generiert wird, per eigenem JIT-compiling in natives SSE übersetzt und ausgeführt.
• Wir haben Mesh Voxelization eingebaut, sodass man nun auch (zusätzlich zu impliziten Funktionen) z. B. in Blender eine Burg erstellen kann und diese auch einfach in das Terrain integrieren kann. Wichtig dabei ist eigentlich nur, dass nicht mehr als ein Feature-Vertex pro Voxel (momentan 0.5m x 0.5m x 0.5m) da ist, dann können die meisten Meshes nahezu perfekt rekonstruiert werden.
• Wir haben mit dem Path Finding angefangen und das ist ein besonderer Spaß auf so dynamischem Terrain. Momentane Idee: grobes Pathfinding auf Chunk-Basis für Waypoints und dann die Terraingeometrie als Nav-Mesh nehmen und lokal per D* Pathfinding zu den nächsten Waypoints machen. Mal gucken wie performant das alles wird.
• Ich schreibe gerade an einem Tool, dass uns den Großteil der C# Api (und dem entsprechenden C++ Wrapper) direkt aus unserem C++ Code erzeugt. Dazu werden Annotationen in Kommentaren eingeführt (z. B. "//!Api ApiObject" für eine C++ Klasse, die in C# abgebildet werden soll (inklusive Polymorphie), oder "//!Api Getter" für einen C++-Member, der in C# als Property mit public get modelliert werden soll)

Ein kleines Bild aus dem Mod:

[Artificial Mind]

So, ich habe jetzt die Apigenerierung größtenteils fertig (bis auf Callback-Delegates, die müssen noch manuell geschrieben werden).

Hier mal ein kleines Beispiel wie das aussieht (Ich hab einige normalen Kommentare rausgeschnitten, um das Beispiel etwas kleiner zu machen. Normalerweise werden alle C++-Kommentare auch in die API kopiert)

World.hh (normaler C++ Code von uns)

Code: Alles auswählen

namespace model
{

//!Api ApiObject
class World
{
private:
    //!Api Getter
    const std::string mName;

    //!Api Getter
    WorldMetadata *mMetadata;

    //!Api Getter
    physics::PhysicsWorld *mPhysics;

public:
    
    //!Api Func
    void attachCamera(CameraBase *_camera);

    [...]
};
}

WorldApi.cc (autogenerierte C-style Wrapper Code, hat noch eine ähnliche .hh)

Code: Alles auswählen

#include "WorldApi.hh"

// Auto-generated includes:
#include <Model/World.hh>

// Auto-generated usings:
using namespace model;
using namespace physics;

extern "C"
{

// Auto-generated functions:
GENESIS_API(void) API_Model_World_Function_AttachCamera_CameraBase(model::World *_this, model::CameraBase * _camera)
{
    _this->attachCamera(_camera);
}

/**
 * Auto-generated Property Getter of World:
 * World metadata
 **/
GENESIS_API(model::WorldMetadata *) API_Model_World_Property_Metadata_Getter(model::World *_this)
{
    return _this->getMetadata();
}

/**
 * Auto-generated Property Getter of World:
 * world name
 **/
GENESIS_API(const char *) API_Model_World_Property_Name_Getter(model::World *_this)
{
    return (_this->getName()).c_str();
}

/**
 * Auto-generated Property Getter of World:
 * ref to the world physics
 **/
GENESIS_API(physics::PhysicsWorld *) API_Model_World_Property_Physics_Getter(model::World *_this)
{
    return _this->getPhysics();
}

}

World.cs (autogenerierter C# API Code)

Code: Alles auswählen

// AUTO-GENERATED FILE

using Engine.Model;
using Engine.Physics;
using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;

namespace Engine
{
    namespace Model
    {
        /// <summary>
        /// One World is a model part with a global coordinate system
        ///
        /// Creation and Deletion is handled by the Universe
        /// </summary>
        public partial class World : ApiObject
        {

            #region Properties

            /// <summary>
            /// world name
            /// </summary>
            public string Name
            {
                get
                {
                    return Marshal.PtrToStringAnsi(apiPropertyGetterName(UnmanagedObject));
                }
            }

            /// <summary>
            /// World metadata
            /// </summary>
            public WorldMetadata Metadata
            {
                get
                {
                    return ObjectResolver<WorldMetadata>.GetObject(apiPropertyGetterMetadata(UnmanagedObject), ptr => new WorldMetadata(ptr));
                }
            }

            /// <summary>
            /// ref to the world physics
            /// </summary>
            public PhysicsWorld Physics
            {
                get
                {
                    return ObjectResolver<PhysicsWorld>.GetObject(apiPropertyGetterPhysics(UnmanagedObject), ptr => new PhysicsWorld(ptr));
                }
            }

            #endregion

            #region Constructors

            /// <summary>
            /// internal c'tor of ApiObject World
            /// </summary>
            internal World(IntPtr _unmanagedPtr) :
                base(_unmanagedPtr, false)
            {
            }

            #endregion

            #region Functions

            public void AttachCamera(CameraBase _camera)
            {
                apiFunctionAttachCameraCameraBase(UnmanagedObject, (_camera == null ? ApiObject.InvalidHandle : _camera.UnmanagedObject));
            }

            #endregion

            #region API Dll Imports

            [DllImport("__Internal", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl, EntryPoint="API_Model_World_Function_AttachCamera_CameraBase")]
            private static extern void apiFunctionAttachCameraCameraBase(HandleRef _unmanagedWorld, HandleRef _camera);

            [DllImport("__Internal", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl, EntryPoint="API_Model_World_Property_Metadata_Getter")]
            private static extern IntPtr apiPropertyGetterMetadata(HandleRef _unmanagedWorld);

            [DllImport("__Internal", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl, EntryPoint="API_Model_World_Property_Physics_Getter")]
            private static extern IntPtr apiPropertyGetterPhysics(HandleRef _unmanagedWorld);

            [DllImport("__Internal", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl, EntryPoint="API_Model_World_Property_Name_Getter")]
            private static extern IntPtr apiPropertyGetterName(HandleRef _unmanagedWorld);

            #endregion
        } // class World
    } // namespace Model
} // namespace Engine

An dem Beispiel sieht man schon, dass kompliziertes und vielschichtiges Marshalling mit in Betracht gezogen werden muss (z.B. bei std::string, aber auch bei Pointern generell). Vieles davon wird bereits richtig umgesetzt, aber es ist echt mühselig. Die C# Klassen werden alle als partial deklariert, damit wird ganz einfach manuelle API-Erweiterungen einbauen können, ohne dass die Dateien in Konflikt geraten.

[CodingCat]

Und die C++-API bekommt auch Getter generiert? :D
Immer wieder erschreckend, wie eklig solche C-APIs ohne Overloading werden. Und Dinge wie ObjectResolver machen mir .NET noch madiger als es eh schon ist. ;) Unabhängig davon, wieder fantastisch, in welcher Vielfalt ihr in diesem Projekt tätig seid. Wenn ihr das rechtzeitig für was anderes als Games/3D nutzt, könnt ihr danach vielleicht richtig was verdienen. :P

[Artificial Mind]

Ne, die C++-API wird nicht nachbearbeitet. Ich hatte die getter nur aus dem Beispiel rausgelöscht um es kleiner zu machen. Solange man sich an unsere Naming Conventions hält, haben wir ein "CLASS_GETTER(type, varname)"-Makro, welches uns dort zu viel copy'n'paste erspart.

ObjectResolver ist übrigends von mir selbst geschrieben, weil es momentan die sicherste Lösung war, vernünftige Objekteidentitäten zu haben (zwei gleiche zurückgegebene IntPtr ergeben das gleiche C#-Objekt).

[Artificial Mind]

Auch wenn ich hier lange nichts mehr gepostet habe: Wir haben viel geschafft und suchen jetzt Alpha-Tester für unser erstes Tech Demo Game!
Man kann sich dafür auf dieser Seite registrieren: https://upvoid.com/miner/about/

Hier unser neues Video mit voice-over von Marcus:
[youtube]aSiFBJQ7heo[/youtube]

Auch wenn sich grafisch nicht besonders viel verändert hat, so haben wir viel interne Technik geschafft.
Ein besonders wichtiger Schritt war die Verwendung von .NET unter Windows. (Wir nutzen Mono 3.2 unter Linux, aber das hat sich unter Windows als zu instabil erwiesen)
Es ist zwar einiges an Arbeit gewesen, trotzdem haben wir jetzt die Api-Anbindung unserer Engine in C++/CLR geschrieben.
Dabei sind auch wirklich nur die Dateien, die auf .NET zugreifen müssen mit /clr kompiliert, sodass der Rest vom Code immer noch garantiert nativ ist.

Weiterhin sind wir von Dual Contouring zu Cubical Marching Squares übergegangen, welches ein wenig die Vorteile von Dual Contouring (Feature Sensitivity) mit denen von Marching Cubes (unabhängige Zellen, mehr geometrisches Detail) vereint.
Dort ist zwar noch nicht alles implementiert, trotzdem kann ich diese Technik bereits sehr empfehlen.

[xq]

Sieht wunderbar aus auf den ersten Blick. Interessantes Projekt!

[Artificial Mind]

Und da gibt es das erste Let's Play über uns :)

[youtube]1vz69rLi37Q[/youtube]
Auf der neuen Seite kann man sich auch für die Alpha anmelden.

RAM-Auslastung ist immer noch ein großes Thema.
Wir haben bereits Snappy getestet um in-memory Teile der Welt zu komprimieren.
Snappy ist zwar recht schnell (ca. 250MB/s compression, 500 MB/s decompression) aber eignet sich vielleicht nicht unbedingt perfekt für unsere floating-point Werte.

Habt ihr Erfahrungen mit performanter Kompression von z. B. Meshdaten?

[ponx]

Irre, Leute! ich bin extrem beeindruckt. Das wird der Hit!

[Slin]

So insgesamt sieht es natürlich alles ziemlich super aus, aber ein paar Kleinigkeiten die ich vor allem im Lets Play auffällig fand:
Die Schatten viel deutlich zu dunkel, also zumindest an der Oberfläche, das sieht doof aus. Auch sind die Schatten für meinen Geschmack zu niedrig aufgelöst wodurch die mit dem ESM aber natürlich dann eine schön breite Penumbra bekommen, a höher aufgelöst und dafür mit stärkerem blur würde das sicherlich trotzdem deutlich besser aussehen.
Das Aufploppen der Bäume geht mal garnicht, also ich sehe ja ein, dass ihr LOD braucht, aber dass die erst auf 50m Entfernung vor einem auftauchen sieht doof aus.
Ich mag die Landschaft nicht, die ist viel zu chaotisch.
Überhaupt, warum nutzt ihr so aggressive Optimierungen wie die aufploppenden Bäume und das stoppen der Physiksimulation ab gewisser Distanz usw? Einfach vom angucken scheint da ja nicht mehr viel Arbeit für GPU und CPU übrig zu bleiben. Ist das Terrain so langsam oder was macht das nötig?

[Artificial Mind]

Als erstes: vielen Dank für deine Antwort! Wir sind noch in einem sehr frühen Stadium wo sich vieles auf Wochen-Basis ändert.

Die Schatten viel deutlich zu dunkel, also zumindest an der Oberfläche, das sieht doof aus.

Momentan ist es noch nicht möglich zwischen Oberfläche und unterirdisch zu unterscheiden, da man ja die komplette Welt verändern kann und somit die Rollen "Oberfläche" und "Unterirdisch" ständig wechseln können. Sobald wir entsprechende Metadaten für das Terrain berechnen können, kann man das auch besser implementieren.

Auch sind die Schatten für meinen Geschmack zu niedrig aufgelöst wodurch die mit dem ESM aber natürlich dann eine schön breite Penumbra bekommen, a höher aufgelöst und dafür mit stärkerem blur würde das sicherlich trotzdem deutlich besser aussehen.

Hier ist das Problem eher, dass wir momentan nur zwei Kaskaden haben. Die aktuelle Sichtweite beträgt ca. 3km und damit ist es nicht besonders trivial überall guten Schatten zu haben, insbesondere da die Shadowmaps ja auch relativ häufig neu gezeichnet werden müssen.
Trotzdem bin ich zuversichtlich, dass wir das in naher Zukunft gelöst bekommen.

Das Aufploppen der Bäume geht mal garnicht, also ich sehe ja ein, dass ihr LOD braucht, aber dass die erst auf 50m Entfernung vor einem auftauchen sieht doof aus.

Das war kein LOD-Effekt, der Bereich war einfach noch nicht generiert. Die Bäume können nur erstellt werden wenn die unterste LOD-Stufe (das höchste Detail) generiert wurde, da sonst gar nicht richtig klar ist, wo der Baum hin kann.
Damit kann es eben immer wieder zum Aufploppen kommen wenn man keinen allzu starken Rechner hat und man eine neue Welt erstellt.
Wenn wir ein wenig einfaden würden wäre es wahrscheinlich angenehmer, ändert leider nichts an der Tatsache, dass die Baumpositionen noch nicht bestimmt werden können wenn die Generierung noch nicht so weit ist.
Ein weiterer Workaround den wir schonmal angedacht hatten ist die Information "Wald" oder "Bäume" schon auf früheren LOD-Stufen zu generieren, womit man wenigstens schonmal was zeichnen könnte bevor die einzelnen Bäume existieren.

Ich mag die Landschaft nicht, die ist viel zu chaotisch.

Auf alle Fälle. Ist auch noch viel zu wiederholend, zu wenig Varianz.
Dort muss sehr viel mehr mit Metadaten und soetwas wie "Biomen" gearbeitet werden, die Planung ist dort auch schon weit fortgeschritten und erste Prototypen zeigen gute Ergebnisse.
Das wird auch in der nahen Zukunft angegriffen.

Überhaupt, warum nutzt ihr so aggressive Optimierungen wie die aufploppenden Bäume und das stoppen der Physiksimulation ab gewisser Distanz usw? Einfach vom angucken scheint da ja nicht mehr viel Arbeit für GPU und CPU übrig zu bleiben. Ist das Terrain so langsam oder was macht das nötig?

Wie bereits gesagt, Bäume und Physik sind noch nicht generiert in dem Bereich. Sobald die generiert sind, ist die Detailreichweite auch ein gutes Stück höher.
Ein großer limitierender Faktor ist allerdings der RAM, denn die Volumendaten und Meshdaten sind ziemlich speicherintensiv.
Mit der Sichtweiteneinstellung aus dem Let's Play werden für das Terrain ca. 400k Primitive gezeichnet, die allerdings für Schatten, Z-Pre und dem normalen Color-Pass benötigt werden. (Also gute 1.2 Millionen Primitive)
Das ist bereits mit Frustum Culling (wäre sonst quasi unmöglich) aber ohne Occlusion Culling.
Die CPU war in dem Video hauptsächlich mit der Generierung beschäftigt vermute ich.

[Slin]

Mit Primitiven meinst du einzelne Triangles vermute ich mal? Denn da sind 1.2 Millionen ja jetzt nicht sooo viele...
Ich werde mich demnächst auch mal an Voxelterrain versuchen, auch wenn wohl deutlich weniger dynamisch, da sieht meine bisherige Planung so aus, dass ich die Meshdaten möglichst im VRAM lassen möchte und wenn nötig auf etwas Präzision verzichte um die Datenmengen überschaubarer zu halten. Die Voxeldaten könnte ich dann auf die Bereiche an denen sich Potentiell etwas ändern könnte, oder eventuell auch nur lazy wenn sich tatsächlich etwas ändert für den relevanten Bereich von der Festplatte laden und die Änderungen zurück schreiben. Aber viel weiter als dass ich rumgerechnet und festgestellt habe, dass das doch ziemlich schnell ziemlich viele Daten werden bin ich noch nicht, insofern macht das eventuell auch alles nicht viel Sinn :P.
Ansonsten würde ich denken, dass es mehr Sinn macht gezielt abhängig vom Typ der Daten zu komprimieren, oder zu entscheiden was man wegschmeißen kann. Gerade bei den Voxeldaten würde ich denken, dass es viele Möglichkeiten gibt da gut zu komprimieren, bzw nur teilweise im RAM zu halten.
Wobei ihr das ja bestimmt eh viel besser wisst und vermutlich schon ziemlich viel herausgeholt habt.

[Artificial Mind]

Für die Physiksimulation müssen die Meshdaten leider auch im normalen RAM liegen.
Die Voxeldaten braucht man für Änderungen und Metadatenberechnung, für die Physik weniger.
Man möchte allerdings nicht bei Terrainänderungen die Daten von der Platte laden, verändern, Meshes berechnen und wieder speichern. Das wäre entschieden zu langsam ;) (Jedenfalls wenn der Benutzer per Klick 'graben' können soll)

1.2 Millionen Dreiecke pro Frame sind nicht zu viel? 72 Millionen Dreiecke pro Sekunde (60fps) ist meiner Erfahrung nach schon relativ anstrengend für aktuelle Hardware.

[Slin]

Okay, ich gebe zu für meine Laptop Grafikkarte ist das schon einigermaßen viel, aber aktuelle Desktopkarten schaffen aus meiner bisherigen Erfahrung noch mehr als das doppelte. Ich habe da letztens mal irgendwo einen ganz guten Post zu gefunden, aber den finde ich leider grad nicht wieder... wobei die Zahlen natürlich stark davon abhängig sind, was mit den Vertices alles gemacht wird.

[Artificial Mind]

Bei Z-Pre und Shadow ist das ja trivial, aber das normale Texturieren des Gelände ist nicht ganz günstig, das sind bei dem Gras bis zu 18 Texture Lookups pro Fragment.

[Dennis]

Ich hoffe es wurde nicht schon irgendwo gepostet, aber ich fand es sehr toll euch auf golem.de wiederzufinden. http://www.golem.de/news/upvoid-engine- ... 04390.html Finde es auch klasse, da ihr euch mit dem Artikel zu "Choosing a Scripting Language" auch für andere mühe gegeben habt.

[kimmi]

Ich hab das auch gleich mal bei Twitter verlauten lassen :).

Gruß Kimmi

[Artificial Mind]

Wow, vielen Dank!

Ja, wir waren auch überrascht von Golem kontaktiert zu werden.
Wir sind noch in einer sehr frühen Phase und wollten einfach schonmal Feedback haben, um nicht an der echten Welt vorbeizuentwickeln.
Einige Sachen verbreiten sich dann eben doch schneller als gedacht.

Immerhin haben wir jetzt über 8000 potentielle Tester die sich angemeldet haben und bereits über 2500 die ihren Alpha-Key eingelöst haben.
Aber wie soetwas natürlich immer läuft ist es bei vielen einfach direkt am Anfang gecrasht ;)
Einige der fieseren Crashes sind bereits behoben, aber so wirklich auf der sicheren Seite sind wir noch lange nicht.

Wir haben dann auch schnell mal ein Community Forum aufgemacht. Das nutzt übrigens Discourse.
Ich muss schon sagen, Discourse ist echt eine gute und moderne Forensoftware. Zwar noch im Beta-Stadium und sicherlich mehr Bleeding als Cutting Edge, aber es macht schon richtig Spaß.

Cheers,
Mind

[Artificial Mind]

Nach zwischengeschobener Auftragsarbeit und einer Menge refactoring haben wir heute endlich die öffentliche Betaphase vom UpvoidMiner begonnen!
[youtube]efIuT67Ic1Q[/youtube]
Gleichzeitig arbeiten wir an unserem ersten kommerziellen Projekt, dem GeoMechanic, der das zerstörbare Terrain besser mit der Bullet Physics Engine koppeln wird. Dazu kommt, dass ich jetzt die nächsten Monate an einer Wassersimulation für unsere Welt arbeiten werde. Grundsätzlich basiert die dann eher auf den Shallow Water Gleichungen als auf Zellulären Automaten (wie z. B. Minecraft).
Die Projektseite zu GeoMechanic ist https://upvoid.com/geomechanic/.
UpvoidMiner Beta kann man unter https://upvoid.com/miner/ testen.

Aber mal genug der Werbung ;)
Im Gegensatz zu vorher sind wir vom Dual Contouring zum Cubical Marching Squares als Isosurface Extraction Algorithmus gewechselt. Auch wenn CMS wesentlich anstrengender zu implementieren ist (wir haben immer noch nicht die volle Feature-Sensitivity drin und mit der Manifoldness hapert es noch hier und dort), hat es doch starke Vorteile gegenüber DC, ganz vorne, dass man endlich nur noch die 8 Eckpunkte + 12 Kanten eines Würfels braucht, um CMS für diesen Würfel zu berechnen. DC braucht dazu immer noch die Nachbarn und diese Abhängigkeit ist echt gemein in einer chunk-basierten Welt.
Was immer noch starke Probleme macht ist die Texturierung des Terrains. Wir nutzen immer noch die triplanar Projection beschrieben in http://http.developer.nvidia.com/GPUGem ... _ch01.html. Zusammen mit Normalmapping und mehreren LOD-Stufen und dem Grasübergang ergibt das 16 Texture lookups nur zum Texturieren vom Gras-Terrain.
Am liebsten würde ich on-the-fly eine einigermaßen sinnvolle und stabile Parametrisierung vom Terrain ausrechnen und das als Texturkoordinaten nutzen, aber das klingt nicht besonders trivial. Hat von euch vielleicht jemand eine coole Idee?

Das Gras ist mittlerweile Geometrie-basiert (danke hier an Zudomon für die initiale Inspiration ;) ) und funktioniert erstaunlich gut und performant. Kein alpha-blending, kein discard, kein z-Pre, keine Model- oder Instance-Transformation (die Gräser werden direkt auf der CPU in world-space errechnet und gespeichert).

- Mind

[Schrompf]

Schön, dass ihr noch am Leben seid :-) Auftragsarbeit empfinde ich eher als Ritterschlag denn als Problem.

Aber sag mal: braucht man denn nicht immer die Nachbar-Chunks, wenn man sanfte Hügel haben will? Also mehr als An/Aus pro Voxel speichert? Beim Gras hätte ich dann spekuliert, dass ihr ohne AlphaBlending ein übles Pixelgewusel bekommt, sobald sich irgendwas bewegt. Die Bilder im YouTube-Video sahen aber echt gut aus... ich bin neugierig!

Viel Erfolg!

[Edit] Vom ersten Test: cooler Launcher, coole GUI, coole Rendertech. Leider sehr ruckelig, ohne dass man wirklich sieht, warum eigentlich. Und ich finde es sehr schade, dass die Bäume nicht bis zur Unendlichkeit sichtbar sind. Die LOD-Stufen ploppen doch eh schon die ganze Zeit, da würde der Übergang zu einem Billboard ab einer gewissen Entfernung auch nicht mehr weh tun. Hab dann ein paar Erdzylinder gebaut und durch die Gegend gerollt - niedlich, aber als z.B. das Gras nicht unter dem Zylinder umknickte, fiel mir erst auf, was Zudo euch gegenüber an Vorsprung hat. Ihr habt dafür definitiv das professionellere Auftreten mit dem InGame-Tutorial und der GUI. Und ich muss sagen: sowohl bei Zudo als auch bei euch fehlt mir einfach massiv das Gameplay. Ein bisschen Rumlaufen und Craften von Dingen, die ich dann fest in die Landschaft einfügen kann, ist für mich kein befriedigendes Gameplay. Ihr habt darüber hinaus ja immerhin noch Physik - technisch ist das alles eine gewaltige Leistung, aber mir hat das alles viel zu wenig menschliche Bedeutung.

[Artificial Mind]

Das Gras wuselt tatsächlich, kann man aber mit FXAA und ner guten Textur etwas in den Griff bekommen. Was auch hilft ist, keine richtige Beleuchtung zu haben (außer Licht/Schatten) und zur Not die Texture gegen eine einheitliche Farbe blenden in der Distanz.
Das mit der Beleuchtung ist lustig weil es mit "richtiger" Beleuchtung einfach schlechter aussieht in großen Bereichen.

Bei unserem Volumenformat teilen sich Nachbar-Chunks immer eine Ebene von Volumendaten (also Materialindizes + Intersection Data. Wir nutzen Hermite Data um die Volumendaten zu speichern). Vielleicht einfach mal so ausgedrückt: Material-Daten stehen in den Vertices, Intersection-Daten in den Kanten. Chunks haben bei uns eindeutige Würfel und teilen sich Vertices mit den Nachbarn. DC extrahiert pro Kante Geometrie und braucht dafür 4 Nachbarwürfel (und damit Nachbarchunks) während CMS direkt auf einem Würfel arbeiten und nur die Daten der Vertices + Kanten braucht.
Falls Interesse besteht kann ich morgen mal eine kleine Skizze machen wenn ich wieder an einem richtigen Rechner bin ;)