Can i see the bad guy?
Author
This has been bugging me for awhile, i belive i have asked this before and i have gotten some good answers, but i still have a few questions. So, this is what i would do to test if i can see him, i would use the dot product with my view vector, and his view vector and see if we are even able to see each other. next, i would cast a line from the orgin of my view to the orgin of his view. and if anything gets in the way of that line, then i cant see him. Some of the problems i am having is, say i cast a line, and it runs into a hill. But say only half his body is hidden by the hill, the other half i can see, but my method above would not account for this and i wouldnt draw the model because i think i cant see him. That is one of the many problems with this method.
There has to be a better way, can you guys tweak the above method, or give me a whole new one? Thanks for the help. I really appreciate it!
One thing you could do (might not be the fastest option 
) is to test visibility for every badguy vertex not facing away, or you could enable stecilbuffer writing when you draw the badguy and check if there are any changes in the stencil buffer, if so, you can see him. This last method might be faster (if there''s a fast way to check if there are bits set to 1 in the stencil buffer) but you can only use it for the player itself, or you should draw the scene once for every opponent 
.
I don''t think there are any other options
.
) is to test visibility for every badguy vertex not facing away, or you could enable stecilbuffer writing when you draw the badguy and check if there are any changes in the stencil buffer, if so, you can see him. This last method might be faster (if there''s a fast way to check if there are bits set to 1 in the stencil buffer) but you can only use it for the player itself, or you should draw the scene once for every opponent .I don''t think there are any other options
.
I think the pervertex method is better, allthough you don''t need to check every vertex, only some of them(like one vertex per joint or bodypart).
---------------------------------
For an overdose of l33tness, flashbang.nu
---------------------------------
For an overdose of l33tness, flashbang.nu
quote:Original post by SkinnyM
So, this is what i would do to test if i can see him, i would use the dot product with my view vector, and his view vector and see if we are even able to see each other.
Just so you know, it''s not because he can''t see you that you can''t see him. So I don''t think using his view vector is a good idea...
I would create bounding boxes, spheres, or ellipsoids around key parts of the guy. Ie one for each arm, leg, one for the head, one for the torso. Then, if you can crate an uninterruptd line from your viewpoint to one of the bounding elements of the bad guy, (i use the center of the bounding elements myself) that also intersects with your view fustrum then you can see the guy. This should take care of the "half-hidden" guy problem
I''m pretty sure Doom used a single line of sight vector, because half the creature and half of you could be exposed around a corner and it still didn''t see you. And then once it did see you, it always knew exactly where you were. Go figure.
Anyway, yes, I think all line of sight calculations should come from the visual area of the creature, and check it against various parts of the target''s body.
Then there is a problem of there being some miniscule tiny little hole, and even though you couldn''t make them out, they make you out from 100 yards away because the line went right through that hole.
I have no problem with a single, inaccurate check as long as it can''t lead to cheap exploits.
Anyway, yes, I think all line of sight calculations should come from the visual area of the creature, and check it against various parts of the target''s body.
Then there is a problem of there being some miniscule tiny little hole, and even though you couldn''t make them out, they make you out from 100 yards away because the line went right through that hole.
I have no problem with a single, inaccurate check as long as it can''t lead to cheap exploits.
If you want to increase your accuracy you could always cast multiple rays from your player to the enemy. one to the head, one to it''s feet and one to either arm. that''ll get you closer to accurate but will, of course increase your processing time (though it''s a small scalar increase so it shouldn''t matter all that much.
i''d also do something like have different collision types for your entities. you can have COLLISION_TYPE_ALIVE, COLLISION_TYPE_STRUCTURE, etc. you can also do collision against the terrain seperately. this will buy you some quick escapes from boolean isInLineOfSight(...) type checks. first you check against terrain, then against world objects, or the reverse (you put the least expensive test first so that you can hopefully avoid the more expensive case at least some of the time). On loading your objects, set their collision type.
It''s also nice to have collision types because you can get away with cheating, like enemy units don''t hide other enemy units, but buildings and walls do. overall you can get really nice savings on your line of sight tests this way.
-me
i''d also do something like have different collision types for your entities. you can have COLLISION_TYPE_ALIVE, COLLISION_TYPE_STRUCTURE, etc. you can also do collision against the terrain seperately. this will buy you some quick escapes from boolean isInLineOfSight(...) type checks. first you check against terrain, then against world objects, or the reverse (you put the least expensive test first so that you can hopefully avoid the more expensive case at least some of the time). On loading your objects, set their collision type.
It''s also nice to have collision types because you can get away with cheating, like enemy units don''t hide other enemy units, but buildings and walls do. overall you can get really nice savings on your line of sight tests this way.
-me
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
