Hi Lucca,
ok, if you think that this is not correct, what do you understand under correct
scene luminance value then?
I've corrected the luminance computation back to the previous one, without
claming the log values. You are right, the final exponentiation should bring
them to the right
Hi all,
Oh, just that you note this, I have moved 0.4.1 to 0.4.2-rc1, to better reflect
current version state.
Lucca:
the syntax is exactly the same as on usual texture2D call. So
texture2DLod(sampler, coordinate [,lod]). So in both shaders luminance_adapted
and luminance_mipmap, just
art wrote:
the syntax is exactly the same as on usual texture2D call. So
texture2DLod(sampler, coordinate [,lod]). So in both shaders
luminance_adapted and luminance_mipmap, just change the texture2D calls to
texture2DLod where mipmap level is accessed.
Hi Art,
Just retried the
Hi Luca, Allen, Josselin,
ok, I found the bug. as I said the bug is not really a bug it is more or less
slightly unclear definition of glsl. The problem was to use texture2D method
instead of texture2DLod to get value from mipmaps. Actually in the definition
of glsl texture2DLod is mean to be
Hi,
cool, I'll give it a try as soon as I can.
Out of curiosity, can you post here the syntax of the call to texture2DLod you
used? I'm on 0.4 for now and I'd like to test on it, later I'll switch to the
trunk.
Thanks!
Luca
--
Read this topic online here:
Dear Art, Luca, Allen,
This is really great news for me to hear that the problem is gone :)
Now my tone mapping should be faster and more accurate.
Thank you Art!
Josselin.
This message was sent using IMP, the Internet Messaging
art wrote:
Lucca, could you please try to change the texture2D () operations in the
shaders which access last mipmap level (i.e. level 100) to an texture2DLod
function. This might help.
Hi Art,
No luck... just tried it and it does not help. Actually the lod function does
not produce
Hi Luca,
ok, I will then try to investigate what is going wrong there. One have first to
check if there is at least some data in the mipmap structure. For this purpose
glslDevil is a good debugger, which I have used several times to test opengl
applications. If there is a data there, then one
Hi Locca, Josselin,
as Lucca said, from the algorithm point of view the computation is correct.
However, it might be that there is a problem accessing last mipmap level of the
texture.
Lucca, could you please try to change the texture2D () operations in the
shaders which access last mipmap
Hi all,
I have been playing a bit with osgPPU, and I have a couple of questions/issues.
Note that I am on the last stable reelase, that is 0.4, so I don't know if
there are more recent changes in the trunk that might fix these things.
The main problem I have is with the HDR example, which I
Hi Luca,
I'm working with the average value, I've found some problems, just
like you. For me the two problems are :
- for each new mipmap level, where you have to perform the mean of the
four pixels of the previous level, the mipmap_shader use values of the
first mipmap level of the
Hi guys,
I, myself, have been working with the blur effect in the hdr example as well as
the glow example. I have not encountered issues with the hdr example except
that it crashes for unknown reasons for me while running it.
This info is good to know if ever I must implement the average
josselin wrote:
Hi Luca,
The way I found is :
1. compute the log10 values of the entire texture in a first shader
2. then perform the mipmap with:
osgPPU::UnitInMipmapOut* sceneLuminance = new osgPPU::UnitInMipmapOut();
sceneLuminance-setName(ComputeSceneLuminance);
{
13 matches
Mail list logo