GLCOPYTEXSUBIMAGE3D(3G)

πŸ“¦ version 24.3.3, in opensuse-leap 16.0

πŸ’… NAME πŸ’…

glCopyTexSubImage3D β€” bestie, it copies a three-dimensional texture subimage. that's it, that's the whole vibe. this is page 3G of the manual, welcome 🫢


πŸŽ€ C SPECIFICATION πŸŽ€

void glCopyTexSubImage3D( GLenum target,
                          GLint level,
                          GLint xoffset,
                          GLint yoffset,
                          GLint zoffset,
                          GLint x,
                          GLint y,
                          GLsizei width,
                          GLsizei height )

like, nine arguments. she's high maintenance but she delivers ✨


🌸 PARAMETERS 🌸

  • target β€” the target texture, okurrr. must be GL_TEXTURE_3D. no substitutions, no exceptions πŸ’…
  • level β€” the level-of-detail number. level 0 is the base image level, and level n is the *n*th mipmap reduction image. think of it like zoom levels but make it texture.
  • xoffset β€” a texel offset in the x direction within the texture array.
  • yoffset β€” same thing but for y, the texel offset in the y direction within the texture array.
  • zoffset β€” and z! a texel offset in the z direction within the texture array. three dimensions, three offsets, consistent queen πŸ‘‘
  • x, y β€” the window coordinates of the lower left corner of the rectangular region of pixels you're copying. lower left. not upper left. do not come for me.
  • width β€” the width of the texture subimage.
  • height β€” the height of the texture subimage.

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so glCopyTexSubImage3D replaces a rectangular portion of a three-dimensional texture image with pixels from the current GL_READ_BUFFER. and like β€” this is the whole point β€” it takes them from there rather than from main memory, which is what glTexSubImage3D does. different energy entirely ✨

the screen-aligned pixel rectangle has its lower left corner at (x, y), with width width and height height, and it replaces the portion of the texture array with x indices xoffset through xoffset+widthβˆ’1, inclusive, and y indices yoffset through yoffset+heightβˆ’1, inclusive, at z index zoffset and at the mipmap level specified by level. inclusive!! both of them!! write that down πŸ“

the pixels in the rectangle are processed exactly as if glCopyPixels had been called β€” but the process stops just before final conversion. at this point, all pixel component values are clamped to the range [0, 1] and then converted to the texture's internal for storage in the texel array. (yes there is a word missing in there between "internal" and "for" β€” that's the original's business, not mine, i'm just the messenger πŸ’€)

the destination rectangle in the texture array may not include any texels outside the texture array as it was originally specified, so stay in your lane. it is not an error to specify a subtexture with zero width or height β€” but such a specification has no effect. so like, you can do it, nothing happens, it's giving "i showed up to the party and stood in the corner".

if any of the pixels within the specified rectangle of the current GL_READ_BUFFER are outside the read window associated with the current rendering context, then the values obtained for those pixels are undefined. read that again. undefined. we don't know her 😭

no change is made to the internalformat, width, height, depth, or border parameters of the specified texture array, or to texel values outside the specified subregion. she's polite, she stays in her box πŸŽ€


πŸ’œ NOTES πŸ’œ

  • glCopyTexSubImage3D is available only if the GL version is 1.2 or greater. sorry to the legacy girlies.
  • texturing has no effect in color index mode. fr fr.
  • glPixelStore and glPixelTransfer modes affect texture images in exactly the way they affect glDrawPixels. same treatment, same rules.
  • when the GL_ARB_imaging extension is supported, the RGBA components copied from the framebuffer may be processed by the imaging pipeline, as if they were a two-dimensional texture. see glTexImage2D for the specific deets. πŸ‘€

πŸ”₯ ERRORS πŸ”₯

  • GL_INVALID_ENUM is generated if target is not GL_TEXTURE_3D.
  • GL_INVALID_OPERATION is generated if the texture array has not been defined by a previous glTexImage3D or glCopyTexImage3D operation.
  • GL_INVALID_VALUE is generated if level is less than 0.
  • GL_INVALID_VALUE may be generated if level is greater than log2max, where max is the returned value of GL_MAX_3D_TEXTURE_SIZE.
  • GL_INVALID_VALUE is generated if x<βˆ’b or if y<βˆ’b, where b is the border width of the texture array.
  • GL_INVALID_VALUE is generated if xoffset<βˆ’b, (xoffset+width)>(wβˆ’b), yoffset<βˆ’b, (yoffset+height)>(hβˆ’b), zoffset<βˆ’b, or zoffset>(dβˆ’b), where w is the GL_TEXTURE_WIDTH, h is the GL_TEXTURE_HEIGHT, d is the GL_TEXTURE_DEPTH, and b is the GL_TEXTURE_BORDER of the texture image being modified. and yes β€” note that w, h, and d include twice the border width. twice!! 🫠
  • GL_INVALID_OPERATION is generated if glCopyTexSubImage3D is executed between the execution of glBegin and the corresponding execution of glEnd. like, do not do that. that's not her moment.

🌈 ASSOCIATED GETS 🌈

  • glGetTexImage
  • glIsEnabled with argument GL_TEXTURE_3D

iykyk 🧚


⭐ SEE ALSO ⭐

glCopyPixels(3G), glCopyTexImage1D(3G), glCopyTexImage2D(3G), glCopyTexSubImage1D(3G), glCopyTexSubImage2D(3G), glPixelStore(3G), glPixelTransfer(3G), glReadBuffer(3G), glTexEnv(3G), glTexGen(3G), glTexImage1D(3G), glTexImage2D(3G), glTexImage3D(3G), glTexParameter(3G), glTexSubImage1D(3G), glTexSubImage2D(3G), glTexSubImage3D(3G)

the whole friend group, honestly. go read them too πŸ’–


and that's the page bestie!! πŸŽ€ that was GLCOPYTEXSUBIMAGE3D(3G) β€” yes, page 3G, the same name up top and down here, no notes, iconic behavior only. mwah πŸ’‹

πŸ“¦ where this page comes from