<p>Flood filling is not a very GPU-friendly operation to begin with, and the algorithm described in the paper is not a very good way to go about flood-filling on the GPU either. It might be possible to make it happen with some heroic efforts and compute shaders, but if flood-filling is what you want to do, I would use a different approach altogether. For example <a href="https://gamedev.stackexchange.com/a/150033/9894">this answer</a> describes how to do flood-filling with a multi-pass approach where each pass extends the filled region by 1 pixel in all directions. It will take a lot of passes to fill a large region. You could probably use some variant of <a href="https://blog.demofox.org/2016/02/29/fast-voronoi-diagrams-and-distance-dield-textures-on-the-gpu-with-the-jump-flooding-algorithm/" rel="nofollow noreferrer">jump flooding</a> for a more efficient method.</p>

<p>However, if you don't actually care about flood filling but are just looking to do exercises to learn GPU programming, I'd recommend trying things like: blur filters, outlining, color transforms, image warping, and so on as those will be a lot more straightforward than any kind of flood fill.</p>

CC BY-SA 4.0
2020-05-24T19:44:09.817Z
2020-05-24T19:44:09.817Z
Nathan Reed
<p><strong>EDIT</strong></p>

<p>After rereading your question, I got the feeling, that I misunderstood your question. So I'll expand my answer referring to this specific part of your question:</p>

<blockquote>
  <p>Maybe we can perform this logic on the CPU and use it to make a texture? The problem here is that I don't know of any way to access and modify specific pixels outside of shaders.</p>
</blockquote>

<p>A texture is basically just an array of (color) values. If you have a 256x256 image, that uses 3 color values (RGB) and each color value is stored in a single byte (<code>GLubyte</code>/<code>char</code>), then your array has 196608 byte sized elements. The color values are usually grouped so that 3 subsequent values represent a single pixel. Then the pixels are also ordered by column and row. So the first 765 array elements represent your first row/column of pixels in the image, the next 765 the second, and so on. With this information, you can calculate where every pixel is located in the image and modify its value as desired.</p>

<p>In case the texture you want to modify is loaded from a file, you should already have the pixel data since this is the format that OpenGL expects when you upload your texture. If the texture is dynamically generated on the GPU, just look into the previous version of my answer (below) for further guidance.</p>

<p>However, calculating lots of pixel data on the CPU is probably quite ineffective. I think the best solution would be to do all modifications on the GPU. If you can't achieve what you want with the standard render pipeline, you should read some tutorials about OpenGL compute shaders. I haven't worked myself with them yet, but I am pretty confident, that your problem should be solvable with them. </p>

<p><strong>Previous version</strong></p>

<p>According to <a href="https://community.khronos.org/t/fastest-way-to-transfer-texture-data-from-gpu-to-ram-and-back/46011" rel="nofollow noreferrer">this discussion in the official OpenGL Forum</a>, you can use <code>glReadPixels</code> to get a texture from VRAM back to your normal RAM. However, in the <a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadPixels.xhtml" rel="nofollow noreferrer">reference pages</a>, they say:</p>

<blockquote>
  <p>glReadPixels, glReadnPixels — read a block of pixels from the frame buffer</p>
</blockquote>

<p>Important here is the term "frame buffer". To find out how to use it with textures, have a look at <a href="https://stackoverflow.com/questions/11863416/read-texture-bytes-with-glreadpixels">this StackOverflow question</a>.</p>

<p>However, the accepted answer also mentions, that you can use <code>glGetTexImage</code> (<a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetTexImage.xhtml" rel="nofollow noreferrer">link to reference page</a>), which is probably more suited. Have a look into the accepted answer of this <a href="https://stackoverflow.com/questions/48938930/pixel-access-with-glgetteximage">StackOverflow link</a> to get an understanding of how to use it. </p>

<p>Both methods should give you the pixel data on the CPU side, so you can modify it as you wish and send it back to the GPU afterward. However, this is probably a relatively slow approach.</p>

CC BY-SA 4.0
2020-04-24T13:16:21.563Z
2020-04-24T13:51:35.347Z
2020-04-24T13:51:35.347Z
wychmaster
<p>I'm trying to implement the following paper in modern OpenGL</p>

<p><a href="http://web.media.mit.edu/~lieber/Publications/Coloring-Book.pdf" rel="nofollow noreferrer">http://web.media.mit.edu/~lieber/Publications/Coloring-Book.pdf</a></p>

<p>The issue is that the algorithm described requires you to consider interior points in an orderly fashion -- horizontally first, then vertically. You also need a way to remember throughout the entire coloring process which parts have been already colored. </p>

<p>I initially thought of putting the logic in a fragment shader, but that will clearly not work because I have no control over the order in which it is called, and also no way to remember state between different invocations.</p>

<p>Maybe we can perform this logic on the CPU and use it to make a texture? The problem here is that I don't know of any way to access and modify specific pixels outside of shaders.</p>

<p>Note that doing this using the fixed function pipeline would be much more straightforward, but I want to learn modern OpenGL.</p>

<p>I'm very new to OpenGL and graphics programming, so would appreciate any suggestions on how one would go about this.</p>

<shader>
Coloring arbitrary closed regions
root
# Coloring arbitrary closed regions

(Asked by: username_0 on 2020-04-24)

I'm trying to implement the following paper in modern OpenGL

<http://web.media.mit.edu/~lieber/Publications/Coloring-Book.pdf>

The issue is that the algorithm described requires you to consider interior points in an orderly fashion -- horizontally first, then vertically. You also need a way to remember throughout the entire coloring process which parts have been already colored.

I initially thought of putting the logic in a fragment shader, but that will clearly not work because I have no control over the order in which it is called, and also no way to remember state between different invocations.

Maybe we can perform this logic on the CPU and use it to make a texture? The problem here is that I don't know of any way to access and modify specific pixels outside of shaders.

Note that doing this using the fixed function pipeline would be much more straightforward, but I want to learn modern OpenGL.

I'm very new to OpenGL and graphics programming, so would appreciate any suggestions on how one would go about this.

**Tags:** shader


---

## 2 answers

### Answer by username_1 on 2020-05-24. Score: 2 | Accepted answer

Flood filling is not a very GPU-friendly operation to begin with, and the algorithm described in the paper is not a very good way to go about flood-filling on the GPU either. It might be possible to make it happen with some heroic efforts and compute shaders, but if flood-filling is what you want to do, I would use a different approach altogether. For example [this answer](https://gamedev.stackexchange.com/a/150033/9894) describes how to do flood-filling with a multi-pass approach where each pass extends the filled region by 1 pixel in all directions. It will take a lot of passes to fill a large region. You could probably use some variant of [jump flooding](https://blog.demofox.org/2016/02/29/fast-voronoi-diagrams-and-distance-dield-textures-on-the-gpu-with-the-jump-flooding-algorithm/) for a more efficient method.

However, if you don't actually care about flood filling but are just looking to do exercises to learn GPU programming, I'd recommend trying things like: blur filters, outlining, color transforms, image warping, and so on as those will be a lot more straightforward than any kind of flood fill.


---

### Answer by username_2 on 2020-04-24. Score: 0

**EDIT**

After rereading your question, I got the feeling, that I misunderstood your question. So I'll expand my answer referring to this specific part of your question:

> Maybe we can perform this logic on the CPU and use it to make a texture? The problem here is that I don't know of any way to access and modify specific pixels outside of shaders.

A texture is basically just an array of (color) values. If you have a 256x256 image, that uses 3 color values (RGB) and each color value is stored in a single byte (`GLubyte`/`char`), then your array has 196608 byte sized elements. The color values are usually grouped so that 3 subsequent values represent a single pixel. Then the pixels are also ordered by column and row. So the first 765 array elements represent your first row/column of pixels in the image, the next 765 the second, and so on. With this information, you can calculate where every pixel is located in the image and modify its value as desired.

In case the texture you want to modify is loaded from a file, you should already have the pixel data since this is the format that OpenGL expects when you upload your texture. If the texture is dynamically generated on the GPU, just look into the previous version of my answer (below) for further guidance.

However, calculating lots of pixel data on the CPU is probably quite ineffective. I think the best solution would be to do all modifications on the GPU. If you can't achieve what you want with the standard render pipeline, you should read some tutorials about OpenGL compute shaders. I haven't worked myself with them yet, but I am pretty confident, that your problem should be solvable with them.

**Previous version**

According to [this discussion in the official OpenGL Forum](https://community.khronos.org/t/fastest-way-to-transfer-texture-data-from-gpu-to-ram-and-back/46011), you can use `glReadPixels` to get a texture from VRAM back to your normal RAM. However, in the [reference pages](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glReadPixels.xhtml), they say:

> glReadPixels, glReadnPixels — read a block of pixels from the frame buffer

Important here is the term "frame buffer". To find out how to use it with textures, have a look at [this StackOverflow question](https://stackoverflow.com/questions/11863416/read-texture-bytes-with-glreadpixels).

However, the accepted answer also mentions, that you can use `glGetTexImage` ([link to reference page](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetTexImage.xhtml)), which is probably more suited. Have a look into the accepted answer of this [StackOverflow link](https://stackoverflow.com/questions/48938930/pixel-access-with-glgetteximage) to get an understanding of how to use it.

Both methods should give you the pixel data on the CPU side, so you can modify it as you wish and send it back to the GPU afterward. However, this is probably a relatively slow approach.


---

