Page 1 of 1
[2.2] Problem with colors on 3D textures
Posted: Fri Mar 22, 2019 11:07 pm
by xrgo
Hello! I have some workspace that renders in to a texture a normal map, it uses a shader that samples an input normal map texture and renders to a quad. (I do some other fancy stuffs but for now everything is commented)
The problem is that I need the input texture to be a 3D texture and it looks dark
If I use the same texture saved as 2D dds it looks good:
Code: Select all
uniform sampler2D brushSampler;
void main()
{
vec4 brush = texture( brushSampler, vec2( inPs.uv0 ) );
outColour.xyz = brush.xyz;
}
but if I save it as Volume (3D) dds (even with a depth of 1) it looks dark
Code: Select all
uniform sampler3D brushSampler;
void main()
{
vec4 brush = texture( brushSampler, vec3( inPs.uv0 , 0 ) );
outColour.xyz = brush.xyz;
}
I tried many many configurations of srgb, pow(brush, 2.2), pow(brush, 1/2.2) and it looks darker or too light, never the right color.
I know the 3D texture is ok because I used it in Ogre 2.1 many times, seems like a bug on Ogre 2.2 to me.
thanks in advance!
Re: [2.2] Problem with colors on 3D textures
Posted: Sat Mar 23, 2019 3:18 pm
by dark_sylinc
We don't really do anything (or can...) that could make a 3D texture darker... or brighter.
The only thing that gets close is sRGB vs non-sRGB formats.
Two possible theories:
- you're using mipmaps + trilinear filtering, and the mip levels are black; thus the GPU will average your samples against black, thus darkening
- Same, but instead of mipmaps and trilinear filtering, you're sampling w/ bilinear filtering or better in the middle between two 3D slices, thus averaging slice 0 (correct) and slice 1 (black)
Re: [2.2] Problem with colors on 3D textures
Posted: Sat Mar 23, 2019 4:07 pm
by xrgo
thanks, I am going to check that (on monday)... the file is generated with mipmaps but I had a similar problem before:
viewtopic.php?f=25&t=94748&start=50#p544023
Re: [2.2] Problem with colors on 3D textures
Posted: Mon Mar 25, 2019 4:42 pm
by xrgo
Ok, I tried with Ogre::TextureFilter::TypeGenerateHwMipmaps and its the same
as I said before, when I save the texture as 2D and load with Ogre::TextureFlags::PrefersLoadingFromFileAsSRGB it looks fine (the below one is the reference)
when I save the texture as 3D and load with Ogre::TextureFlags::PrefersLoadingFromFileAsSRGB
this is what I get:
if I put outColour.xyz = pow( brush.xyz, vec3(2.2) );
and with outColour.xyz = pow( brush.xyz, vec3(1/2.2) );
if I load without Ogre::TextureFlags::PrefersLoadingFromFileAsSRGB:
and with outColour.xyz = pow( brush.xyz, vec3(2.2) );
and with outColour.xyz = pow( brush.xyz, vec3(1/2.2) );
now the big clue:
If I open a screenshot with photoshop and set exposure as +1 it looks good!
it really seem to be a gamma problem, but I cant find the right option/combination
Re: [2.2] Problem with colors on 3D textures
Posted: Mon Mar 25, 2019 4:55 pm
by xrgo
ok, multipling by 2 in the shader fixes the problem outColour.xyz = brush.xyz*2;
but why? feels like a bug
Re: [2.2] Problem with colors on 3D textures
Posted: Mon Mar 25, 2019 6:38 pm
by dark_sylinc
xrgo wrote: ↑Mon Mar 25, 2019 4:42 pmOk, I tried with Ogre::TextureFilter::TypeGenerateHwMipmaps and its the same
That does not guarantee mipmaps are generated; because either the API can, or a simple bug on our end. Check in RenderDoc the mips are indeed not black.
ok, multipling by 2 in the shader fixes the problem outColour.xyz = brush.xyz*2;
but why?
That just further fuels the theory it's a mip (or slice) interpolation problem, because (colour + black) / 2 * 2 = colour;
Re: [2.2] Problem with colors on 3D textures
Posted: Mon Mar 25, 2019 7:15 pm
by xrgo
I checked in renderDoc and the mipmaps are there and they are not black
so I checked if its a slice problem and indeed!! thanks!
I had this in my material file:
Code: Select all
texture_unit
{
filtering bilinear
tex_address_mode border
tex_border_colour 0 0 0 0
}
I need it to be border so it wont tile, but I just need u and v nontiling so...
Code: Select all
tex_address_mode border border clamp
did the trick
now I understand the behavior... why it was working with 2.1 thought? xD
thanks again!!!