Holes in surface
Author
Dear programmers,
I have a rectangular matrix of datapoints which I want to plot with directx;
z = f(x,y)
I convert these data into vertices and then I display the vertices either as "D3DFILL_WIREFRAME" or via "D3DFILL_SOLID".
This is no problem as long as the matrix is roughly upto 100 x 100 datapoints.
But if I have more datapoints, e.g. 200 x 200 datapoints, then my surfaces have holes; a lot of vertices are not drawn.
I tried a lot, but I have no idea.
Do you have any idea?
Thanks for your advices
[Edited by - Tomerland on October 29, 2007 4:38:01 AM]
You're using a triangle list aren't you? 100x100 points, with 6 vertices per point (two triangles), is 60000 vertices, and if you're using a 16-bit index buffer, you can only reference up to 65536 vertices.
So, if you're using a 16-bit IB, you'll need to either move to a 32-bit IB, or split the data into multiple IBs.
So, if you're using a 16-bit IB, you'll need to either move to a 32-bit IB, or split the data into multiple IBs.
Author
Hi Steve,
I'm not totally sure if I understand your points. But it seems you meet an important issue in my code.
I'm using a "IDirect3DVertexBuffer9 *m_pVertexBuffer" as a vertex-buffer and the typical code-sequence (see below) to copy "my vertex-data" in this vertex buffer:
m_pVertexBuffer->Lock( ..6*sizeof(S_MY_CUSTOMVERTEX)... );
memcpy( ...);
m_pVertexBuffer->Unlock();
As you write, my vertices are trianglelists (with this factor "6").
But the difference to your writing is: I do not use index-buffers.
I will make now experiments to split my vertex-buffer into a list of smaller separate vertexbuffers each of them smaller then 2**16-Bytes.
Thank you
I'm not totally sure if I understand your points. But it seems you meet an important issue in my code.
I'm using a "IDirect3DVertexBuffer9 *m_pVertexBuffer" as a vertex-buffer and the typical code-sequence (see below) to copy "my vertex-data" in this vertex buffer:
m_pVertexBuffer->Lock( ..6*sizeof(S_MY_CUSTOMVERTEX)... );
memcpy( ...);
m_pVertexBuffer->Unlock();
As you write, my vertices are trianglelists (with this factor "6").
But the difference to your writing is: I do not use index-buffers.
I will make now experiments to split my vertex-buffer into a list of smaller separate vertexbuffers each of them smaller then 2**16-Bytes.
Thank you
If you're not using index buffers, making a smaller VB won't matter unless you're using unsigned shorts to represent buffer sizes in your code.
What is the current size in bytes of your vertex buffer? And is it static or dynamic?
What is the current size in bytes of your vertex buffer? And is it static or dynamic?
Author
Hallo again :-))
I found out, if the number of vertices is greater than (2**16=65536) than I have that ugly behaviour in a reproducable way.
I the number of vertices is below 2**16, than it works absolutely fine.
I calculate:
number_of_vertices = 6*(sizeX*sizeY)
Concrete:
number_of_vertices = 6*(104*104); < 65536 <--- works fine ! ! !
number_of_vertices = 6*(105*105); > 65536 <--- works bad
Thanks a lot for this advice ! ! ! !
I don't fully understand your last hint. I create the vertexbuffer in this way:
pDevice->CreateVertexBuffer( nrOfVertices*sizeof(S_MY_CUSTOMVERTEX)....)
I'm not sure if this is static or dynamic !?
With very kind regards
[Edited by - Tomerland on October 29, 2007 9:49:29 AM]
I found out, if the number of vertices is greater than (2**16=65536) than I have that ugly behaviour in a reproducable way.
I the number of vertices is below 2**16, than it works absolutely fine.
I calculate:
number_of_vertices = 6*(sizeX*sizeY)
Concrete:
number_of_vertices = 6*(104*104); < 65536 <--- works fine ! ! !
number_of_vertices = 6*(105*105); > 65536 <--- works bad
Thanks a lot for this advice ! ! ! !
I don't fully understand your last hint. I create the vertexbuffer in this way:
pDevice->CreateVertexBuffer( nrOfVertices*sizeof(S_MY_CUSTOMVERTEX)....)
I'm not sure if this is static or dynamic !?
With very kind regards
[Edited by - Tomerland on October 29, 2007 9:49:29 AM]
The vertex buffer with be static unless you create it with the D3DUSAGE_DYNAMIC flag.
What is sizeof(S_MY_CUSTOMVERTEX) ?
The 64k vertices thing does sound pretty suspicious. Can we see your DrawPrimitive() call? And do you get the same behaviour with the reference rasteriser (D3DDEV_REF instead of D3DDEV_HAL to CreateDevice())?
What is sizeof(S_MY_CUSTOMVERTEX) ?
The 64k vertices thing does sound pretty suspicious. Can we see your DrawPrimitive() call? And do you get the same behaviour with the reference rasteriser (D3DDEV_REF instead of D3DDEV_HAL to CreateDevice())?
Author
Hallo again; much help from your side, so many topics :-))
1.
My vertex-buffer was declared static.
Due to your hint I also made it dynamic with "D3DUSAGE_DYNAMIC", but there was no change in bad behaviour.
2.
When I call CreateDevice with "D3DDEVTYPE_REF" instead of "D3DDEVTYPE_HAL", then everything seems to work fine (problems are gone); but the SW is much slower.
3.
I use the following structure
struct S_MY_CUSTOMVERTEX {
FLOAT x, y, z;
DWORD color; // The vertex color
};
The sizeof-operator returns 16 as size of this structure which seems to be ok
4.
My DrawPrimitive-Call is:
m_pDevice->SetStreamSource( 0, m_pVertexBuffer, 0, sizeof(S_MY_CUSTOMVERTEX) );
m_pDevice->SetFVF ( FVF_PROVIDERCUSTOMVERTEX );
m_pDevice->DrawPrimitive ( D3DPT_TRIANGLELIST, 0, m_slNrOfVertices/3 );
Thank you for your help !
1.
My vertex-buffer was declared static.
Due to your hint I also made it dynamic with "D3DUSAGE_DYNAMIC", but there was no change in bad behaviour.
2.
When I call CreateDevice with "D3DDEVTYPE_REF" instead of "D3DDEVTYPE_HAL", then everything seems to work fine (problems are gone); but the SW is much slower.
3.
I use the following structure
struct S_MY_CUSTOMVERTEX {
FLOAT x, y, z;
DWORD color; // The vertex color
};
The sizeof-operator returns 16 as size of this structure which seems to be ok
4.
My DrawPrimitive-Call is:
m_pDevice->SetStreamSource( 0, m_pVertexBuffer, 0, sizeof(S_MY_CUSTOMVERTEX) );
m_pDevice->SetFVF ( FVF_PROVIDERCUSTOMVERTEX );
m_pDevice->DrawPrimitive ( D3DPT_TRIANGLELIST, 0, m_slNrOfVertices/3 );
Thank you for your help !
Interesting. If the reference rasteriser works, but HAL doesn't, that indicates a driver bug (The driver maybe uses a 16-bit index buffer internally if you don't use one). What graphics card do you have, and do you have the latest drivers?
Author
hmm, ... not sure which graphics-devices/driver-versions I have installed (I don't have admin-rights on this computer)
I found some things like "Intel(R) 82945G Express Chipset Family". When I tried to update the driver, I got the message, that there is no newer version available.
But nevertheless:
There seems to be a suspicious 64k-Limit.
If this is right, I will split my huge vertex-buffer in small 64K-junks.
I found some things like "Intel(R) 82945G Express Chipset Family". When I tried to update the driver, I got the message, that there is no newer version available.
But nevertheless:
There seems to be a suspicious 64k-Limit.
If this is right, I will split my huge vertex-buffer in small 64K-junks.
There are limits on how many primitives you can pump through in a single draw call. I'm not on my dev box right now, but look at the D3DCAPS9 structure in the docs - there's a MaxPrimitiveCount or something like that.
Having said that, the description in the docs never made that much sense to me and I have filed a doc bug/request with MS, but it was after 9 was put to bed so I doubt it'll get fixed.
Bare in mind it doesn't limit how much data you can store in a single VB or IB, just how many draw calls you need and what parameters you need. Keep your data the same and render it in two calls instead of just one.
hth
Jack
Having said that, the description in the docs never made that much sense to me and I have filed a doc bug/request with MS, but it was after 9 was put to bed so I doubt it'll get fixed.
Bare in mind it doesn't limit how much data you can store in a single VB or IB, just how many draw calls you need and what parameters you need. Keep your data the same and render it in two calls instead of just one.
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
