Thread: New BSP Engine

Hey everyone, I've been working for about 2 weeks now on a BSP engine and have come up with some good results. Basically I've got the renderer complete, along with collision detection and entities (like doors and elevators)

You can download the current version here:
http://www.thejefffiles.com/projects/BloodRight/

that's my development site over at TheJeffFiles.com for the game. There are some screenshots and the updates.txt file from the game.

I'd like to see some of the specs that some people got while playing the game, to see if I need to fix any bottlenecks in the code.

Well, take it lightly on the engine, I've only had about 2 weeks to work on it so far, so it's probably got bugs in it

Note: to show the frames per second and stuff, you need to set the debugging mode to 1 in the game.ini file

looks like a pretty good start, keep up the good work.

maybe for a future add on you can have some collision response code

hm, what do you mean by collision response code? the way I do it right now is just do projections at the ground and the ceiling, and then project rays in the direction that you move. The only problem I've found with that at this point is sometimes if you land just right on the edge of a block or something, you can go through it........so i'm still trying to figure that out

I'm at school right now, working on getting elevators working correctly.

I don't know what algorithm you're using for collision detection, but what I mean for collision response code is that your velocity is modified so that your new direction makes you slide across the plane you hit. Obviously there's a LOT more to it than this (I am reprogramming my physics, essentially I'm trying to make a rigid body simulator), but the basic idea is to get that nice smooth sliding effect when you hit a surface, such as in quake

hey, nice job. believe it or not bsp editors are in high demand.

Looks good. It could look a LOT better with better textures though, namely the wall texture (Look @ screenie 2). It's not that important in the very beginning, but without good textures, you may make false judgements about your engine.

I'm currently working on a indoor 3D engine that I'm going to make a simplistic FPS with. I don't know what all I'm going to optimize it with yet, but I'm probably going to use octrees.

how did you screw up the texture coordinates? they're compiled and stored in the bsp file, unless you're making your own editor?

it's not that anything is really screwed up, it's just that some of the textures are stretched bigger than they're supposed to be. This gets annoying when you have a door texture that you tile to fit right on the door, but when you compile it, it loads the texture in to the engine with half ratio, so you see twice as much as you're supposed to....

I don't think it's anything wrong with my loader, because i've gone over that a few times to make sure that it wasn't. I suppose I'll just have to see....

Okay, umm, I am assuming that
a) you are basing your engine off of the quake3 format
and subsequently
b) you are using some version of Radiant. If you are using the crossplatform GTKRadiant highlight the surface (or hold down shift in 3D to select the entire brush and all of its faces) press S which is for the surface editor, then hit fit...that automatically calculates the texture coordinates to fit. It is probably the same for Q3Radiant but I'm not totally sure (and there are some differences between GTK and Q3 Radiant).

yah, of course i'm using the quake3 format, and i'm also using GTKRadiant 1.2.1, because 1.4.0 or whatever the newest one is generated really screwed up polygons for some reason.

I'll tell my level designer about the fit thing, and i'll see if it fixes the problem. Thanks

okay, you need to implement rendering by triangle meshes, not triangle strips or fans or whatever it is in the tutorial.

just look at my source. YOu need to load the mesh indices from the file. Look at gametut's definition for a tBSPFace...it has vertex indices and meshvert indices, you need to use meshvert indicex so you can render GL_TRIANGLES not the other crap.

gtk1.2.1 is basically garbage by now anyway

Isn't it faster to render as fans, because there's a lot less vertices that need to be passed to the pipeline? Or is there some obscure thing that I'm not noticing about this?

actually no, im pretty sure the fastest thing you can render is a triangle. What do you think most implementations of OpenGL do when they get a triangle fan or some higher order primitive? They turn them into triangles!

Originally Posted by Silvercord

actually no, im pretty sure the fastest thing you can render is a triangle. What do you think most implementations of OpenGL do when they get a triangle fan or some higher order primitive? They turn them into triangles!

Rendering triangle fans or strips is faster than just plain triangles. If you have a mesh where many triangles share vertices and you render it as individual triangles, the same vertex will be sent through the pipeline many times. If you use a strip or a fan, shared vertices only go through the pipeline once saving expensive bus transactions and pipeline calculations.

Heres a decent explanation:
http://www.codercorner.com/Strips.htm