Screen Boundaries help needed.

[Red]

Okay, this is gonna be a math-heavy one so buckle up!

I'm trying to calculate the boundaries of the screen relative to the plane that the player is going to be locked to... And I've been working with the "get screen size ratio" action as well as the "get tan" action from the ecosystem.

so, first off I tell it to get the aspect ratio and file that in a variable... That's all fine and dandy... Then I get the FoV angle with a "get property" action and divide that by half to get the angle from the center to the top (since the FoV works with the Y axis in Unity.)

Then I use the "get tan" action to calculate the tangent to get the right distance from the center point to place the boundary marker (using a sphere as a test) and that works to get me the vertical offset... When I scale the window (having a separate system that will update the marker spheres if the aspect ratio changes which I'm manually calculating in another FSM but the function is the same as the "Get Screen Size Ratio" action) the top and bottom spheres stay where I want them to, right at the top and bottom of the screen.

Now here's where the difficult part comes in: How do I calculate the angle of the camera in the Horizontal?

The data that I have that I can work with is the FoV, the screen size ratio and the height/width of the screen itself.

[Red]

Hmm, musing/spitballing here...

But if I know the height and width of the screen in pixels and can get the distance between them in Unity-space... Then I could find a way to get a conversion factor made up...

So, if the height is 1000 pixels in height and the markers are 20 units apart, that would mean that one unit is 50 pixels.

So, now that I have the conversion... I can apply that rate (since it's assumed that a pixel is a square on nearly every screen out there) if the width is 1500 pixels, then with that conversion process that means that the screen is 30 units wide.

From there I guess I could hammer out the rest... because I already know the distance in units from the plane to the camera... And the distance in width (halved for the use of the functions) so, it'd then be... tan(A)=width/distance... so, A= arctan(width/distance)... But since I don't see an arctan I'm wondering... are arctan and atan the same thing? (I'm going off of some online geometry calculating pages to get the formulas... Math wasn't my strongest subject.)

EDIT: Waittaminute... If I know the conversion process... Then I already have my answer.

Since I already know the point at which to project the distance of the placement objects from, I can use the screen width in pixels and apply that conversion factor to get the distance in unity units... So I then take that value, divide it by half and extend out in both positive and negative this new value and that should give me the boundaries on the horizontal.

I'll give this a test to see if it does the trick.

[Red]

WOOT! IT works!

So, in order to get the distance to the screen boundaries relative to a plane (in my case the plane that the player is locked to)

Step one:
-Get the screen height and width.

-Get the Field of View for the camera.

-Get the distance between the camera and the plane.

-Divide the FoV by half

-Take resulting value and "get tan" of that angle (I have "deg to rad" checked.)

-Then multiply the distance by the tan y value and that's the distance from the center point to the upper and lower border in Unity Units.

-Now take the distance to the screen borders and multiply by two.

-Then you take the screen height and divide that by the new vertical distance. This will give you the conversion factor to apply to the screen width gained earlier.

-Now take the conversion and multiply that by the width in pixels.

-Divide that by two.

-That gets the offset in both the horizontal and vertical that you can use to apply to detecting the boundaries of the screen (with a perspective camera) relative to a plane that is perpendicular to the angle that the camera is at.

I suspect the math is far more pernicious if you've got an angled camera that isn't staring straight ahead... Because at that point I'm not sure that the "get tan" would be the right method to go about it... And I'm sure you could use the method for an angled camera to calculate a perpendicular camera but that's a battle for another day.

[Red]

If anyone's curious, this is the system... There are quite a few times when knowing where the border of the screen is relative to the player can come in handy. (first part, I can't post more than four screenshots at a time.)

[Red]

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.)

[jeanfabre]

Hi,

 Good. But you know you can also use the screen view reference ( screen going from 0 to 1) and then do a raycast from that point and position your limits there, this way it's a lot less math and "direct".

Maybe with this you can get to what you want as well, by then coming back the other way to find out screen based offsets

I can't find the original thread, so I have attached it here as well.

 Bye,

 Jean

[Red]

Oh geez you've got to be kidding me, it's that simple?

Wow... Guess I should take the crown of "the king of over-complicating things." :lol:

Thank you for this though.

[jeanfabre]

Hi,

 Yeah, a lot of time, going hard core is unnecessary because Unity has a lot of features, but mastering them to find the right combination to do the minimal amount of coding or fsm's is the big thing.

However you have to appreciate that because you went the long way, you have gained true experience. That's the only way to learn properly. We all went down that road...

Bye,

 Jean

[Red]

True there... And this has reminded me why I should have kicked myself back in High-school when I said "When am I ever going to need to know trigonometry?"

But hey, I was young and stupid... As we all were when we were around that age :lol: And yeah, having gone the long way around has helped me come to a better appreciation of it all.