Rotation Matrix/World Matrix problems

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 07, 2007 at 17:43

Hey all. I’m trying to get my world matrix for my engine working. I need to rotate the vertices on each axis then translate them. But when I try nothing is displayed. I think I must be creating a rotation matrix wrong. I thought I can create a rotation axis for X, Y and Z then multiply them together to make one rotation matrix. Is this correct or is there another way of doing this?

EDIT:

I have something that works as in it rotates:

rotMatrix.RotateX(m_rotation.GetX());       
worldMatrix = rotMatrix;

rotMatrix.RotateY(m_rotation.GetY());
worldMatrix = worldMatrix.Multiply(rotMatrix);

rotMatrix.RotateZ(m_rotation.GetZ());
//Set the world matrix to that of our mesh
worldMatrix = worldMatrix.Multiply(rotMatrix);

worldMatrix = worldMatrix.Multiply(transMatrix);

But I think my projection or view matrices are screwed up because look at my “Cube”:

cubewi4.jpg

26 Replies

Please log in or register to post a reply.

46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Mar 07, 2007 at 18:57

This looks more like a case of bad indices/triangles. Matrices won’t affect single vertices, unless explicitly told too.

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 07, 2007 at 19:35

I would’ve thought that the projection could screw up how they are shown on the screen seeing as it is “projecting” form World to Screen?

A9102969e779768e6f0b8cb87e864c94
0
dave_ 101 Mar 07, 2007 at 21:35

Yes, but you’d more likely see something stretched/oriented wrong/scaled/translated, if it was a matrix problem, than broken up (vertex problem)

9cd1fa8d4bb45c93065544fe45c285ce
0
Rubicon 101 Mar 07, 2007 at 22:21

I’d back up the idea of screwed data.

Your cube is in the centre of the screen and I presume the rest of it looks like it’s spinning around ? If so, it’s your vertex data for sure.

Sidenote: I’d recommend picking up a matrix and vector class and using that instead of rolling your own. Getting all the overloads sorted out (if you use C++ or other oop) so you end up with Vertex.Pos*=Matrix for applying a matrix to a vertex for example makes you code seriously readable and is less bug-prone.

We actually wrote our own, but with hindsight I wish we’d started from someone elses!

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 08, 2007 at 07:41

Thing is I copied the vertex/index data for this cube from the Irrlicht engine and I know that works. When you move the camera or rotate it that triangle thats sticking out in the pick seems to stay there and just gets elongated, stretched.

9cd1fa8d4bb45c93065544fe45c285ce
0
Rubicon 101 Mar 08, 2007 at 09:21

Which is a common example of projecting to infinity due to NAN errors in the vertex data. Might not be it, but you need to make sure as this *sounds* like a classic case

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 08, 2007 at 15:40

I thought I might as well post my vertex data. I don’t know if theres anything wrong here. The variable colour is 0xFFFFFFFF:

//Vertex data
vertices[0].X = 0.0f; vertices[0].Y = 0.0f; vertices[0].Z = 0.0f; vertices[0].NX = -1.0f; vertices[0].NY = -1.0f; vertices[0].NZ = -1.0f; vertices[0].diffuse = colour;
vertices[1].X = 1.0f; vertices[1].Y = 0.0f; vertices[1].Z = 0.0f; vertices[1].NX = 1.0f; vertices[1].NY = 1.0f; vertices[1].NZ = 1.0f; vertices[1].diffuse = colour;
vertices[2].X = 1.0f; vertices[2].Y = 1.0f; vertices[2].Z = 0.0f; vertices[2].NX = 1.0f; vertices[2].NY = 1.0f; vertices[2].NZ = -1.0f; vertices[2].diffuse = colour;
vertices[3].X = 0.0f; vertices[3].Y = 1.0f; vertices[3].Z = 0.0f; vertices[3].NX = -1.0f; vertices[3].NY = 1.0f; vertices[3].NZ = -1.0f; vertices[3].diffuse = colour;
vertices[4].X = 1.0f; vertices[4].Y = 0.0f; vertices[4].Z = 1.0f; vertices[4].NX = 1.0f; vertices[4].NY = -1.0f; vertices[4].NZ = 1.0f; vertices[4].diffuse = colour;
vertices[5].X = 1.0f; vertices[5].Y = 1.0f; vertices[5].Z = 1.0f; vertices[5].NX = 1.0f; vertices[5].NY = 1.0f; vertices[5].NZ = 1.0f; vertices[5].diffuse = colour;
vertices[6].X = 0.0f; vertices[6].Y = 1.0f; vertices[6].Z = 1.0f; vertices[6].NX = -1.0f; vertices[6].NY = 1.0f; vertices[6].NZ = 1.0f; vertices[6].diffuse = colour;
vertices[7].X = 0.0f; vertices[7].Y = 0.0f; vertices[7].Z = 1.0f; vertices[7].NX = -1.0f; vertices[7].NY = -1.0f; vertices[7].NZ = 1.0f; vertices[7].diffuse = colour;
vertices[8].X = 0.0f; vertices[8].Y = 1.0f; vertices[8].Z = 1.0f; vertices[8].NX = -1.0f; vertices[8].NY = 1.0f; vertices[8].NZ = 1.0f; vertices[8].diffuse = colour;
vertices[9].X = 0.0f; vertices[9].Y = 1.0f; vertices[9].Z = 0.0f; vertices[9].NX = -1.0f; vertices[9].NY = 1.0f; vertices[9].NZ = -1.0f; vertices[9].diffuse = colour;
vertices[10].X = 1.0f; vertices[10].Y = 0.0f; vertices[10].Z = 1.0f; vertices[10].NX = 1.0f; vertices[10].NY = -1.0f; vertices[10].NZ = 1.0f; vertices[10].diffuse = colour;
vertices[11].X = 1.0f; vertices[11].Y = 0.0f; vertices[11].Z = 0.0f; vertices[11].NX = 1.0f; vertices[11].NY = -1.0f; vertices[11].NZ = -1.0f; vertices[11].diffuse = colour;
46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Mar 08, 2007 at 17:58

It’s more likely your indices. The missing ‘triangle’ in your cube is because of bad ordering of your vertices, meaning that two triangles which should lie next to each other overlap instead.

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 09, 2007 at 20:33

Index data:

//Indices
indices[0] = 0; indices[3] = 0; indices[6] = 1; indices[9] = 1; indices[12] = 4; indices[15] = 4; indices[18] = 7; indices[21] = 7; indices[24] = 9; indices[27] = 9;
indices[1] = 2; indices[4] = 3; indices[7] = 5; indices[10] = 2; indices[13] = 6; indices[16] = 5; indices[19] = 3; indices[22] = 6; indices[25] = 5; indices[28] = 8;
indices[2] = 1; indices[5] = 2; indices[8] = 4; indices[11] = 5; indices[14] = 7; indices[17] = 6; indices[20] = 0; indices[23] = 3; indices[26] = 2; indices[29] = 5;

indices[30] = 0; indices[33] = 0; 
indices[31] = 11; indices[34] = 10; 
indices[32] = 10; indices[35] = 7;
46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Mar 10, 2007 at 15:15

It sure is. Now you need to re-arrange them so they are correct :)

Too make it easier on yourself, try and split up the cube to its individual faces, and fix one at a time.

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 11, 2007 at 10:10

OK I tried that. I made a cube in a 3D Modeller, exported it and took the vertex and index data straight from that. But it still doesn’t look right. Now it looks like a flattened L shape. :S

//Indices
indices[0] = 0; indices[3] = 3; indices[6] = 4; indices[9] = 7; indices[12] = 0; indices[15] = 5; indices[18] = 1; indices[21] = 7; indices[24] = 3; indices[27] = 6;
indices[1] = 2; indices[4] = 1; indices[7] = 5; indices[10] = 6; indices[13] = 1; indices[16] = 4; indices[19] = 3; indices[22] = 5; indices[25] = 2; indices[28] = 7;
indices[2] = 3; indices[5] = 0; indices[8] = 7; indices[11] = 4; indices[14] = 5; indices[17] = 0; indices[20] = 7; indices[23] = 1; indices[26] = 6; indices[29] = 3;

indices[30] = 2; indices[33] = 4; 
indices[31] = 0; indices[34] = 6; 
indices[32] = 4; indices[35] = 2;

//Vertex data
vertices[0].X = -0.5f; vertices[0].Y = 0.0f; vertices[0].Z = -0.5f; vertices[0].NX = 0.0f; vertices[0].NY = 1.0f; vertices[0].NZ = 0.0f; vertices[0].diffuse = colour;
vertices[1].X = 0.5f; vertices[1].Y = 0.0f; vertices[1].Z = -0.5f; vertices[1].NX = 0.0f; vertices[1].NY = -1.0f; vertices[1].NZ = -0.0f; vertices[1].diffuse = colour;
vertices[2].X = -0.5f; vertices[2].Y = 0.0f; vertices[2].Z = 0.5f; vertices[2].NX = 0.0f; vertices[2].NY = 0.0f; vertices[2].NZ = -1.0f; vertices[2].diffuse = colour;
vertices[3].X = 0.5f; vertices[3].Y = 0.0f; vertices[3].Z = 0.5f; vertices[3].NX = -0.0f; vertices[3].NY = 0.0f; vertices[3].NZ = 0.0f; vertices[3].diffuse = colour;
vertices[4].X = -0.5f; vertices[4].Y = -1.0f; vertices[4].Z = -0.5f; vertices[4].NX = 0.0f; vertices[4].NY = 0.0f; vertices[4].NZ = 1.0f; vertices[4].diffuse = colour;
vertices[5].X = 0.5f; vertices[5].Y = -1.0f; vertices[5].Z = -0.5f; vertices[5].NX = 1.0f; vertices[5].NY = 0.0f; vertices[5].NZ = 0.0f; vertices[5].diffuse = colour;
vertices[6].X = -0.5f; vertices[6].Y = -1.0f; vertices[6].Z = 0.5f; vertices[6].NX = 0.0f; vertices[6].NY = -0.0f; vertices[6].NZ = 1.0f; vertices[6].diffuse = colour;
vertices[7].X = 0.50f; vertices[7].Y = -1.0f; vertices[7].Z = 0.5f; vertices[7].NX = -1.0f; vertices[7].NY = 0.0f; vertices[7].NZ = 1.0f; vertices[7].diffuse = colour;

I’ll post a screenshot as soon as I work out why the triangles flicker if I turn off lighting.

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 12, 2007 at 21:09

Right I made a video showing what happens exactly. The camera is pulling away slowly and the “cube” is rotating on it’s Y-Axis:

Clicky

Any help at all?

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Mar 12, 2007 at 21:56

I can see exactly two triangles. And their indices aren’t correct. I don’t thinkt that you pass the wrong indices anymore. It must be something else, like the creation of the indes buffer maybe..

Check this please..

Here’s what I see (from a triangle point of view):

othersbug.gif

9cd1fa8d4bb45c93065544fe45c285ce
0
Rubicon 101 Mar 13, 2007 at 00:16

Heh, I know that diagram so well! :surrender

So often do I see it, I’ve even named it:

“Cats Ears” :wallbash:

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 13, 2007 at 07:46

I don’t use index or vertex buffers directly. I use DrawIndexedPrimitiveUP(). Could it be that it’s not interpretating my index data correctly? The index data I pass to it is an array of type unsigned long.

Here is my call to the D3D Function:

m_d3d9Device->DrawIndexedPrimitiveUP(D3DPT_TRIANGLELIST, 0, rData->GetVertexCount(), rData->GetIndexCount() / 3,
(void *)indexData, D3DFMT_INDEX16, rData->GetVertexData(), sizeof(Vertex_Diffuse));

9cd1fa8d4bb45c93065544fe45c285ce
0
Rubicon 101 Mar 13, 2007 at 09:46

And yet you’re specifically telling it they’re U16 size with D3DFMT_INDEX16. There’s a cracking explanation of how to call these functions in the docs…

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Mar 13, 2007 at 10:56

problem solved. :-)

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 13, 2007 at 16:16

Well I changed D3DFMT_INDEX16 to D3DFMT_INDEX32, which is the only other option, before but it still doesn’t make a cube. I get something weird like this:

CLICK

That’s the object rotating slowly on it’s X-Axis. The camera is also at -35 on the Z Axis and 20 on the Y looking at 0,0,0. I also notice that as I pull away from the object the parts that are off camera just keep stretching. I can never get the whole thing on the screen at once.

46407cc1bdfbd2db4f6e8876d74f990a
0
Kenneth_Gorking 101 Mar 13, 2007 at 17:39

Your indices are stored in an ‘indices’ array above, but in the draw-call you use indexData. Are you by any chance mem-copying the data from one array to another, and if so, are you sure their sizes are the same? i.e not copying from a ‘byte*’ array to an ‘unsigned long*’ array.

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 13, 2007 at 19:24

No, I’m copying from a vector of unsigned longs to an unsigned long pointer.

unsigned long *indexData = new unsigned long[rData->GetIndexData(i).size()];
for(int y = 0; y < rData->GetIndexData(i).size(); y++)
{
    indexData[y] = rData->GetIndexData(i).at(y);
}
B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Mar 13, 2007 at 20:04

1st: Stop using DrawIndexedPrimitiveUP. It’s inefficient and should be avoided anyways.

2nd: Browse the examples until you find a basic DirectX example that uses Index and Vertex Buffers (it’s somewhere in the tutorials - I’m sure about that).

3nd: Throw away everything you don’t need..

4th: Implement you cube using the new code as a boilerplate

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 13, 2007 at 20:36

I know how to use index and vertex buffers. It’s just that I am trying to keep all of the API specific stuff in one module. Which means I need to store my vertex/index data in my own custom types. Anyway doesn’t DrawIndexedPrimitiveUP create vertex/index buffers internally? Unless I convert my data to vertex and index buffers then draw but I don’t see how that would make much difference?

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Mar 13, 2007 at 20:44

Not to sound rude, but since you hadn’t hadn’t found this rather simple error on your own I don’t really trust in your problem solving skills when it comes to directx coding. Nothing to be ashamed on, we all have to start at one point, but it’s better to start from a new, stable codebase now.

Who knows what else lurks inside your code…

Btw, keeping dependencies inside one code is a good thing to do. I don’t know why everyone uses d3dx even for the most simple vector stuff these days..

Eb3291f61c6a5e09cabefb4348f193d6
0
Dom_152 101 Mar 13, 2007 at 21:11

This is my first *Big* project using Direct3D but I don’t know how the problem is simple or else I would’ve worked it out by now. I mean I’ve checked my index data I don’t know how many times, I’ve checked all of my transformation matrices. I’m grateful for all the help you’ve given me so far but even doing as you’ve said it’s still not completley right. I don’t want to rewrite the whole codebase again. I would rather fix what I have than start a-fresh especially because it’s sort of intertwined with other modules to do sorting by materials and whatnot.

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Mar 13, 2007 at 22:09

That’s why I wrote my suggestion. You already sort by material and whatnot, but the very basics don’t work. A simple cube still does not render correctly.

Start simple, forget about your codebase for a while and get that damn cube on the screen first.

*Then* integrate your codebase step by step and test each feature inside out.

9cd1fa8d4bb45c93065544fe45c285ce
0
Rubicon 101 Mar 13, 2007 at 23:24

vertices[3] has a (0,0,0) normal which is probably being projected to infinity or something. I don’t see why that would happen unless your pixel shader is overcomplicated for this, but some general points even if this isn’t the answer. (As I don’t see why it should be tbh):

a) Triangles that never go away usually have a vertex at infinity.
b) I found some dodgy looking data in your example.
c) Vertices at inifinity are usually caused by NAN vertex or broken shader - you can’t really put them there in code one individually unless you try real hard as they get transformed elsewhere later.
d) You can get a NAN by normalising a NULL normal like the one at vertices[3] then doing something with it.
e) Lighting might turn your tri invisible with NULL normals depending on shader/RS settings

EDIT:Also vertices[7]’s normal isn’t actually normal.