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]

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" (:

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.

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

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.