Determine percentage of screen covered by an object without using frustum culling

On the CPU-side of an 3D first-person / ego perspective game I need to check whether what the players currently sees on screen is the inside of a box object defined by world space coordinates (the player might be outside of that box but on screen sees only/mostly the inside of the box, or vice-versa, looks from within the box to the outside).

The "casual" way of performing such a check would incorporate frustum culling but such an approach would be hard to achieve with my given set of engine parameters which I'd like to avoid if there is a simpler way.

What I actually have at the point where I would like to do the check (high-level script on CPU, not GPU side):

• Camera world position
• Camera direction
• Camera FOV
• Two Box corner world coordinates (left-bottom-front, right-top-back)

What I do not have right away:

• View frustrum definition (near/far plane or say 6 planes defining frustum)
• Any specific pixel information (uv, view space position, depth or the like)

What I would like to calculate:

• Percentage of screen "covered" by box.

Any hints on how to perform such calculation?

Here's a rough sketch of an algorithm that might do this.

Use the camera to calculate an inverse view projection matrix. Then transform all the cube's vertices using this matrix. You now have all the vertices in screen space (-1~1). Compute the convex hull of all these vertices and then clip this convex hull inside the screen space. You now have a polygon of which you can compute the area. The total area of the screens space is 4 so its easy to compute a percentage and this method is independent on resolutions and aspect ratios.

• I hope you are not implying that screen space (window-space) is [0,1] with this statement: "You now have all the vertices in screen space (0~1)". About the only thing in window-space that is usually in that range is the depth, as the default depth range in most APIs is [0,1]. I also cannot figure out where the idea of window-space having an area of 1 comes from? Are you thinking of some different coordinate space? Even NDC is actually [-1,1] in X and Y, thus it would have an area of 4. Can you elaborate? – Andon M. Coleman Jun 13 '14 at 11:24
• My bad it is indeed [-1,1] with an area of 4. Just a simple mistake. – Roy T. Jun 13 '14 at 11:35
• Thanks; "Use the camera to calculate an inverse view projection matrix" how would I do this? Not sure I understand... – Meltac Jun 16 '14 at 15:37
• Normally you use your camera and its look at to calculate a normal view-project matrix. For the inverse see gamedev.net/topic/595333-inverse-of-view-projection-matrix – Roy T. Jun 17 '14 at 15:34
• Thank you. Would there be a yet simpler way, without all those matrix calculation stuff? I had thought of some check using the view angles between the camera direction and the view vector (direction) to the cube's corners or center point. That way I could for example determine whether a certain point (i.e. corner vertex) is located inside or outside of the screen boundaries, only be checking view angle and distance, thus avoiding the requirement of any world-to-screen-space or whatever matrix calculations. – Meltac Jun 18 '14 at 8:34

According to the book Real-Time Cinematography for Games, the fastest but least accurate way to do this is by calculating the projection of an object's bounding sphere onto the viewplane of the camera.

r = f*r_w / (v . (p_w - q))

Where:

f = focal length

r_w = bounding sphere radius of the object

v = normalized camera direction

p_w = bounding center of object

q = camera location

. = dot product

Finally, the area of the object on the screen space is:

a = PI*r^2

Similarly you can project the 8 corners of the bounding box onto the screen plane and calculate the bounding box area.