• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
pulo

Texure mapping goes wrong. Why?

5 posts in this topic

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
0

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.

1

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.

2

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!

1

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.

0

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.

0

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  
Followers 0