The `Index Buffer` will need updating every frame based on what the camera can see.
The `Vertex Buffer` will only need updating every time a block is destroyed.This may only happen once every 1.5 seconds, based on the rate you can destroy blocks.
Notice the index buffer is made up of 4 byte integers. If you had 150,000 faces in your vertex buffer, you will need 900,000 indices to draw every face.
Add frustum culling, which will take it down to ~33% (Based on what the camera can see), 297,000 indices is now required to draw all the faces that the camera can see.
297,000 indices * 4 bytes = 1.13MB
That amount of data should have no proplem being sent down to the grapihcs card every frame.
- Viewing Profile: Posts: bullfrog
14 years ago on June 15th Gamedev.net was first launched! We want to thank all of you for being part of our community and hope the best years are ahead of us. Happy birthday Gamedev.net!
Community Stats
- Group Members
- Active Posts 14
- Profile Views 629
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
-
Gender
Not Telling
399
Good
User Tools
Contacts
bullfrog hasn't added any contacts yet.
Latest Visitors
Posts I've Made
In Topic: Face Instancing: Dividing Draw Calls?
08 August 2012 - 06:38 PM
In Topic: Face Instancing: Dividing Draw Calls?
08 August 2012 - 03:47 AM
Yes it will, the less draw calls the better in most situlations.
You may be going around the problem in the wrong way. The graphics card is made to have huge amounts of vertices and indices deleted and loaded every frame.
Heres how I got around this same problem with a very good frame rate.
For every chunk, calculate which cube faces are visible, then store the vertices and indices for the faces in memory.
Create 1 very large static vertex buffer and fill it with all vertices from all the chunks.
Create 1 very large dynamic index buffer.
Every frame use frustum culling to find with chunks are visible to the camera, fill the index buffer with the indices from the visible chunks and draw.
If a cube is destoryed, you will need to reload the visible faces for that chunk and refill the whole vertex buffer. Don't worry like I said, graphics cards are built to do this!
You may be going around the problem in the wrong way. The graphics card is made to have huge amounts of vertices and indices deleted and loaded every frame.
Heres how I got around this same problem with a very good frame rate.
For every chunk, calculate which cube faces are visible, then store the vertices and indices for the faces in memory.
Create 1 very large static vertex buffer and fill it with all vertices from all the chunks.
Create 1 very large dynamic index buffer.
Every frame use frustum culling to find with chunks are visible to the camera, fill the index buffer with the indices from the visible chunks and draw.
If a cube is destoryed, you will need to reload the visible faces for that chunk and refill the whole vertex buffer. Don't worry like I said, graphics cards are built to do this!
In Topic: Null pointer exception during primitives draw call.
06 June 2012 - 06:09 PM
You know what the problem is. The `device` variable is NULL and you are calling draw on it. Step through your code to find why the device is NULL. If you use visual studio, use the call stack.
In Topic: Class Function Overloading Method Question
11 May 2012 - 03:10 AM
This is more of a `Is this the correct way of doing it` question. But I have added functionality if it helps.
So the user adds a CPlayerModel to their game. They need to call Draw on the CPlayerModel.
They have the choice of either CModel::Draw or CPlayerModel::Draw. Both are available to be called even though CPlayerModel::Draw should be the only function that used be for drawing this object type.
What stops the user from calling the CModel::Draw? Or should the user just have the "Smarts" or do the research before choosing which draw function to use?
class CModel
{
void Draw(CRenderer& _rRenderer)
{
rRenderer.DrawIndexBuffer(m_uiIndexBufferId);
}
}
class CPlayerModel : public CModel
{
void Draw(CRenderer& _rRenderer, const CVector3& _krPlayerPosition)
{
SetModelPosition(krPlayerPosition);
CModel::Draw(rRenderer);
}
}
So the user adds a CPlayerModel to their game. They need to call Draw on the CPlayerModel.
They have the choice of either CModel::Draw or CPlayerModel::Draw. Both are available to be called even though CPlayerModel::Draw should be the only function that used be for drawing this object type.
What stops the user from calling the CModel::Draw? Or should the user just have the "Smarts" or do the research before choosing which draw function to use?
In Topic: Visual Studio C++ Release Build Issue
06 May 2012 - 08:00 PM
Without seeing the code there is only so much other people can do to help you. Such as pointing out common causes to this issue.
- not defining default values for variables
- putting functions into debug only macros, such as asserts
- memory trampling
- not defining default values for variables
- putting functions into debug only macros, such as asserts
- memory trampling
- Home
- » Viewing Profile: Posts: bullfrog

Find content