shadowmaps - Allgemeines und Spezielles

0x00000001

spl@t schrieb:

Bis jetzt habe ich s bzw. u und t bzw. v zum Texturzugriff, und p bzw. w als Tiefe mit der verglichen wird! Die 4. Komponente q bzw. kA-wie-das-in-DX-heißt-? ist ja irgendwie zum Scalen auch schon verwendet.
Workaround wäre also, den Lichteintrittsvektor multipliziert mit dieser komplizierten Matrix, die ich dem Shader gebe, für die Cubemap, und sonst, wie bisher, den Kameravektor multipliziert mit der Matrix zum Scalen und Vergleichen zu nutzen?

Hä was? Du berechnest im Vertexshader einfach

VertexPos - Lichtpos

und das wird dann als Texturkoordinate für die Shadowmap übergeben. Nix mit Matrix oder sonstwas.

Gefällt mir gar nicht, denn eben habe ich auf die in GLSL eingebaute Shadowtexture-read-funktion umgesattelt, die einen Vektor mit 3 Komponenten verlangt, bei dem eben die 3. Komponente der Vergleichswert ist, und die ersten beiden s und t / u und v. Ich glaube dadurch habe ich jetzt endlich meine 24 bit Präzision!
Andere, normale Textureread-funktionen darf man bei Z-Maps auch nicht benutzen! (man kann aber, so wie ich vorher, dem shader sagen, dass es keine depth-map ist, und dann die normale textur-funktion verwenden, nur das ist glaub ich der Grund für 8 bit die ich vorher anscheinend wirklich hatte und nicht ganz Standardkonform glaub ich)

Ich glaub bei diesem OpenGL Zeugs kann ich dir überhaupt nicht helfen, ich kann Dir nur mal sagen wie ich es in D3D mache.
Dort rendere ich mit einem Speziellen Shader die Shadowmap, und zwar einfach die Umgebung in die Textur reinrendern ( Textur hat das Format 16 Bit Floating Point, aber das ist eigentlich egal). Bei Punktlichtern muss ich das dann halt 6 mal in alle Richtungen machen.
Beim richtigen Rendern errechne ich im Vertexshader den Abstand (Vertex,Licht) und übergebe ihn in einem Farbregister. Im Pixelshader wird der Wert mit der Shadowmap verglichen und das wars.

Also eigentlich folgt daraus: Ich kann keine Cubemaps verwenden, sondern muss 6 Einzeltexturen benutzen. Aber wie greife ich auf DIE zu? D.h., wie entscheide ich, auf welche?

Also das kannst Du im Prinzip vergessen, weil in älteren Shadern kannst Du den Programmablauf nicht beeinflussen. Du müsstest aus allen 6 Texturen lesen.
Schau mal ob Du nicht auch in die Texturen reinrendern kannst. Müsste ja gehen weil ich mach es ja :p

Aber der Effekt ist schon einmal sehr gut, eben antialiased; aber eigentlich ist es ja gefaked, denn die Tiefe aus Cam-Sicht, mit der ich vergleiche, bleibt immer die selbe.

ja genau, und das ist auch der grund warum das mit der abnehmenden härte nicht geht. Sieht aber trotzdem ganz ordentlich aus.

Artefakte:
...

An Deinem Bild seh ich eigentlich nix falsches....als störend empfindest Du die Pixeligen übergänge oder?
Also da kann man glaub ich wie gesagt nix gegen machen, weil die Shadowmap wird ja in die Szene projeziert, und wenn die Fläche parallel zum Licht steht kann der jeweilige Texel beliebig lang gezogen werden.
Der Effekt fällt aber nicht mehr so ins Auge wenn
- Die Schatten stark gefiltert werden
- die schatten nicht schwarz werden sondern noch Licht "durchlassen"
- man keine einfarbigen Flächen verwendet sondern richtige Texturen.

Kannst übrigens mal in dem Thread von mir vorbeischauen:
http://www.c-plusplus.net/forum/viewtopic.php?t=71147

Da hat rapso so ab Seite 3 ein paar wertvolle Tips zu Shadowmaps abgelassen

spl*t

Ich glaube wir haben ein bisschen aneinander vorbei geredet.
Ich kann mir auch garnicht vorstellen, wie das mit der Cubemap ohne Matrizenmultiplikationen gehen soll. Obwohl ich das mit der Cubemap erstmal, wegen fehlendem OpenGL-Support für Depth Cube Maps, vergessen kann (meine Idee keine Cubemap sondern 6 normale depth maps zu nehmen, ist unpraktikabel: habe ich 2 Lichter macht das schon 12 zusätzliche Texturen, das wird nix), bin ich trotzdem noch daran interessiert wie das überhaupt (bei dir) gehen kann.
Ich stelle mal meine Sichtweise auf Basis des Algorithmus, den ich momentan verwende, dar, vielleicht verstehst du dann meine Verwunderung:
Im Moment rendere ich von der Lichtquelle die Tiefen in nur eine depth map texture (der z-Buffer wird in die Textur kopiert). Beim Rendern der Szene wird die eye space vertex position als Texturkoordinate für die Depthmap benutzt, aber _nicht_ einfach so ohne weiteres (!).
Dieser 4-Komponentenvektor (die 4. Komponente ist diese homogenues blabla kA was) wird nämlich mit einer Matrix multipliziert, die ihn erst in Wold Space, dann in light eye space, und schließlich in light clip space transformiert.
Hierzu ein Zitat von http://www.paulsprojects.net/tutorials/smt/smt.html

The best way to do this is to use:

T = Pl * Vl * Vc^-1

where:
T is the texture matrix
Pl is the light's projection matrix
Vl is the light's view matrix
Vc is the camera's view matrix

Der Witz ist jetzt, dass diese transformierte Vertexkoordinate automatisch als 3. Komponente den Abstand zur Lichtquelle enthält. Und nur mit diesen Transformationen bekomme ich erst die echten Texurkoordinaten für die Shadowmap.
Durch die 4. Komponente müssen die ersten 3 aber noch dividiert werden, und außerdem müssen die Komponenten von -1 - +1 auf 0 - 1 gemapped werden.
Aber dann, und ERST DANN, passts.

Und jetzt kommst du, und sagst, dass du ohne Transformationen mit dem Lichtvektor auf die Cubemap zugreifst, und das funzt? Ich bin hochgradig verwirrt!
In welchem Space ist eigentlich dieser Vektor? D.h., ich welchem Space sind Vertexpos und Lightpos bei dir? Worldspace?

Wenn das wirklich so klappen sollte, wäre ich von dieser Methode so überzeugt, dass ich doch wieder von meiner Depth Map auf ne normale float-Textur umwechseln würde, von der ich dann auch ne Cubemap nehmen könnte.
Aber dazu müsste ich in OpenGL enormen Aufwand betreiben um die 24 oder 32, naja, wenigstens 16 bit zu bekommen (offlinerendering in einen pbuffer, hab sowas noch nie gemacht...)

Hab jetzt keine Zeit mehr, was ich sonst noch alles schreiben will (zu den Artefakten und Soft Shadows) folgt nachher per Edit.

EDIT:
Die Artefakte bin ich los! War ein dummer Fehler in der Lichtberechnung, so dass die backfacing polygons (vom Licht aus) trotzdem beleuchtet wurden. Guck mal oben bei der Teekanne und dem linken Torus. Man siehts auf dem Bild schlecht, teilweise ist es schlimmer gewesen.
Wegen den Soft Shadows hab ich noch eine Idee: Man könnte 2 Shadow maps pro Lichtquelle rendern, jeweils mit anderem bias/polygon offset. Oder auch mehr. Und dann kann man im Shader aus beiden maps auslesen, da, wo nur in der shdowmap, die gerendert wurde, als die Objekte zur Lichtquelle hin verschoben wurden, Schatten festgestellt wird, wird der Schatten halb eingefärbt, und wenn in beiden Schatten festgestellt wird, ganz. Sollte sehr realistisch sein - bis auf die scharfen Übergänge. Wenn man jetzt aber wieder mehrmals in beiden maps sampled und die offsets beim Depthmaprendern klein hält, könntes gehen.
Ist vielleicht noch irgendwie erweiterungsfähig, wer weiß?

Naja, ich muss erstmal point lights zum Laufen kriegen. Deine Cubemapmethode macht tatsächlich Sinn, ist mir übrigens vorhin beim Aufzeichnen aufgefallen.
Schade dass ich keine Nvidia-Karte habe, dann hätte ich 16 Textureunits, so nur 8. 16 hätten grade gereicht (6 Seiten * 2 für soft shadows + colormap + glossmap + normalmap + heightmap)
Hätte mir dann meine eigene Cubemaplookup-Funktion geschrieben, die die 6 Depthmaps und nen Vektor verwendet hätte.
Naja, Pech.
So werde ich mir mal "dual paraboloid shadow mapping" angucken,
da braucht man als kleinen Extrabonus zusätzlich dazu dass man nur 2 Texturen für 360* Pointlights braucht, auch keinen Vektor sondern kann die transformierte Texturkoordinate benutzen, so wie ich bisher.
Ok, ein Vorteil ist letzteres nicht wirklich. Ist ja langsamer. Aber andererseits müsste ich für nen World Space-Vektor meinen kompletten bis jetzt vorhandenen Code umkrempeln

spl*t

ach man, ist doch alles schei*e. Für diese Dual Paraboloid-technik muss die Geometrie wegen Verzerrungen viel zu viele Polygone haben.
Es scheint keine Möglichkeit zu geben, in OpenGL (nicht 2.0) Shadowmapping mit Pointlights mit angemessener Prezision und ohne den riesigen Aufwand von
-pbuffers (*bäh*)
-wordlspacevektoren in ursprünglichen tangent space shadern (*bäh*)
zu implementieren.

Es ist an der Zeit, einen Bekannten (12.-Klässler) mit tollen Mathekenntnissen dazu zu bringen, was neues zu erfinden, glaube ich :xmas2:

Oder habt ihr hier noch Ideen?

0x00000001

Dual Paraboloid wollte ich auch erst machen, aber es hat eigentlich nur Nachteile gegenüber Cubemap.

Bei den Spotlights habe ich ja auch die ganzen Projektionsmatrizen verwenden müssen, das kannst Du also so lassen wenn es funktioniert.
Die Texturkoordinaten kriegt man nur für die Cubemaps so einfach, weil das Projezieren in den Level einfach "in deren Natur liegt".
Stell Dir vor, Du malst den Inhalt der Shadowmap auf einen Glaswürfel und legst das Licht nun mitten in den Würfel rein. Dann wird der ganze Würfel einfach durch die geraden Lichtstrahlen in den Raum abgebildet. Und so ein Lichtstrahl ist einfach wie gesagt der Verbindungsvektor zwischen Lichtpunkt und Vertex (einfach in Weltkoordinaten). Die Texturkoordinaten für die Cubemap sind ja Vektoren, die in den Würfel "geschossen" werden.

Aus Deinem Problem mit den Texturunits entnehme ich dass Du noch mit Shader 1.x arbeitest!? Gut, dann ist das mit dem Filtern schwieriger. In Shader 2.0 kannst Du halt mehrmals aus der selben Textur lesen ohne irgendwelche festen Texturregister zu benutzen.

Ich schreibe auch heute abend noch weiter....

spl*t

Thx ^^
Stimmt, hast recht, das mit den Cubemaps macht Sinn.
Ich arbeite mit Shader 2.0. Aber eine google-recherche hat ergeben, dass die Radeon 9800 Pro nur 8 Texturen gleichzeitig unterstützt. Wenn das nicht so ist, dann gibt es ja noch Hoffnung! Wird zwar bestimmt nicht leicht den Worldspacevektor einzubasteln, und dann ne eigene Cubemaplookupfunktion (lustiges Wort) zu schreiben, aber das mach ich doch vieeel lieber als in sonen doofen pbuffer zu rendern!
Hab übrigens mal den Shadercode etwas anders angeordnet, und bekomme jetzt mindestens 8 Zugriffe, mehr hab ich noch nicht probiert. Dummer Compiler!

0x00000001

Kann sein, dass man nur 8 (verschiedene!) Texturen benutzen kann (laut DX Doku sind es eigentlich 16). Aber das macht nix, beim Filtern der schatten liest man ja immer nur aus der gleichen Textur (shadowmap). Insgesamt kann man glaube ich 32 Texturreads machen. Kann es sein dass Du da grad was verplanst?

An Deiner Stelle würde ich das mit den 6 Texturen lieber mal vergessen. Also ich mein schonmal gelesen zu haben, dass es extensions gibt mit denen man in eine Textur rendern kann. Und wenn Du das nicht magst hättest Du immer noch die möglichkeit einfach die 6 Shadowmaps auf die Cubemap Seiten zu kopieren !?
Das wäre die beste Lösung, 6 einzelne Texturen find ich etwas abartig (und unnötig kompliziert).

eine Idee: Man könnte 2 Shadow maps pro Lichtquelle rendern, jeweils mit anderem bias/polygon offset. Oder auch mehr. Und dann kann man im Shader aus beiden maps auslesen, da, wo nur in der shdowmap, die gerendert wurde, als die Objekte zur Lichtquelle hin verschoben wurden, Schatten festgestellt wird, wird der Schatten halb eingefärbt, und wenn in beiden Schatten festgestellt wird, ganz. Sollte sehr realistisch sein - bis auf die scharfen Übergänge. Wenn man jetzt aber wieder mehrmals in beiden maps sampled und die offsets beim Depthmaprendern klein hält, könntes gehen.

Um offen zu sein, mit dem Satz komm ich nicht ganz klar
Soll das jetzt Probleme mit Artefakten lösen oder willst Du die Schatten damit weicher machen?

spl*t

Ne, mit den direkt-in-Buffer/Textur-render-extensions (wgl) will ich's garnicht erst versuchen. Dann sitz ich wieder 1 Jahr am debuggen und werde paranoid dabei. Ist glaub ich auch irgendwie unausgereift und langsam.
Deine Idee die 32-bit-Depth maps in andere Texturen reinzukopieren klingt...
nunja... hm... genial? JA! DAS IST ES! DANKE!
Nungut. Fast. Es scheint keine 32-bit-double-Textur in OGL zu geben.
Also könnte ich in eine 16-bit Textur kopieren, oder es doch mal mit einer 32-bit-depth-cubemap versuchen, die vllt. doch funzt. (es gibt keine depth cube map lookupfunktion im Shader, das sagte ich ja bereits, aber ich kann dort ja die normale lookupfunktion nehmen) In letzterem Fall wird dann aber höchstwahrscheinlich auch in 16 bit konvertiert, nur einen Schritt später. Also nehm ich lieber die erste Methode und verzichte gleich auf die 32 bit. Muss auch mit 16 gehen!
Das ist jetzt für mich persönlich als Hilfe und für eventuell existente Personen die gleiche Probleme haben:

Rendern in 6 16-bit-depth maps
Kopieren dieser in die GL_LUMINANCE16 - Cubemap
Worldspace muss her; dazu die ModelMatrix dem Shader übergeben
Mit Lichtvektor auf Cubemap zugreifen und mit Länge des Vektors vergleichen
Das schaffe ich heute auf keinen Fall mehr.
Bin gespannt obs klappt.

Die Methode des komplizierten Satzes soll die Schatten realistisch weicher machen. Wie rapso in dem von dir verlinkten Thread schreibt, soll die Entfernung den Offset beim wiederholten Samplen beeinflussen. Zusätzlich, und das hab ich mir so gedacht, könnte man aus 2 Shadowmaps samplen, wobei die 2. erstellt wurde indem die Objekte leicht vergößert wurden.
(eigentlich wollte ich nicht vergrößern sondern verschieben, in der einen map nach vorne und in der anderen nach hinten. Wie beim bias halt. aber das wird nix so richtig. Aber mit glScalef gehts ganz gut, nur dass der Schatten dann bei größeren Objekten weiter auseinandergezogen wird als bei kleinen ist doof)
Oder ist das das selbe was rapso erreicht, nur in grün? Nunja, hab beides kombiniert, und es geht wie gesagt ganz gut, solange es im Rahmen bleibt.

spl*t

Ich beginne ganz langsam, OGL zu hassen.
Das Kopieren in ne float-textur geht nämlich nur über erneutes Zeichnen der Textur auf nem Quad und dann Framebuffer-in-Textur-rendern. Da hätte ich dann wieder das Problem, dass meine Depth Map auf 8 bit reduziert wird (es sei denn ich würde die Tiefe in R, G u. B aufspalten. Dass klappt aber auch irgendwie nicht so gut)
Und Depth Cube Maps gehen tatsächlich nicht. ARGH!

(5) What about 1D, 3D and cube maps textures? Should depth textures be supported?

RESOLVED: For 1D textures, yes, for orthogonality. For 3D and cube map
textures, no. In both cases, the R coordinate that would be ordinarily
be used for a shadow comparison is needed for texture lookup and won't
contain a useful value. In theory, the shadow functionality could be
extended to provide useful behavior for such targets, but this
enhancement is left to a future extension.

So ein Schwachfug. Sagt ja keiner dass ich die shadowlookup-funktionen nutzen will. Wurde von einem im OpenGLforum richtig erkannt:

Which is really kind of stupid, since the R coord stuff should be a part of the shadow extension, not the texture extension. Since the depth texture extension itself doesn't do the actual compare.
->

AFAIK that is not possible. GL_DEPTH_COMPONENT can only be used for 2D textures, because it uses the r-texture-coordinate for some comparison-stuff, which makes it impossible to use it with cubemaps (which need the r-component for texture-accesses).

Someone told me, the solution would be to use float-textures (cubemaps) and do the depth-comparison manually in a fragment program. However this is still a pain in the butt, since for rendering to float textures you need to use pbuffers, etc.

That´s the reason, why i didn´t do that yet, still waiting for the EXT_render_target extension to make my life easier.

Jan.

Jaja...
8-bit, ich komme!

0x00000001

Also mit 16 Bit float Buffer meine ich nicht einen z-Buffer, sondern das ist allgemein ein Format das nur einen Rot-Kanal mit 16 Bit breite hat.

Bei DX so definiert:

#define D3DFMT_R16F 111 // 16-bit float format using 16 bits for the red channel.

Vielleicht kannst Du die "111" ja irgendwo eingeben?
Ansonsten kann Ich dir da garnicht helfen, hab in OGL noch nichtmal ein einziges Dreieck anzeigen lassen. Aber ich dachte hier im Forum gibts so viele OGLer, wissen die nix?

Die Methode des komplizierten Satzes soll die Schatten realistisch weicher machen. Wie rapso in dem von dir verlinkten Thread schreibt, soll die Entfernung den Offset beim wiederholten Samplen beeinflussen. Zusätzlich, und das hab ich mir so gedacht, könnte man aus 2 Shadowmaps samplen, wobei die 2. erstellt wurde indem die Objekte leicht vergößert wurden.

Ich meine zu ahnen was Du vor hast, ich hatte so eine ähnliche Idee. Ich habe es ausprobiert und es hat nicht funktioniert was auch einen logischen Grund hatte der mir jetzt aber nicht mehr einfällt.
Wenn Du aber was hinkriegst, lass es mich wissen.

spl*t

Ok. 2 Probleme:

wie berechnest du die Distanz zur Lichtquelle im vertex shader? Einfach Länge des Lichtvektors geht ja schlecht, ich brauch ja ne Zahl zw. 0 und 1.
Der Schatten ist verschoben. Ne Idee woran das liegen könnte? Naja, bestimmt nicht, kann ja überall was falsch sein in meinem application code...
(Hab das rausgefunden indem ich |Lichtvektor| mal mit 0.01 multiplizert habe. Der Schatten ist dann aber immer nur in einer Ebene des Bildes)+

EDIT:
Huch! Hatte deine Antwort garnicht gesehen sondern erst jetzt! Hab leider keine Zeit mehr; morgen bin ich auch nicht da. Nur soviel: war endlich schlau genug, nicht die z-Buffer-Tiefe in die Map zu schreiben, und dann im Schattenshader nichts vergleichbares berechnen zu können, sondern die quadratische Entfernung zur Lichtquelle (ich mach dies so, nirgendwoanders so gesehen: Vertexkoordinate in eyespace transformieren, dazu ist keine Matrix oder Position von außen nötig) davon das dot-product mit sich selbst ist bereits der quadratische Abstand zur Lichtquelle; das wird dann durch ne Konstante geteilt damits zwischen 0 und 1 liegt (Lichtradius²) und in die Textur gerendert.
Im Schattenshader kann dann doch die Länge des Lichtvektors (ins quadrat) benutzt werden. Leider sind jetzt Artefakte auf den Flächen da, trotz Frontfaceculling. Stimmt vllt. doch was nicht mit dieser Methode oder leigt das an den 8 bit? Naja, keine Zeit mehr jetzt, auf deinen Post kann ich auch nich mehr eingehen, bis übermorgen, und Frohe Weihnachten :xmas1: :xmas2:

0x00000001

spl@t schrieb:

Vertexkoordinate in eyespace transformieren, dazu ist keine Matrix oder Position von außen nötig) davon das dot-product mit sich selbst ist bereits der quadratische Abstand zur Lichtquelle;

Das ist doch der Abstand (Vertex,Kamera) und nicht (Vertex,Licht). Aber wenns aufm Bildschirm am Ende richtig aussieht, egal :p

Wenn Du den Abstand immer im Quadrat abspeicherst geht Dir halt auch etwas Präzision verloren, da d² eben nicht mehr linear ist und somit die Werte nicht mehr gleichverteilt. Vielleicht kommen da ein paar Artefakte her.

spl*t

Der Schatten ist jetzt teilweise richtig und teilweise falsch. Auf der Wand hinten gibts nen schönen Schatten von der Teekanne, aber die Teekanne wirft falsche Schatten auf sich selbst (aber richtige auf die anderen Objekte). Der Tiefenwert wird auf die 4 Farbwerte aufgeteilt (floats, die dann in unsigned byte kovertiert werden und in der Textur wieder als floats, also max 2 Nachkommastellen pro Farbkomponente hab ich mir gedacht); ist das so richtig?

//im Shader der zum Cubemaprendern genutzt wird
// d = Tiefe
gl_FragColor = vec4(
floor(d*100.0)*0.01,
fract(floor(d*10000.0)*0.01),  
fract(floor(d*1000000.0)*0.01),  
fract(floor(d*100000000.0)*0.01)
);

//im Hauptshader
float d  = col.r + col.g * 0.01 + col.b * 0.0001 + col.a * 0.000001;

(fract gibt den Nachkommateil zurück, floor rundet auf ganze Zahlen ab)

Soweit ich nämlich den Assemblercode richtig interpretiere, macht "Humus" das in seiner Demo "Shadows that rock" irgendwie mit 2er anstatt 10er-Potenzen, sehe aber den Sinn nicht

Achso, im ersteren Shader ist doch der Abstand zur Kamera gleichzeitig der Abstand zum Licht, weil die Kamera das Licht ist, oder? Die Aussage bezog sich nämlich auf den Vorgang die Tiefen in die Farb-Textur zu rendern.

0x00000001

spl@t schrieb:

Achso, im ersteren Shader ist doch der Abstand zur Kamera gleichzeitig der Abstand zum Licht, weil die Kamera das Licht ist, oder? Die Aussage bezog sich nämlich auf den Vorgang die Tiefen in die Farb-Textur zu rendern.

Stimmt natürlich, ich war in Gedanken beim Hauptshader.

Bist Du Dir denn sicher dass Du die Tiefen so komisch codieren musst?
Das bedeutet so ja, dass Du bei jedem zugriff auf die Shadowmap 3 Multiplikationen und 3 Additionen hast. Ist doch krank!?

Ich sollte jetzt eigentlich aufhören zu schreiben, wahrscheinlich verzapfe ich eh nur Müll wenn's um Open GL geht
Hallo an alle die OGL können, wieso sagt niemand was?

So wie ich das jetzt verstanden habe liegt das Problem darin, dass Du nur in den Backbuffer rendern kannst der ja RGBA ist.
Tja ich weiß nicht, wenn das so ist würd ich mir vielleicht doch mal überlegen ob es nicht geschickter wär direkt in die Textur zu rendern.

PS: Die 2er Potenzen sind genauer darstellbar als die 10er (zumindest auf unseren Binärrechnern)

spl*t

0x00000001 schrieb:

Ich sollte jetzt eigentlich aufhören zu schreiben, wahrscheinlich verzapfe ich eh nur Müll wenn's um Open GL geht
Hallo an alle die OGL können, wieso sagt niemand was?

Du hast mir bis jetzt sehr geholfen! Danke dafür! Jetzt bin ich aber tatsächlich mehr auf mich alleine gestellt, wo das Theoretische eigentlich geklärt ist. Diese Artefakte die ich noch hatte, kann ich nämlich nur auf der Teekanne beobachten, alles andere (Cube, Sphere und Torus gibts noch als fertiges Objekt) (sind aber keine self-shadowing-objekte [nagut, der Torus schon, und der wirft auch prima Schatten auf sich selbst (soweit ich das erkennen kann)], vielleicht lags irgendwie daran, wird sich dann zeigen wenn ichs in meinen Wrapper einbaue und mit komplizierteren Objekten probiere(ich mag Klammern irgendwie (ich sollte mir mal LISP angucken ))) scheint zu funzen.
Und warum kein Anderer was sagt, würde mich auch mal interessieren

0x00000001 schrieb:

So wie ich das jetzt verstanden habe liegt das Problem darin, dass Du nur in den Backbuffer rendern kannst der ja RGBA ist.
Tja ich weiß nicht, wenn das so ist würd ich mir vielleicht doch mal überlegen ob es nicht geschickter wär direkt in die Textur zu rendern.

Die Extension EXT_render_target wird noch nicht unterstützt. Ich könnte höchstens in sonen 32-bit-pro-Farbkomponente-pbuffer rendern, was aber einmal langsam und zum anderen umständlich ist. Also warte ich lieber und lass es erstmal so.

0x00000001 schrieb:

PS: Die 2er Potenzen sind genauer darstellbar als die 10er (zumindest auf unseren Binärrechnern)

Ja? Wäre das besser als mein Code mit den 10er-Potenzen? Wie würde das (der Code) dann genau aussehen?
Naja, solange es da nicht irgendwie schneller wird, reicht auch die jetzige Variante locker: Die Präzision ist noch auf eine Entfernung von 300 Einheiten ausreichend, die Auflösung ist aber bei 6 * 1024² schon bei 50 Einheiten Abstand zur Lichtquelle extrem grob.

Jetzt muss ich "nur noch" mit den Filtermethoden rumspielen und dann alles in meinen Wrapper einbauen. Cya in 1ner Woche oder so^^