Sign in to follow this  
pulo

Texure mapping goes wrong. Why?

Recommended Posts

Hey there,

 

i am currently trying to render a model and "attach" a texture to it.

The model is based on a .obj file which i am converting to a binary file for faster loading times (my code is nearly the same as this one: http://www.getcodesamples.com/src/B364EC3C/690BAF9B).

 

Now rendering the model works quite nice. 

Texture mapping seems to be a problem though. By looking at my rendering it seems like the texture coordinates are wrong, but the obj2vbo.cpp file was provided by microsoft in a sample code, so i would rather look a my own code first.

 

This is how i load the binary file:

void createMeshData(_In_ byte* meshData, _Out_ VertexBuffer** vertexBuffer, _Out_ IndexBuffer** indexBuffer, _Out_ uint32* vertexCount, _Out_ uint32* indexCount){
    *vertexCount = *reinterpret_cast<uint32*>(meshData);
    *indexCount = *reinterpret_cast<uint32*>(meshData + sizeof(uint32));
    BasicVertex* vertices = reinterpret_cast<BasicVertex*>(meshData + sizeof(uint32)* 2);
    *vertexBuffer = this->m_renderer->createVertexBuffer(vertices, sizeof(BasicVertex) * (*vertexCount), false);
    unsigned short* indices = reinterpret_cast<unsigned short*>(meshData + sizeof(uint32)* 2 + sizeof (BasicVertex)* (*vertexCount));
    *indexBuffer = this->m_renderer->createIndexBuffer(indices, sizeof(unsigned short)* (*indexCount), false);
}

By debugging the Shader i found that my samplerState and my TextureResource bound to the shader should be correct.

My sampler description looks like this:

 

D3D11_SAMPLER_DESC samplerDesc;
samplerDesc.Filter = D3D11_FILTER_MIN_MAG_MIP_LINEAR;
samplerDesc.AddressU = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressV = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressW = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.MipLODBias = 0.0f;
samplerDesc.MaxAnisotropy = 1;
samplerDesc.ComparisonFunc = D3D11_COMPARISON_ALWAYS;
samplerDesc.BorderColor[0] = 0.0f; samplerDesc.BorderColor[1] = 0.0f; samplerDesc.BorderColor[2] = 0.0f; samplerDesc.BorderColor[3] = 0.0f;
samplerDesc.MinLOD = 0;
samplerDesc.MaxLOD = D3D11_FLOAT32_MAX;

While this is my PixelShader:

 

Texture2D objTexture;
SamplerState samplerState;


struct PixelInput
{
    float4 position : SV_POSITION;
    float2 tex: TEXCOORD0;
};


float4 main(PixelInput input) : SV_TARGET
{
    float4 textureColor;


    textureColor = objTexture.Sample(samplerState, input.tex);


    return textureColor;
}

Do you see something obvious wrong? If not then let me know and i take another look at my conversion code or post it here aswell if i see nothing wrong with it.

Thanks in advance!

 

EDIT: Here is a picture of how it looks at the moment:

ddWOnu4.jpg

Edited by pulo

Share this post


Link to post
Share on other sites

A basic method for debugging is to "follow the data."

 

Have you examined the imported vertex data? Are the texture coordinates correct? IIRC, obj files are ASCII and can be examined in an editor (Notepad, Visual Studio, etc.). Compare what you're importing with what should be imported.

 

If the vertex data is correct, are you creating the vertex buffer correctly?

 

You can skip around a bit, but at points in your code you think may be incorrect, examine the data itself and determine if it's correct. If so, examine the output data from that line or function. You will eventually find some line of code where the input data is correct, but the output from that line or function is incorrect. The problem lives obviously there.

 

Rather than guessing what may be incorrect, determine what is incorrect.

Share this post


Link to post
Share on other sites

One thing you can check very easily is UV wrapping.

 

First open up the OBJ file in a text editor and find the UV coordinates.

 

Just scroll through them and get an idea of the range. Are any UV values less than 0 or greater than 1 ?

 

If so make sure you are wrapping your texture reads. Remember there could be two modes, wrap and mirror.

 

If not you can stop worrying about UV coordinates and focus on something else.

 

Next check your index buffers, I have seen exporters with bugs in them (actually I have more exporters WITH bugs than I have exporters WITHOUT bugs unsure.png )

 

Can you see vertex 0 and UV coord 0 being used in the index data?  

 

If not I would immediately try subtracting 1 from all indices.

 

After that it is time to start sticking breakpoints in your code and checking things by hand.

Share this post


Link to post
Share on other sites

Alright. I found the problem:

 

I had to invert the "v" coordinate of the texture coordinates (v = 1-v).

Is there a way to detect if my texture coordinate need inversion or do need to specify this before conversion (or alternatively export my mesh for a left handed coordinate system)?

 

Thanks for any suggestion!

Share this post


Link to post
Share on other sites


Is there a way to detect if my texture coordinate need inversion or do need to specify this before conversion (or alternatively export my mesh for a left handed coordinate system)?

 

Unfortunately, there's no way to definitively detect whether model data was generated right-handed or left-handed. Several options (none are really good): use only right- or left-handed models for your app.

 

You can also create another file with the same title but with, e.g., "txt" extension. The file needn't contain anything. Use it as a flag - try to open the file; if it exists, it's a left-handed model. If the open call fails (i.e., the file doesn't exist), it's right-handed.

 

Otherwise, you'll have to hardcode information somewhere.

Share this post


Link to post
Share on other sites

Alright. I found the problem:

 

I had to invert the "v" coordinate of the texture coordinates (v = 1-v).

Is there a way to detect if my texture coordinate need inversion or do need to specify this before conversion (or alternatively export my mesh for a left handed coordinate system)?

 

Thanks for any suggestion!

 

It's not uncommon for the 3D package (Maya or whatever) to place the texel origin at the lower-left corner so this is just something you have to deal with.

 

If you manage this conversion of data offline, as part of your build process, you'll have an easier time. Give your importer/converter options to flip the texcoord and rotate around the axes, as this is also sometimes necessary.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this