Hallo Jan,
ich habe zwar leider keine Lösung für dieses seltsame Verhalten, aber
ich experimentiere selbst gerade damit, mit OpenSG in einen pbuffer zu
rendern; in meinem Fall benötige ich die ungeclampten float-Werte auf
der CPU (für weitere, nicht shader-taugliche Berechnungen). Nur bisher
bekomme ich nicht wirklich viel von meiner HDR-Umgebung zu sehen, sprich
die Werte sind entweder "garbage" oder auf [0,1] geclampt. Liegt wohl
sicherlich daran, dass mir dafür das ausreichende OpenSG-Wissen fehlt,
da Andreas Zieringer mir schonmal gemailt hatte, dass er pbuffer
erfolgreich einsetzt (jedoch LDR...).
Wie bekommst du die Originalwerte in den pbuffer gerendert, ohne dass
sie vom normalen OpenSG-Renderingprozess geclampt werden? Welche Art von
Fenster/Viewport/Background/RenderAction verwendest du dabei? Benutzt du
dazu Tools wie RenderTexture oder so? Liefert ein glReadPixels() mit
GL_FLOAT wirklich ungeclampte Werte, bzw. was gibt's für Alternativen,
um die HDR-floats "as is" auf die CPU zu bekommen. (Die geringe
Performance von glReadPixels wird durch die wenigen Daten (max. 64x64x6
Cubemap) wieder relativiert).
Fragen über Fragen...aber du kannst da sicher etwas (HDR)-Licht ins
Dunkel bringen...;)
Schonmal besten Dank für Tipps aller Art!
Viele Grüße,
Matthias
fyi: Als Plattform verwende ich Linux (SuSE 9.1) mit NV3x/NV40, sowie
OpenSG 1.4.0 und Cg 1.3...
Jan Wurster wrote:
Dear *,
This is probably only half-related to OpenSG, however I write to you
in the hope that somebody more experienced in the matter could shed
some light on it ;)
I'm using a passthrough shader to render in to a floating point
pbuffer, which sort of works fine for me. For the simplest case
(nontextured material), the shader is just a plain one-line affair:
MOV result.color, fragment.color;
This works as intended. When I write the pbuffer to disk (or render
it on screen by putting it on a GL_QUAD), geometry looks exactly like
when rendering directly to screen.
However if I use an OSG::Transform to scale the geometry in question,
standard rendering still looks the same (as one would expect). BUT
after the passthrough, the effect of lightsources seems multiplied by
the inverse scale. Scaling up makes lighting darker, scaling down
brighter. Interesting ...
My guess would be ... perhaps .. normals? But why am I experiencing
this only when using a passthrough shader?
I've also tried avoiding OpenSG's FragmentProgramChunk and binding
the shader globally before renderAllViewports - but that resulted in
the exact same output.
Any ideas? :) I could probably hack something up to connect the
object scale to the shader and fix it there - but if there's a way
around it ...
Best regards,
-.jan.-
PS: Another question - is anybody aware of something like glTrace /
spyglass for linux that actually works? :) glTrace is supposed to only
work with mesa software drivers, so is pretty much unusable - and
while spyglass looked promising, I couldn't get it to run (the perl
parser was - at least not by just quickling browsing through it - not
keen on making friends with the recent OpenGL headers).
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
