Render to Cubemap

[Corrail]

Ich weiß, dass es das ganze derzeit nur in WGF bzw. in der Theorie gibt habe aber trotzdem ein paar Fragen zu dem Thema:

Ist das mit derzeitige Hardware möglich?
Kann man das im Treiber simmulieren (wie Vertex Shader)?
Sind MRT bzw. floating point rendering targets möglich (auf derzeitiger hardware)?
[EDIT] Wie funkioniert das?
Wann wird es kommen... ? ;)

[Coda]

Du must halt 6 verschiedene Perspektiven rendern. Eine andere Möglichkeit kenne ich zumindest nicht.

[Corrail]

Das ist schon klar, aber das ganze soll in Zukunft auch in einem Pass möglich sein, nicht in 6.

[Asmodeus]

Angenommen, man hätte 6 MRT zur Verfügung (bei NV40 sind es nur 4, oder?)
Um die Sache in einem Pass zu bewerkstelligen müsstest Du alle 6 Perspektiven gleichzeitig darstellen. Diese Ansicht renderst Du nun in alle 6 MRTs. Um nun auf jeder der so entstehenden 6 Texturen aber nur den ensprechenden Ausschnitt zu haben müsstest Du die Sache eben über die Texturkoordinaten noch "zurecht mappen". Dadurch würde natürlich ne Menge Texturauflösung verloren gehen. Aber es wäre jedenfalls in einem Pass möglich.

EDIT: mehrere Ansichten gleichzeitig rendern sollte ja mit glScissor() und GL_SCISSOR_TEST ohne weiteres möglich sein.

Gruss, Carsten.

[Corrail]

(bei NV40 sind es nur 4, oder?)

AFAIK ja

Um die Sache in einem Pass zu bewerkstelligen müsstest Du alle 6 Perspektiven gleichzeitig darstellen. Diese Ansicht renderst Du nun in alle 6 MRTs. Um nun auf jeder der so entstehenden 6 Texturen aber nur den ensprechenden Ausschnitt zu haben müsstest Du die Sache eben über die Texturkoordinaten noch "zurecht mappen". Dadurch würde natürlich ne Menge Texturauflösung verloren gehen. Aber es wäre jedenfalls in einem Pass möglich.

EDIT: mehrere Ansichten gleichzeitig rendern sollte ja mit glScissor() und GL_SCISSOR_TEST ohne weiteres möglich sein.

Gruss, Carsten.

Wie willst du du eine ganz 360° Umgebung rendern? Mit allem was über 180° geht bekommst du schon Probleme oder seh ich da was falsch?

[Asmodeus]

Wie willst du du eine ganz 360° Umgebung rendern? Mit allem was über 180° geht bekommst du schon Probleme oder seh ich da was falsch?

Ich hoffe, dass ich mich jetzt nicht täusche, aber für jeden Scissor setzt man doch z.B. mit gluLookAt() die Betrachterposition eh neu, unabhängig vom Betrachtungswinkel.

EDIT: Sorry, ist trotzdem Schwachsinn, da das Darstellen jeder Scissorbox ja quasi einem einzelnen Pass entspricht, somit sind es ja wieder 6.

Gruss, Carsten.

[Corrail]

Ja, das stimmt schon. Nur dann brauchst du wieder 6 Passes und nicht einen. ;)

[Asmodeus]

Die Frage ist vielleicht eher, ob die Sache mit MRTs überhaupt zu lösen wäre.
Nach meinem Verständnis haben wir doch damit nur eine 1 zu n Verbindung, eine Szenenansicht zu n Rendertargets. Um das Problem in einem Pass zu lösen bräuchten wir aber vielleicht eher eine n zu m Verbindung, also Beispielsweise 6 Szenenansichten die auf 6 Rendertargets abgebildet werden.
Natürlich wäre fraglich, ob die Sache dann nicht eh genauso schnell (genauso langsam) wie ein 6 Passverfahren wäre.

Gruss, Carsten.

[Corrail]

Also ich bezweifle, dass das mit MRTs zu lösen wäre. In MRTs werden zwar immer andere Daten gespeichert, aber es werden immer die gleichen Primitives gerendert. Meiner Meinung nach müsste man da schon vorher eingreifen, und zwar beim Rasterizer.

[Xmas]

Ich weiß, dass es das ganze derzeit nur in WGF bzw. in der Theorie gibt habe aber trotzdem ein paar Fragen zu dem Thema:

Ist das mit derzeitige Hardware möglich?
Kann man das im Treiber simmulieren (wie Vertex Shader)?
Sind MRT bzw. floating point rendering targets möglich (auf derzeitiger hardware)?
[EDIT] Wie funkioniert das?
Wann wird es kommen... ? ;)
Auf derzeitiger Hardware ist es nicht möglich, bzw. man müsste es genau so emulieren wie man es heute macht, sprich man rendert nacheinander 6 verschiedene Ansichten.

Auf kommender Hardware könnte es so funktionieren:
Man transformiert die Vertexkoordinaten in den Eye-Space (man könnte auch Cube-Space sagen).
Statt der normalen Perspektivprojektion berechnet man nun sechs Koordinatensets für jeden Eckpunkt:
(x/z, y/z, P-z*Q)
(-x/z, -y/z, P+z*Q)
(y/x, z/x, P-x*Q)
(-y/x, -z/x, P+x*Q)
(z/y, x/y, P-y*Q)
(-z/y, -x/y, P+y*Q)
mit
P = Near / (Far - Near)
Q = 1 / (Far - Near)
als vorberechnete Konstanten, um den Tiefenwert auf 0..1 zu skalieren.

Das sind optimiert 3* (1 Division, 3 Multiplikationen, 2 Negationen, 1 Addition, 1 Subtraktion) pro Eckpunkt. Das muss nicht mal besonders schnell sein, nur gerade so dass es bei einem simplen VS nicht der Flaschenhals ist.

Nun rendert die Hardware jedes Dreieck prinzipiell sechsmal, und verwendet dabei von jedem Eckpunkt für die n-te Cube-Fläche das n-te Koordinatenset. Die meisten Dreiecke können dabei trivial verworfen werden, was entsprechend schnell sein sollte. Der Normalfall ist ja, dass ein Dreieck nur auf einer Seitenfläche zu sehen ist, theoretisches Maximum sind 5 Seitenflächen.

Dabei wäre es interessant zu wissen, ob man hier lieber x Dreiecke puffert und diese dann alle in einem Rutsch auf Würfelfläche 1, 2, 3, etc. rendert, oder ob man sowieso im Schnitt von Lokalität ausgehen kann (alle Dreiecke eines Objekts auf einer Seite).