Jump to content
  • Advertisement
Sign in to follow this  
Bozebo

Visibility determination

This topic is 3081 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Can it be tested if a ray can be traced from a location to a shape? Without intersecting other geometry which is selected after the initial culling - and ordered by distance. (sphere, bounding box etc, then tri)

As in, for checking if an AI can see a player (not just a point), or providing aim assists.

I suspect I would find the answer when I am investigating ray tracing more for other things, but the query popped into my head now and I might as well find out the answer.

edit:
I found this thread which has some unfortunate sounding info.

Quote:
cast a ray from the head/center of an AI object to the center of other objects


If that is the case, are my options do perhaps do 3 ray traces? one to the "left", one to the "right" and one to the origin of the object - that way there is more information to go by to approximate whether the object is visible or not.

Another way would be to render from that perspective and update with the stencil buffer while rendering to a small texture involving the object to be checked? Though, even in the simplest forms would this still be too inefficient? And it would probably be unavailable server-side for a multiplayer game. However this might be good for an aim assist method (where the player can miss on his/her chosen vector but a sub system of the shooting mechanism has a chance of forcing the shot to land - but only if a target is visible. Or some kind of super-scope that does the same sort of thing)

Or is there a simpler solution I am overlooking?

[Edited by - Bozebo on July 5, 2010 8:29:27 AM]

Share this post


Link to post
Share on other sites
Advertisement
Yeah, casting a few rays from the AI's head to locations on/in the player is a fairly traditional approach for AI visibility queries. Physics engines usually have ray-casting facilities available that you can use instead of writing these modules yourself.

Share this post


Link to post
Share on other sites
Quote:
is there a simpler solution I am overlooking?

Unfortunately, probably not. As you seem to suspect, casting rays will only be an approximation. Depending on the complexity of the shapes (both target and occluding objects), you'd have to cast a large number of rays to ensure no part of the target is visible.

The discussion you reference mentions rendering all objects (with depth) as viewed from the player's perspective and seeing if any part of the target gets rendered. That's very accurate but a bit complicated and time-consuming.

Ray casting is a compromise.

Share this post


Link to post
Share on other sites
Yeah (what the other guys said) but I just wanted to add that you may say "casting a single ray doesn't give me very accurate results!"

That is true, but it's often accurate enough in practice.

In games you often don't need the 100% realistically accurate solution to a problem. Often you find something that is quick to compute that works "good enough" (:

Share this post


Link to post
Share on other sites
Thanks for the clarification.

My stencil buffer method could be quite good for an aim-assist (can be done in the same render as the player's view), I can modify the last bit in the stencil buffer if the earlier bits are of use by another mechanism that won't need to full stencil buffer resolution. IE, to show that at least 1 pixel of the opponent's head nearest the crosshair is visible. I plan to make a weapon in a game that seems to make headshots far more likely, for playability/fun/lore reasons. It would be quite interesting. Another (possibly better) way would be to have it use a different hit test, possibly using a larger head collision volume for the raytracing - or not culling the collision volumes down to the finer level that normal hit registration would use.

Share this post


Link to post
Share on other sites
Another option would be to raycast to a couple of nodes on the character. Have a few locators placed on your character that are marked as visibility/aim nodes, and raycast to them. If you require stealth-game level accuracy, you could probably mark a few key bones in the characters skeleton to use as visiblity nodes so that they animate with the character as well.

It'd give you a reasonably good accuracy, and you can tune the amount of aim nodes as required per character (So if they've got exceptionally long limbs for some reason, you could place a couple of additional target nodes along the length of the arm).

Share this post


Link to post
Share on other sites
Quote:
Original post by PlayfulPuppy
Another option would be to raycast to a couple of nodes on the character. Have a few locators placed on your character that are marked as visibility/aim nodes, and raycast to them. If you require stealth-game level accuracy, you could probably mark a few key bones in the characters skeleton to use as visiblity nodes so that they animate with the character as well.

It'd give you a reasonably good accuracy, and you can tune the amount of aim nodes as required per character (So if they've got exceptionally long limbs for some reason, you could place a couple of additional target nodes along the length of the arm).


Ah. That's a good example of a game's custom requirements within a model format, along with things like weapon holding nodes etc. I am planning on implementing multiplayer "bot" AI, so I think a number of nodes on the player located on different limbs could be good because I want to give the bots different skill levels and "personalities" (ie, they might take extra time to go for headshots). It will be quite cool if I can make them trace opponent's through walls to try and get them with bullet penetration, which should be possible with some trial and error of different implementations (when line of sight is lost, track the same target and trace another ray to see if the geometry passed through towards the chest/head node is below a certain thickness).

That is another point, for tracing rays to simulate bullets. I am planning on making it quite technical, it will have a number of states for each ray in the individual bullet simulation. ie: not colliding with anything, colliding with "soft", "medium", "hard" resistant surfaces - take things into account such as the bullet type and the normal where it collides with a tri and where it collides with the exiting tri from that piece of geometry, depending on the material type I am hoping to implement refraction and reflection. So effectively it is tracing a number of rays for each projectile it needs to simulate. However, I am not sure how intensive that processing could - if it is too intensive I may have to limit it to certain bullet types. But that is another topic altogether I suppose, and I am far from that stage.
Also I was thinking about weapon rates of fire. That could require rather fine timings, recoil simulation is another thing to think about - and in multiplayer I am not sure whether it would need to be server or client side. All problems I will have to solve at some point, later.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bozebo
My stencil buffer method could be quite good for an aim-assist (can be done in the same render as the player's view), I can modify the last bit in the stencil buffer if the earlier bits are of use by another mechanism that won't need to full stencil buffer resolution. IE, to show that at least 1 pixel of the opponent's head nearest the crosshair is visible.
You could implement this using hardware occlusion queries too (instead of writing bits into the stencil buffer). The only problem with GPU-based visibility checks is that you've got to deal with the latency involved (or if you don't, you'll stall the GPU). One way to do this is to issue your occlusion queries, but don't ask for the result until 2 frames later (to avoid stalling the GPU) - your AI / auto-aim should be able to deal with 2 frames of lag.
Some other engines deal with this by pre-computing a volume of depth-cube-maps to get approximate visibility, or even by implementing a basic software rasterizer and doing a Z-buffer render on the CPU.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!