The occlusion query extension is written in such a way as to allow for the specification of different types of queries. I suggest adding bounding region or bounding frustum queries.
At the moment, occlusion queries can only be used to check the number of fragments the are passed by the fragment shader and subsequent fragment tests. This behaviour is defined by the target parameter “SAMPLES_PASSED_ARB”.
The ARB query is preceeded by extensions from HP and NV. The original HP occlusion query only provides feedback on whether or not any fragments passed all fragment tests, the NV occlusion query returns a count of passed fragments, and the ARB query added the possibility of extensiblity to other types of queries.
I would like to see queries that return some form of coordinate range for rendered fragments. For example, the screen-space region or the minimum and maximum eye space x, y, and z coordinates of rendered fragments.
I’ll describe a few ways in which this could be useful.
Case 1: “Where did the object appear?”. One could render an object and check if a portion of the object appears on an area of the screen (or even within a volume of space).
Case 2: “Optimising shadows”. Much like shadow maps, render an object from the point of view of a light source. Query the range of each coordinate to determine a frustum. Everything outside this frustum is definitely not shadowed by the object.
Case 3: “Optimising portals” (similar to case 2). Render a portal. Query the eye space range of each coordinate to determine a frustum that can be used for conservative object culling and geometry clipping (reducing the amount of data that makes it to the fragment processing stage).
I think that returning the eye space range or frustum is ideal, but the simpler query of the 2D region (for basic scissoring) would also be useful. Either result could be interpreted from the other.
Here are some suggestions for new targets: SAMPLES_PASSED_REGION_ARB, SAMPLES_PASSED_FRUSTUM_ARB.
If floating point data is returned (probably for a frustum query, but not for a region query) additional functions will be required such as: void GetQueryObjectfvARB(uint id, enum pname, float *params);
I’m not sure about how amenable this is to hardware implementation. However, it seems to that it would require conditional writes global variables for each fragment that passes all fragment tests.