There are two ways to go about looking for collision when using rays. From the source object or from the external object. Let's call a player the source object. And let's call a .x terrain our external object. If we detect from the source object, our player can interact with the terrain in a very specific manner; i.e. sliding along walls, fitting into corners, getting stuck in a narrow place, climbing stairs, etc. The problem is that, let's say there is a waterfall on your terrain and you want your player to go through it - naturally. The waterfall counts as a limb, which counts a part of the terrain object, and therefore your player cannot walk through it.
But there is another way to approch collision detection, and to make this work properly requires a sort of coding prestidigitation. You can use the limbs of the terrain object to cast rays to detect collision of the player. This is not an easy task by any means, but it will allow you to 'skip' that waterfall and allow the player to pass right on through.
You start with the 5.8 vertex commands to get the verticies of the limb to detect collision from. Use the verticies to cast rays to the boundries of the limb (I typically go from the limb center to the verticies, but you can go from vertex to vertex as well. Then, if the there is a collision, you can use vector commands to interpolate the exact point of collision. From that point, you 'push' the player a given distance (typically the player_size - impact_distance) away from the wall. I personally use an averaging system to calulate an average distance away from all collision points so as to prevent/reduce a vibrating effect.
The trick to managing this inverted collision system is several fold.
1) Detecting all limbs all the time would literally halt any pc. So you have to turn limb collision on/off as the player get's near or moves away from the limb. It should be okay to turn a few limbs at the same time.
2) Detecting all the verticies all the time for even one limb will grind most pc's to a halt, and the remaining few will crawl. So you have to add in an accuracy setting that skips verticies. I use that and an offset that changes each frame. Then I keep the average from the previous frame collision detection and factor in the current frame's collision detection plus any movement from the object. I do this for about 3-5 frames (at 60 FPS, it's about 1/12 of a second) and then reset everything. You get smooth, fairly accurate collision and a decent frame-rate.
3) Fine tuning. Once you have everything down, you will need to fine-tune the settings to balance frame-rate, accuracy, and smoothness (minimal vibration).
Take a look at the DBPro coding challenges at the current challenge, which is a robot-hand challenge. I am using this techinique to effectively lift a ball with a robot hand. I am still working out the details, but it's more than a decent start.
"Droids don't rip your arms off when they lose." -H. Solo
REALITY II
