I received messages from you saying you agree with the collision being on the client as well. I think it would be best there and we can just set up rules so there is no cheating, otherwise we cant use a more advanced collision model then a cube bounding box I don't think. Unless we use some sort of raytracing but I would just like to keep it on the client if possible this way we can avoid waitng for Indri to get finished.
So I propose enhancing the OGRE BB collsion and then adding raytrace type collision later, probbaly not per poly.
A quick primer on how the client-server interaction works in Worldforge:
In a closed source system, the server usually sends much more information than the client shows. It's then up to the client to make sure that it doesn't show more information about the world fhan the user should be able to see (visibility culling).
However, with Worldforge we can't use that approach since everything is open source. It would be too easy to tweak the client to show everything, thus "cheating". Instead, all visibility culling happens on the server side. At any given time, the server and the server only decides what the client will see. You can try this in ember by activating the free flying camera by pressing f6 and moving away from the avatar. You'll notice that the farther you get from the avatar the lesser amount of entities there are.
This means that we don't have to worry about collision detection on the client side to prevent "cheating". I.e. if someone would try to bypass the collision detection on the client by moving them through a wall, it wouldn't do any good since the server would still think that they are on the other side of the wall, and wouldn't show any new entities.
Therefore, the only kind of collision detection we need to do is the kind that maked the movement for the player smoother. We don't need to care about doing collision detection in order to keep the player out of certain areas. The server already takes care of that.
Currently in Ember, if you move into something solid, you'll notice that on servers with high lag you'll be able to penetrate it a bit until you're snapped back to a position at it's border. This is the server doing colliison detection and then sneding updated positions to the client. We want to avoid this by having collision on the client which will stop the client from trying to move through solids.
To complicate it a bit this is really something that should be handled by Eris. Eris is the "glue" layer between Ember and Atlas and handles most low and medium level entity operations. Eris already does client side motion updates, and should also do collision detection against the bounding boxes each entity has. I've spoken about this with James, who is the eris developer, but we haven't gotten it implemented yet.
Btw, Ember already has raytrace collision code per poly though the use of Opcode.