Help with bounding frustum

KakCAT · February 24, 2022, 10:36am

Hi!

I’m trying to decide if I don’t understand bounding frustum at all or if the functions provided by monogame are not working correctly.

I have the following example:

gist.github.com

https://gist.github.com/KakCAT/59d59fbc738831b844896b691fd0259e

boundingFrustumTest.cs


static void testFunction ()
{
Vector3 camPos,camDir;

	// test camera looking into X direction
	camPos=new Vector3 (0,0,0);
	camDir=new Vector3 (1,0,0);
	doFrustumTest (camPos,camDir);

This file has been truncated. show original

‘doFrustumTest’ creates a box in front of and behind a frustum, and checks if it’s intersecting (when it’s in front) and disjoint (when it’s behind).

Then ‘testFunction’ uses ‘doFrustumTest’ to check different combinations of camera positions and camera directions. The first two work, but the third one (a camera looking slightly into the sky) fails.

Any ideas why this happens? Shouldn’t the third test pass?

Thanks!

EDIT: I know that ‘doFrustumTest’ is not valid for all combinations of camera directions, but it shouldn’t fail with the supplied vectors in the third test.

Squarebananas · February 24, 2022, 6:35pm

This seems to be a false positive where it is reporting an intersection where there is none.

The frustum is represented by 6 planes with each plane extending infinitely. The box needs to be in front of at least 1 of the 6 planes for a disjoint containment type. However stepping through the source the box is behind 1 plane (the far plane) and intersects the other 5 planes.

My understanding is frustum intersection tests in MonoGame are a quick test that may include false positives for performance reasons. If it is vital that no false positives occur another test such as a separating axis theorem test could then be used afterwards but this is much more computationally expensive and isn’t normally used for fast object render culling.

KakCAT · February 25, 2022, 9:18am

Hi Squarebananas, thanks for taking the time to confirm this. I really didn’t know if I was doing something conceptually wrong or if it was a MG problem.

I’ll move the example to the github issues. I have no problem with it giving false positives in awkward conditions (although I don’t think my conditions ingame were awkward at all) for the sake of speed, but should at least be remarked.

I suppose I’ll change my frustum checking functions for some kind of 2D frustum checking, after all my camera never rolls and should be lighter and easier.

Thanks!