3

I'm writing a small rendering engine using C++ and DirectX 11. I've managed to render models using indexed vertices. Now I want to support textures and vertex normals as well. I'm using Wavefront OBJ files, which uses indices to reference to the correct texture and normal coordinates (much like indexed vertices). This is the first time I'm doing something like this with vertices, textures and normals combined, so this is all a bit new to me.

The problem I'm facing is that the number of indices for vertices, normals and texture coordinates are not the same and I'm trying to find a right way to use all these indices in a vertex shader. To illustrate the problem more clearly, I've made some images.

The left image is a wireframe of a simple piramid object and the right image is its UV coordinate layout (with the bottom of the piramid in the center). In the left image you can see that the piramid has 4 vertices, so there are 4 vertex indices. The right UV layout has 6 UV coordinates so there are 6 texture indices. For each face of the piramid has a normal of its own, so there are only 4 normal indices.

I've found this question while searching on SO and it seems to work in theory (I haven't tried it yet). Is this a common way to solve a problem like this or are there better ways? What would you recommend I do?

Thanks :)

P.S.: my vertex, normal and texture data is stored in separate arrays on the cpu side.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Krienie
  • 611
  • 1
  • 6
  • 14

2 Answers2

2

I would recommend you to analyze the problem narrowing down to the simplest case; to me it helped using only two squares (flat surface, 4 triangles) and try to correctly map the texture on both squares as shown in the image.

enter image description here

Using this simple case you have this data:

  • 6 vertices
  • 6 UVs
  • 6 normals (for each vertex, even though some vertex might share same normal)
  • 12 indices

In theory this will suffice to describe your whole data, but if you test it will find out that one of the mapped textures won't be fully mapped onto one of the squares. That's because for the vertex 2 and 3, you have two different UV coord sets, it's impossible to describe using so few vertices, you need more vertices!

To fix this problem, the data you gather from whatever exporter you chose, will duplicate vertices when clashes like this occur. For the example above, two more vertices will be needed, it will produce a duplication of data for the normals, 2 more elements to the indices but now it will describe correctly map the UV coords.

Finally, for your example those 4 vertices can't fully describe all UV coords, then duplicating some vertices will be needed to complete the UV layout, the indices array will grow.

For the part am not sure is if the OBJ format exporter actually throws the data ready to read, either you can try to figure it out with an exporter or you can try another format (which I better recommend you) that can export data that is already in the right format ready to be pushed into the graphics pipeline of DirectX11.

Hope the example that helped me understanding this problem, will help to you as well. Take a look to some basic DirectX11 tutorials, or if you can this book.

notNullGothik
  • 432
  • 5
  • 20
  • Yes, this actually makes sense. It's more clear to me now, and now knowing this I think OBJ format isn't ready to read straight from the OBJ exporter. I think I will look at some other data formats which are more suitable. Do you know a data format you can recommend? – Krienie Jul 17 '13 at 20:05
  • I heard COLLADA is a good one and has a readable format (xml), haven't tried myself but maybe will be the best way for you to go. For what I actually did was to create my own exporter for Blender and 3DMax, you can see the results in my blog notnullgothik.blogspot.com, most commercial engines will use their own adding at please optimization and data on binary format as I use. – notNullGothik Jul 17 '13 at 20:11
1

Ah seems to me that you need to visit: http://www.rastertek.com/tutdx11.html

See what they have here and give it a whirl

user2529011
  • 705
  • 3
  • 11
  • 21