For the thousandth time, tronyn's is NOT BSP2, it's 2PSB. 

(Think I'll let the weird Spanish translation stand for that one)

ALLCAPS, I can send you a true bsp2 map in a couple of hours; back to the office today.

Do you just need the bsp? 

Yes, just the .bsp itself. 

The dropbox folder (mail etc. sent).

The BSP inside 'should' always be a fullviz, if that matters to the port process.

If not then I can upload one quickly enough - it takes about 10 minutes to compile, using Tyrann's tools. 

Vis data is not used (or even parsed) currently, so that won't matter. I do plan to implement it in some capacity, but haven't yet. Trying to tackle the performance of loading big maps first, so that I don't end up having to refactor a bunch of stuff. I suspect implementing vis will cause/require me to change how I generate my objects, and before I do that I want to see what performance gains I can get. 

What's in there should definitely work as a decent benchmark then. 

If your meshes were grouped together better, then I'm sure you could use unity's occlusion culling feature (pro unity only tho) 

In theory you could just skip adding mesh colliders to the faces as you made them, and then create meshes from the bsp brushes in the map, and a collider to them, and skip adding a renderer, so you have an invisible clipping brush. That would be needed for sure on some maps, where simplified collision stops the player getting hung up on detail in the map.

If you have access to the .map file, and use the brushes in the .map file to generate the collision meshes, then a couple of things occur to me:

1) You could detect which brushes are essentially boxes (probably a lot of them), and use box colliders for them instead of mesh colliders.
2) The non-box brushes are still guaranteed to be convex, so you can enable the convex flag on their mesh colliders, which I'm sure helps. 

Hmm. Doesn't the .bsp have primative bounding boxes in it for fast collision testing? Maybe I'm thinking of the wrong thing. I didn't mean to use the .map to create boxes from brushes, I thought they were in the .bsp. I think I used the word "brush" when I shouldn't have, causing confusion.

I hadn't even thought about marking the mesh colliders as convex. That's a great point. I'm about to start doing some System.Stopwatch tests to see what takes the longest and what is worth it to optimize and what isn't.

Still haven't looked into lightmaps, but from a cursory glance it looks like they're not going to be simple; at least not as simple as Quake 3's were. 

no. bounding boxes in bsps are for frustum culling. they're not useful for collisions as the bsp tree will cull all that effectively enough anyway. 

Trying to parse the vis data, and I'm trying to verify that I correctly understand the run-length encoding used. Consider:

10100010

Would that RLE to

1010310
or
10100310

Some places say that Quake vis data only does RLE on runs of zeros, but the only doc I have is the one that has proven to be very outdated. 

Can a face be part of more than one leaf? 

I've sped up start up dramatically. Replaced all remaining Lists with length initialized arrays. This cut startup time on ivory.bsp (which as become my benchmark) from two and a half minutes to two and a half seconds.

I also detect clip/skip faces and don't render them, which makes maps a lot more fun to fly around!

Here is a build for you guys to test out and play with:

https://dl.dropboxusercontent.com/u/5408868/qtest.7z

I've included Sock's ivory.bsp as the default map because it is awesome, and I used the spectacular rockwork to test/verify my texture creation/application was working right, which it is.

If you'd like to try a different map, open the "assets/resources/maps" folder and name the map you'd like to try "map.bsp" and it'll be used. The camera will spawn at the world origin. Mouse1 will move you forward, Mouse2 backwards. No WASD, just mouselook.

Currently there is no vis consideration at all, so what is being rendered is up to Unity. This isn't ideal at all, so the map might chug if your video card isn't up to it. Give smaller maps a try!

Currently only BSP29 maps are supported, but BSP2 support will be trivial to add. I'll do it next session I think, to take a break from fighting with vis data. 

Could you explain, what the main purpose of that uQuake util 

Doesn't run on my rig 

not a valid Win32 application apparently. 

Sorry forgot to mention that build is 64-bit only. I'll build a 32 bit version.

Honestly I'm not sure what the ultimate purpose is/will be. Really I'm just doing it because it's fun to make. Though Unity runs almost everywhere (Windows, OS X, iOS, Android/Ouya, web browser, Windows Store/Phone, etc) so if I can pull it off the end result will be a (free) Quake engine for a bunch of devices. Really now I'm just doing it as a programming project based around one of my favorite games. 

You might also need the Visual C++ runtime on 64 bit, which is here (it's tiny) http://www.microsoft.com/en-gb/download/confirmation.aspx?id=14632 

Not had much chance to get things on my blog recently, but put out a short article today.

http://tomeofpreach.wordpress.com/2013/10/19/random-entities-find/

It's a combination of a neat mathematical trick and a little bit of glue code which allows you to select one entity at random from find or findradius result sets. There's also a pattern at the end for writing find loops, so you don't have to repeat your find code at all. Whether it's an actual improvement or not is up for discussion... 

Sorry for the 64-bit snafu. Also sorry for using Dropbox, it's not the best for sharing public files. Lets try Github instead.

https://github.com/mikezila/uQuake1/tree/master/Builds

Pick your favorite flavor, 32 or 64. You might need the Visual C++ 2010 runtime if it complains about Mono. 

I'm thinking on the problem of using the vis data from the maps in my renderer, and I'm running into a few snags. Some of these snags are no doubt a result of me trying to take shortcuts.

At first I thought I could use the bounding boxes for the leafs, and just check against them using the player/camera position. This would make it very easy, as each leaf knows what other leafs to render. Problem is that the only bounding boxes in the .bsp are stored as shorts, not floats. The problem with that is that to convert "Quake space" to "Unity space", I have to scale (and rearrange) the vector3s by 0.03! That's a pretty extreme scale, but it wouldn't be a problem if the bounding boxes were stored as floats, but they're not. Once I do this scale, the boxes are not accurate enough, they're obviously off center, and not shaped/proportioned correctly. I thought I could work around this by making a bounding box myself that encompassed all of the faces in a leaf, but there is a lot of overlap in many places, even if I just overlap the center of the faces and not their whole bounds. On the plus side I accidentally made a pretty nice tool to check if parts of your map geometry are producing shitloads of leafs.

I also made a bad assumption that a given face could only be a member of one leaf, but it looks like that's not the case. I should have known better, as if a face could only be in one leaf it'd probably be listed in the face struct.

Is there any shortcut I can take, as opposed to just implementing the bsp tree wholesale? I'm thinking pretty hard, because with all the modern tools available it seems like it'd be easy, but I can't come up with anything. 

It sounds at first blush like you're doing something wrong with the bounding box scaling. Scaling it should be perfectly doable without it shifting off center. There must be an incorrect assumption you're making there or something. 

I agree with Willem, are you sure you are not somehow casting the result of the scaling back to short? Although if you multiply a short and a float, the result should be a float, also. 

Yeah I was botching it. I was reading the 12 bytes that contain the shorts and passing them to be handled by the leaf constructor, but in that constructor I was only using the first six bytes to make my six floats (ugh). Corrected that and now the boxes are placed and rendered correctly. I'm currently fighting with Unity's local vs worldspace shenanigans, but it looks like this might just work.

Thanks for calling me out on my assumption. 

There's also a pattern at the end for writing find loops, so you don't have to repeat your find code at all. Whether it's an actual improvement or not is up for discussion...

How does it compare to using a for loop to find, instead?