Raycasting front-to-back

mortified_penguin

Die Länge des Strahls ist ja gleich der Tiefe des Volumens, also sollte der Durchlauf von len bis 0 richtig sein. Wenn ich aber testweise von 0 bis len laufe, bekomme ich den gleichen Fehler den ich im OP beschrieben hab.

Finnegan

Mir gehen grad ein wenig die Ideen aus, daher ein paar allgemeine Fragen:

Habe ich das richtig verstanden? Das ist exakt genau dasselbe Setup, das in der back-to-front-Variante korrekt funktioniert?
Es gibt da noch ein paar Dinge, die mich etwas wundern:

vec4 trace_front_to_back(sampler3D volume
...
                         , sampler1D opac_lut
                         , sampler1D color_lut
...
      vec4 voxel_curr
                = texture3D(textures[0]
                    , vec3(coord.x, coord.y, steps/(len*1.0)));
...
        voxel_curr *= texture1D(color_tf, curr_voxel_val);
        vec4 current_transparency = texture1D(opac_tf, curr_voxel_val);
}

Müssten die ersten Argumente von texture* nicht die Sampler sein, die du in den Parametern von trace_front_to_back
übergeben bekommst? Also:

...
      vec4 voxel_curr
                = texture3D(volume
                    , vec3(coord.x, coord.y, steps/(len*1.0)));
...
        voxel_curr *= texture1D(color_lut, curr_voxel_val);
        vec4 current_transparency = texture1D(opac_lut, curr_voxel_val);
...

Sind die _tf Variablen global? Sind die korrekt aufgesetzt und verweisen die auf die richtigen Texturen?

Eine weitere Sache hier:

voxel_curr *= texture1D(color_tf, curr_voxel_val);

Du modulierst die Intensität des Voxels mit der (via Sampler interpolierten) Farbe für diesen Wert aus dem LUT.
Ist das so gewollt, dass die LUT-Farbe mit der Voxel-Intensität skaliert wird?
Ich hätte jetzt gedacht, dass dass im LUT lediglich ein "Mapping" Intensität->Farbe stehen würde.
So wie es da steht haben z.B. niedrige Intensitäten immer eine "dunkle" Farbe, egal wie "hell" die Farbe im LUT
für die Instensität definiert wurde.

Ausserdem hast du im OP von "Slices" gesprochen. Wie machst du das Rendering selbst?
Ich bin bisher davon ausgegangen dass du lediglich ein Quad renderst, bei dem dieser Shader aktiviert ist.
Ist das korrekt? Falls du aus irgendeinem Grund das Volumen stückweise rendern solltest also ein Quad pro "Slice",
die jeweils hintereinander liegen, könnte natürlich auch der Z-Buffer dein Problem sein, da dann nur das erste Quad
gerendert wird und die dahinter liegenden nicht, da für diese dann der Z-Test fehlschlagen würde (wegen dem ersten Quad).

Finnegan

mortified_penguin

Ja deine Punkte sind korrekt, das hab ich beim refactorn übersehen. Das ist das selbe Setup, mit dem back-to-front raycasting funktioniert.

Ich render nur einen Quad auf den dann das Volumen projiziert wird.

Finnegan

So langsam gehen mir wirklich die Ideen aus

Renderst du das Quad eventuell mit aktiviertem Alpha-Blending? In diesem Fall würdest du z.B. bei voller Deckkraft (transparency=0) den Alphakanal des Voxel-Anteils des Ausgabe-Fragments ebenfalls mit 0 multiplizieren, was dann beim Rendering genau den umgekehrten Effekt wie bei deinem Raycasting hätte: Voxel-Anteile die du als voll transparent und somit schwarz bestimmt hättest würden dann mit maximaler Deckkraft einfließen während die opaken Anteile transparent wären..., das könnte evtl. den beschiebenen Effekt auslösen. Nur so eine Idee. Ich weiss nicht genau wie du das back-to-front implementiert hast, eventuell könnte sich da der Effekt eines zusätzlichen Alpha-Blendings nicht zeigen. Hast du vielleicht mal einen Screenshot zur Hand? Vielleicht wird daran deutlicher wo das Problem liegen könnte.

Finnegan

mortified_penguin

Ich hab kein Alphablending aktiviert. Hier mal ein Bild, zur besseren Sichtbarkeit hab ich beim zweitletzten Slice angefangen. Lila ist die Haut, weiß der Knochen.
http://fs2.directupload.net/images/150809/yqy79z7s.png

Finnegan

Eine kurze Info, was in dem Volumen abgebildet ist wäre noch fein gewesen :D. Ich vermute das ist ein Schädel?

Sieht tatsächlich ein wenig so aus als wäre bereits die erste current_transparency die du dir für beliebige voxel_curr aus dem opac_lut -Sampler ziehst Null. D.h. auch die leere "Luft" scheint eine Transparenz von 0 zu haben, da ich davon ausgehe dass der Schädel in Z-Richtung breiter wird und dann der nicht-schwarze Bereich eigentlich größer sein müsste.

Ich würde das mal schrittweise Debuggen und mir de Werte ansehen, die du da aus den verschiedenen Texturen rausziehst. Optimalerweise mit einem geeigneten GLSL-Debugger (kann leider keinen empfehlen) oder die klassische "print"-Methode, wobei "print" im Fall von GLSL natürlich das zurückgeben einer Farbe via return ist

Du könntest dir z.B. mal ganz simpel statt accum die erste current_transparency ausgeben, die du aus dem LUT ziehst. Die sollte ja zumindest in den Luft -Bereichen nicht 0 sein sondern eher Weiß (1).

Die anderen Werte kannst du ähnlich debuggen und so zumindest grob feststellen ob die Werte stimmen. Da dein Shader-Modell ja offenbar Branching unterstützt kannst du natürlich auch noch präziser debuggen: wenn Bedingung zutrifft, dann gib "Grün" zurück, ansonsten "Rot" ... so solltest du dem Problem stückweise auf die Schliche kommen. Ich sehe nämlich jetzt so ad hoc nur durch Code-Starren nichts auffälliges mehr, sofern die ganzen Rahmenbedingungen okay sind (Texturen korrekt, Sampler richtig konfiguriert, Sättigungsarithmetik, Berücksichtigt dass gesampelte Werte gemäss Sampler-Konfiguration interpoliert sind, sinnvolle Behandlung von Rand-Pixeln der Texturen [CLAMP, REPEAT, feste Farbe, etc.] - beachten dass Pixel außerhalb der eigentlichen Textur [ausserhalb von [0,1] \times [0,1\]] via Interpolation in einen gesampelten Randpixel "hineinbluten" können, len und step_size haben sinnvolle Werte, etc. - vieles davon sollte aber schon beim back-to-front probleme gemacht haben).

Finnegan

mortified_penguin

Was mich wundert ist, wenn ich die Schleife folgendermaßen verkleinere:

for (int i=0; i<16; ++i) {
            vec4 voxel_curr
                    = texture3D(volume
                        , vec3(coord.x, coord.y, (1.0*33)/(steps))); // random slice
            accum = voxel_curr;
   }

Also eine beliebige Schicht wähle und deren Wert an (x,y,33) in einer Schleife in die Variable accum schreibe, bekomme ich ein schwarzes Bild, wenn die Schleife öfter als 22 mal durchläuft. Eventuell ein Treiberbug?

Finnegan

mortified_penguin schrieb:

Also eine beliebige Schicht wähle und deren Wert an (x,y,33) in einer Schleife in die Variable accum schreibe, bekomme ich ein schwarzes Bild, wenn die Schleife öfter als 22 mal durchläuft. Eventuell ein Treiberbug?

Ach? Und vorher ist das Bild okay wie du es erwartest? Und steps ist auch 33 (beachten: Texturkoordinaten liegen dann ausserhalb der Textur, dann greift die Sampler-Konfiguration für die Ränder)?

Wenns nur an der Anzahl der durchläufe liegt könnte es auch kein Treiber-Bug sondern ein Treiber-Feature sein, das einen Shader-Thread abbricht, wenn er zu lange braucht - schonmal ne Endlosschleife in nem Shader programmiert? Bei meiner letzten Erfahrung damit ging gar nix mehr - schon übel wenn das System im Grafiktreiber hängt, der grad auf die GPU wartet :D.

Allerdings klingt 22 für mich noch ziemlich klein. Es gibt da Raycasting-Shader mit aufwändigeren Schleifen die ganz schicke Resultate erzielen und ordentlich laufen.

Finnegan

P.S.: Ich würde bei obiger Schleife ausserdem erwarten, dass der GLSL-Compiler die Schleife komplett wegoptimiert. Ich weiss die sind wahrscheinlich nicht ganz so pfiffig wie ein akueller C++-Compiler, aber das sollte eigentlich simpel genug sein.

mortified_penguin

Scheint in der Tat ein Treiberbug zu sein. Ich arbeite unter Linux mit nouveau; habs jetzt auf meinem Laptop mit proprietärem Treiber probiert, da scheint alles ok zu sein. Warum jetzt allerdings die Version back-to-front geht deren Schleife genauso oft durchläuft und sogar noch geschachtelt ist, versteh ich jetzt auch nicht wirklich.

Danke übrigens für die Hilfe

Finnegan

Manchmal sind es relativ simple Dinge die ein Treiber toleriert und ein anderer nicht. Hatte z.B. mal ein fehlendes Padding bei einer uniform-Datenstruktur in Direct3D11... länger nicht bemerkt, da der NVidia-Treiber das kommentarlos geschluckt hat. ATI-Treiber hat einfach nix gemacht und hat nen schwarzen Bildschirm angezeigt. GL_ARB_debug_output könnte bei OpenGL eventuell hilfreich sein Sachen zu finden, wo man sich z.B. nicht genau an die Spezifikation hält. Ansonsten ist der proprietäre Treiber die richtige Wahl wenn man GPU-Programmierung macht. Man mag von dem Laden halten was man will, deren OpenGL-Implementation ist einfach die beste die man für aktuelle GPUs finden kann ... auch wenn ein hinreichend komplexes Programm dann nicht selten auf anderen Treibern schlecht oder gar nicht läuft (liegt aber leider daran dass doch so manche OGL-Implementierungen nicht das gelbe vom Ei sind).

Finnegan