# OpenGL Questions regarding D3DXLoadMeshFromX and LPD3DXMESH

This topic is 4443 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello everyone, I normally belong the the OpenGL faction (but please don't hunt me out of this forum anyway ;) ), but now certain circumstances require me to parse DirectX .X files. Because I don't really feel like writing a parser myself, I thought of using D3DXLoadMeshFromX to do the dirty work for me. I'm an absolute beginner regarding DX programming, so i looked at some tutorials and tried to help myself using Visual Studio's Intellisense. I've already setup the DirectX programming environment, and I can successfully load .X files using D3DXLoadMeshFromX. I've already found out, how to extract vertices from the loaded mesh, and materials/texture names from the material list What I'm missing now is: - how do I extract texcoords and normals? I just can't find any Methods or Attributes that would return one of the two. And another thing: Is it possible, to use D3DXLoadMeshFromX without creating a D3DDevice (and everything that comes with it, like CreateWindow(), etc)? I only need to get the .X file into memory and then analyze its contents. Thanks for any help in advance Regards Chris

##### Share on other sites
The texcoords and normals are a part of the vertex format in DX. Each vertex has it's own set of texcoords and a normal, as well as a position and possibly a color. When you extract the vertices from the vertex buffer, this includes the normal and texcoords in the data structure.

You didn't mention about locking the index buffer, I just want to make sure you're aware you need to get the indices from the index buffer. These let you turn the array of vertices into faces, if you need that info as well.

Lastly, you can't create a ID3DXMESH object without a valid D3D device, simply because the mesh object includes resources on the device itself. Since the code is written to be rendered using DX, the mesh already has it's resources in a ready-to-draw state, as a part of trying to be helpful.

What you can do is create the mesh with the SystemMem flag, which would at least create the resources only in system memory. This would eliminate the need to ever transfer any data to/from the GPU, which would cause quite a slow down. There is still some overhead involved in having a device and loading the .x mesh, but it wouldn't be as painful.

Hope this helps.

##### Share on other sites
Since you said, that normals/texcoords come with a vertex, my guess is, that I'm doing vertex extraction the wrong way (storing them in a wrong structure).

Here is my experimental piece of code:
LPDIRECT3DVERTEXBUFFER9 pVB;mesh->GetVertexBuffer(&pVB);	D3DXVECTOR3*  pVertices;pVB->Lock( 0, 0, (void**)&pVertices, 0 );float a=pVertices[0].x; //bingo, got the right valuepVB->Unlock();

As you can see, I'm storing vertex data in a structure called D3DVECTOR3. Maybe I'm just missing something, but is this ok?
Because I can't seem to find a way to get normals/texcoords out of that structure.
Edit: I've just seen, that there is a class called D3DVERTEX, which sadly is for DX8.1. Am I right with the guess, that I'd need to use a DX9 equivalent? If yes, what's it called?

Regarding Device creation:
Ok, I guess I will just implement a dummy device from a dummy window and use that with the SystemMem flag

Thanks :D

##### Share on other sites
There's no structure or class you need to follow, unfortunatly. What there is is a standard on how the data is held inside the buffer. The bad news is that the size of each vertex depends on this structure, and all the elements are optional, except position.

This all means that extracting the actual data from a mesh is quite difficult if you don't know it's format when you write the application.

If you only need the position, this get's pretty simple since you can easily get the stride size you need to use when going through the buffer from the mesh (using GetNumBytesPerVertex). This is your vertex size, and you can be sure that the first 3 floats are the position. The rest of the current vertex would depend on which of the element it has.
If you then skip the stride size forward, you'll get to the next vertex, and again the first 3 floats are the position.

Like I've mentioned, if you can limit yourself to a certain format, you can save yourself a huge headache. If you can't, you'll have to get the Mesh Vertex Declaration (using GetDeclaration), or the FVF (using GetFVF) and work your way from that. I can assure you it won't be pretty :).

That's all I can think about. Maybe someone else has some nice ideas. I sure don't have any.

Hope this helps :).

##### Share on other sites
Allright, thank you.

I guess, I will play around a bit, and see if I get it working the way I'd like it to.
If not, I will go ahead and parse the file myself.

Thanks for your replies sirob, as they helped a lot

Greets
Chris

1. 1
Rutin
24
2. 2
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 19
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631761
• Total Posts
3002179
×