I kinda hope that some day more engines will support sqlite and we could use that to track and record all kinds of things locally. FTEQW supports it. 

sql is only really useful for single player, and even then you can often get away with frik_file instead.

when it comes to deathmatch you probably want some central server recording matches in aggregate, which would likely be programmed in something more php-ey instead of qc. naturally this avoids sql in the game server, but does require some sort of communication to said server... 

Is there an easy way to heist the vertex/mesh data from a Quake map? I'm trying to whip up some C# for using Q1 brushwork inside of Unity3D, and I'm hitting a wall.

Since I don't care about the lightmaps or vis data, I figured I'd try to divine the vertex data from the .map, but converting from the brush based geometry (calculating planar convergence) is beyond my skill. It'll probably be easier to let a compiler do the lifting on that and just read the data I want out of the resulting .BSP Are there any libraries available for working with Q1 .BSP? 

i think the bsp is a better choice as it is more mesh-like, and is already cleaned of things like tjunctions, overlapping polygons, etc. 

than has a bsp to blender importer: http://http://andyp123.blogspot.de/2013/06/blender-quake-bsp-importer.html 

when it comes to deathmatch you probably want some central server recording matches in aggregate, which would likely be programmed in something more php-ey instead of qc. naturally this avoids sql in the game server, but does require some sort of communication to said server...

The most obvious solution is to program the central server to mimic a client connection to the game server! Sure you waste a client slot on your stats bot, but who plays 16 player deathmatch anymore anyway...Of course you'd communicate directly from the QC using SVC messages to ensure your code runs on every engine. Just write, lets say byte-by-byte UTF8 encoded JSON, wrapped up as a sprint statement to the bot.

Preach goes off to write a web server in QC and is never heard from again 

my inner nerd has been awakened. this sounds like such a cool idea :D 

@preach
I know you jest, but there are bots that connect to QuakeWorld servers to scrape scores already...
That said, QuakeWorld does at least support explicit spectators so you don't need qc code to make them non-solid to avoid interfering with the game with free frags.

@ALLCAPS
walk the surface list. each surface has a list of edge indicies (either positive or negative). each edge has two references to each vertex. if the edge index was positive, take the first vert refered to by the edge, if negative then take the second (negate the edge index so its positive, but no bias as 0 is always invalid, and -0 can thus never happen). Walk the edges to get the list of verts for each surface.
To determine texture coords, you'll need to do some maths based upon the texinfo[surf->texinfoid] stuff:
vert.s = (dotproduct(texinfo->vecs[0].normal, vert.xyz) + surf->texvec[0].dist) / texturewidth;
vert.t = (dotproduct(texinfo->vecs[1].normal, vert.xyz) + surf->texvec[1].dist) / textureheight;
where dotproduct is of course ((a.x*b.x)+(a.y*b.y)+(a.z*b.z))

the texture index used is refered to via the texinfo object, which is of course refered to by the surface object.
the texture/miptex lump inside the bsp has this form:
int32 numtextures;
int32 offsetintolump[numtextures];
the start of each actual miptex is a 16 byte name, followed by the width and height as int32s, and if you're using unity or whatever then you should probably just use replacement textures and skip parsing beyond those fields, but if you do, there's an additional 4 offsets to the 8bit paletted image data after the height, expressed as offsets from the start of the texture and not the lump, one for each of the 4 mip levels that software rendered quake supported. You can likely just use the first and ignore the others. 

I decided to swap from using Q1 BSP to Q3 BSP, because there is a lot more documentation on Q3 BSP specs. I'm reading in the bytes for the header and everything looks good except for the first entry in the directory.

The length isn't a multiple of 4. At first I thought it was my code, but I checked the .bsp with a hex editor and it really isn't a multiple of four in the .bsp, and I checked multiple maps. Is this normal?

Is it because it's the entities node, and they're stored as strings/char[]? The spec says each directory's size should be a multiple of 4, and it doesn't say anything about the entities directory being exempt from that. 

That if I "round up" the size of the entities lump to four bytes it then matches with the beginning of another lump, so perhaps it on specifies how many single character bytes there are, instead of how many four-byte dwords it takes up? 

4-byte alignment, not 4-byte length. 

I finishes up extracting and parsing entities before I passed out, and everything seems to be working! Good to have clarification, though; thank you. This is my first time ever trying to decode/parse a binary blob like this, so I'm learning as I go. 

Here it is. Not finished, but getting there.

https://github.com/mikezila/SharpBSP

Once I have it working well and maybe crank out a winforms application that shows some info about a loaded .bsp I'll make a thread/news post about it.

I use C# instead of C++ partly because Unity3D uses it, and it'll make pulling this data into a Unity game/scene very easy, and partly because I'm a scrub that can't handle C++.

Not that anybody cares, but it's free to take/use/copy/modify. 

I've made some pretty great strides in parsing and rendering Quake 3 maps. I've hit a snag, though, and that snag is bezier patches.

Here's a video showing what I have so far, and my issue with the patches:
http://youtu.be/8RfwLP0BrSI

Textures, texture mapping/coords are working 100%. Only textures provided by shaders are not working. Animated textures and billboards aren't implemented yet, either.

But issue is that the code to calculate bezier patches is code I lifed from an article on render Quake 3 maps, and did my best to port from what I assume is C++, to C#.

I used these two documents to parse the .bsp and to try rendering the bezier curves
http://www.mralligator.com/q3/ - Map format details
http://graphics.cs.brown.edu/games/quake/quake3.html - Details on converting the vertex systems/scale and bezier curve code

I'm really stuck, as I don't understand enough about bez curves to write my own implementation. Anyone here worked on rendering them that could lend a hand/advice? 

you don't need patches (they're evil), just use q3map2's -patchmeta argument when compiling maps for your game.
q3map2 will then generate trisoup instead. 

That's great to know, and I'll use that for sure if I develop a Q3 .bsp intending to load it into uQuake instead of actual Quake, but I'm tackling the issue of rendering the patches for the sake of being able to render existing Quake 3 maps that use them. 

why not look at the quake 3 source code to see how it tesselates bezier patches? 

My raw understanding of the patches (and C/C++) is very limited, but I will likely have to do that. Right now I'm working on rendering multi-patch faces without any tessellation, just the reference points. I can render single-patch faces, but I'm working on how to extract the 9 reference points from the face, and making an individual patch out of that when there is more than one patch in the face.

Once that is done and references are rendering correctly, the only piece of code that will need changing to have beziers 100% working will be the method that takes those control points and fills the patches vertex and triangle strip data. Getting closer. 

well if your problem is the theory behind it, maybe i can help a little bit.

First, quake3 patches use bezier curves, which are parametric equations. This means that to generate a point on the surface you need to input a parameter. The parameter can go from zero to one, and as it moves from zero to one the point generated moves along the curve from the start to the end. The parameter is usually called "t".

Second, quake3 patches use quadratic curves, not cubic curves (which are more common i think), so that means they have 3 points to define a curve instead of 4. The three points are startpoint, control point, endpoint.

Third, how to solve a quadratic curve? First, look at this picture:

http://upload.wikimedia.org/wikipedia/commons/2/2d/Bezier_2_big.gif

P0,P1, and P2 are the three control points. Green stuff is intermediate calculations, and the red line is the final curve.

So to solve for the black point (a point on teh curve) you first find a point on the line from p0 to p1, call that A, then find a point on P1 to p2, call that B, then find a point on the (green) line from A to B, that point is your solution (black dot.) In all three cases, when you "find a point" you are finding the point using t -- if t is 0.5, find the halfway point. if t is 0.25, find the point 1 quarter of the way from the first point to the second point.

Okay, assuming you understand all that... the quake 3 patches are 2-dimentional surfaces, not just single lines. So instead of 3 points, they have 9. To solve it you need to do multiple tasks like the one above (solving a simple 3-point curve.) Since it's two-dimensional, to find a point you need two parameters instead of 1 -- instead of t, you need s & t.

Imagine the 9 points are arranged in a 3x3 grid. First row is 1,2,3, second row is 4,5,6, last row is 7,8,9. First solve three horizontal curves using s -- 123 is the first curve, 456 is the second curve, and 789 is the third. Each uses s as the input parameter. Each gives you one new point -- A,B,C. Now solve curve ABC with parameter t. Now you have found a point!

Okay, so now you can find any point on the surface of the patch using s,t coordinates. How to render a patch? What you do is divide the patch into a grid of quads. The vertexes of the quads are determined by inputting s & t. If you want N * M quads, you need (N+1) * (M+1) points. The first point is 0,0 and the last point is 1,1. Intermediate points are evenly spaced in between. 

That helped me so much, that using that info, some time and study, and some patience I have perfected parsing, tessellating, and rendering (with textures!) Quake 3's bezier patches. Huzzah!

http://imgur.com/a/i470V

Textures that are provided by shaders in Quake 3 aren't working for obvious reasons. I also need to debug lightmap ripping/application, but those are pretty minor issues. Unity's realtime and baked lights look better anyway.

Thanks a ton. 

Here is a link to the github of the project. It's free to do with as you please.

https://github.com/mikezila/uQuake

Don't want to keep mucking up the coding help thread, so if/when I make videos and take screenshots to show it off I'll probably make a new thread. 

Nice, you got it working! Glad to help. 

Is this a quake 1 engine?? 

The engine itself is Unity3D, which is a freely available engine that you can use for almost anything. I've built a reader for .bsp files, and a "renderer" that creates the level as Unity gameobjects. It's not a "true" bsp engine because only the geometry is used, things like leafs, nodes, the bsp tree itself, and vis data is not used. Unity handles those things on its own at runtime.

Right now it only supports Quake 3 maps, but I want very much to add support for Quake 1 maps. Once I get lightmaps working on Quake 3 maps I'll set to support Quake 1 maps. My original goal was actually Quake 1 maps, but extracting the geometry from them is a little more complex than Quake 3 maps, so I did this first as a warm up and to see if it was possible. 

nice work figuring it out!