GLSL Floating-Point-Texturen

[Matti]

Hi,

afaik sind Texturen die einzige Möglichkeit größere Daten-Mengen vom Haupt-Programm zum Shader zu transportieren. Also ich will ein Vector-Array in den Shader bekommen und dafür wollte ich eine 1D-Textur verwenden:

glTexImage1D(GL_TEXTURE_1D, 0, 3, size, 0, GL_RGB, GL_FLOAT, data);

Mein Problem: alle Elemente werden auf 0..1 geclamped. In meiner veralteten OpenGL-Hilfe habe ich auch die Ursache gefunden: beim Typ GL_RGB werden die Werte immer geclamped. Allerdings habe ich keinen Typ gefunden, wo es nicht geclamped wird. Gibt es inzwischen vielleicht Typen, die nicht geclamped werden?

[Coda]

ARB_texture_float

[Chris Lux]

Matti[/POST]']glTexImage1D(GL_TEXTURE_1D, 0, 3, size, 0, GL_RGB, GL_FLOAT, data);
das was coda sagt... und dann wird aus deinem:

glTexImage1D(GL_TEXTURE_1D, 0, GL_RGB32F_ARB, size, 0, GL_RGB, GL_FLOAT, data);

so wie du es hattest, werden die daten intern in byte daten umgewandelt.

edit: wichtig noch dazu... heutzutage sind gibt es noch limitierungen bei der floating point texture unterstützung. bei ati kann man keine texture fileter nutzen und bei nvidia nicht bei den 32bit varianten, die 16bit varianten funktionieren hingegen mit allen features. das soll bedeuten, dass wenn das rendering auf einmal sehr langsam wird kann es sein, dass es in software ohne hardwareunterstützung geschieht ;)

[Matti]

Danke für eure Hilfe. Zum Ausprobieren komme ich aber erst am Wochenende wenn ich wieder zu Hause bin, momentan sitze ich an nem Laptop mit shared Memory S3 Grafik.

bei ati kann man keine texture fileter nutzen und bei nvidia nicht bei den 32bit varianten, die 16bit varianten funktionieren hingegen mit allen features. das soll bedeuten, dass wenn das rendering auf einmal sehr langsam wird kann es sein, dass es in software ohne hardwareunterstützung geschieht ;)
Danke für den Hinweis. Da ich aber keine Bilder in der Textur speichern will, sondern die Textur nur als Float-Array "mißbrauchen" will, habe ich den Filter sowieso auf GL_NEAREST gesetzt.

[Rumbah]

Auf Ati Karten ist es übrigens RGB_FLOAT32_ATI aus ATI_texture_float, zumindest meine Karte (X1600) unterstützt ARB_texture_float nicht.

[Coda]

Ist auch logisch, weil sie damit kein Mipmapping bzw. Filtering kann

[Expandable]

Ist auch logisch, weil sie damit kein Mipmapping bzw. Filtering kann

Deswegen könnte man ja trotzdem erwartet, dass ATi auch die ARB-Extension unterstützt. Wäre u.U. durchaus sinnvoll.

[tokugawa]

Danke für den Hinweis. Da ich aber keine Bilder in der Textur speichern will, sondern die Textur nur als Float-Array "mißbrauchen" will, habe ich den Filter sowieso auf GL_NEAREST gesetzt.

Je nach Daten könnte man den Filter allerdings als nette Interpolationsmethode benutzen (falls die Daten interpolierbar sein sollen).

[Chris Lux]

Deswegen könnte man ja trotzdem erwartet, dass ATi auch die ARB-Extension unterstützt. Wäre u.U. durchaus sinnvoll.
das ist bei ATi immer so eine sache mit den opengl treibern. sie werden ausgegeben als opengl 2.0 compliant, was voraussetzt, dass texture_non_power_of_two funktioniert. letztens habe ich doch versucht eine 3d textur mit npot ausmaßen anzulegen. dies wurde promt mir einem (tata) BSOD gewürdigt. und dies reproduzierbar.

[tokugawa]

das ist bei ATi immer so eine sache mit den opengl treibern. sie werden ausgegeben als opengl 2.0 compliant, was voraussetzt, dass texture_non_power_of_two funktioniert. letztens habe ich doch versucht eine 3d textur mit npot ausmaßen anzulegen. dies wurde promt mir einem (tata) BSOD gewürdigt. und dies reproduzierbar.

Sowas kommt auch unter DirectX vor... einfache Reboots über einen DrawPrimitive-Call mit einem Primitive-Count von 0 (der zugegebenermaßen keinen Sinn macht, aber auf NVIDIA krieg ich da wenigstens einen Fehlerwert zurück, und keinen System-Reboot) sind da keine Seltenheit...

Sehr robust scheinen die Treiberprogrammierer nicht zu programmieren...