Since i have your attention, i have a totally unrelated side question with regards to camera:GetFrustum(). I see from CommanderUI_ViewFarPlanePoints() that their's a function frustum:GetPoint(# from 0-7) for getting the corners of the near and far plane. Is their a way of getting the A,B,C,D (plane normal and distance) for the 6 planes of the frustum (and perhaps the near and far plane distance from the camera if that's also already computed by the engine)? I know i can use a formula to recreate the frustum planes from any 3 vectors located on the plane (supplied by frustum:GetPoint(...)) but i'd rather avoid the extra processing per update if the engine already did the work.
EDIT: Nvm i found a way to optimize my approach, but the stuff i requested could be added for completeness.
EDIT2: Hmm this is weird. The points frustum:GetPoint(0 to 3) are very close to the camera origin (all approximately 0.01600 from cameraOrigin). Seems too close to be considered the near plane?
EDIT3: Ok what exactly is frustum:GetPoint(...). It returns values for input outside of [0,7]... like frustum:GetPoint(30+ etc). Hmm wait, i think it's accessing memory that it shouldn't lol.
Yeah, it generates an assert when not in ship mode and you call that function with invalid values.
I'll change it to produce a script error if that function is called with an invalid index.
I am not sure what you are trying to achieve with the Frustum but the only function currently available to script for Frustum is GetPoint which returns the 8 points like you said. That works fine as far as I know.
You're right the frustum is correct. The problem was on my end. The epic fail was using GetFov, instead of GetRenderFov, to calculate vertical fov with a formula that expected radians instead of degrees. The calculated vertical fov seemed <i>correct</i> so when i saw numbers that were very small (around 3.69e-7) associated with nearPlane distance i started to think it was the nearPlane of the frustum that was too close (oops).
I needed vertical fov to implement an optimized version of frustum culling (the plan was first get it to work the way described in the last link, which used vertical fov, and then change the algorithm to work off of horizontal fov when everything was working): <a href="http://www.ijvr.org/issues/issue3-2008/7.pdf" target="_blank">Link 1</a> <a href="http://www.lighthouse3d.com/tutorials/view-frustum-culling/radar-approach-testing-points/" target="_blank">Link 2</a> <a href="http://www.lighthouse3d.com/tutorials/view-frustum-culling/radar-approach-implementation/" target="_blank">Link 3</a>
For the screenshot's that follow, the marine (bot) is the "target" entity and the frustum culling code is testing if the bots eyePos is visible:
<!--quoteo(post=1857531:date=Jul 1 2011, 01:30 PM:name=MurphyIdiot)--><div class='quotetop'>QUOTE (MurphyIdiot @ Jul 1 2011, 01:30 PM) <a href="index.php?act=findpost&pid=1857531"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I am not sure what you are trying to achieve with the Frustum...<!--QuoteEnd--></div><!--QuoteEEnd--> I needed a "Is in field of view" function that worked correctly. A function based off of GetCanSeeEntity seemed like a possible direction but i found that GetCanSeeEntity gives <a href="http://i.imgur.com/YzLrl.png" target="_blank">incorrect</a> results the closer the targetEntity gets to a corner of the screen.
GetCanSeeEntity also behaves <a href="http://i.imgur.com/rD222.png" target="_blank">very weird</a> for a spectator (flickers between returning true and false with slight mouse movements).
With a <a href="http://pastebin.com/syHAsgP9" target="_blank">custom version</a> of GetCanSeeEntity i got this <a href="http://i.imgur.com/bSlUq.png" target="_blank">result</a>:
Luckily frustum culling (err worst case = 6 dot product tests for visibility), and now super optimized "radar" frustum culling (worst case = 3 dot product, and no need to calculate any frustum planes since an approximation can be used for near-plane distance), works perfectly.
Edit: Here's IsPointInFrustum, for anyone that could use it: <a href="http://pastebin.com/PetdQtmN" target="_blank">http://pastebin.com/PetdQtmN</a> And the more useful IsSphereInFrustum: <a href="http://pastebin.com/V9Czzhmq" target="_blank">http://pastebin.com/V9Czzhmq</a>
I tried recreating the problem shown in this <a href="http://i.imgur.com/YzLrl.png" target="_blank">screenshot</a> but was unable.
Here is my <a href="http://i.imgur.com/KKPM7.png" target="_blank">setup</a>. You should be able to see the Skulk behind the console in roughly the same location as the marine in yours.
1 is the existing GetCanSeeEntity method and 2 is your version as <a href="http://pastebin.com/syHAsgP9" target="_blank">linked</a>.
They definitely weren't exactly the same but close enough in most cases as far as I could tell.
Here try with this <a href="http://www.gamefront.com/files/20547610/testbed____GetCanSeeEntity_rar" target="_blank">updated version</a> of my previous testing code. It works off of the closest player (so no limit to how many bots can be added) and draws where the eyepos and origin are.
It's using a slightly modified <a href="http://pastebin.com/MemZWcDh" target="_blank">IsInFov</a> that allows for a vector to be tested.
Results: Typically, when viewing marines (as a marine), it's going to be either the <a href="http://i.imgur.com/hYTlb.jpg" target="_blank">origin</a> or <a href="http://i.imgur.com/U5dnK.jpg" target="_blank">eyepos</a> that isn't detected. But it is possible, if your marine avatar is <a href="http://i.imgur.com/OOhLt.jpg" target="_blank">crouched</a>, or if you're a <a href="http://i.imgur.com/WV33v.jpg" target="_blank">skulk</a>, to see both locations not be detected. Also, because skulks are so short (their eyepos is close to their origin), it's possible to see a <a href="http://i.imgur.com/E0AXv.jpg" target="_blank">double-miss</a> (when viewed by a standing marine), and the usual <a href="http://i.imgur.com/egrgL.jpg" target="_blank">half-miss</a> is also possible.
Not to go off topic, but was checking out sentry targeting and i see in RebuildStaticTargetList that the targets are tested for visibility with Shared.TraceRay. I'm not sure how costly TraceRay is but i wonder if testing if the targets were in the sentry guns frustum would be a possible optimization before doing the TraceRay.
Comments
Thanks for reminding me!
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function GUICrosshair:OnResolutionChanged(oldX, oldY, newX, newY)
Shared.Message("oldX: " .. oldX .. " oldY: " .. oldY .. " newX: " .. newX .. " newY: " .. newY)
end<!--c2--></div><!--ec2-->
Add that function to any GUIScript you have and it will be called when the resolution changes.
This will be in the next Steam patch, 180.
Since i have your attention, i have a totally unrelated side question with regards to camera:GetFrustum(). I see from CommanderUI_ViewFarPlanePoints() that their's a function frustum:GetPoint(# from 0-7) for getting the corners of the near and far plane. Is their a way of getting the A,B,C,D (plane normal and distance) for the 6 planes of the frustum (and perhaps the near and far plane distance from the camera if that's also already computed by the engine)? I know i can use a formula to recreate the frustum planes from any 3 vectors located on the plane (supplied by frustum:GetPoint(...)) but i'd rather avoid the extra processing per update if the engine already did the work.
EDIT: Nvm i found a way to optimize my approach, but the stuff i requested could be added for completeness.
EDIT2: Hmm this is weird. The points frustum:GetPoint(0 to 3) are very close to the camera origin (all approximately 0.01600 from cameraOrigin). Seems too close to be considered the near plane?
EDIT3: Ok what exactly is frustum:GetPoint(...). It returns values for input outside of [0,7]... like frustum:GetPoint(30+ etc). Hmm wait, i think it's accessing memory that it shouldn't lol.
I'll change it to produce a script error if that function is called with an invalid index.
I am not sure what you are trying to achieve with the Frustum but the only function currently available to script for Frustum is GetPoint which returns the 8 points like you said. That works fine as far as I know.
I needed vertical fov to implement an optimized version of frustum culling (the plan was first get it to work the way described in the last link, which used vertical fov, and then change the algorithm to work off of horizontal fov when everything was working): <a href="http://www.ijvr.org/issues/issue3-2008/7.pdf" target="_blank">Link 1</a> <a href="http://www.lighthouse3d.com/tutorials/view-frustum-culling/radar-approach-testing-points/" target="_blank">Link 2</a> <a href="http://www.lighthouse3d.com/tutorials/view-frustum-culling/radar-approach-implementation/" target="_blank">Link 3</a>
For the screenshot's that follow, the marine (bot) is the "target" entity and the frustum culling code is testing if the bots eyePos is visible:
<!--quoteo(post=1857531:date=Jul 1 2011, 01:30 PM:name=MurphyIdiot)--><div class='quotetop'>QUOTE (MurphyIdiot @ Jul 1 2011, 01:30 PM) <a href="index.php?act=findpost&pid=1857531"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I am not sure what you are trying to achieve with the Frustum...<!--QuoteEnd--></div><!--QuoteEEnd-->
I needed a "Is in field of view" function that worked correctly. A function based off of GetCanSeeEntity seemed like a possible direction but i found that GetCanSeeEntity gives <a href="http://i.imgur.com/YzLrl.png" target="_blank">incorrect</a> results the closer the targetEntity gets to a corner of the screen.
GetCanSeeEntity also behaves <a href="http://i.imgur.com/rD222.png" target="_blank">very weird</a> for a spectator (flickers between returning true and false with slight mouse movements).
With a <a href="http://pastebin.com/syHAsgP9" target="_blank">custom version</a> of GetCanSeeEntity i got this <a href="http://i.imgur.com/bSlUq.png" target="_blank">result</a>:
Luckily frustum culling (err worst case = 6 dot product tests for visibility), and now super optimized "radar" frustum culling (worst case = 3 dot product, and no need to calculate any frustum planes since an approximation can be used for near-plane distance), works perfectly.
Edit: Here's IsPointInFrustum, for anyone that could use it: <a href="http://pastebin.com/PetdQtmN" target="_blank">http://pastebin.com/PetdQtmN</a> And the more useful IsSphereInFrustum: <a href="http://pastebin.com/V9Czzhmq" target="_blank">http://pastebin.com/V9Czzhmq</a>
I always suspected something was not entirely correct with our method but never looked into it.
I'll see if I can get this integrated into the game.
Here is my <a href="http://i.imgur.com/KKPM7.png" target="_blank">setup</a>. You should be able to see the Skulk behind the console in roughly the same location as the marine in yours.
1 is the existing GetCanSeeEntity method and 2 is your version as <a href="http://pastebin.com/syHAsgP9" target="_blank">linked</a>.
They definitely weren't exactly the same but close enough in most cases as far as I could tell.
It's using a slightly modified <a href="http://pastebin.com/MemZWcDh" target="_blank">IsInFov</a> that allows for a vector to be tested.
Results:
Typically, when viewing marines (as a marine), it's going to be either the <a href="http://i.imgur.com/hYTlb.jpg" target="_blank">origin</a> or <a href="http://i.imgur.com/U5dnK.jpg" target="_blank">eyepos</a> that isn't detected. But it is possible, if your marine avatar is <a href="http://i.imgur.com/OOhLt.jpg" target="_blank">crouched</a>, or if you're a <a href="http://i.imgur.com/WV33v.jpg" target="_blank">skulk</a>, to see both locations not be detected. Also, because skulks are so short (their eyepos is close to their origin), it's possible to see a <a href="http://i.imgur.com/E0AXv.jpg" target="_blank">double-miss</a> (when viewed by a standing marine), and the usual <a href="http://i.imgur.com/egrgL.jpg" target="_blank">half-miss</a> is also possible.
Not to go off topic, but was checking out sentry targeting and i see in RebuildStaticTargetList that the targets are tested for visibility with Shared.TraceRay. I'm not sure how costly TraceRay is but i wonder if testing if the targets were in the sentry guns frustum would be a possible optimization before doing the TraceRay.