See through walls
Blitz3D Forums/Blitz3D Programming/See through walls
| ||
| I am writing a FPS and have got the mouse code and first level model complete. Trouble is if I walk into a wall it stops as expected, however when I use the mouse to look up and down it seems to "ignore" the fact that the wall is solid and allows me to see into the room behind by cutting through it. Anyone know a way to fix this ... BTW.I have used floorplan 3d to create the basic room layouts which works realy well as you can drop in doors, windows etc then export as a DXF. Import this into Milkshape then texture as needed. It is quick and easy and the results are pretty good. |
| ||
| Decrease the Near range of CameraRange. Ie, CameraRange camera,0.25,200 Remember, the bigger the difference between near and far, the lower the resolution of the z buffer. In english this means it's good practise to ensure that the near range is high and the far range is low... Near range affects how close you can get without "clipping" an object. Clipping is the term for what you are experiencing. |
| ||
| That's the best approach, but you might also alter your EntityRadius. With a larger collision radius so that you don't get as close to the wall will prevent clipping from the near clipping plane. |
| ||
| What you could do, to increase your Z-Buffer range, is do two renders. It shouldn't slow things down really, as your only really rendering the same amount of stuff :) |
| ||
| That's odd advice. Unneccessary for what he's asking, and anyway how would rendering twice help with z-buffering? |
| ||
It would help because, you set the camera range to the far settings:CameraRange camera,100,10000 render the scene. Make sure the cameraclsmode is set NOT to clear the scene. Then set the camera to render the near stuff CameraRange camera,0.1,100 then render again. Then you get more rendering accuracy. Was just a passing point :) |
| ||
| Very interesting. Does that work? (ie. have you tried it?) If so, that's a good trick to know. |
| ||
| Yep, it works. It's helpful if you have two things very close that further away, they seem to cut through each other. |
| ||
| Thats pretty cool. would help minimize/prevent Z buffer fighting. |
| ||
| It works, i use THREE render passes for this stuff in my game actually. Tracer |
| ||
| Thanks for all the input. I have tries 2 render passes but am still experiencing the problem and getting a lot of flickering. Any chance of a full example how this should be done properly. |
| ||
| decrease your camerarange near value. The two rendering pass was just a passing point about increasing overall z accuracy. try: CameraRange cam 0.1,1000 Or, increase your cameras/player collision raduis, so it doesn't get too close to the wall. |
| ||
| Guys Thanks for the help so far,but I have been testing a lot and heres what is happening. I have tha camera parented to a model of a man holding a rifle. The man is clear and the gun is textured, The camera is set only to see the gun and parented to the man. This looks fine and moves around as expected. I think the proplem is with the fact that when the gun hits the wall it stops as predicted, but if i move the gun up and down it no longer is blocked by the wall and "cuts" through it ignoring any radius settings etc I have set. Making the radius too big stops the model going through doorways. Any ideas ? BTW the camera settings offered to date have definately cleaned up the view detail. |
| ||
| Is this the gun that cutting through? |
| ||
| Well, you "could" have the gun kinda fall back into the player the closer you shove yer face against the wall, like it would in real life if you ran into a wall and the weapon hit it. :-/ |
| ||
| Yes the gun cuts through the wall. I have tried surrounding it with a transparent box but still no joy. I think its to do with the centrepoint of the player being too low. I may be wring but I think it is pivoting from the feet. I will try and reposition in the modeller and retest. |
| ||
| Hmm, are you sure about the radii? I would test the collisions with a wall and the gun at different angles. Also, are you sure the whole gun mesh is covered by the hitbox/ellipsoid? Or is it just the player (camera) that has the collision detection, so the gun would pass through objects regardless... |
| ||
Ok man, then this is what to do. Set your gun to entityorder -9 or something.EntityOrder gun,-9 this should force the gun to be drawn in front of everything else :) |
| ||
| a great camera trick which i've used in sota/fmc/<next big thing 2> is to do this everyframe, 1.Get position of camera. 2.Get position of where the camera needs to move to. 3.Cast a linepick from player position to new position. 4.If hit, change the position of where the camera has to move to to pickedX(),y and z. (Only for that frame.) 5.Move the camera smoothly, to the destination, be it original or pick induced. The result of this very simple to code routine is a camera that never goes through walls and is never obstructed by geo.(3rd person, first person will just never go through walls obviously) and never jumps, due to the curved movement. I have a function that does just this you can use if it helps. |
| ||
| Not perfect but I have managed a much beter result using the info from you guys. A combination of entityorder and camerarange has almost removed the issue 100%. Now all I need to sort out is what to do to stop the jitter when the camera rotates to is max and min assigned values. ie if camerarotate > 300 then camerarotate = 300 causes an annoying jitter when 300 is reached. I cant use if camerarotate = 300 then camerarotate = 300 as it does not always work. |
| ||
| Whazt is the increment size the camera may change by? this will reflect the severity of the 'jitter' If it's 5, then try something like If CameraRotate>=296 Then CameraRotate=300 OR In your code where you stipulate the camera being moved (by mouse/whatever) include IF/THEN/ENDIF statementsd around it to ensure CameraRotate will not be increased if equal to the maximum etc. |
| ||
| It sounds like you are rotating the camera then testing If CameraRotate>300. You should do the test before you do the rotation. |
| ||
| Yeah, take the current rotation, before anything is added to it. Store it in a variable. If the current movement, take the camera rotation, too far, then set the rotation back to the old, stored values. Also, make sure that the entitypitch (x rotation), doesn't go above 179, or below -179, cause it flips round, and cause a jutter. |
   |