I need some clarifications about a paragraph of this wiki page:
https://www.opengl.org/wiki/Buffer_Object#Buffer_Object_Usage
COPY is used when a buffer object is used to pass data from one place in OpenGL to another. For example, you can read image data into a buffer, then use that image data as vertex data in a draw call. [...]
Does that mean that I can theoretically byte-by-byte copy data from a conventional 2D texture into a VBO? How do I do this? That may come in handy.
Related
From question/answer i know that once I bind GL_PIXEL_UNPACK_BUFFER, OpenGL will feed texture2D using the data in buffer bind to GL_PIXEL_UNPACK_BUFFER.
But while there are various shapes of textures, such as GL_TEXTURE_3D, GL_TEXTURE_1D... there is no such a attribute of GL_PIXEL_UNPACK_BUFFER's bound buffer which specifies the internal shape of its data. If I want to transfer data to a texture storage bind to GL_TEXTURE_3D using pbo, I need to first send data to the buffer bind to the pbo.
Do I need to care the data's layout I send to pbo? Like the data should be (xxx...,yyy...,zzz...) or (xyz,xyz,xyz...).
An example or pseudocode is helpful.
Using a pixel buffer in a pixel transfer operation changes one thing about pixel transfer operations: where the data comes from. When you don't use a PBO, the data comes from (or goes to) an address in memory you directly allocated. When you do use a PBO, the data comes from (or goes to) a byte offset into a buffer object's storage.
Nothing else about the pixel transfer operation changes. How the "packed" pixel data is laid out remains the same regardless of the location of the pixel transfer.
The matters you are talking about are governed by the nature of the pixel transfer operation you started (ie: what function you called) and the pixel transfer parameters you passed to it. Again, these work the same way regardless of whether you're using a buffer object or client memory.
Is there a method for binding only a single attribute of a VBO to a texture buffer object?
Problem is, I use an interleaved VBO for drawing spheres with the attributes position, radius and another one. Now, I want to use another shader which draws other stuff using instanced geometry at the positions in my sphere VBO.
What I could do is just texelFetch() the data I need which is really ugly concerning the needed alignment (VBO attributes have different size) and the unused space, which is bad because of the limited size of a texture buffer. Another way could be copying only the data I need from one VBO to a separate VBO, but that's not really satisfying either.
So... is there another possibility?
Buffer textures do not have attributes. So what you're talking about doesn't make sense.
Also, VBOs are not a thing; there is no such thing as a "VBO". There are simply buffer objects and different uses for them. glVertexAttribPointer does not modify the buffer object. It just tells OpenGL's vertex reading system how to fetch data from it. Other systems that fetch data from buffer objects use their own mechanisms for doing so, which are entirely separate.
Like buffer textures.
If you want to "draws other stuff using instanced geometry", why don't you just use instancing? Apply a divisor (presumably of 1) to those attributes, so that they will only get different values for different instances.
I'm writing data into a 3D texture from within a fragment shader, and I need to asynchronously read back said data into system memory. The only means of asynchronously initiating the packing operation into the buffer object seems to be calling glReadPixels() with a NULL pointer. But this function insists on getting passed a rectangle defining the region to read back. Now I don't know if these parameters are ignored when using PBOs, but I assume not. In this case, I have no idea what to pass to this function in order to obtain the whole 3D texture.
Even if have to read back individual slices (which would be kind of stupid IMO), I still have no idea how to communicate to OpenGL which slice to read from. Am I missing something?
BTW, I could use individual 2D textures for every slice, but that would screw up (3D-)mipmapping if I'm not mistaken. I wanted to use the 3D mipmaps in order to efficiently find regions of interest in the resulting 3D texture.
P.S. Sorry for the sub-optimal tags, apparently no one ever asked about 3d textures before and since I'm not allowed to create new tags...
Who says that glReadPixels is the only way to read image data? Maybe in OpenGL ES it is, but if you're using ES, you should say so. The rest of this answer will be assuming you're talking about desktop GL.
If you have a texture, and you want to read its contents, you should use glGetTexImage. The switch that controls whether it reads into a buffer object or not is the same switch that controls it for glReadPixels: whether a buffer is bound to GL_PIXEL_PACK_BUFFER.
Note that glGetTexImage will retrieve the entire texture (for a given mipmap level).
It seems as though glTexSubImage2D requires a pointer to the full texture buffer. How does one make partial updates to a texture by only providing a pointer to the update region rather than the whole buffer?
For example if I want to overlay a second image onto an existing texture, rather than copy the image data onto my texture buffer then call glTexSubImage2D, I just get opengl to update the texture without having to copy data between RAM locations.
Where do you get the notion that glTexSubImage2D requires a pointer to the full texture buffer ?
From the documentation linked above, it seems to me that the last parameter is a pointer to the buffer containing your new data only. The other parameters are what you use to specify which texture object to update (just an OpenGL identifier, no pointer to the original data required) and the offset and size to copy your new data to.
TL;DR: glTexSubImage2D takes a pointer to your new data and does exactly what you think it should in your example :)
What is the difference between FBO and PBO? Which one should I use for off-screen rendering?
What is the difference between FBO and PBO?
A better question is how are they similar. The only thing that is similar about them is their names.
A Framebuffer Object (note the capitalization: framebuffer is one word, not two) is an object that contains multiple images which can be used as render targets.
A Pixel Buffer Object is:
A Buffer Object. FBOs are not buffer objects. Again: framebuffer is one word.
A buffer object that is used for asynchronous uploading/downloading of pixel data to/from images.
If you want to render to a texture or just a non-screen framebuffer, then you use FBOs. If you're trying to read pixel data back to your application asynchronously, or you're trying to transfer pixel data to OpenGL images asynchronously, then you use PBOs.
They're nothing alike.
A FBO (Framebuffer object) is a target where you can render images other than the default frame buffer or screen.
A PBO (Pixel Buffer Object) allows asynchronous transfers of pixel data to and from the device. This can be helpful to improve overall performance when rendering if you have other things that can be done while waiting for the pixel transfer.
I would read VBOs, PBOs and FBOs:
Apple has posted two very nice bits of
sample code demonstrating PBOs and
FBOs. Even though these are
Mac-specific, as sample code they're
good on any platoform because PBOs and
FBOs are OpenGL extensions, not
windowing system extensions.
So what are all these objects? Here's
the situation:
I want to highlight something.
FBO it not memory block. I think it look like struct of pointer. You Must attach Texture to FBO to use it. After attach Texture you now can draw to it for offscreen render or for second pass effect.
struct FBO{
AttachColor0 *ptr0;
AttachColor1 *ptr1;
AttachColor2 *ptr2;
AttachDepth *ptr3;
};
In the other hand, PBO is memory block "block to hold type of memory. "Try to think of it as malloc of x size, then you can use memcpy to copy data from it to texture/FBO or to it".
Why to use PBO?
Create intermediate memory buffer to interface with Host memory and not stop OpenGL drawing will upload texture to or from host.