OK, cypher I'll put my 2p worth in please don't take as gospel though just my own observations really:
As I understand it, most games wouldn't have Poly collision between two complex models, far too slow, rather the models would be approximated in some way (like having a box or simple model applied) to work out the collisions.
The other nasty thing I've found with poly collision in DB is that the functions that determine if a hit or collision has occured (Object hit and Object Collsion) don't return the angle of the Normal of the Poly you hit. In other words you don't get any info on the direction the poly you hit was facing, making it "imposible" to work out any kind of sliding collision response.
BSPs in DBPro are a little different tho as they're made from simple "closed" units, like a box or wedge, the BSP is then compiled into something manageble well before your game loop, allowing for HUGE levels to be constructed. However I believe that the DB collision commands are not working yet so your code will never know if you hit the wall, although an "auto collide" object will simply glide along it regardless of your code knowing anything about it or not. Basically, especially with the bugs reported, you seem to loose a level of control using BSP at present.
If you don't use Pro & BSP and you don't want to use static, non rotated (and bugged - see below) DB collision boxes, what have you got if you want to create something like a winding race track in a 3D package and have fast Collision Detection (ie simple shapes) and a Sliding Collision Response for your track barriers?
Well that's what I was trying to get some way to solving with my little tut. It isn't the best solution to all of this by any means, seems only to work in DB1, doesn't cater for "hills" and does require alot of mucking about in 3D Studio or whatever, rotating and sizing Plains into position to get it to work.
What it does demonstrate tho is how to "manually" insert the simplest of objects that will be hidden in your game to act as the "collision boundries". Also because they're broken into seperate objects (Plains) if a hit is detected the angle of the rotation can be retrieved from the objects parameters (object angle y(n)) to enable us to work out our sliding response.
Having said all that tho, in DB Classic the easiest way to do all this would be to just use non rotated boxes in your 3D model (like a city grid - very UNLIKE your track tho) and then use similar code to pull out each limb and create a Static Box to replicate it, thus enabling you to use DB1's built in Sliding collision response (there's a tutorial on this in the standard DB help files). A word of warning though - rotating the boxes is not allowed as DB will no longer give sliding response data and I believe there's a bug with Static objects and GeForce Cards (as I have) which will crash your proggie.
Finally, I saw DarkGT the other day, posted elswhere on this forum, where he'd got (quite nice) Collision detection on his hand modelled track - it even did hills (lol). Unfortunatly he's not telling anyone how's he's implemented that, saying only that he's hand modelled each polygon. Possibly he's storing some data in a file in a similar manner to my "array to hold the widths of your plains". Again though, even in that example he's not got Sliding Response, it looks more of a "bump and test" routine.
Sorry to ramble on, hope this info helps you a little
