And this does seem limited in that the plane that the testing is done on must be perpendicular to the camera... I suspect the math/calculations to get this with an angled plane would be far, far more beastly.
And to add to that I highly suspect this could be refactored to be leaner... maybe... Dunno, my brain's running out of steam at the moment so I think that's about it for now.
That said, This isn't for side-to-side offsetting but there is room in there for up and down for those of you that have camera objects that are elevated over or below the player (and nested in a controlling game object...)
EDIT: Whoops, looks like refactoring it broke it...
So, these screenshots aren't correct. (apologies on that front.) Fixed and updated the screenshot.
There are limitations to this... Since this is a camera that's nestled as a child of the game-object, if the camera field would not be wide enough to cover the parent object, it starts to break... And it can handle left and right apparently (according to the testing I've done.) so, seems pretty good on that front. even though I kinda figured it out I still want to thank y'all for tolerating my brain-dump
And if you're asking yourself why you'd want to know the offsets to know how far away the borders are of the camera boundaries relative to the player (whilst locked to one plane and perpendicular?) Well, side-scrolling games use something like this a lot... Granted, most side-scrollers have the camera limited in that it simply won't travel off of the plane since they're dealing with 2D sprites only (Sonic, Mario, etc) but having it like this would give the system the ability to detect where the boundaries are so that you can place a boundary object/flag/location explicitly without having to fiddle with the placement to ensure that the framing is correct and also without having to worry about screen aspect changes (So, if one player is playing in wide-screen and another is not, you don't have to worry about one player seeing more than the other.)