Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualvoodoodrul

Posted 05 July 2013 - 05:39 PM

glBufferData will trash the buffer, yes; think of it as being the same as calling glTexImage at runtime (i.e. you most definitely don't want to do it).  It's difficult to recommend a better buffer update strategy without having a clear understanding of exactly what the problem that the OP is trying to solve actually is, so more detail around those lines would be appreciated.

It's probably best to refer you to my earlier thread - http://www.gamedev.net/topic/644944-optimization-of-many-small-gldrawelements-calls/

 

Just focus on the last couple entries there to get a feel for how I am creating vertex arrays. 

 

Sorry for creating another thread, but I guess I had diverged from the initial problem enough to facilitate a new one.. 

 

As you can see, that's how I'm drawing my cubes and populating a vertex array. It works well as long as I explicitly call glDeleteBuffers() and glGenBuffers() again before populating the VBO. 

 

I have discovered that these rogue faces occur on the edges of chunks - each chunk is a:

glPushMatrix()

glTranslatef()

//draw VBO

glPopMatrix();

 

It's as if the degenerate verticies I am using to draw only certain faces are "bleeding over" into the next chunk.render(), but that's a completely unique glBindBuffer() operation and shouldn't impact the previous one..

 

Is it possible that the glGenBuffers() just slows it down enough to sit inside of some race condition or state issue? Clearly everything in the render() loop should be occurring in a single thread anyway so I doubt it. I do offload work into thread for things like building the vertex arrays (converting the chunk to a mesh) and then flag that chunk as "ready" for the render loop to actually push it in to the VBO if not already.. 


#2voodoodrul

Posted 05 July 2013 - 05:21 PM

glBufferData will trash the buffer, yes; think of it as being the same as calling glTexImage at runtime (i.e. you most definitely don't want to do it).  It's difficult to recommend a better buffer update strategy without having a clear understanding of exactly what the problem that the OP is trying to solve actually is, so more detail around those lines would be appreciated.

It's probably best to refer you to my earlier thread - http://www.gamedev.net/topic/644944-optimization-of-many-small-gldrawelements-calls/

 

Just focus on the last couple entries there to get a feel for how I am creating vertex arrays. 

 

Sorry for creating another thread, but I guess I had diverged from the initial problem enough to facilitate a new one.. 

 

As you can see, that's how I'm drawing my cubes and populating a vertex array. It works well as long as I explicitly call glDeleteBuffers() and glGenBuffers() again before populating the VBO. 

 

Is it possible that the glGenBuffers() just slows it down enough to sit inside of some race condition or state issue? Clearly everything in the render() loop should be occurring in a single thread anyway so I doubt it. I do offload work into thread for things like building the vertex arrays (converting the chunk to a mesh) and then flag that chunk as "ready" for the render loop to actually push it in to the VBO if not already.. 


#1voodoodrul

Posted 05 July 2013 - 05:20 PM

glBufferData will trash the buffer, yes; think of it as being the same as calling glTexImage at runtime (i.e. you most definitely don't want to do it).  It's difficult to recommend a better buffer update strategy without having a clear understanding of exactly what the problem that the OP is trying to solve actually is, so more detail around those lines would be appreciated.

It's probably best to refer you to my earlier thread - http://www.gamedev.net/topic/644944-optimization-of-many-small-gldrawelements-calls/

 

Sorry for creating another thread, but I guess I had diverged from the initial problem enough to facilitate a new one.. 

 

As you can see, that's how I'm drawing my cubes and populating a vertex array. It works well as long as I explicitly call glDeleteBuffers() and glGenBuffers() again before populating the VBO. 

 

Is it possible that the glGenBuffers() just slows it down enough to sit inside of some race condition or state issue? Clearly everything in the render() loop should be occurring in a single thread anyway so I doubt it. I do offload work into thread for things like building the vertex arrays (converting the chunk to a mesh) and then flag that chunk as "ready" for the render loop to actually push it in to the VBO if not already.. 


PARTNERS