首页 > 代码库 > glsl-VBO- change

glsl-VBO- change

 

修改其值的最快方式:

创建:

Mutable Storage

To create mutable storage for a buffer object, you use this API:

void glBufferData?(enum target, sizeiptr size, const void *data, enum usage)

The target parameter is just like the one for glBindBuffer; it says which bound buffer to modify. size represents how many bytes you want to allocate in this buffer object.

The data parameter is a pointer to user memory that will be copied into the buffer object‘s data store. If this value is NULL, then no copying will occur, and the buffer object‘s data will be undefined.

The usage parameter can be very confusing.

修改:

glBufferSubData:

We have seen that glBufferData? can be used to update the data in a buffer object. However, this also reallocates the buffer object‘s storage. This is not usually what one wants, as recreating the buffer can often be a heavyweight operation.

Instead, one can use the following API:

void glBufferSubData?(enum target, intptr offset, sizeiptr size, const void *data)

The offset parameter is an integer offset into the buffer object where we should begin updating. The size parameter is the number of bytes we should copy out ofdata. For obvious reasons, data cannot be NULL.

Modifiable buffers With Mapping VS glBufferSubData: 

Generally speaking, mapping a buffer and writing to it will be equally as efficient as glBufferSubData?. And in most cases, it will be much faster, particularly if invalidation and other Buffer Object Streaming techniques are employed.

To cover this, flags? should be set to GL_MAP_WRITE_BIT?. This lets the implementation know that you will not be using glBufferSubData? at all.

 

glBufferSubData? is a nice way to present data to a buffer object. But it can be wasteful in performance, depending on your use patterns.

For example, if you have an algorithm that generates data that you want to store in the buffer object, you must first allocate some temporary memory to store that data in. Then you can use glBufferSubData? to transfer it to OpenGL‘s memory. Similarly, if you want to read data back, glGetBufferSubData? is perhaps not what you need, though this is less likely. It would be really nice if you could just get a pointer to the buffer object‘s storage and write directly to it.

You can. To do this, you must map the buffer. This gives you a pointer to memory that you can write to or read from, theoretically, just like any other. When you unmap the buffer, this invalidates the pointer (don‘t use it again), and the buffer object will be updated with the changes you made to it.

 

Mapping a VBO Code:

	glBindBuffer(GL_ARRAY_BUFFER,mVBOtrackMidHandle[0]);	float * pMidPathVertex=(float * )glMapBuffer(GL_ARRAY_BUFFER,GL_WRITE_ONLY);	for(int i=1;i<10;++i)	{		pMidPathVertex[i*12+7]=pMidPathVertex[(i-1)*12+4];		pMidPathVertex[i*12+10]=pMidPathVertex[(i-1)*12+1];		pMidPathVertex[i*12+4]=pMidPathVertex[i*12+7]-10;		pMidPathVertex[i*12+1]=pMidPathVertex[i*12+10]-10;	}	glUnmapBuffer(GL_ARRAY_BUFFER);

 

mapping weak:

Everything has a price. The price of this is that you must deal with the ordering of reads and writes. By mapping the buffer in this fashion, you are taking full responsibility for synchronizing mapped access operations with OpenGL (and with other direct uses of the API).

When you use a mapped pointer to write to a buffer, the data you write does not immediately become visible to OpenGL. It only becomes visible to OpenGL when you issue a glMemoryBarrier(GL_CLIENT_MAPPED_BUFFER_BARRIER_BIT)? call.

One thing to remember about buffer mapping is this: the implementation is not obligated in any way to give you an actual pointer to the buffer object‘s memory. It is perfectly capable of giving you a pointer to some memory that OpenGL allocated just for the purpose of mapping, then it will do the copy on its own time.

If you are attempting to stream data to the buffer, you should always map the buffer only for writing and you should write sequentially. You do not need to write every byte, but you should avoid going backwards or skipping around in the memory.