Question on .x files and saving a mesh
Author
I am thinking about a few things with DX that I could do easier/faster than my OpenGL terrain engine can do. One thing that comes to mind is the ability to save out a .x file with a mesh you have created with the DX utility functions. So this is what I have come up with, with my mapeditor I could save out the 2D mesh for my terrain as a .x file and load that as my terrain, now with the attribute groups you save with mesh, couldn't I use them to break my terrain down into patches and render those patches with the DrawSubset() and use view frustum culling to determine which patches I can see and call them? Now if this is ok, my next question is calling DrawSubset() a fast call... What I mean by that is with OpenGL if you use VBO's you typically are rendering your mesh as fast as OpenGL can vs. immediate mode.
Thanks for the help.
Yeah, it'd work fine the way you described it.
But I'd almost go so far as to put money on it being possible to get substantially better performance from a custom solution.
Some of the details behind efficient terrain rendering can be a bit tedious to implement and test, but if you sit back and think through them they are usually very simple. For example, a quad-tree is not a complex data-structure...
But, I suppose if you want simple code with minimal effort then meshes are a reasonable choice [smile]
hth
Jack
But I'd almost go so far as to put money on it being possible to get substantially better performance from a custom solution.
Some of the details behind efficient terrain rendering can be a bit tedious to implement and test, but if you sit back and think through them they are usually very simple. For example, a quad-tree is not a complex data-structure...
But, I suppose if you want simple code with minimal effort then meshes are a reasonable choice [smile]
hth
Jack
Oh, to actually answer your question....
DrawSubset() should be setting up the VB, IB and declaration and then issuing a Draw call. Not the fastest in the world, but probably not bad.
Drill into it with PIX if you want the gory details.
hth
Jack
DrawSubset() should be setting up the VB, IB and declaration and then issuing a Draw call. Not the fastest in the world, but probably not bad.
Drill into it with PIX if you want the gory details.
hth
Jack
Author
Thanks for the reply Jack! I am as of now using a patching system with brute force to do my rendering with VBO's and triangle strips... With DrawSubset() is that the only way to render a mesh in DX for .x files? or is there some kind of element function call to say render x amount of indicies at a time from a mesh... Yeah basically I am looking at a simple but effect method to render a terrain mesh, due to I have a decent amount of work done in OpenGL and really don't want to redo all my work in DX if I can come up with a simple but fast enough method... :) Anyway I will keep it in mind now that you think my idea should work. Thanks
If you want to use the built-in easy mesh drawing functions, then DrawSubset() is as far as it goes.
However, you can easily do slightly better by coding your own; either by snarfing the vertex buffer out of the Mesh object and getting the attribute ranges, or by entirely loading the file yourself (using an EnumObject to parse the file, etc).
When it comes down to it, though, the big savings in terrain is doing some kind of LOD for distant blocks, rather than drawing everything at full rez. I know Carmack says differently, but he's not trying for a 20 km visible horizon on last-generation hardware. He may be excused if he believes the world consists mostly of sewers and deep, winding canyons :-)
However, you can easily do slightly better by coding your own; either by snarfing the vertex buffer out of the Mesh object and getting the attribute ranges, or by entirely loading the file yourself (using an EnumObject to parse the file, etc).
When it comes down to it, though, the big savings in terrain is doing some kind of LOD for distant blocks, rather than drawing everything at full rez. I know Carmack says differently, but he's not trying for a 20 km visible horizon on last-generation hardware. He may be excused if he believes the world consists mostly of sewers and deep, winding canyons :-)
Author
Thanks for the reply hplus. My reasons for using the .x file to store the terrain mesh is that with .x files I can use the built in calculatetangent() to get my tangents for my terrain, and DX will calculate my normals also. So with DX doing both of these this saves me more time if I move to DX from OpenGL... I am looking at what DX has to offer me in terms of getting me back to where I am at currently... I am assuming the calculateTangent is only for .X files...
D3DXCalculateTangent is for D3DXMesh. Not .x files. Do not mix the two, D3DXMesh != .x file.
.x files are just a format you can use to store data.
You can load stuff from an .x file into a D3DXMesh, do the tangent calculations, and then get the vertex and index buffers from the D3DXMesh interface. Then render it in your own way. AFAIK DrawSubset calls SetVertexBuffer each time it is called, and that is not good. Expensive. With terrains, usually index buffer manipulations provide good results.
.x files are just a format you can use to store data.
You can load stuff from an .x file into a D3DXMesh, do the tangent calculations, and then get the vertex and index buffers from the D3DXMesh interface. Then render it in your own way. AFAIK DrawSubset calls SetVertexBuffer each time it is called, and that is not good. Expensive. With terrains, usually index buffer manipulations provide good results.
Author
Quote:Original post by darkelf2k5
D3DXCalculateTangent is for D3DXMesh. Not .x files. Do not mix the two, D3DXMesh != .x file.
.x files are just a format you can use to store data.
You can load stuff from an .x file into a D3DXMesh, do the tangent calculations, and then get the vertex and index buffers from the D3DXMesh interface. Then render it in your own way. AFAIK DrawSubset calls SetVertexBuffer each time it is called, and that is not good. Expensive. With terrains, usually index buffer manipulations provide good results.
AFAIK DX can't calculate tangent vectors unless your data is in D3DXMesh data format? My issue is I don't want to code more code to calculate tangent, normals ect... if DX can/will do it for me. I am also guessing that instancing works with the D3DXMesh format also?
D3DX can calculate tangents and normals in any object of type ID3DXMesh, if that object has space for a tangent frame and normals in its vertex declarator.
You can create a ID3DXMesh with space from an ID3DXMesh without space by using CloneMesh().
You can put data from a .X file into an ID3DXMesh by using the convenient load functions; you can also write an ID3DXMesh to a .X file using the convenience functions.
However, you can also create an ID3DXMesh with data that comes from somewhere else, by just locking the index and vertex buffers and putting data into them.
Similarly, you can write data from an ID3DXMesh object to whatever file format you want, by just locking the vertex and index buffer and reading the data back out.
When you're creating an ID3DXMesh object to operate on like this, rather than drawing, then your best bet is to create it in SYSTEM or SCRATCH pools, which will give you better performance on computation. If you want to draw the mesh, use MANAGED pool.
.X files are swell for easy loading and saving of baseline mesh functionality. You can also bend them several ways, with subsets, materials, and using the LoadMeshHiearchy function to load. However, for a full-on scene graph or graphics engine, you'll probably find those functions too limited, and instead load your own; either using an enumeration object for the .X file, or by using your own file format.
Clear as mud?
You can create a ID3DXMesh with space from an ID3DXMesh without space by using CloneMesh().
You can put data from a .X file into an ID3DXMesh by using the convenient load functions; you can also write an ID3DXMesh to a .X file using the convenience functions.
However, you can also create an ID3DXMesh with data that comes from somewhere else, by just locking the index and vertex buffers and putting data into them.
Similarly, you can write data from an ID3DXMesh object to whatever file format you want, by just locking the vertex and index buffer and reading the data back out.
When you're creating an ID3DXMesh object to operate on like this, rather than drawing, then your best bet is to create it in SYSTEM or SCRATCH pools, which will give you better performance on computation. If you want to draw the mesh, use MANAGED pool.
.X files are swell for easy loading and saving of baseline mesh functionality. You can also bend them several ways, with subsets, materials, and using the LoadMeshHiearchy function to load. However, for a full-on scene graph or graphics engine, you'll probably find those functions too limited, and instead load your own; either using an enumeration object for the .X file, or by using your own file format.
Clear as mud?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
