Jump to content
  • Advertisement
Sign in to follow this  
Plerion

Mipmaps not used with multiplied texture coordinates

This topic is 1556 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:

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

Share this post


Link to post
Share on other sites
Advertisement

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

 

Greetings

Plerion

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!