Line of sight check error
by Tony Oakden · in Torque Game Engine · 03/05/2005 (6:04 pm) · 10 replies
I've come up against a wierd bug in the line of sight check.
I've got a BSP space with several seperate BSP platforms inside it. I made the platforms seperately so that I could move them about in the world editor and so tune my game easier. I use the line of sight check demonstrated in aiplayer.cc to check if my AI can see the player:
getContainer()->castRay( location, targetLoc,
InteriorObjectType | StaticShapeObjectType | StaticObjectType |
TerrainObjectType, &dummy)
where:
location = location of the AI
TargetLoc = location of the Player
This seemed to work fine at first with simple blocky BSP spaces. But now I've found that sometimes my AI can see the player through the thinner platforms. I've double checked and location and targetLoc are set up correctly and the platforms are definetly there as the player and AI are interacting with them in physics. But the AI are trying to attack the player through the platforms.
Now here is the really weird bit. If I scale the platforms to be slightly thicker in the editor (just a y scale of 1.1 is enough) the AI sees them just fine. Also if I half the thickness of them in Quark and then double them in the game world so that the net thickness is back to the same as above the problem also goes away :P !
This seems like if might be something to do with the way in which the line of sight code steps through the scene graph. Maybe a problem of resolution which means that at certain spacings the check skips over the platforms? I don't know how the routine works so I'm just guessing here :)
Has anyone else noticed this behaviour and maybe tracked down the cause? I haven't made any changes to castRay so I can't imagine it's anything I've done. With the scaling decribed above I seem to be able to work around this but it would be much better if I knew what was going on.
regards,
Tony Oakden
I've got a BSP space with several seperate BSP platforms inside it. I made the platforms seperately so that I could move them about in the world editor and so tune my game easier. I use the line of sight check demonstrated in aiplayer.cc to check if my AI can see the player:
getContainer()->castRay( location, targetLoc,
InteriorObjectType | StaticShapeObjectType | StaticObjectType |
TerrainObjectType, &dummy)
where:
location = location of the AI
TargetLoc = location of the Player
This seemed to work fine at first with simple blocky BSP spaces. But now I've found that sometimes my AI can see the player through the thinner platforms. I've double checked and location and targetLoc are set up correctly and the platforms are definetly there as the player and AI are interacting with them in physics. But the AI are trying to attack the player through the platforms.
Now here is the really weird bit. If I scale the platforms to be slightly thicker in the editor (just a y scale of 1.1 is enough) the AI sees them just fine. Also if I half the thickness of them in Quark and then double them in the game world so that the net thickness is back to the same as above the problem also goes away :P !
This seems like if might be something to do with the way in which the line of sight code steps through the scene graph. Maybe a problem of resolution which means that at certain spacings the check skips over the platforms? I don't know how the routine works so I'm just guessing here :)
Has anyone else noticed this behaviour and maybe tracked down the cause? I haven't made any changes to castRay so I can't imagine it's anything I've done. With the scaling decribed above I seem to be able to work around this but it would be much better if I knew what was going on.
regards,
Tony Oakden
#2
Can anyone confirm if what Alan said is true? If so then I guess I can use meshes with collision volumes instead but I was under the impression that BSP would be faster from collision and rendering POV.
I've not had any problems with this other than the LOS stuff though. And even that seems to work most of the time.
03/05/2005 (10:56 pm)
Thanks Alan,Can anyone confirm if what Alan said is true? If so then I guess I can use meshes with collision volumes instead but I was under the impression that BSP would be faster from collision and rendering POV.
I've not had any problems with this other than the LOS stuff though. And even that seems to work most of the time.
#3
Any help would be much appreciated.
03/07/2005 (10:56 pm)
I've replaced all the BSP with mesh. I still get the same line of site bug. E.g. AI can see my player through the platforms if they are too thin - about .25 units but if I scale them up a bit it works fine. Does anyone know if there is a minimum thickness of object which is required for the line of site check to work? Any help would be much appreciated.
#4
I'm having the exact same problem with DTS files and gServerContainer.castRay going right through them without seeing them. I dove through the code last night for a while because I need that function working for my mouse picking (a modified click n Pick) to work. It appeared that the point.interpolate was interpolating past the object. But I could be wrong as well, combining the math and the container optimizations, I had trouble reading it.
I really need help on this though as I need to be able to make sure that if a ray goes through, it detects what is along that ray. I tried to reduce the ray length in the assumption that the detail was afactor of ray length, but that didn't seem to work (dividing by 20 didn't really change it's ability to detect).
If this fix works, it's ugly, but I guess we could use that. But I'd prefer to figure out what's going on with the castRay. Is there anyone who has the knowhow on this function to save me tons of work crunching it to figure out where it's going wrong?
Aside: Doesn't this belong in the engine section since castRay is c code? oh well.
03/08/2005 (7:59 am)
Wow, timing.I'm having the exact same problem with DTS files and gServerContainer.castRay going right through them without seeing them. I dove through the code last night for a while because I need that function working for my mouse picking (a modified click n Pick) to work. It appeared that the point.interpolate was interpolating past the object. But I could be wrong as well, combining the math and the container optimizations, I had trouble reading it.
I really need help on this though as I need to be able to make sure that if a ray goes through, it detects what is along that ray. I tried to reduce the ray length in the assumption that the detail was afactor of ray length, but that didn't seem to work (dividing by 20 didn't really change it's ability to detect).
If this fix works, it's ugly, but I guess we could use that. But I'd prefer to figure out what's going on with the castRay. Is there anyone who has the knowhow on this function to save me tons of work crunching it to figure out where it's going wrong?
Aside: Doesn't this belong in the engine section since castRay is c code? oh well.
#5
03/08/2005 (2:21 pm)
Hey your right Philip I posted in the wrong place! I wondered why I wasn't getting much response... Lets move this across to engine...
#6
Torque SDK Private Forums >> Engine
I also need this routine to work reliably so will be watching this thread with interest. I had a quick look inside castRay and it is indeed very difficult to work out the program flow. Definetly something not working properly though. Rather annoying when core routines don't work the way one expects and no one seems to know why:(
03/08/2005 (5:06 pm)
OK I've posted the same thread in:Torque SDK Private Forums >> Engine
I also need this routine to work reliably so will be watching this thread with interest. I had a quick look inside castRay and it is indeed very difficult to work out the program flow. Definetly something not working properly though. Rather annoying when core routines don't work the way one expects and no one seems to know why:(
#7
03/08/2005 (5:10 pm)
But to put that comment into perspective this reminds me a lot of problems we had in my day job with a well known game engine. The SDK for which costs thousands of times as much as Torque :)
#8
05/06/2005 (6:19 am)
It would probably be a lot easier to patch torque than the unreal engine.
#9
05/06/2005 (11:28 am)
Yes patching the unreal engine seems to be a problem. I herd from a well known publishing company it cost to much to be a viable option. Got to love big companies and there lack of moral fiber.
#10
05/06/2005 (3:48 pm)
Hey Tony. Don't you have a PATCH for that "other game" you worked on? You know, the one that's like "Tony Hawk with Spinfusors?" 
Alan Kantz