ZFX + Developia

Guten Morgen Liebes Forum,

ich habe die letzten paar Stunden an einem kleinen Prototypen für zerstörbares Terrain gearbeitet.
Erstmal ein kleiner Screenshot dazu: Wer es selber mal testen möchte, hier ist eine Linux Version (ja, sorry, aber ich arbeite gerade unter Linux ;) ), unter Ubuntu 12.04 compiled:
http://dl.dropbox.com/u/443720/TerrainPrototype.zip
Es wird mindestens OpenGL 3.2 benötigt.
WASD, sowie rechte Maustaste gedrückt gehalten bewegt die Kamera.
Links-Click zerstört einen Teil des Terrains.
Die Bälle hüpfen munter herum und zerstören bei jedem Aufprall auch etwas Terrain.
Es gibt nur einen 32 * 32 * 32 Terrain Chunk (-> Prototyp).

Zur Technik:
Das Terrain liegt als Density 3D Textur auf der CPU und auf der GPU.
Wenn sich etwas an dem Terrain ändert, wird ein Geometry Shader aufgerufen, der momentan ein billiges Dual Contouring (mit sehr hackiger Voxel Point Estimation) benutzt.
Diese Geometry wird per Transform Feedback in einen Vertex Buffer geschrieben, der dann jeden Frame gedrawt wird.
Das Erstellen einer 32 * 32 * 32-Geometry dauert < 1ms.
Der Vertex Buffer wird dann auf die CPU gemappt und die Dreiecke werden als Static Mesh an Bullet übergeben.
Da man bei den meisten Szenarien davon ausgehen kann, dass große Teile des Terrains statisch sind und sich nur sehr selten verändern, kann man so sehr performant viel zerstörbares Terrain haben.
Als Texturierung habe ich einen schlecht optimierte Shader, der zwei 3D Noise Texturen verschiedener Skalierung als Farb- und Bump-Map benutzt. (Das ist momentan auch der Performance Bottleneck ;) )

Cheers,
Mind

Interessanter hätte ich ein Bild/Video gefunden, in welchem du einen Tunnel durch den Block bohrst.

Oh, hört sich ja interessant an. Ist das jetzt nur ne Demo, oder hast du auch vor, das irgendwann mal wo einzubauen?

Sowas hatte ich auch mal in [w]tech. Ist aber seit der letzten GUI-Grundüberholung nicht mehr ganz so zugänglich und nützlich. Hier haben wir ein Video davon, denke das kommt deiner Sache schon ziemlich nahe (Läuft aber auf der CPU). Außerdem wird im 2. Video Layerpainting mit verschiedenen Shadern gezeigt, was für dich auch recht interessant sein könnte:

http://www.youtube.com/watch?v=utgdDmSTOO0&feature=plcp
http://www.youtube.com/watch?v=48MM9zzMxRM&feature=plcp

(Oh gott, ist das alt. Man schämt sich ja schon fast für das aussehen der Engine und die Texte :D)

Andre hat geschrieben:Sowas hatte ich auch mal in [w]tech. Ist aber seit der letzten GUI-Grundüberholung nicht mehr ganz so zugänglich und nützlich. Hier haben wir ein Video davon, denke das kommt deiner Sache schon ziemlich nahe (Läuft aber auf der CPU).

Das wollte ich ja gerade vermeiden, da große Mengen Terrain auf der CPU einfach echt lange brauchen. Hast du mal Zeitmessungen gemacht, wie schnell die CPU Variante ist?

Zum Thema Video: ich wollte gerade mal gucken, dass ich mehrere Chunks einbaue und dann nachher ein Video mache (bzw. wie kann ich unter Linux ein Video von einem Fenster aufnehmen? O.o).

Zum Thema Verwertung: Das ist hier erstmal ein kleines Proof-Of-Concept. In der Uni bin ich in einer "Spieleprogrammier-AG", die vom Grafiklehrstuhl angeboten wird. Dort steht demnächst die Wahl des nächsten Spielethemas an und dieser Prototyp soll zeigen, dass meine Idee umsetzbar ist ;)

So, viele Chunks sind auch ok, auch wenn ich bei meiner momentanen single-threaded Architektur auf 16*16*16 pro Chunk zurückgegangen bin, damit die Updates kleiner sind.

Ich habe mir grad keine besondere Mühe an den Chunkgrenzen gegeben, deswegen sind dort ein paar off-by-ones und Unstetigkeiten.

Sehr schick.

Zum Vergleich mal ohne Normal Mapping:

Zeitmessungen habe ich nicht gemacht. Hat aber für den Editorgebrauch gereicht. Da war allerdings später auch noch ein anderer Thread am werkeln, damit es wirklich flüssig läuft... Ich hab sowas aber auch schon auf der CPU verdammt fix gesehen.
Deine Methode ist aber auf jeden Fall hoch interessant für mich.

Die CPU kann da wirklich nicht gegen die GPU anstinken.
Das hier läuft in Realtime: http://http.developer.nvidia.com/GPUGem ... _ch01.html

Da ich momentan die Daten auch direkt für Bullet brauche, muss ich das natürlich von der GPU zurück auf die CPU kopieren, um die Dreiecke zu bekommen. Ich denke richtig auspielen wird sich der GPU Vorteil, wenn man anfängt, LOD Stufen von riesigem Terrain zu berechnen, welche nur zur Anzeige gedacht sind und nicht zurückkopiert werden müssen.

... was ich auch nie bestritten habe ;)

Was LOD-Stufen betrifft: Hast du schon eine Idee wie du dich um die Seams zwischen den Stufen kümmern willst?

Hm, Alpha Fade-In/Fade-Out, LOD Stufen in Zweierpotenzen und hoffen, dass die Normal Map den Rest regelt xD

Hast du ne bessere Idee?

Ich denke das hier solltest du dir mal anschauen: http://www.terathon.com/voxels/
Bestaussehende Methode, die ich bis jetzt gefunden habe. Und ich glaube kaum, dass es noch wirklich besser geht. Leider habe ich keine Ahnung wie komplex das ganze wirklich ist. Habe das ganze leider erst gefunden nachdem ich meine Arbeiten am Voxel-Terrain erstmal unterbrochen habe.

Also das sieht zwar an sich gut aus, basiert aber auf Marching Cubes, welches ich vermeiden möchte. Ich benutze Dual Contouring. Morgen kann ich mal die Assistenten am Grafiklehrstuhl fragen, ob die eine Methode dafür kennen. Mir ist auch jetzt erst richtig klar geworden welche Seams du meinst, danke für den Hinweis ;)

Was noch ein unschöner aber eventuell funktionierender Workaround wäre:

Nimm doch die LowPoly-Stücke und schiebe alle Vertexe ein Stück in entgegengesetzte Normalenrichtung. Dadurch sollte man an den Grenzen von Detailstufen nicht unter den Teilen durchgucken können.

So, ich bin bei der Texturierung auf Triple-Projection umgestiegen, damit hab ich nur noch 6 Texture Calls pro Fragment.
Unter Windows scheint das ganze etwas langsamer zu laufen, das liegt irgendwie an der Qt+OpenGL+Windows-Combi.
Aber unter Linux habe ich bei 2 Mio Dreiecken meine 300+ fps. Umgerechnet in Minecraft Maßstäbe ist das ca. die 5-fache Sichtweite von Minecraft. (Ich habe 21 x 21 Chunks, die jeweils 32x32 in xz-Richtung sind. Minecraft hat 9 x 9 Chunks zu je 16x16)

Hier eine Windows-Version mit 5 x 5 Chunks je 32x32 in xz-Richtung, sowie maximal 20 Chunks tief:
https://dl.dropbox.com/u/443720/Terrain ... indows.zip
Fixed Exe ohne jpgs: https://dl.dropbox.com/u/443720/Terrain ... xedExe.zip (kann sein, dass man die nehmen muss, wenn er die jpg nicht findet)

Mich bestraft diese Version mit einem Absturz und der Fehlermeldung: "Loading image Texture/Dummy.jpg has failed! FileManager::getResource: Resource could not be loaded: Dummy.jpg"
Habe es mal mit Adminberechtigung und Windows XP SP3 Kompatibilitätsmode probiert aber das hilft nichts. Achja, ich nutze Win8 - aber unter dem Kompatibilitätsmodus meldet er mir nicht mehr "Untested Windows version 6.2 detected!" weshalb ich davon ausgehe, dass der Build eventuell einfach fehlerhaft ist?

Hm, also ich habe das unter Windows 7 64bit kompiliert (allerdings 32bit, wenn ich das richtig erinnere).
Bei einem Kollegen und mir unter Windows 7 läuft es einwandfrei. "Loading image failed" ... ist denn die Textur in dem Pfad? Also ist die zip komplett entpackt?

Bin auch auf einer 64bit Maschine für den Zweifelsfall.
Die ist komplett entpackt als Dummy.jpg ;)

Ok wenn du Qt nicht installiert hab, meine ich mich erinnern zu können, dass es Probleme mit jpgs gab.

Nimm mal diese exe hier, die benutzt keine jpgs mehr: https://dl.dropbox.com/u/443720/Terrain ... xedExe.zip

Tatsächlich lag da das Problem, läuft jetzt!
Sieht auf jeden Fall sehr interessant aus!

Jo, funktioniert und ist lustig :)

Hm, ich wollte es grad mal ausprobieren.
Das Programm startet auch (mit der fixed exe) und ich kann sehen wie die Bälle anfangen zu fallen, jedoch ins "nichts" weil kein Terrain da ist. Muss ich das erstmal aktivieren oder stimmt da was nicht?
Das ganze unter Win7 x64 / NVIDIA GF GTX 285 / ohne Qt.

ja das mit dem ins "nichts" fallen habe ich mittlerweile bei meiner Version gefixt. Das liegt daran, dass deine Graka nur OpenGL 3.3 kann und anscheinend wird gl_InstanceID beim Instanced-Drawing nicht vernünftig gesetzt, wenn man Transform Feedback Buffer hat. Ich bin halt auf normales Drawing und gl_VertexID umgestiegen. Ist aber noch nicht hochgeladen. Ich guck mal morgen oder so, ob ich eine neue Windows-Version fertig bekomme.

So ich habe mal ein wenig weitergearbeitet:
- Mehrere Materialtypen
- Viewfrustum Culling
- Z-Prepass
- Automatische Chunk-Generierung in der Umgebung von veränderten Chunks
- Verschiedene Texturen für die Projektions-Seiten
- Diverse Speicheroptimierungen
Es müssen noch die Übergänge zwischen den Materialien gesmoothed werden und Chunk-Grenzen müssten noch vernünftig konsistent gemacht werden.
Momentan kann jedes Material einen eigenen Shader haben, was ein unglaublicher Vorteil ist.
LOD ist auch ein Thema, allerdings nicht unbedingt für den Prototypen (genauso wie ich vernünftige Material- und Chunkübergänge für den Prototypen nicht unbedingt priorisiere).

Als nächstes möchte ich mich jedoch der Fluid-Simulation widmen. Hat da jemand gute Ideen wie man auch potentiell große Fluidmengen performant überzeugend simulieren kann?

Artificial Mind hat geschrieben:Als nächstes möchte ich mich jedoch der Fluid-Simulation widmen. Hat da jemand gute Ideen wie man auch potentiell große Fluidmengen performant überzeugend simulieren kann?

gwX hat in der Hinsicht pro Frame eine Map von aktiven Fluiden. In jeder Simulationsiteraton wird diese Map neu berechnet. Dadurch kann ein kleiner Fluss mal "einfach so" fließen und bei einem Dammbruch stockts halt doch mal ein bisschen.
Ansonsten: den Cache beim programmieren im Fokus behalten.

Ich mach mir nur Sorgen, wenn es z. B. regnet und sich überall Pfützen bilden und das danach wieder versickert und so.

Aber ich muss wahrscheinlich das einfach mal ausprobieren.

Hab deinen Prototypen auch eben einmal ausprobiert. Sieht gut aus soweit. :) Leider scheint es zu VSyncen, sodass ich nur bis 60fps komme mit meiner GTX570.

Unter Windows ist glaube ich VSync standardmäßig an.

So, ich habe mich mal an prozeduralen Bäumen versucht.
Das zugrundeliegende Modell ist eher biologisch motiviert und orientiert sich an diesem Paper: http://dl.acm.org/citation.cfm?id=1531364
Selbst das Terrain wird mit einbezogen, sodass die Bäume um Vorsprünge und so herumwachsen.