Collision with moving Doors

Blitz3D Forums/Blitz3D Programming/Collision with moving Doors

Shambler(Posted 2003) [#1]
I've set up collisions between the camera and a door.

When the door is stationary the collisions work OK, it stops the camera going through the door.

But when you click on the door to shut it, the camera will pass through the door and doesn't get pushed away as I want.

The simplest solution I suppose is to make the door always open away from the players position but does anyone have an idea of how to get the door to push the camera out of the way??


Piccie:




JaviCervera(Posted 2003) [#2]
hmm.. if you're using polygon collision detection for your door, maybe RotateMesh instead of RotateEntity should work. But I haven't tried it...


jhocking(Posted 2003) [#3]
I haven't tried it either but I doubt that'll work. The problem is that the built-in collision detection is based on moving objects colliding with something. Since the door is moving you'd have to detect collisions of the door against the player. With a properly set collision sphere/ellipse for the door this might work well but if not you will have to do things manually using LinePicks or MeshesIntersect or something.

Come to think of it, MeshesIntersect would be my recommendation. It is a slow(er) command but you'd only need to use it once a frame to check the nearest door (as opposed to all doors in your level.) This will tell you if the door and camera are intersecting. Act on that information to push the camera back.


sswift(Posted 2003) [#4]
Blitz's collision system isn't the best in the world. It only detects collisions reliably between a moving object, and an object which is not moving. If both objects are moving, 90% of the time it will fail to detect the collision... unless both objects use sphere collision, and then it seems to be able to handle it better... it's reliable about 90% of the time.

What really needs to happen is someone needs to come up with a more reliable collision system, because I'm guessing that Mark won't be fixing the collision system anytime soon.

The other option is to run your game physics twice every frame. The first time, move the door. The second time, move the player/camera. Do an update world for each movement. The result will be that you're actually doing collisions against static objects, at the cost of some speed.


sswift(Posted 2003) [#5]
Tough on second thought, since you can onyl have sphere-with-something collisions, if you rotate the door and it hits the player, when the player is standing still, it won't odo crap because when the door collides with something that is sphere to polygon or sphere to sphere. So the door is the sphere in the case where it is moving. Which obviously is not the shape of a door.

I guess the only real solution is a custom collision system.


Rob(Posted 2003) [#6]
linepicking provides a reasonably constant collision system for simplistic moving objects such as a door.


Shambler(Posted 2003) [#7]
Edit...I clicked edit/update but it made new posts >.<


Shambler(Posted 2003) [#8]
Edit...It's the one below this one ^^


Shambler(Posted 2003) [#9]
I've 'solved' the problem like this.

I use an entity pick from the camera to check if the player wants to open/close the door.

The door then opens/shuts doing a meshesintersect test with a sphere mesh which is around the camera.

If the meshesintersect test is true the door stops.

When the door is moved again it goes in the opposite direction to what it did last.

I might post a minimal download demo of this soon.

And here it is...

http://homepage.ntlworld.com/jm.keay/squeam!.zip


no lightmaps,lores textures and no sound, just a functional test, see what you think!


Zethrax(Posted 2003) [#10]
You might want to take a look at the source code for 'Operation Chateau Pregney' also. It uses doors similar to the ones you're using. The link for it is below.

http://melog.ch/dropper/


jfk EO-11110(Posted 2003) [#11]
I guess all Blitz FPS have this Problem. I have even seen it in the Lithtech Enginge. Yes, use Meshintersect ONLY if the Door is in Motion and the Player is near the Door. If the meshes intersect simply pause the Door-Motion. To prevent that "I cannot open the door because I am in its way" you could always swing it to the other side than the players side. In OCP I used some additional dummyboxes and stuff, overcomplicated patchwork, I'd try to make it simpler today.


Shambler(Posted 2003) [#12]
Thanks for all the responses.

I didn't want to make the doors swing in both directions, although this would have removed the need for a meshintersect test its just not how I wanted the doors to operate.

I do 2 entitypicks so that you can't operate the door unless you are far enough away from it, rushing into the door when its moving will stop it though.

For me this is the most realistic method and I don't notice any slowdown so for now its onto other things.

I've added a particle system and a Hud to the updated picture above...next is coronas =)


jhocking(Posted 2003) [#13]
Just for determining distance to the door you don't need to use picks. Just using EntityDistance is faster.


Shambler(Posted 2003) [#14]
EntityPick is used so that I know the player is facing the door but point taken ;)