gtkr1.5 has that tool as well, so it's been around for awhile. 

Just tested it. Aside from inverted normals, gtkr1.5 brushexport2 works fine.
Still an extra link in tool chain, but at least it is something I have some experience with. 

If you want export all brushes as mesh with UV then yes, it should be fairly easy to do.
I'll update OBJ-2-MAP in a few days. ATM I'm adding classic format and valve220 + UV to one OBJ-2-MAP version, so you'll be able to choose. 

I believe I found a bug in the tool. Trying to send you an email, but server is rejecting it.


...
The error that the other server returned was:
550-5.1.1 The email account that you tried to reach does not exist. Please try
...
 

Probably best to post the bug here, actually. Multiple people are touching the source code these days so it's more productive to make it public. 

Since description page doesn't say that mesh should be 100% convex, thus I assume it is a bug.
Here are few meshes I experimented with:
https://dl.dropboxusercontent.com/u/58150516/q1/test_obj.7z

test_0
Worst case. Doesn't show at all in editor.
For some reason I can't create new brushes after opening generated map.

test_1, test_2
Only part of original mesh exist in resulting map.

test_3
Fully convex. Works flawlessly.

Default conversion settings used.
GtkRadiant 1.6
Any additional info I can provide? 

You are right, unfortunately n-gons and weird faces will not work in OBJ-2-MAP. I have a plan to add triangulation for non supported faces. What do you think about this?

ps.
thx for examples, it will help a lot 

n-gons should work as long the face is convex. 

Well, maybe not with all modes ... hmm ... 

Browsing around the internets I came across a thing, which led me along a train of thought that ended up here:

there is a workflow that I realise would allow to rip / export these maps. it is as follows:

1964 N64 emulator.
add lemmy's gfx plugin.
load quake64
export geometry to VRML
convert VRML to obj in (insert modelling app)
convert obj to map

heck, this would even work with other n64 geometry. 

I imagine it's fairly low poly and blocky. 

N64 Quake maps are just very simplified Quake maps. I'd say not really worthy of the effort to get it ported to PC. This is contrary to Quake 2 and Doom which were both different experiences from their PC counterparts, Doom 64 has already been ported to PC with Doom64EX and I think Quake 2 deserves similar treatment. 

any other games you guys deem worthy? 

Meaning n64 quake's maps were simplified versions of the actual stock maps we've seen already? 

that's right. Quake 64 were simplified versions of the id maps. Doom 64 and Quake 2 were completely new. 

doesn't this "export geometry to VRML" work with visible geometry only? 

so in order to export large regions you need to do multiple parses. 

Cut out areas in each map. I think the DM ones survived, apart from DM3, which I vaguely remember was cut completely. 

Yes, the N64 maps were lower poly versions of the stock id maps, but even so that conversion pipeline you posted would be a horrible way to do it considering they were most likely in the same or similar quake .bsp format, so I assume the triangulation of the geometry would be a horrific mess like in a typical quake bsp. 

Did few more tests with geometry triangulated before OBJ export:
-------------------------
1
https://i.gyazo.com/b7aaee92102d303b106f224717330994.png
Still doesn't show in editor.
-----
2
Tried to explode mesh to separate objects by planar surfaces and export as single OBJ. (Dragged apart just to demonstrate separation, actual export had it all composed to form original shape from first image.)
https://i.gyazo.com/c68d21c69231501a34a7e4d1af420f90.png
In editor each plane was enormous.
https://i.gyazo.com/64b3cb526d1492c1e9c0e3cbf301c830.png
I suspect brush[es] is too big to fit editor's working area every time I'm seeing nothing on map load, but can't confirm.
-----
3
Divided in 3 objects.
Those 2 broken cubes in the middle is one obect.
https://i.gyazo.com/1a73b829eca2febfd9ace8e7b11bcba3.png
That worked a bit better - holes automatically capped, but middle part is missing.
https://i.gyazo.com/4e2b52fe9bd44f5a929b83d8aa2d2058.png
-----
4
Same as before, but each broken cube is separate object now.
https://i.gyazo.com/295ee6321b434b52dd0dbd8be3cad663.png
Results in this:
https://i.gyazo.com/1ad1233bd0ef52c2fddba2c1922a9f5d.png
Cube parts go to "infinity". At least far beyond the end of editor grid.
--------------------

OBJ files:
https://dl.dropboxusercontent.com/u/58150516/q1/test_obj2.7z 

I doubt they're in bsp format. Even if they are, the rom dump process probably doesn't retain any semblance of a file format. It's probably the simplest way without actually reverse engineering the rom programming.

you could *try* and hope for some success with watching memory for bsp headers, it's just so unlikely though. In all likelihood the programmers stripped all superfluous data from the game to save space. 

True. Console games are generally munged pretty harshly to get into memory. Headers and such are right the fuck out... 

DW

Try this one again:

https://embed.gyazo.com/295ee6321b434b52dd0dbd8be3cad663.png

But cap all the geometry in Blender so there aren't any holes. OBJ2MAP doesn't add capping geometry or do anything other than convert triangles to planes. You need to feed it valid Quake geometry. 

In other words, the cubes extending to infinity is totally expected ... there aren't any side planes to clip it against. 

To see it in action, feed it a cube and look at the results. Then remove one of the cube faces, run it through again, and see what happens.

That should solidify what's going on in your mind. :)