Hi ,
I am new to this forum and noob in 3d programming.I have loaded my model and set camera.The model is nothing but a quake level.So when the appplication is loading, the first person view is inside the level.Now the issue is here that when I move camera away from the model, I am able to see the surrounding world.I want to disable that behaviour.How can I do that? Also, in the level, there are some stairs and steps.When the camera is hit on the wall or steps while moving, I falls through it.should I enable collision detection? What is the general solution to this? Thanks in advance.
Yes, you would need to handle collision detection to prevent the camera from moving through the walls, floor and ceiling. This would also fix your problem where if you move the camera away, you can see the whole level. If they can’t back the camera through the ceiling, they won’t be able to see everything.
However, you could also compute where the floor is, and constrain the camera to being 6 feet above the floor and always within it (e.g. a person standing). This would act like a limited FPS character that they could move around. You would need some special code to work for the stairs, though or they might get stuck on the first step.
How can I identify whether I hit on a wall or stair case or something like that? Because when I hit on a wall, I should get a behaviour like to stand still or on stair case, the player should be able to climb up the stairs.so when we do it programatically how do we do this in a generic way?
You would classify each polygon in the map as wall or stair. Or you would look at the height of the wall, and if it’s the height of a single step, assume it can be walked over or on and allow the player to move up. This may also depend on the information available in the Quake levels, they may already identify the stairs for you.
@lhkbob thanks for the reply. Can you paste some small quake file format content? Because, in my case, I am using a .3ds file,not quake and it is not human readable.So where can I search this information in the .3ds file?
Unfortunately no, I have not used quake files before. I don’t think 3ds has that kind of info in it. What you should do instead is preprocess the level after you have loaded to try and find stairs.
First look for all of the vertical polygons, these will be the walls. You can compute the height of the wall, and if it’s a very small value, then it’s a step of a stair. When you find a stair, you have to search for all horizontal polygons that connect to it so you can find the ground segments that you would move the character to when they step up or step down.
Alternatively, you can have one model that represents the physics world and one that is rendered. This is common practice in video games. When you detect a stair case, you can replace it with a sloped ramp in the physics representation.
I have not programmed this myself, but you can try googling “stair collision detection” to see how people have solved it before, there might even be some good tutorials.
IIRC quake levels don’t do any preprocessing or special flagging of surfaces to determine wall/floor/stair, it’s just done at collision time. A quake player is allowed to step up if a suitably horizontal surface is found within a height threshold, otherwise they’ll be blocked by it’s lip.
No need to make things more complicated than that. 
Quake level files already have this built in - the designer can add invisible ‘clip’ polys to smooth out collision (which go in the bsp tree but not the poly list), and there’s a brush flag for ‘detail’ brushes (which go in the poly list but are not inserted into the bsp tree). Basically you just need to perform collision against the bsp tree and render the polys.
I figured quake levels did something like this, but he’s using a quake level that’s been converted to a 3ds file.
Unless there’s a compelling reason not to, I’d just go back and load the original bsp file. It’s a well documented file format and it’s got lots of metadata for optimised collision and rendering. Throwing all that good data away seems like a waste.
I do not have original quake file.All I have is a converted .3ds file.But I used this model in other games where already the collision detection(againist wall, stars etc) has been taken care in it.So what I want to know is that when I implement a collision detection here in first person controller scenario, I need to do create a camera node and when the camera node touches the model wall, I should calculate collision.Is that all I want to do now, right? Also, one more thing.When the application starts, the model is placed in such a way that the camera is inside the model facing the wall.And if I provide collision detection, then I can control the camera movement as well, right? Suppose, if I am able to provide collision detection in this case, can I re-use the same code in other scenario as well(without doing any modifications)? Let us say I have a different .3ds model that was converted from quake level.Do I need to modify my the model manually before loading it through application? Sorry for troubling you so much.Just want to know how it is done generally.