Jump to content
  • Advertisement
Sign in to follow this  
QQemka

Basic texturing

This topic is 819 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. I am following the great tutorial from lesson 1 at http://www.braynzarsoft.net/viewtutorial/q16390-11-textures

 

They forgot to show the shader file at the end (where many things changed since last tutorial).

In tutorial 12 it is shown, without any info about what changes mean - could someone explain why are there 2 new global objects? I see from code that they are used in pixel shader, but would like to know a bit more. Are only 2 sufficient to render mulstiple objects with different meshes? How do PSSetShaderResources and PSSetSamplers know that they have to set exactly those objects?

Texture2D ObjTexture;
SamplerState ObjSamplerState;

Greetz

Share this post


Link to post
Share on other sites
Advertisement

When you declare a texture in your HLSL shader code and compile it with the shader compiler, the compiler will assign the texture to a t# register. There are several register types, but the t# registers are always used for shader resource views. By default, the compiler will assign the registers sequentially based on the order in which you declared your textures. So if you TextureA, TextureB, and TextureC all declared in a row, then they'll get assigned to t0, t1, t2 respectively. You can also explicitly tell the compiler which register you'd like to use by using the "register" keyword, like this:

 

Texture2D ObjTexture : register(t0);

 

Now the reason that the registers are important is because they exactly correspond to the binding slots used for PSSetShaderResources. So if you call PSSetShaderResources with StartSlot set to 3 and NumViews set to to 2, then you will bind shader resource views to registers t3 and t4. In your case, the texture will get assigned to t0 so you can just pass 0 for StartSlot and 1 for NumViews, and then pass along a single-element array containing your shader resource view pointer. 

 

Sampler states work exactly the same way, except that they use a different set of registers and binding slots. Samplers will use registers s0 through s15, and they will correspond to the binding slots of PSSetSamplers.

 

The way that the binding slots work is that they're persistent on your device context even if you change shaders. So if you bind shader A, set 3 textures, and then draw, those same 3 textures will still be bound if you bind shader B. If you want to un-bind those textures, you need to do it by passing an array of NULL pointers to PSSetShaderResources (or by calling ID3D11DeviceContext::ClearState, which will clear all bindings for all shader stages).

 

Finally, one thing to keep in mind for advanced scenarios is that it's possible to query a shader's reflection data to find out which textures exist and which registers they were assigned to. To do that, you need to use the ID3D11ShaderReflection interface and use GetResourceBindingDesc/GetResourceBindingDescByName

Share this post


Link to post
Share on other sites

Hmm, I think i partly understood. Is it enough to have just one Texture2D and one SamplerState and use it for every texture?

Share this post


Link to post
Share on other sites

Very much depends on your use scenario. Does the texel being evaluated through your pixel shader only reference a single texture for it's computation? If your making a game that only needs simple texturing, and to have it sampled by a single SamplerState at any given shader execution, sure one Texture2D, and SamplerState should be fine.

 

As MJP stated, you'll change the texture, and sampler bindslots cpu side for different textures, and (if need be) corresponding samplers, and the bindslots will retain there textures, and samplers between draw calls, and shader swaps. 

 

The website you mentioned will eventually step you through more advanced use scenarios where for a given texel you'll evaluate it against several textures, such as, normal maps, shadow maps, and ect.

 

Marcus Hansen

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!