Jump to content

  • Log In with Google      Sign In   
  • Create Account


Mipmaps not used with multiplied texture coordinates

  • You cannot reply to this topic
3 replies to this topic

#1 Plerion   Members   -  Reputation: 354

Like
0Likes
Like

Posted 11 July 2014 - 07:31 AM

Hello all

 

I am currently facing an odd issue with mipmaps. The terrain im rendering has several layers of textures and they are not all scaled the same. Therefore i have created my shader like this:

cbuffer DataBuffer : register(c1)
{
	float4 texScale;
};

//.....

	float4 tex1 = texture0.Sample(texSampler, texCoord * texScale.x);
	float4 tex2 = texture1.Sample(texSampler, texCoord * texScale.y);
	float4 tex3 = texture2.Sample(texSampler, texCoord * texScale.z);
	float4 tex4 = texture3.Sample(texSampler, texCoord * texScale.w);

The problem is, that this generates extremely bad results, it almost seems like the mipmaps are not used at all, see:

b22033f676.png

 

This also holds true if the buffer containing texScale holds 4 times the value 1 (verified using 2 different frame inspectors)

 

If i change the code to this:

	float4 tex1 = texture0.Sample(texSampler, texCoord);
	float4 tex2 = texture1.Sample(texSampler, texCoord);
	float4 tex3 = texture2.Sample(texSampler, texCoord);
	float4 tex4 = texture3.Sample(texSampler, texCoord);

It looks ok:

13dba8c319.png

 

This is extremely strange especially when i see that texScale is also 1/1/1/1 and then it creates completely wrong results.

 

For the verification, see:
27f2593c85.png

 

Is there something im missing about texture sampling?

 

Thanks in advance,

Plerion


Edited by Plerion, 11 July 2014 - 07:33 AM.


Sponsor:

#2 MJP   Moderators   -  Reputation: 10243

Like
4Likes
Like

Posted 11 July 2014 - 04:19 PM

So assuming all of your shader code is correct, then there's really 3 possibilities for why it's not working correctly:

 

1. The value in the constant buffer is somehow wrong or not getting bound to your shader correctly due to a bug in your code

2. The HLSL shader compiler is producing incorrect or unintended code that doesn't use the right constant buffer value

3. There's a bug in the driver causing incorrect behavior

 

#2 and #3 are pretty easy to verify. For #2 you can just compile your shader with fxc, and look at the generated assembly code to verify that it's doing what you expect. If you're not familiar with shader assembly, you can post the result here and I can help you decipher it. For #3, you can validate the driver behavior by running your program using the reference device. Beware that it's very slow, but will always produce correct results according to the D3D spec.


Edited by MJP, 11 July 2014 - 04:19 PM.


#3 Jason Z   Crossbones+   -  Reputation: 4700

Like
2Likes
Like

Posted 11 July 2014 - 06:33 PM


Beware that it's very slow, but will always produce correct results according to the D3D spec.

Off topic: The only caveat here being that multithreaded context behavior is not easily reproduced on the reference device, so if you have bug due to multithreading the reference device won't help you!



#4 Plerion   Members   -  Reputation: 354

Like
3Likes
Like

Posted 16 July 2014 - 11:42 AM

Hello all

 

Turns out i made a little boo boo in my engine. For constant buffers i was adressing registers b0-n but in the shader i have assigned them to register c0-n. So thats why it didnt take the 1/1/1/1 from the buffer even if it was present :)

 

Greetings

Plerion







PARTNERS