Sign in to follow this  
Atom

ID3DXMesh failing [solved]

Recommended Posts

Atom    100
Hello everyone. : ) I'm having a problem with my ID3DXMesh failing when calling D3DXCreateMesh. Whats happening is that when I try to create a mesh with 256x256 heightmap it fails, but it works when I try my 128x128 heightmap. I have checked to make sure the d3d device is valid, the vertex declaration is valid and the math is right. The error message its giving me is D3DERR_INVALIDCALL when I try 256, but not with 128? : ( Does it have to do with the fact that the amount of vertices's is 65536? Thanks for the help on this issue in advance. [Edited by - Atom on March 24, 2008 9:17:46 AM]

Share this post


Link to post
Share on other sites
Sc4Freak    643
My guess is that you need to set 32-bit indices. By default, ID3DXMesh uses 16-bit indices, which means a maximum of 65534 indices (the last one is reserved).

From the documentation:
Quote:
NumFaces
[in] Number of faces for the mesh. The valid range for this number is greater than 0, and one less than the maximum DWORD (typically 65534), because the last index is reserved.
Quote:
D3DXMESH_32BIT
The mesh has 32-bit indices instead of 16-bit indices. See Remarks.

...

Remarks
A 32-bit mesh (D3DXMESH_32BIT) can theoretically support (2^32)-1 faces and vertices. However, allocating memory for a mesh that large on a 32-bit operating system is not practical.

Share this post


Link to post
Share on other sites
Atom    100
Would it be practical if I create sub-ID3DXMeshes to represent to the final terrain. For example:

256/4 = 64

So I would create 16 sub-ID3DXMeshes of a 64x64 section of the terrain.

which each sub-ID3DXMesh would now only have 4096 vertices?

The ID3DXMESH_32BIT seems like a solution but:

Quote:
A 32-bit mesh (D3DXMESH_32BIT) can theoretically support (2^32)-1 faces and vertices. However, allocating memory for a mesh that large on a 32-bit operating system is not practical


"not practical" doesn't sound like a good way to solve this problem.

Edit: Is a 128x128 terrain still a acceptable/decent sized map for a game? What size heightmap do you use in your game/engine for rendering your terrain?

Share this post


Link to post
Share on other sites
Sc4Freak    643
You misunderstand the documentation. It's saying that allocating 2^32-1 (~4 billion) faces and vertices isn't practical on current systems.

32-bit indices take up twice as much space as 16-bit indices.

But let's say you're using a triangle list, which means 3 indices per face (which is essentially worst case scenario). And your mesh has 256*256 vertices. That means you've got 2*3*256*256 indices in total. Using 16-bit indices, that's 384k of memory. Using 32-bit indices, that's 768k of memory. That's a whopping difference of 384k of memory between 16-bit indices and 32-bit indices. Unless you're using a computer from 1991, 384k of memory is nothing. But it's 100%, guaranteed to be a lot faster (and use far less memory) than designing arcane methods to get around that 2^16-2 limitation of 16-bit.

Hope this helps.

Share this post


Link to post
Share on other sites
Atom    100
Thanks for explaining and clearing that up for me. I get what your saying now. And yep it helped out a bunch. : )

Share this post


Link to post
Share on other sites
Buckeye    10747
Quote:
Is a 128x128 terrain still a acceptable/decent sized map for a game? What size heightmap do you use in your game/engine for rendering your terrain?


The size of your terrain depends on what you want to do in the game and how detailed you want the terrain. Obviously, the fewer the quads, the "blockier" the terrain will appear.

It also depends on the scale you use. For a mile between vertices, 128 miles on a side for the terrain is pretty big. For a foot, it may be small.

I have a flight program with 144 terrain meshes, each mesh comprised of 72 quads on a side, scaled to 202.5 feet between vertices. I subdivide the terrain that way so I can not draw meshes that are beyond the fog or behind the eye-point. (I don't use a height-map; I use USGS elevation data; same principle though;)

I also have a walk-around program for a building that's ~200 feet square. Different mesh sizes for that one.

If you don't want to use 32-bit indices, subdivide the terrain into parts as you suggest. If you want to draw all the terrain, why not use 4 128x128 meshes?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this