Posted by elect on Feb 10, 2016; 2:30pm
URL: https://forum.jogamp.org/Extending-Functionality-of-Shader-Programs-tp4036139p4036146.html

Ok, I got it by looking at the wiki sample

So, it seems you really need to count the pixels inside, I can already tell you this should be a pretty easy task.

What can be hard, instead, is calculating the boundary points.. since this involves some trick and approximations errors can play a big role here..

Anyway, to come back to the interior points calculation, what you can do is:

- clearing with a blank color
- find a way to understand if you are inside the geometry, you can do that by playing with depth values. You can achieve that by doing something similar to the depth peeling algorithm. I don't have clear in mind right now the steps you have to do, but it should be pretty feasible
- run a compute shader that for each pixel matching your geometry color (or != blank color) will increase an atomic counter
- retrieving all the counters (one for slice) and then sum up

Speaking about bottlenecks:

- atomic counter can only be unsigned int, so you have 2^32
- max texture size is 16k on recent hw, so you should have up to 2^14 * 2^14 = 2^28 bytes/pixels

About the shader syntax, sorry, I forgot to answer you on that part, it is exactly the same, except a little bug about including additional shaders with double quotes

this in C

#include "light.glsl"

must be written in jogl as

#include light.glsl

For the rest everything the same, the compiler is the same, so..