Advertisement Jump to content
Sign in to follow this  

Mipmaps not used with multiplied texture coordinates

This topic is 1645 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:



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:



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:


Is there something im missing about texture sampling?


Thanks in advance,


Edited by Plerion

Share this post

Link to post
Share on other sites

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

Share this post

Link to post
Share on other sites

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!

Share this post

Link to post
Share on other sites

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 :)




Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!