Very strange bottleneck...
If you want to use index buffers you must arrange the vertex buffer(s) so that a vertex that is shared between several triangles only occurs in the vertex buffer once, but has several entries in the index buffer (once per triangle it''s a part of). This way you can utilise the vertex translation cache of the GPU, and you should see a speedup. This way your index buffer won''t only contain [1,2,3,4,5,6,...]. You are right that having an index buffer with only a list of consecutive vertices will most likely be slower than just sending vertices, since you have no vertex sharing. It shouldn''t be too difficult to figure out the vertex sharing in a ROAM algorithm though (within a patch at least).
Author
arrrrrrg!!!
It''s me agin...
The DrawPrimitive lines is not the reason for my bottleneck...
Whene I lock the buffer I get a pointer (pVertex) to an MYVERTEX array right?
What causes the FPS dropdown is the 4 lines I excute for each vertex... which are:
pVertex[dwCurrentVertex].p = D3DXVECTOR3(x, y, z);
pVertex[dwCurrentVertex].n = D3DXVECTOR3(0, 1, 0);
pVertex[dwCurrentVertex].u = x / dwMapSize * 8;
pVertex[dwCurrentVertex].v = z / dwMapSize * 8;
These four lines causes my bottleneck!!!
The writing to the VertexBuffer!!
Why is it happenning..?
It''s me agin...
The DrawPrimitive lines is not the reason for my bottleneck...
Whene I lock the buffer I get a pointer (pVertex) to an MYVERTEX array right?
What causes the FPS dropdown is the 4 lines I excute for each vertex... which are:
pVertex[dwCurrentVertex].p = D3DXVECTOR3(x, y, z);
pVertex[dwCurrentVertex].n = D3DXVECTOR3(0, 1, 0);
pVertex[dwCurrentVertex].u = x / dwMapSize * 8;
pVertex[dwCurrentVertex].v = z / dwMapSize * 8;
These four lines causes my bottleneck!!!
The writing to the VertexBuffer!!
Why is it happenning..?
pVertex[dwCurrentVertex].p = D3DXVECTOR3(x, y, z);
This causes a temporary vector to be created then copied to your vertex. I''d manually copy the xyz values.
pVertex[dwCurrentVertex].u = x / dwMapSize * 8;
You can easily precalculate 8 / dwMapSize and then multiply x & y by this instead of doing it per loop.
Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions
This causes a temporary vector to be created then copied to your vertex. I''d manually copy the xyz values.
pVertex[dwCurrentVertex].u = x / dwMapSize * 8;
You can easily precalculate 8 / dwMapSize and then multiply x & y by this instead of doing it per loop.
Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions
Author
I lose about 5FPS when the only thing I do per vetex is:
pVertex[dwCurrentVertex].u = 1.0f;
5FPS loss without even rendering anything or puting anything else into the buffer... I use multiple vertex buffers, dynamic, write only, discarded every lock...
I lose 5FPS when I write 4 bytes per vertex into the buffer... this is so strange!!
EDIT: Can it be a driver problem and not an application problem?
[edited by - z9u2K on June 28, 2002 3:23:10 PM]
pVertex[dwCurrentVertex].u = 1.0f;
5FPS loss without even rendering anything or puting anything else into the buffer... I use multiple vertex buffers, dynamic, write only, discarded every lock...
I lose 5FPS when I write 4 bytes per vertex into the buffer... this is so strange!!
EDIT: Can it be a driver problem and not an application problem?
[edited by - z9u2K on June 28, 2002 3:23:10 PM]
Are you locking the vertex buffer and retrieving a pointer to a vertex structure and manually copy all your values, if so make a pointer to a byte structure and use memcpy to copy your vertices this is faster and the shorter time you lock the faster it''ll go.
PS. This is how it''s done in the SDK check the vertices tutorial DS.
// Shadows
PS. This is how it''s done in the SDK check the vertices tutorial DS.
// Shadows
However if I should make a suggestion (I haven''t read through the entire thread so this might have been touched on before) don''t use ROAM during runtime I believe - and remember that I might be terribly wrong here but anyway - I believe that you won''t have any real benefits of using roam during runtime with today''s hardware instead calculate a number of LODs for your terrain and swap between these levels depending on how far you are (or the camera is) from that terrain, however if you still want to use ROAM do it in the following way.
1.) Calculate all vertex positions.
2.) Save all vertices (I believe that 65535 (an integer) is the boundary for the number of vertices you can render with each DrawPrimitive() call however it might be the number of triangles) you are going to use in one (or more) buffer(s).
3.) Set all renderstates.
4.) Render your terrain with as few DrawPrimitive() calls as possible (I don''t know if it''s slower to render 16000 vertices with one call then to render 2000 triangles 8 times so try it out).
Regards Shadows
1.) Calculate all vertex positions.
2.) Save all vertices (I believe that 65535 (an integer) is the boundary for the number of vertices you can render with each DrawPrimitive() call however it might be the number of triangles) you are going to use in one (or more) buffer(s).
3.) Set all renderstates.
4.) Render your terrain with as few DrawPrimitive() calls as possible (I don''t know if it''s slower to render 16000 vertices with one call then to render 2000 triangles 8 times so try it out).
Regards Shadows
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
