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 :)
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.
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.
I have a PBO which is updated each frame by CUDA. After it, I also want to update a texture using this PBO, which I do using glTexSubImage2d. I'm afraid updating the whole texture is expensive and would like to update only the viewable region of the texture while my PBO has the whole data on it.
The problem is that, although glTexSubImage2d accepts an offset, width and height as parameters, they're only used when painting to the texture, while I still need my buffer data to be linearly layed. I'm afraid preparing the buffer data myself might be too expensive (actually it would be extremely expensive, since my PBO resides in GPU memory.)
Is there any alternative to glTexSubImage2d which also takes parameters for the buffer offset or should I keep updating the whole texture at once?
Please read up on the pixel store parameters, set with glPixelStore. The parameters GL_UNPACK_ROW_LENGTH, GL_UNPACK_SKIP_PIXELS and GL_UNPACK_SKIP_ROWS are of most interest for you:
These values are provided as a convenience to the programmer; they provide no functionality that cannot be duplicated by incrementing the pointer passed to glDrawPixels, glTexImage1D, glTexImage2D, glTexSubImage1D, glTexSubImage2D, glBitmap, or glPolygonStipple. Setting GL_UNPACK_SKIP_PIXELS to i is equivalent to incrementing the pointer by i n components or indices, where n is the number of components or indices in each pixel. Setting GL_UNPACK_SKIP_ROWS to j is equivalent to incrementing the pointer by j k components or indices, where k is the number of components or indices per row, as just computed in the GL_UNPACK_ROW_LENGTH section.
You're still going to use glTexImage and/or glTexSubImage for data transfer.
glTexSubimage2D has errors on getting data from the PBO if the selected ROI in the texture is not equal to the whole texture size.
That is a known issue which may not be fixed (e.g. opengl forum thread).
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).
Have anyone tried this (how-can-i-use-a-dynamically-sized-texture-array-with-glteximage2d) with glTexSubImage2D instead? I really need it and I can't put it to work properly, all I get is a striped, funny coloured square on my original texture.
What do you mean, you need it ?
glTexSubImage2D redefines a contiguous
subregion of an existing
two-dimensional texture image.
What that means is that you need to specify the size of your texture with glTexImage2D. That is what that API is for.
glTexSubImage2D is only there to update (parts of) the contents of an already defined Texture.
glTexSubImage2D does not resize your texture.
All it does is update a rectangle of your existing texture with new texels/pixels.
If you need to change the size of your texture you will need to create a new texture of the correct size and discard the old one.