Voxelmanagement (mal wieder^^)

[mike7774]

Hallo liebe Zfx Community,

ich habe mal wieder ein paar Fragen bzgl. Voxelmanagement. Aber erstmal will ich die aktuelle Situation erklären.

Momentan entwickle ich gerade ein Programm welches Voxel zur Grafikdarstellung verwendet. Dazu benötige ich (mehr oder weniger) dynamische Voxelstrukturen. Der aktuelle Ansatz sieht dabei so aus, dass ich mir eine Konstrukt aus n³ "Voxelbricks" (ich nenn es mal so) erstelle. Jeder dieser Voxelbricks beinhaltet einen Octree mit Voxeldaten und kann dynamisch in kleinere Voxel "subdivided" werden. Level 0 des Octrees beinhaltet 8 Voxel, Level 1 32 Voxel usw.

Das ganze funktioniert schon relativ gut, und soll letztendlich über die Distanz des Betrachters dynamisch die benötigte Voxelauflösung darstellen, nur habe ich das leidige Problem das ich nach jedem "subdivide" die Geometriedaten des kompletten Bricks neu berechnen muss. Das ganze in kleinere Buffer aufzuteilen löst das Problem nicht, es verlagert es nur.
Momentan verwende ich für jeden Brick einen Vertex-/Indexbuffer und habe damit bereits n³ Draw Aufrufe (also wenn das ganze Voxelmesh im Viewport ist).
In jedem Frame Daten aus kleineren Buffern zu sammeln und per memcpy in einen Hauptbuffer zu kopieren dürfte das Problem auch nicht lösen (das ganze soll in Echtzeit gerendert werden).
In einer anderen Anwendung habe ich Voxelchunklisten erstellt welche über Flags gemanaged wurden, das dürfte in diesem Fall auch nicht möglich sein. Hashtables könnten hilfreich sein, nur habe ich damit noch keine Erfahrung und Google hilft auch nur bedingt weiter.
Um jetzt endlich mal auf den Punkt zu kommen - Welche Möglichkeiten würde es geben die Vertex-/Indexdaten aus meinen Octrees zu erstellen ohne sie bei jeder Änderung des Octrees jedesmal neu zu erstellen.

[Schrompf]

Level 0 des Octrees beinhaltet 8 Voxel, Level 1 32 Voxel usw.

Level 1 hat 64 Voxel, oder?

Um jetzt endlich mal auf den Punkt zu kommen - Welche Möglichkeiten würde es geben die Vertex-/Indexdaten aus meinen Octrees zu erstellen ohne sie bei jeder Änderung des Octrees jedesmal neu zu erstellen.

Komplett ohne Neuerstellung wird knifflig. Du könntest das Ganze der GPU überlassen und die Arbeit dort mit nem Compute Shader machen. Knifflig, aber machbar, denke ich. Du könntest einen vollgevoxelten Fertig-Mesh nehmen und im Geometrie-Shader jeden Voxel live bestimmen oder halt weglassen. Verlagert die Arbeit von "Pro Sichtänderung" zu "Pro Frame", da rettet Dich wahrscheinlich nichtmal mehr die abartige Rechenkraft einer GPU.

Oder Du machst halt Teil-Lösungen. Bei mir z.B. wird ein Voxelvolumen in Quader-Meshes aufgeteilt wie bei Dir. Aber wenn ich einen Teil mit niedrigerer Voxelauflösung rendern will, dann erstelle ich ihn für ein doppelt so großes Volumen. Also quasi 8 Meshes für LOD 0 werden zu einem Mesh für LOD 1 zusammengefasst. Damit decken höhere LOD-Stufen nach hintenraus immer größere Volumenteile ab und Deine n³-Komplexität wird zu einer O(3log n)-Komplexität - auch mit entsprechend selteneren Änderungen. Ruckelt und hackt bei mir zumindest immernoch heftig, aber da muss ich noch mal profilen, woran das liegt, und dann Krishty-style mal in die ASM abtauchen, ob man das was rausholen kann. Und dann kann man die Mesherstellung als rein lesende Operation auf dem Voxelbaum ja prima parallelisieren. Nur wenn man parallel dazu den Baum ändert, wird es ... spannend.