Inside FOV checking functions

Moderator: GZDoom Developers

User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Inside FOV checking functions

Post by Rachael »

There's also the whole thing where some people may have 5:4 displays, some people may have 21:9 displays. Both render quite differently both horizontally and vertically. In my opinion, even for more innocent uses of the function, such a function is simply untenable for exposing to modders.

In my opinion, whatever problems this is meant to solve should be solved with assumptions, and generous ones at that. If you want an enemy to only aggro when the player sees it, then only allow the player's view to be +/- 45 degrees for that check. If you want to stop rendering a certain object because it is resource intensive, either lower your resource consumption, or use a more generous +/- 75 degrees.

I have reservations about including functions like these in ZScript and would much prefer to see them not be used.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Inside FOV checking functions

Post by Graf Zahl »

Good point. I never thought about the hardware dependency issue here.

Yes, such functions should never be exposed to mods, it's simply not how stuff is supposed to work.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Inside FOV checking functions

Post by Apeirogon »

Soooo....even if I provide math for this, it still get [No] anyway?!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Inside FOV checking functions

Post by Graf Zahl »

If it depends on the current screen dimensions, yes.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Inside FOV checking functions

Post by Apeirogon »

It depends on vectors. As I said before, one vector represent camera and it angle/pitch, or any other vector, and are unit vector, another position of actor/point in world relative to "camera" actor.
With the assumption that both vector placed in one plane, which placed in 3d space, find scalar product, divide it on product of a length of both vectors and the find arccosine of result number. Final result return angle, between 0-180, between vectors.
If require, it can return how much, and in what axes, you need to turn second vector to make it parallel to first.

But this is actually more hack than actual check_if_in_fov(something). For default cuboid doom actors it required 8 calls to distance_3d, to check all 8 angles. But distance check CAN be reduced from sqrt(number) to arcsin(another number).

I try to understand how c++ find square root, but looks like it not something what I learned in...school I think.
Screenshot_2018-10-13-20-20-15.png
Screenshot_2018-10-13-20-20-15.png (26.46 KiB) Viewed 1093 times
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Inside FOV checking functions

Post by Rachael »

You're never going to need square root in such a function. For instance, arctan((a1.x-a2.x)/(a1.y-a2.y)) is a fairly straightforward way of getting an angle of two actors, provided their y position never matches (and if it does, you can just use static values depending on whether the x calculation is negative to prevent a /0 abort).

What you guys are asking for here is literally a "is this inside the camera?" check, and that's never going to happen. The game sim does not know how widescreen your monitor is - and it never should. That is terrible game design if it does. The ONLY proper way to do such a check is, for instance, using the formula I listed above, and making broad assumptions about the player's camera. I'd say the average 16:9 monitor probably has about 112 degrees of field of view, and if you base that on the player's angle, that's about 56 degrees on each side. I'm fairly sure you can figure out the rest from there.

But on that note, isn't there already some sort of AngleTo(a1, a2) function already available anyhow?
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Inside FOV checking functions

Post by Apeirogon »

You formula dont use Z component of a vectors. Actor can be much higher/lower that camera position, but function still return "actor in camera fov".
Or camera can be point straight up.
Or camera can use "home made" functions to freely turn around its x/y/z axis.
Or actor can be hidden from direct observation by map geometry.
Or...
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Inside FOV checking functions

Post by Rachael »

Or I can ask what do you need all these checks so badly for? This reeks of throwing everything but the kitchen sink at a simple problem.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Inside FOV checking functions

Post by Rachael »

By the way, the formula for calculating pitch would indeed use square roots. It's basically arctan(sqrt((a1.x - a2.x)^2 + (a1.y - a2.y)^2) / (a1.z - a2.z)). You might have to invert the division, but otherwise it should work. It's basically using the flat 2D XY distance from an actor as the first component.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Inside FOV checking functions

Post by Apeirogon »

Emulate camera as cone with some angle in vertex, which represent camera fov, and than check angle between cone axis and line from cone vertex to actor with cone vertex angle.
Again, I dont say "use actual player screen to check something", I say "check angle between several vectors to check something".
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: Inside FOV checking functions

Post by Apeirogon »

And you can find distance without root, using a bunch of sin and cos.
User avatar
KeksDose
 
 
Posts: 595
Joined: Thu Jul 05, 2007 6:13 pm
Contact:

Re: Inside FOV checking functions

Post by KeksDose »

Step back for a moment. What do we want?

I voiced my concerns last page. The idea in the OP cannot be reconciled with the usage cases MC suggested (screen check and things you'd never look through, like missiles spotting you). The best we are willing to add to the engine is a fov-check not caring about the monitor, the latter. Let's stop calling it fov-check. It's an angular location test. There are more than just one way to do this:

One is what Apeirogon is getting at, a cone-shaped check, that takes just one angle.

A way with two angles is with with what I posted last page. It properly accounts for 90° pitch, but it is wedge-shaped. Actors way above the centre line of the check have an easier time avoiding this check.

You can make it length preserving at the locally vertical edges, so for bigger vertical angles, the space covered remains the same. That's another option addressing the previous.

First agree on the exact nature of the check, not just "no monitor." Any of these can cover "screen check with assumptions about what the player may see."

edit: I'd say the cone and wedge checks are the most commonly used, since they got mostly thrown around here. IMO, anything more sophisticated should be left up to mods.
User avatar
Pixel Eater
 
 
Posts: 667
Joined: Wed Aug 02, 2017 12:31 am
Location: In between the Moon and you, between the buried and me.

Re: Inside FOV checking functions

Post by Pixel Eater »

Would a visual calibration for the player reduce much of the predictive math needed?
User avatar
KeksDose
 
 
Posts: 595
Joined: Thu Jul 05, 2007 6:13 pm
Contact:

Re: Inside FOV checking functions

Post by KeksDose »

There are no visuals. It's a location test. Mathematics are not the problem here. We had everything we needed to do this on the previous page.

What I posted is not necessarily a screen test, but it is roughly viable as one. At no point are there any assumptions about the screen or renderer, as the angles are freely chosen. It covers "limited screen test" pretty great. In fact, if you pass the screen fovs, it's an open-gl screen test without pixel stretching. That doesn't mean it's screen-based.

What Apeirogon suggests is a useful alternative, too. Choose your destiny.
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”