Rechner-gestützte Visualisierung volumetrischer Daten (Scientific Visualization, Volume Rendering, u.s.w.)

Sehr hübsch diese Samuel M. Goldwasser Seite.

Diese Voxel-Sache hat sich ja anscheinend bisher nicht so recht durchsetzen können.

War aber mal eine zeitlang wirklich "en-vogue" und gevoxelte Fraktallandschaften finden sich in allerlei Demos ( Amiga, Acorn, PC ). Ist aber nicht wirklich viel "wertvoller" für die Grafikgenerierung als "normales 3D".

In Games wird es trotzdem manchmal benutzt

https://docs.cryengine.com/pag…ge.action?pageId=25535599

bei Minecraft bin ich nämlich gar nicht sicher, ob das wirklich "voxelt". Am Ende sind das 3D Würfel ...

und für den Amiga ( und auch den Atari ) ist für demnächst eine Opensource Engine angekündigt

https://www.reddit.com/r/amiga…nce_the_vergeworld_voxel/

und ein Voxel-Geballer gibt es auch

http://voxelstein3d.sourceforge.net/

Hier mal noch was Ernsteres aus der Abteilung "alte Nachrichten"

https://www.computerwoche.de/a…er-3d-darstellung,1140210

Was das TAAC System mit Voxeln zu tun hat, erschließt sich mir aber nicht. Das hatte ich bisher immer als eine sehr frühe Form einer "normalen" 3D Engine eingeordnet. Quasi als Versuch mit SGI irgendwie mithalten zu können.

Ich glaube die wirklich sinnvollste Anwendung für Voxel findet sich im Rahmen der Med-Diagnostik etwa bei MRTs oder 3D Röntgen Scans. Das wurde i.a. auch auf SGIs ausgewertet. Die Software dürfte aber heute schon fast nicht mehr existieren, auch wenn die mal extrem weit "vorn" und wahrscheinlich "elend teuer" war.

Zitat von ThoralfAsmussen

Diese Voxel-Sache hat sich ja anscheinend bisher nicht so recht durchsetzen können.

Ich denke das ist ähnlich wie mit normalen und dünnbesetzten Matrizen: es kommt auf den Anwendungszweck an.

Um eine m×n Matrix M zu speichern, schreibe ich normalerweise ihre Einträge M(i,j) in ein 2d array. Eine dünnbesetzte Matrix ist eine bei der nur wenige Einträge von 0 verschieden sind. In dem Fall ist es (Speicher-)Effizienter um nur die von 0 verschiedenen Einträge zu speichern, beispielsweise als liste von Tripeln aus (i,j,M(i,j)) aus Koordinaten mit entsprechendem Eintrag. (Es gibt hier natürlich verschiedene Speicherweisen die unterschiedlich geeignet für bestimmte Matrix-Operationen sind.)

Ohne jetzt Computergraphik-Experte zu sein, stelle ich mir das hier ähnlich vor: bei 3d Anwendungen wo der größte teil des Raumes leer ist, dürfte eine Art Koordinatendarstellung effizienter sein als die Speicherung jedes einzelnen Pixels einer "3-dimensionalen Matrix". (Polygone sind dann sozusagen das Vector-Graphik pendant dazu und je nach Einsatzzweck wesentlich geeigneter.)

Für bestimmte Einsatzzwecke aber ist so eine 3d-Matrix durchaus geeignet. In der Computertomographie und ähnlichen Verfahren beispielsweise ist die Auflösung des Bildes fest (für ein bestimmtes Gerät.) Prinzip ist ganz grob folgendes: man schickt aus verschiedenen Winkeln eine gewisse Strahlenart (bekannte Wellenlänge, Amplitude) in das Messobjekt (z.B. Mensch) und misst was außenrum wieder raus kommt (die Streuung). Daraus wird dann mathematisch recht aufwändig eine Dichtefunktion für das Messobjekt rekonstruiert (wobei Dichte hier sozusagen der Widerstand für die gewählte Strahlenart ist.) Es gibt, in abhängigkeit von diversen Faktoren wie Wellenlänge und Messgenauigkeit, eine maximal sinnvolle Auflösung (hat am Ende u.a. mit dem Shannon-Abtasttheorem zu tun). Das ganze wird jetzt Scheibchenweise gemacht und man erhält auf diese Weise ganz natürlich eine 3d-Dichte-Matrix. Die kann man jetzt natürlich unterschiedlich visualisieren, und das sieht man sehr schön in dem von escimo verlinkten Video von Sam Goldwasser. An einer Stelle wird beispielsweise ein cut-off für die Dichtefunktion festgelegt und nur ausreichend dichte Pixel (oder Voxel) werden angezeigt: es bleibt eine Darstellung der Knochen ohne das umliegende Gewebe.

Also Speicherplatz braucht man schon viel - deshalb ging das ja auch erst spät los und Voxel sind erst > 1992 so richtig wahrnehmbar gewesen ( für den Nicht-Grafiker ).

Aber - im Vergleich zur normalen 3D Grafik gibt es zwar Unterschiede in der Menge der Punkte, aber die Art wie die Punkte gespeichert werden, ist m.E. so anders nicht.

In einem Fall - nämlich dem 'normalen' Vektor-3D ( OpenGL und Co ) - legt man die Punkte in eindimensionale Array's ( also Vektoren ) mit [ x, y, z ] und evtl. noch eine Farbe dazu. Und je nachdem wie das Modell dann aufgebaut ist, hat man noch weitere Arrays die z.B. Linien darstellen, also [ Anfangspunkt , Endpunkt ] oder Dreiecke mit [ Eckpunkt 1, Eckpunkt 2, Eckpunkt 3 ] oder auch mal Trapeze mit [ P1, P2, P3, P4 ]. Je nachdem sind auch die Farben dort mit drin, etwa als Linienfarbe. Benutzt man generell für alles gefüllte Flächen, reicht evtl. eine Farbe pro Flächenelement, üblicher ist wohl eine Farbe je Eckpunkt. Bei Benutzung von Texturen kann man sich das sogar komplett sparen, hat dann aber natürlich jede Menge zusätzliche Bilddaten ( eben die Textur ), die i.a. auch noch in verschiedenen Auflösungen vorliegen ( MipMap ) sollte.

Bei den Voxeln dagegen hat man drei Koordinaten pro Voxel zzgl. eine Farbinformation bzw. eine Transparenz, oder evtl. auch einfach einen Grauwert - der dann direkt die Signalstärke ( Meßwert aus der realen Welt ) - abbildet. Also sowas in der Art von [ x, y, z, wert, transparenz ] im Maximalfall.

Das Problem ist dann, daß mit höherer Auflösung der Speicherbedarf extrem explodiert - weshalb das eben genau keine Technik für Rechner mit 1 MB Speicher ist. Es sind ja schließlich Volumenelemente, d.h. eine 'Verdoppelung' der Auflösung führt zu einer Verachtfachung des Speicherbedarfs (!). ( 2³ ) Das macht man nicht oft - und deshalb sehen die Voxeldemos auch immer irgendwie schlecht aufgelöst aus. Mittlerweile ist das bißchen anders, weil RAM eher vorhanden - das Problem bleibt aber.

Nur : bis hierher hatte das mit Matrizen nicht viel zu tun - es sei denn man nennt die eindimensionalen Matrizen ebenso. Die mehrdimensionalen Matrizen kommen da nur ins Spiel, wenn man die Punkte dann geschickt auf einer 2D Ebene ( Bildschirm ) abbilden will und daher eine Perspektive hineinrechnen will oder die gesamte Punktwolke drehen muß.

Bleibt als Vorteil für Voxel einfach nur, daß man die Meßwerte direkt in den Farbwert abbildet und die Anordnung im Rechner schön direkt dem entspricht, wie man es gemessen hat. Das wiederum funktioniert gut aber auch nur bei Messungen, die in schön kontinuierlichen, gleichbleibenden Abständen einen Meßwert liefern.

Ich weiß ja nicht, wie das heute gemacht wird, aber da es diese sehr krassen Beschleuniger für 3D Vektorgrafiken zu einem Spottpreis gibt ( GamerGrafiken ), werden Voxel wahrscheinlich insgeheim intern bei solchen Sachen wie z.B. CT-Bildern auf eine Art gleichmäßig verteilte Vektorwürfel abgebildet - und die kann man dann schön schnell mit der 3D Karte drehen. Da die Karte sowieso so gebaut ist, daß da ein steter Datenstrom an Koordinaten immer wieder neu ankommen muß, läßt man wahrscheinlich einfach die "transparent" gesetzen Voxel weg und schickt nur die Infos für die 8 Eckpuntke des Würfels um den darzustellenden Voxel herum an die Karte. Möglicherweise kann man das aber sogar direkt in der Karte generieren, so daß also aus einem Voxeldatenpunkt ein Würfel generiert wird - Stichwort Tesselation ( müßte man mal nachschauen, ob das für Punkte überhaupt zulässig ist ). In dem Fall hätte man quasi echte Voxel in Maximalgeschwindigkeit - und da man sowas zu horrenden Summen verkaufen kann, Zulassung natürlich vorausgesetzt, wird es sowas wohl schon durchaus geben. Vielleicht als add-on für eine Quadro Karte.

Wo Voxel vermutlich auch eine echte Rolle spielen, dürften "finite Elemente" sein. Zumindest sollte man da bestimmte Eigenschaften, die man vorher ausgerechnet hat ( Druck, Zugspannung o.ä. ) direkt als Voxelfarbe abbilden können und dann quasi direkt anzeigen. Ich habe solche Bilder auch schon live gesehen ( Baustatiksoftware ), aber ob das da dann wirklich mit Voxeln gemacht worden ist, kann man so vom kurz Draufschauen gar nicht sagen.

Die in den Großrechnern laufenden Fluidsimulationen wären wahrscheinlich auch noch eine schöne Anwendung für das Thema. Da hat man aber evtl. das Problem, daß die (virtuellen) Meßpunkte nicht gleichmäßig verteilt sind.

Hier noch zwei kurze Links - die man durch Weiterklicken beliebig ausweiten kann

http://web.cs.wpi.edu/~matt/co…ks/powwie/p1/ray-cast.htm

http://www-graphics.stanford.edu/projects/volume/

Alles schon "historisch", aber schön zu sehen, daß sie es noch auf den Servern haben. Wahrscheinlich aber nur solange, bis der letzte Beitragende den Laden verlassen hat. Überhaupt kann man die Pat Hanrahan und auch anderer Leute Grafikkurse dort sehr empfehlen.

Die Maschine, die sie sich gebastelt haben, ist auch ganz lustig

http://www-graphics.stanford.edu/projects/multigraphics/

für alle mit Interesse an ordentlicher 3D Grafik war das zur Aufbauzeit sicher ein ziemlich "fettes" Teil.

.

Bei FEM und CFD Rechnungen verwendet man meistens "Netze" oder "Gitter" deren Punkte nicht gleichmäßig verteilt sind. Dort wo "viel passiert" verdichtet man und woanders spart man Punkte. Es werden dann physikalische Größen in den Gitterpunkten berechnet und zur Visualisierung wird dann dazwischen interpoliert. Damit kann man gut hinein und hinaus-zoomen. Das geht seit OpenGL und mit heutigen Grafikkarten sehr schnell.

Solche Netze haben dann typisch 50-100 Mio Punkte und in jedem Punkt x,y,z und 20 Variablen die man ansehen möchte plus die Verbindungsinformationen (welche Punkte gehören zu welchem Tetraeder oder Würfel?) plus die Visualisierungsdaten (Farbwerte, Licht, Interpolation etc.). Die 32-64 GB RAM sind dann schnell voll.

Es gibt auch Ansätze quasi auf "Molekülebene" zu rechnen, dort kann dann ein Voxel=eine Rechenzelle sein, aber auch da hat man eine endliche Auflösung und man kann nicht unendlich hineinzoomen. Für praktische Anwendungen kommen solche Systeme heutzutage noch begrenzt zum Einsatz, da die Rechner zu wenig Speicher haben.

Quelle: DLR

Objektoberfläche mit Zellen - im Raum geht es dann senkrecht dazu ähnlich weiter. Oben (blau) Anfangs-Netz, unten (rot) nach einer Verfeinerung dort wo etwas "passiert".

Quelle: DLR

Die hellblauen Bildteile dort, wo die Netze an den Oberfläche und im Raum verdichtet sind, sind Flächen die Überschallgebiete einschliessen, die durch Interpolation durch die Raumzellen ermittelt werden. Weil die Netze in diesem Fall für schnelle Vorab-Rechnungen recht grob sind (ca. 1 Mio Punkte) sieht man an den Rundungen und Kanten die grobe Auflösung als leicht "krakelige" Oberflächen.

Der gute, alte SUN TAAC-1 arbeitete, wenn ich mich recht entsinne, mit CGI, einer Grafikschnittstelle ähnlich wie OpenGL. Das dürfte vergleichbar mit den SGI IRIS Workstations der Zeit gewesen sein.

Man konnte damit solche Finite-Volumen(/Elemente Objekte darstellen, aber ich denke das war nicht auf Voxeln basierend, aus Speichermangel.

Ein Kollege hatte damit einen Film über ein Detail Strömungsphysik (aus Einzelbildern) erstellt - so was war damals noch spektakulär.

Aber wenige Jahre vorher haben wir auch TRON im Kino angeschaut - wow! Heute lacht man darüber.

Zitat von ThoralfAsmussen

Bei den Voxeln dagegen hat man drei Koordinaten pro Voxel zzgl. eine Farbinformation bzw. eine Transparenz, oder evtl. auch einfach einen Grauwert - der dann direkt die Signalstärke ( Meßwert aus der realen Welt ) - abbildet. Also sowas in der Art von [ x, y, z, wert, transparenz ] im Maximalfall.

Das Problem ist dann, daß mit höherer Auflösung der Speicherbedarf extrem explodiert - weshalb das eben genau keine Technik für Rechner mit 1 MB Speicher ist. Es sind ja schließlich Volumenelemente, d.h. eine 'Verdoppelung' der Auflösung führt zu einer Verachtfachung des Speicherbedarfs (!). ( 23 ) Das macht man nicht oft - und deshalb sehen die Voxeldemos auch immer irgendwie schlecht aufgelöst aus. Mittlerweile ist das bißchen anders, weil RAM eher vorhanden - das Problem bleibt aber.

Nur : bis hierher hatte das mit Matrizen nicht viel zu tun - es sei denn man nennt die eindimensionalen Matrizen ebenso. Die mehrdimensionalen Matrizen kommen da nur ins Spiel, wenn man die Punkte dann geschickt auf einer 2D Ebene ( Bildschirm ) abbilden will und daher eine Perspektive hineinrechnen will oder die gesamte Punktwolke drehen muß.

Die Verachtfachung des Speicherbedarfs tritt ein wenn du für jede Koordinate im 3d Raum einen Wert/Farbe/Dichte speicherst. Dann brauchst du aber nicht die Koordinate zu speichern wie in deinem Beispiel, sondern packst die Werte einfach in eine... 3d Matrix

Deine Speichermethode entspricht der einer dünnbesetzte 3d-Matrix (na gut, die muss man nicht Matrix nennen und darf sie auch einfach als Liste auffassen). Dünnbesetzte Matrizen sind bei gängigen Verfahren aber nur effizient wenn maximal ca 1% der Koordinaten einen Wert zugeordnet bekommen. Im Fall von MRT und ähnlichem wird aber eben jedem Punkt in Raum eine Dichte zugeordnet und damit macht diese Speicherweise keinen Sinn.

Wie die Messdaten heutzutage weiterverarbeitet werden weiß ich nicht, damit kenne ich mich nicht aus.

Stimmt anscheinend. SunVoxel ist richtig eine eigene Geschichte dafür, und rendert dann auch auf den ganz frühen Beschleunigern.

Gibt aber auch noch jede Menge andere - schöne Liste solcher Tools:

http://med.stanford.edu/biocom…onstruction/software.html

Sind auch nicht alles Voxel Programme, aber manche können das, oder eine günstige Form davon, wie z.B. Montage , was Output aus "Slices" generiert und z.B. als Postscript oder auf dem Monitor ausgeben kann

https://web.archive.org/web/20…upenn.edu:80/montage.html

Ein großes Programm ist sicher ImageVolumes für SGIs. Wie der Name sagt, kann das solche Daten nicht nur (Iris beschleunigt) visualisieren, sondern v.a. auch Volumeninhalte "messen", also aus den Messwerten Dinge abschätzen, die man anders überhaupt nicht vernünftig auswerten kann ( auf einem Röntgenbild kann man das bestenfalls abschätzen und bißchen mit einem Lineal "pseudoquantifizieren" ). DAS ist dann wirklich richtig nützlich.