🔒 Locked

Vertex buffer....

Started by Bru Apr 13, 2009 at 3:54 PM 12 replies 1.2k views

Original Post

Apr 13, 2009 at 3:54 PM

well you might remember i had a thread about this last time, but i still didnt manage to solve my problem with retrieving xyz data from vertex buffer. i am not even sure i am doing something wrong, even if i retrieve all the data i'll find out the coordinates ones are not correct. i use a LPD3DXMESH and load an x file into it using D3DXLoadMeshFromX. then i try getting the xyz data like this :


BYTE* vbptr = NULL;
DWORD stride = Mesh->GetNumBytesPerVertex();
Mesh->LockVertexBuffer(0, (LPVOID*)&vbptr);
D3DXVECTOR3 *pos = VerticesNum;//VerticesNum is an array of vector 3
for (DWORD i = 0; i < Mesh->GetNumVertices()/3; i++)
{

   memcpy(pos, vbptr, 12);
   vbptr += stride; 
   pos++;
}

i retrieve the index buffer too(Which i belive i copy correctly), after that i print the results into a file only to find out the results are not correct. here are the ten first vertices in my x fille :


   1.922921;0.220691;3.382240;,
   1.714091;0.216531;3.211916;,
   1.218880;0.365594;3.685974;,
   1.541734;0.057994;3.712066;,
   1.922921;0.220691;3.382240;,
   1.541734;0.057994;3.712066;,
   1.883994;-0.206110;3.363554;,
   2.126323;-0.062655;2.993244;,
   1.922921;0.220691;3.382240;,
   2.126323;-0.062655;2.993244;,

while in the text file where i put the data i retrieve from the vb i get


1.92292;4.65259;3.38224;
1.71409;4.64843;3.21192;
1.21888;4.79749;3.68597;
1.92292;4.65259;3.38224;
1.21888;4.79749;3.68597;
1.54173;4.48989;3.71207;
1.92292;4.65259;3.38224;
1.54173;4.48989;3.71207;
1.88399;4.22579;3.36355;
1.92292;4.65259;3.38224;

i dont understand it, it seems like it should be working perfectly, what did i do wrong?

Jason Z

325

Jason Z

Apr 13, 2009 at 5:06 PM

You could try doing a frame grab with PIX, and then checking the vertex position values prior to the vertex shader. That would tell you what the first 10 vertices should look like, including if there are any texture coordinates or other vertex attributes included with each vertex. If there are additional attributes, then you will need to skip the appropriate amount between each vertex to ensure that you only get the position data.

Bru

Author

Bru

Apr 13, 2009 at 5:11 PM

Quote:
Original post by Jason Z
You could try doing a frame grab with PIX, and then checking the vertex position values prior to the vertex shader. That would tell you what the first 10 vertices should look like, including if there are any texture coordinates or other vertex attributes included with each vertex. If there are additional attributes, then you will need to skip the appropriate amount between each vertex to ensure that you only get the position data.

grabbing frame using pix? what's pix? does it have anything to do with hlsl? i dont use hlsl yet.

Jason Z

325

Jason Z

Apr 13, 2009 at 8:17 PM

Quote:
Original post by Bru
Quote:
Original post by Jason Z
You could try doing a frame grab with PIX, and then checking the vertex position values prior to the vertex shader. That would tell you what the first 10 vertices should look like, including if there are any texture coordinates or other vertex attributes included with each vertex. If there are additional attributes, then you will need to skip the appropriate amount between each vertex to ensure that you only get the position data.

grabbing frame using pix? what's pix? does it have anything to do with hlsl? i dont use hlsl yet.

PIX is the D3D debugging tool that is part of the DXSDK installation. If you haven't used it yet, it's worth it to spend some time becoming familiar with it. It can be used to examine the contents of a vertex buffer before and after transformation.

Bru

Author

Bru

Apr 13, 2009 at 8:46 PM

Quote:
Original post by Jason Z
Quote:
Original post by Bru
Quote:
Original post by Jason Z
You could try doing a frame grab with PIX, and then checking the vertex position values prior to the vertex shader. That would tell you what the first 10 vertices should look like, including if there are any texture coordinates or other vertex attributes included with each vertex. If there are additional attributes, then you will need to skip the appropriate amount between each vertex to ensure that you only get the position data.

grabbing frame using pix? what's pix? does it have anything to do with hlsl? i dont use hlsl yet.

PIX is the D3D debugging tool that is part of the DXSDK installation. If you haven't used it yet, it's worth it to spend some time becoming familiar with it. It can be used to examine the contents of a vertex buffer before and after transformation.

i see, i found the program and managed to run my game in it but that's pretty much it. i didnt see anyway to debug anything with it.

Jason Z

325

Jason Z

Apr 13, 2009 at 9:25 PM

Try using the 'Single Frame Capture whenever F12 is Pressed' experiment, then run your app through PIX, capture a frame, then inspect the various draw call that you generated in the lower left hand side of the application window. You will be able to select a draw call, then on the lower right hand side you will be able to see the mesh before and after. Play around with it for a while, you will get the hang of it.

Bru

Author

Bru

Apr 13, 2009 at 9:47 PM

Quote:
Original post by Jason Z
Try using the 'Single Frame Capture whenever F12 is Pressed' experiment, then run your app through PIX, capture a frame, then inspect the various draw call that you generated in the lower left hand side of the application window. You will be able to select a draw call, then on the lower right hand side you will be able to see the mesh before and after. Play around with it for a while, you will get the hang of it.

thanks i managed to do that and see the whole scene before and after i call a specific draw call, but what does that actually give me? i cant realy see any data about the vertex buffer(no information seems to appear in the "mesh" tab)

edit : oh, nevermind it seems like no data appears when i use the draw call of the mesh, but i found that little + near the function and called inside there was the real draw, i'll check it now :)

edit 2 :
well, the data in prevs seems to be like what i print into the text file when i retrieve the data from the vertex buffer, but with or without transformation, how comes that's not the same as the original xyz data in the x file?

Jason Z

325

Jason Z

Apr 14, 2009 at 4:59 PM

I don't know why, but it means that the difference is from the X file loading and not your vertex buffer. Is it possible that there is some animation applied to the model that could be shifting the vertices? Where did you get the X file?

Bru

Author

Bru

Apr 14, 2009 at 5:48 PM

Quote:
Original post by Jason Z
I don't know why, but it means that the difference is from the X file loading and not your vertex buffer. Is it possible that there is some animation applied to the model that could be shifting the vertices? Where did you get the X file?

a friend made it for me. it has no animation.
should i upload the x file?

Jason Z

325

Jason Z

Apr 14, 2009 at 6:11 PM

Quote:
Original post by Bru
Quote:
Original post by Jason Z
I don't know why, but it means that the difference is from the X file loading and not your vertex buffer. Is it possible that there is some animation applied to the model that could be shifting the vertices? Where did you get the X file?

a friend made it for me. it has no animation.
should i upload the x file?

I'm not really familiar with the format, but perhaps someone else on this forum is? Upload it and let's see what everyone else sees...

Jason Z

325

Jason Z

Apr 14, 2009 at 6:22 PM

Quote:
Original post by Bru
Quote:
Original post by Jason Z
I don't know why, but it means that the difference is from the X file loading and not your vertex buffer. Is it possible that there is some animation applied to the model that could be shifting the vertices? Where did you get the X file?

a friend made it for me. it has no animation.
should i upload the x file?

I'm not really familiar with the format, but perhaps someone else on this forum is? Upload it and let's see what everyone else sees...

Bru

Author

Bru

Apr 14, 2009 at 6:32 PM

well there it is :
http://rapidshare.com/files/221428312/sphere_subd.x.html

Evil Steve

382

Evil Steve

Apr 15, 2009 at 3:21 AM

Can we see a bit more of your code? Are you checking that LockVertexBuffer() succeeds? Also, that memcpy() and pointer stuff looks suspicious to me. Does the following work?

BYTE* vbptr = NULL;DWORD stride = Mesh->GetNumBytesPerVertex();if(SUCCEEDED(Mesh->LockVertexBuffer(0, (LPVOID*)&vbptr))){   FILE* pFile = fopen("C:/verts.txt", "w");   for (DWORD i = 0; i < Mesh->GetNumVertices()/3; i++)   {      D3DXVECTOR3 pos = *(D3DXVECTOR3*)vbptr;      fprintf(pFile, "(%f, %f, %f)\n", pos.x, pos.y, pos.z);      vbptr += stride;    }   fclose(pFile);}Mesh->UnlockVertexBuffer();

You could also try calling Mesg->GetDeclaration() and checking that the first component of the vertex declaration is in fact a 3D position:

D3DVERTEXELEMENT9 decl[MAX_FVF_DECL_SIZE];if(SUCCEEDED(Mesh->GetDeclaration(decl))){   if(decl[0].Offset != 0 || decl[0].Type != D3DDECLTYPE_FLOAT3 || decl[0].Usage != D3DDECLUSAGE_POSITION)   {      // Declaration does not have the position as the first element at offset 0   }}

If you find that the vertex position isn't there, then it might be some strange format.

Waterwalker

Apr 15, 2009 at 3:36 AM

Quote:
Original post by Bru
for (DWORD i = 0; i < Mesh->GetNumVertices()/3; i++)

A mesh is a mesh is a mesh and it has NumVertices and not NumVertices/3. I remember that you are a fan of divides by 3 from last time :)

So I would think that if you output the vertices using your index list (which you assume to be correctly read) you are in danger of accessing vertices you have not copied into VerticesNum because you have only copied a thrid of all vertices.

Again, I strongly suggest renaming VerticesNum to VertexArray or something like that.

Try reading all vertices and check again. Also, load the x file with the DirectX SDK mesh viewer to see if it is a valid X file and can be loaded with the official tools.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.