News | Forum | People | FAQ | Links | Search | Register | Log in
OBJ-2-MAP V1.1
So I added a few new features to my OBJ-2-MAP utility and put together a small web page explaining how to use it.

This is a utility that can take OBJ files exported from any modeling app and convert the geometry inside into Quake brushes.

Have at it! I think everything will work.

[edit: updated url]
Oh My God! 
Google sketchup mapping! 
Let The Brushes Flow! 
Yea this will be interesting for future maps. 
Hosting websites on Dropbox is only meant for short-lived temporary sharing, please upload to Quaketastic or your own website?

Page cannot be crawled or displayed due to robots.txt.

See robots.txt page. Learn more about robots.txt.
When I get time. 
I've moved the site to my web site. Does this work better? 
Could an admin change the link in the OP? 
Does Geo need to be convex and manifold? 
Now we just need map to obj so as to plug Trenchbroom or Radiant into the UE4 workflow. 
Fixed url 
only if you select standard. If you select the other 2 modes, it will create 1 brush per face.

Going standard and convexorizing your geometry yourself works really well though. 
Minor Request 
when you have a lot of faces to process, this can take several seconds. you might consider adding a progress bar as currently, the window just freezes and the icon disappears from the taskbar until it completes. 
I always meant to do that ... I just never had a case where it took more than a second so I just didn't bother. Heh. 
users will always find a way to break your software, especially if that user is me!

i think the only real weirdness is the way it vanishes from the taskbar while it is working and doesn't reappear until you click ok in the dialog box that pops up when its done. it makes it look like it closed if you bring another application into the foreground and can't see the window anymore. 
It does that? I learned something today. Ha... 
Dot & Comma Confusion 
There is a bug.
In some countries we use commas to separate float part instead of dot, and now it tries to find comma by default on my machine = Exception Thrown.

Easy to fix.
When you parse obj's vertices do CultureInfo("en-US"), like this:

double.Parse(strArray[1],new CultureInfo("en-US"))

It will force Parser to search for dot.

Btw. are you not interested in releasing it as Open Source?
We could improve it! :)

this is something that only really comes up when you're working with this tool the way I am, but it would be cool if you could save settings specific to certain models, so when I convert an obj for the first time, it writes a text file with all your current settings beside the .obj file. then the next time you choose that obj file, it autopopulates the settings into the gui so you don't have to type them in again. 
i'm also a lazy bum, in case you didn't know. ^_^ 
Haha, no, makes sense. That irritates me too... 
I HAVE SOME THINGS TO CLARIFY WITH YOU, i get a deamon back from epic.

thats so cool:) 
Talking To Myself 
i try this one

willem -AT- wantonhubris -DOT- com

Vote for obj2 map, makes your life a breeze!

Now more tris free!! 
I Can Paste My Troubles Here I Guess 
i have had some map files recently that troubled me and my minions. Basically it was a parsing error that stopped all editors from loading the obj2map output.

Modo files works a charme, these hassles came from Z-brush files that were either scaled bad or what do i know.

I dont have a clue right now, i can sent you all assets for a check. Sure. 
mfx , can you upload some example OBJ / MAP file that doesn't work? You can export just simple object that gives broken results. I would like to take a look and maybe find some solution. 
My new website is . Email is warren @ that domain.

But yeah, post it here maybe ... someone will be able to tell you what's up, I'm sure. 
I have a dragon now, be nice to me.

Thx Warren! 
Mother of god... 
So Is Nice... 
Scale Comparison 
Fuck yes! 
Input .mdl made by ptoing.

Thanks man! 
A custom Ogre? The model looks different somehow. 
This is why we need smooth shading functionality in light.exe 
So, uh, who is going to do that rpgsp1 secret thing with a 3D scanned original? 
btw I did small patch for OBJ-2-MAP for myself. Dot/Comma problem fix + settings saving (to xml per model) If Warren don't mind I can release it as unofficial binary patch. 
Sure ...

I told Eric this but I might as well make it official. I apparently lost the source code to this. It must have been during my transition from Epic that it got lost in a crack somewhere and deleted. I've searched high and low and ... nothing.

So, I apologize. If anyone wants to reverse engineer the EXE or whatever kids do these days, I don't mind.

Go forth and do whatever you like. It's honestly not that complex an app so maybe something should start up an open source version of it or something so everyone can pile in fixes and features... 
This is my karmic retribution for not allowing the source to be downloaded right from the start.

Smooth move, Warren! 

Yeah I have reversed source, even Designer's window form is in the project. Variables have generated names, but that's easy to correct.

I'll add informational comments and release it in some private git repository, so we can check out if everything is fine before public release.
We need to think what licence we want to apply, or maybe we'll keep it as private repo for community only? 
Ha, awesome! Thanks for heading that up, I appreciate it... 
Wow, that's amazing you were able to decompile the whole thing :o

So it is actually an openable project now? 
.Net decompilers are very clever these days.
Yup it's a whole VS project, decompiled to C#. 
I'll prepare git repo next week.
Sorry you need to wait, I was extremely busy last days and I'm heading on 4 day holiday atm, so I'll be away from computer till Monday (I'll lurk from mobile ;) )
Here you have binary, so you can use my latest changes:

It saves settings to XML file (OBJFileName.xml) when you hit GO! and load settings when you choose OBJ file.

Happy mapping! 
Blender OBJ Export? 
I have tried many times trying to get blender OBJ export to work with this tool, but each time I get a NullPointerException in the debug window. 
Shoot me the OBJ file and I'll see what I can do about it.

(email in my profile) 
ShoTro have you tried this build: ?

I have used it with blender and had no problems. 
Hey Kreathor 
Could I grab your decompiled source? Wanted to play around with a few things. 
What languages/tools you used for UI and code itself? 
AFAIK It's C# 

There's a repository that Kreathor set up over here ...

The source has actually been updated and had a few features added ... so you contributing to that source tree would be ideal. 
Requires Login 
Ah, Cool! 
Looks like it's a private repo, I just asked kreathor to add me.

I'm going to try doing import of UV's and texture names from the obj file. If the model is triangluated and you export to Valve220 it should work flawlessly. 
Mother of god... 
Repo Is Public Now 
I made repo public! Sorry for inconvenience! :) 
ah mah gahd, this is awesome you guys! 
There's a fewest-planes wrapping algorithm floating around somewhere that would be ideal for exporting weird shapes like dragon heads in an optimum minimum number of convex brushes ... 
Oh My Goodness! 
Just out of curiosity is it possible to use valve220 map formats to make quake1 and 2 maps for the compilers? 
Yes, modern Quake compilers can process Valve220. 
This has probably been asked a dillion times, but does the .bsp format support arbitrary texture alignment or is it as limited as .map and you need .bsp2? 
Final .BSP Dont Care 
.bsp ultimately does not give a crap since its turned into pure polygons with uv coordinates. .map brushes and the way the data is stored was purely out of speeding things up during those dark days when unwrapping and texture alignment was a pain in the butt.

In fact you could in theory edit the texture mapping after a compile and replace it. 
its only quake3 that has actual xyz+st+lmst+rgb coords. the earlier versions all calculate everything based upon the xyz and their texinfo's texture planes (basically like valve220 with the scale+rotation things baked in to the plane itself).

this means the (software) renderer can generate the s+t coords dynamically after clipping, instead of having to clip those s+t coords to the screen too and getting extra imprecision+inefficiencies from doing so. 
Wait, really? So ... potentially I could, say, model an entire level and then use whatever eric is cooking up to turn it into an actual map? With custom UVs everywhere?

Don't tell me that's true ..I'll never sleep again... 
bsp.exe will be having a right old party, but it sounds like it :} 
UV Conversion 
This was a lot more of a pain than I thought, lol, but I think I got it working, Here is a beta.

If anyone tries it out:

Before doing the conversion, you have to add all of the textures used by the OBJ file to a Quake WAD, and put it in the same directory as the OBJ. (The reason for this is OBJ2MAP needs to get the Quake texture sizes is order to write the correct texture axis values.)

Secondly, the texture names are read from the "usemtl" lines in the .OBJ. Whatever's after "usemtl" is used as a texture name - directories and file extensions are stripped off first. I'm pretty sure this isn't quite the correct way to read skins from a .obj, I think you're supposed to use a material file, etc..

Finally the output is Valve 220 format only, so this is only usable with Hammer/Jackhammer/TB2/etc.

Future ideas:
- read .mtl file for looking up texture name?
- automatically read in the images referenced by the OBJ and convert them to a WAD file?

I included a sample model (from xonotic) that I was testing with, along with a texture wad, so you can see how things need to be set up for it to work.

source code is here 
NICE Time To Take This For A Spin. 
This should make for some crazy maps in the future if this works as I imagine it too... 
Crazy! Can someone post some screenshots of it working? :P How much freedom is actually possible here?

Or, a better question ... what sorts of limitations on UV mapping are there? 
More Complex OBJ Doesn't Work For Me 
I'm getting "Error computing texture vectors" in log.
Ericw I can send you an OBJ if you want. It's quite big. Everything exports except UVs.
Exporting simple box works lol :D

I was looking at code but have no clue why it's not working atm. Need more time to analyse your work :)

Ohhh... and in Jackhammer Y Scale of tex is 0, so you need to change it to 1 manually... 
Only limitation I'm aware of is, if the .OBJ contains quads, the tool will just pick 3 verts to compute the MAP texture alignment, and ignore the fourth.

Other than that, it seems to work as expected, it'll shear/rotate/scale/offset the texture as needed so the UVs line up.

I just have this ugly robot model (same one that's included in the obj2map zip) for a screenshot: 
argh - sure, sending over the .obj would be great. 
I just wanted to export "shit" like this:

Maybe I was too optimistic :D 
Screenshot Derp 
here's the working link:

khreathor: dunno, should be possible :P
Thanks, just got your email. 
That's pretty insane!! 
i think you are too optimistic :P

that would be cool though! 
If you listen carefully you can hear the BSP format sobbing gently in the corner. 
Promising But Some Errors.. From 3dsmax 
So I gave it a spin and it does some things right and others wrong with my current setup as far as I can tell.

Here is a screenshot showing my lovely test cylinder in 3dsmax and the resulting data inside TB2.

For starters when I load my wad file it applies all the textures correct. But for some reason in 3dsmax its taking the name of the texture from the material name? And not the actual texture loaded. Oh well I can make that work.

It does get the tiling amount correct for the top but the side faces are skewed. I do believe TB2 supports Valve220 though unless I missed something. I've also included the OBJ output from 3dsmax and the wad file I used. 
Hmm Weird 
I think you set everything up correctly, but when I convert your obj it looks fine.
Old build of TB2 by any chance? Double check in Jackhammer? 
Can Confirm... 
I got same results with cylinder as Skiffy...
Tested on Jackhammer 1.1.700
Log full of "Error computing texture vectors".
I just wonder if it's not another problem with dot and comma conversion. In some EU countries we use comma instead of dot, to point floating part. During computation Parse is doing wrong conversion or something like that and outputs rounded results or throw exception. That's why I added "Culture" thing to force dot... but I found maybe one place in the new code where you can add this, but it shouldn't matter tbh. Gonna check it in a moment.

EricW can you sens us MAP file with this cylinder? 
Ah Thanks For The Hint 
yep.. confirmed it is a comma floating point issue, will fix it 
OK Should Be Fixed. 
I updated the download in post #66 
Idk Anymore... 
Still not working properly for me... I think I'll debug it step by step, after I finish other stuff. Can you upload cylinder MAP for me? I wanna see how far values are from proper map file. 
What is a good simple (as in learning curve) modeller to use for this? I've tried TB, Quark, and JH / Hammer to make maps over the years. But have never tried using a modelling program (other that POVray with Moray). 
Sooo Many Choices 
Hmmm if you start from nothing? 3dsmax, Maya, Modo... Cinema4d.... Blender? 
I guess Blender ... it's the only free modeling app, isn't it?

I use MODO for everything. 
Blender, No Question 
Got It... 
I just lost 8h of source debugging, line by line, with calculator and shit, to realize, it was all fault of "Axis Aligned?" checkbox... -_- fckin' checkbox...


Results are amazing man... <3

You deserve a medal and sixpack of a beer!

I think new era of Quake mapping just started :D 
Oh Man 
sorry you had to go through all that debugging, but awesome that you found the problem and it works! argh, I must have always been testing with "Axis aligned" unchecked.. 
Axis Aligned?? 
I must be missing something in TB2 then? my models are still messed up :( 
did you try the beta 2 version? I updated the download in post #66. that should fix the cylinder model if Windows is set to use comma for the decimal point when printing numbers. 
You probably have set Method to Standard, it wont work with this unfortunately. You need to go with Extrusion or Spike.
I think it's not hard to turn off this Alignment in code for Standard too. Will take a look later. 
I use standard because I construct proper BSP brushes for various things instead of relying on the extrude or or Spike method. So yes indeed I would prefer to have the standard one working too.

This is what we did on Gunman Chronicles back in 2000 :)

We used to have a tool similar to OBJ2MAP but it got lost in a HD crash source and all. But hey now we have this improved monster! :) 
you worked on gunman TC? i remember being really impressed with the screenshots I saw of it at the time. (when it was a quake TC)

Especially the giant hand sculpture. 
Gunman Chronicles was neat fun. You would think that sculpture would be among the top image results for the game but...oh well :^| 
Yea Ages Ago. 
Yea I was the main modeler / animator on the project back then. So all enemies and guns plus tons of props modeled / animated. 
Street Cred, Yo! 
Yeah Gunman Was Great Fun 
and I remember some of the cool models, like the Star Wars like monster that comes out of the ground. 
It Had A Lovely Name 
Known as the Xenome Grande, very creative.
Large Alien in Spanish hehe. That sucker was sculpted in clay and then surfaced using a microscribe and Amapi the modeling software with good drivers for it back then. It was a pain in the butt to animate. I had no clue how to setup spline rigs back then. So FK tentacle animations all the way! woot!... :P 
it was definitely a very interesting monster for a modded q2 engine! 
does that actually compile and work in game? 
I haven't got time to compile and test it in game, but with BSP2 it should work without a problem. 
Looks Great! 
Now make a quake level! 
now all it needs is arghrad-style phong shading. 
And A Shub For A Hat... 
Simple Forms 
After trying out some complex forms I thought it better to start with simple forms to get grip on this handy program.
So I started with a cube and tetraeder and that worked well.

My cylinder doesn't come out.
So I assured myself the points were on grid, used noesis to convert it again, as my *.obj files didn't seem right.

What I tried looks like a cylinder, but I needed the spikes method, otherwise there were some blended side patches and the form was not editable in quark.
Now it has the form but the patches are glued inwards. 
Maybe turn off "axis aligned" ... that will mess up a cylinder. 
keep on ending on this result.
Here are the obj and map file.

I tried the email, but it's outdated. 
Location Outdated 
I would like to add some fine results,
but feel so lame by example. 
Your map file looks fine to me as far as the geometry goes. The cylinder is open at the ends so you can see the ugly spikes generated by the "spikes" method, that's normal.

Whose email is outdated btw?

For the texturing, try downloading the tool again from post #66, you have the older version; it should say "UV conversion beta 2" in the title bar. Your obj file has "usemtl UnKnown0", so you need a wad file in the same directory with a texture called "UnKnown0" for the UV import to work. 
I sended an email to warren.marshall/dot/epicgames/point/com.
That's the email adres on the linked site and it didn't work.
I saw there's another one in "people" so I guess it is altered.

I will try the updated one, maybe it has better results.
This one brings up a cylinder with triangles messed up to the inside.
I expected a smooth round outside.

thanks for the hint. 
I don't work at Epic Games anymore.

But regardless, any UV stuff is really Eric's ... I have NO idea what black magic he's doing. :) 
JackJazz will miss you.
Doesnt Export On Extrusion 
Hey there,
I've been looking for something like this for quite a while for mapping with COD: WaW and COD 4, but I just cant get it to work the way I want. It seems "extrusion" is more than likely the mode I'd want to use (as I want to recreate a map from a 3D model. I've used OBJ exporter for 3DSmax 2015 which seems to have exported properly. I've removed all textures (as I don't mind re-texturing), so in OBJ2MAP i've typed caulk in place of DEFAULT so COD WaW Radiant will read it. Unfortunately due to the conversion process, it's just got too massive in scale, and there is no option to reduce scale on OBJ2MAP.
Any ideas ?
Thanks in advance. 
I totally must have had a mans look. Just saw the "scale" % field. It still crashes at Extrusion though (Unhandled Exception). It makes me have to exit the program and re-load it, otherwise the log file is "in use" by another process. 
That's odd. Does "Spikes" crash as well? That might work for something modeled in Max as well.

Also, try checking or unchecked the 'axis aligned' box and see what happens. 
Crashes on Spikes as well. Tried both combinations (with and without axis aligned box) and it does the same thing. I wonder if its Windows 10 related...or maybe I need some Runtime files that you have and I don't.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at OBJ2MAP.XVector.Multiply(XVector _V, Double _Scalar)
at OBJ2MAP.MainForm.GoButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

All I'm getting when I get it to make a map (which takes bloody ages) is a bunch of jumbled (but joined) brushes which I can only manage to load into trenchbroom (although i'm trying to get it into COD Radiant. There is no pattern there, it's just a jumbled mess.

Radiant throws a fit and tells me it's missing a { no matter how many times I compile it.

I think maybe I'm just expecting too much from this..single models it will no doubt work, but a whole map is probably just too much for it to handle. 
How many faces is your model? I was able to convert a whole map's worth of geometry for terrain without problems from obj2map, so it might be something else. I used max 2009, possibly the obj format is a little different in 2015? 
Vertices: 33410
Faces: 12
Brushes: 202

It is possible that the obj is getting corrupt in the conversion process I suppose, but I can load it perfectly into windows 10 3d builder and Blender. I can not get anything to export the .map's properly though. 
Which build of obj2map was that with? Maybe try the beta in post 66; I remember fixing a bug with a similar stack trace as what you posted. 
Both versions (1 and 1.1.1) did the same thing. I'll try this beta (extrusion\grid align locked it up to a "not responding" state), so I'll try the other combinations and let you know 
Standard\axis aligned : Stuck on "Adding brush 0 to map" - Not Responding -..took 40 mins to get the brush 1

extrusion\axis aligned : Stuck on "Adding brush 0 to map" - Not Responding

extrusion\no axis aligned : Unhandled Exception
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index

Spikes\axis aligned : Stuck on "Adding brush 0 to map" - Not Responding

Spikes\no axis aligned : Unhandled exception - The path is notof a legal form. 
I'm going to try 3DSmax 2009 and see what happens with THOSE OBJ's. 
Ok, installed 3dsmax 2009, Re-ripped and exported the OBJ again (successfully). Same errors as before. Must be Windows 10 related. I'll try on other PC's around the home when I get a chance 
OBJ is an ascii format. Open it and check it. 
Or post the file here. Maybe someone can figure out what's going on. 
Vertices: 33410
Faces: 12
Brushes: 202

I mean what were the stats in Max. Also the above numbers don't make any sense. 12 faces with 33k verts?

As a reference, I was successfully able to convert a mesh with 5k triangles and 2.5k verts into a map file from Max2011 (sorry, i said 2009 earlier). 
Try to triangulate whole model and see if it works. 
I've uploaded the file to my ftp. Now please note, this is a private project, and the contents DO infringe copyright. So please delete it once you're done, as it's not mine to distribute. I'll be deleting the file off the ftp in 24 hours. 
That Mesh Is Kinda Messed Up 
I have a hard time seeing it ending up as a map file at all. 
That's what the OBJ converter does from 3DSmax 2009 and 2016. It loads fine into Win10 3D builder and blender, but as far as map conversion..I think i've hit a wall. (so to speak) :) 
Imported The Obj Into Blender 
Mesh is just a massive cloud of orphaned vertices.

I'm all for experimental maps and whatnot, but... 
There Are Triangles There 
Try zooming out 
I looked at that OBJ. That's never going to convert. That's insane. 
And Where's It From? 
I'm guessing from the googie look and file name it's something Fallout related? 
I mean, maybe break it down into smaller chunks or something but :

(a) it's absolutely immense - MODO tells me there's ~163,000 triangles

(b) there's a mountain of triangles (none of which are anywhere near a grid, I'd wager)

(c) I think it broke when loading into MODO, to be honest, as there are missing polys everywhere, tons of overlapping stuff, etc.

Just ... bleh. 
The idea behind this app is that you're modeling with Quake in mind. :) 
I loaded it into MODO and I had to flip it upside down to make it look right. Then 90% of the tris are triplicated, so ran a poly.unify on those.
Even then it's still a mess of weird orphan objects floating in the middle of nowhere, partial houses, and broken terrain. 
Yep, I totally agree with all of you. It's a bloody mess. Just needed more opinions before I threw it in the "too bloody hard" basket.
Anyway..Treyarch just announced mapping tools for Black Ops 3, so making new Prefabs is the next project instead. Thanks for all your questions\answers on this problem. 
Eric, can you add your source code into the main repository? If it's there, I apologize, I'm not too familiar with this stuff ... but I don't see it.

Anyway, bug report ... you can't leave the MAP filename blank anymore. That was useful for people who only wanted to copy the results to the clipboard. If you leave the MAP filename blank, it crashes. 
Err ... I think I see it now, you DO have code in there. Stupid SourceTree... 
Yeah- all my code is up on bitbucket, I was working on my own fork here: , but khreathor pulled all of my texturing stuff into the "wip" branch of the main repo. 
someone has a favorite head shape 
yeah I merged it into wip branch, because I wanted to keep old stable source. It will be good to make some radio button where you can choose between old and new method, classic MAP and Valve 220 MAP. What do you think? 
Latest compiled version of this treasure anywhere? Not sure how best to go about compiling the one from the repo... 
afaik, the latest builds are post #47 for the regular version or #66 for UV+texturing import.

Compiling it is pretty easy, install VS Community 2015 (large download), double click the .sln file, and click the Start button. 
Anyone Use It Yet On A Full Map? 
Ah cool thanks. Just wondering but did anyone use this in Arcane Dimension or any other recent maps yet? 
see necros' fire and brimstone jam map 
I've used it for pieces in maps ... "The Hell That's Coming" had a skull face cave entrance and there was something else too.

I haven't done a full map tho, no. That would be ... interesting. And I imagine leaky. 
Full map... Make it func_detail and box it in. Basically do like you'd do in Doom3 with meshes. 
Aren't there still collision horrors everywhere? 
How long does vis take with such a map?

I imagine this style of design wouldn't lend to big maps with lots of monsters because there would effectively be no visblocking (or am I wrong?). 
Well, if it's a giant func_detail inside of a box ... VIS should be almost instantaneous. 
I imagine you're not literally suggesting surrounding it with a big box, but rather having a boxy structural hull that still essentially follows the layout of the map?

Interesting Discussion 
What would be the drawback of building your map out of simple brushes, and then when you need detail that requires using techniques that often cause invalid brushes / microleaks (such as vertex editing), just adding such things as detail brushes inside the already built and sealed structure?

As an example, let's say I'm doing a section where I have rocks on one wall of a room. I'd build that wall using a simple cuboid brush that seals the room, and then add the rocks as detail brushes. Is that feasible, or do detail brushes cause other headaches? 
I'm pretty sure that's more or less how everyone has mapped since detail brushes became available. I may be wrong. 
I've heard (but not looked into it myself) that detail brushes that stick through the structural hull and into the void are problematic - does anyone know anything about this / elaborate? 
I would advise against that anyway. Build the detail brushes flush against the sealing structure.

I'm trying to put together some best practices for the TrenchBroom 2 manual. 
"I would advise against that anyway. Build the detail brushes flush against the sealing structure."

Why is that? 
Like UE, where BSP is just for blocking and the rest is meshes. 
Afaik detail brushes don't care where they are. func_ objects that are in more than one leaf, or that stick out of the world, can have the entity flicker problem though.

Details are part of the bsp though, so if you can see em, there they are.

The bug they can cause is when a mapper either on purpose or mistakenly uses them to seal a leak, inadvertently creating one.

The bad practice is making everything in the world detail, apart from your outer hulls, effectively trading off vis time for performance. This is usually unnecessary, but also kind of subjective over 'when' it becomes bad practice, depending on your geometry. 
Oh, but UE and other engines has a portal system that Quake 1 doesn't have (not that I know of). Does Quake 1 have hint brushes? 
I mean, you can make the sealing walls world and the rest detail, as BSP + meshes in UE. But you don't have any tool in Quake 1 to manually tweak VIS behaviour, like Q2's hint brushes. 
Modern quake compilers do have "hint" texture support to force a BSP split. Never tried it myself.

Oh, but UE and other engines has a portal system that Quake 1 doesn't have (not that I know of).

Darkplaces has "r_drawportals 1" which is cool for viewing the portals/leafs. There's also a gtkradiant plugin that can load prt files generated by qbsp. 
I would advise against that anyway. Build the detail brushes flush against the sealing structure.

In Q1 compilers, func_detail brushes take part in CSG (clipping away overlapping geometry) and outside filling (clipping away anything that faces the void) just like world brushes.

This is unintuitive, imho, and means you can't just build a sealing structure and completely cover it in detail, because the detail will clip away the sealing structure. e.g. If you have a long corridor and cover the floor/ceiling/side walls completely with func_detail rocks to make a cave tunnel, you'll get bad vis quality (vis will see through into other parts of the map).

otp, regarding a giant box filled with func_detail, that would be the same as unvised as far as performance in engine. In fact it would be better not to vis it so the engine doesn't waste time doing useless tests against the vis data which is all '1' (every leaf can see every other leaf). 
Just tidyness. I know that in general qbsp doesn't mind clipping overlapping brushes. However Having brushes align and not overlap makes for less visual clutter in the editor.

But that said, I wouldn't be surprised if even though it appears that qbsp doesn't care, having overlapping brushes has other ill effects esp. if entities are involved. But I have no proof of that. 
"But that said, I wouldn't be surprised if even though it appears that qbsp doesn't care, having overlapping brushes has other ill effects esp. if entities are involved. But I have no proof of that."

Yeah, there are many urban legends regarding overlapping brushes. I'm a believer that it doesn't matter at all but I know there are others who have strong feelings the other way. To me, it's a bunch of busywork to miter everything but what-ev... 
I Do It Cause Im OCD Like That. 
We need a barf icon. 
<- That's It 
Overlapping brushes don't matter at all to the resulting hulls in my experience, i guess you talk about the case where a plane is represented by 2 or more brushes.

In that case i only care for the sides which share the plane to have the same texture alignment/ratio/angles. You get it.

Of course this may produce weird portals for vising, and the face splitting isn't always ideal in other cases resulting in lightmap errors and and and.

So better not do it if you can avoid it. :) 
e.g. If you have a long corridor and cover the floor/ceiling/side walls completely with func_detail rocks to make a cave tunnel, you'll get bad vis quality (vis will see through into other parts of the map).

I still don't get what the problem is here - you'll end up drawing more because the visibility err "chunks" are more coarse-grained, but how does that make an important difference on today's computers? 
I still don't get what the problem is here - you'll end up drawing more because the visibility err "chunks" are more coarse-grained, but how does that make an important difference on today's computers?

I think ericw is worried not that simplified visblocking has slightly worse performance, but that you might accidentally have no visblocking from your tunnel at all. In other words, there can be no difference between building detail brushes around standard brushes, and only using detail brushes for the corridor. The former case gets reduced to the latter if all the standard brushes get clipped away by the details - and it's not obvious that detail brushes pose this risk. 
I Do It Cause Im OCD Like That.


Wait. Whoa 
ericw, preach:

So are you saying that the only parts of a structural brush that can contribute to visblocking are the parts of that brush that remain visible in the map?

I kinda assumed it worked more like quake 3 where the structural brush can be completely covered by the detail.

This changes everything :( 
Oh... Wow... That sucks. :( 
Well, I can't speak authoritatively but it's only logical that VIS can only work with the visual faces in a BSP as that's all it has once it starts working. It doesn't work with the MAP file, it reads and writes the BSP. 
But that doesn't make a ton of sense to me ... so if I stick a func_detail cube in the middle of a wall, that means there's a square in the wall where I can see through to the rest of the level or something, in terms of VIS? That can't be right. 
Yeah I thought about that as soon as I posted my post and felt even more confused. 
To Clarify 
That was my interpretation of what ericw was saying, I can't vouch for it being correct. 
I just tested this. Two box rooms connected by a horseshoe hallway, no visibility between them.

Lining the walls of one room with detail brushes does indeed permit visibility into the other room. Plus, because vis is assumed to be two-way, you can see into the detail-brush-lined room from the other room, too.

A small detail brush in the center of a wall does not create a 'portal' with which to see into the other room, however. Extending that detail brush until it almost covers the wall behind it, with an 8 unit margin around the edges, also does not permit visibility.

Interestingly, I can extend that detail brush to touch the floor and ceiling, thus dividing the structural plane 'behind' it wholly in two, and vis is still blocked. I can extend it on a third side so it touches the next wall, reducing the structural plane to a tiny thin strip along the other edge, and vis is still blocked. So, if there's any fraction of a brush plane left in the world, it blocks vis as if the entire thing were there. As soon as the detail brush gobbles up the entire plane, though, it's gone completely and visibility is fully permitted. 
Theoretically, if the information of the original structural brushes was retained somewhere, could this be...fixed? 
Guess What 
I've just disproved all of the above with further tests!

I tried to make a showcase map with one example of each detail brush, and rearranging the hallways broke the effect one way or the other. The original test was the one horseshoe, modified and saved and rebuilt, and my first run was with no detail brushes at all to verify that vis was blocked under normal circumstances, so the effect was real. It seems to only happen in a more narrow set of cases than we'd thought.

Looking at how I've rearranged the map, the detail brush 'test chambers' are at the ends of little hallways now, and stepping into one fully closes off visibility of everything else regardless of detail brush use. I'm guessing that since there's a portal that's closed in all cases higher up the tree, that closure simply applies all the way down the branch into each test chamber and overrides any 'hole' a detail brush might make.

I'll clean this map up and put all the test cases in it, and you can just noclip between them instead. :P 
Forgot What Thread This Was 
I'm posting the link in 'Mapping Help' instead so as not to further hijack the OBJ2MAP thread for detail brush debugging. 
So basically func_detail breaks the world. Neat... 
Good info tho, thanks for doing that. So as long as some part of the original structural poly remains, VIS will be intact. 
Wait so Lunaran your saying that Func Detail was not working at all like we intended it to do? 
It does as long as you don't consume entire polygons from the structural brushes.

func_detail is still compiled into the BSP but it doesn't generate portals ...without structural polygons, no portals, so VIS gets a peep show into parts of the map it shouldn't.

Use responsibly. :) 
Did someone say peep show? 
Lol You Fools 
func_detail gets "stitched" onto surrounding existing portals which take part in PVS, it just doesn't get computed in the first place. Maybe this explains "holes" and such things.. 
Map To OBJ? 
I was wondering if it is possible to revert process?

For example, user would be able to throw together rough prefab, convert to OBJ, import to modeling software and use it as a reference for exact size precision.

Maybe modern map editors already able to do this, but as GtkRadiant user I don't have this option. 
Doom3 editor does that.

Use q1 to q2 mapconverter, should let you load in Doom3 editor, then export brushes as obj. Or maybe it's jusy ase..? 
Hammer Does It Too 
well, what it does is export to a half-broken file in the obsolete DXF format, which Maya can in fact import, with difficulty and a lot of cleanup. Because Source.

Sketchup might load it too, but this is already a longer shittier tool chain than loading in doom3. 
Netradiant Does It 
Also you can set it to not output faces that have a certain texture on them so you can texture everything with skip or whatever apart from the visible faces and the output mesh is a lot cleaner 
Well, that's what I would prefer to dodge - having a chain of tools [or overkill ones] for something that seems to be a trivial task. 
Dayum... latest netradiant? That's awesome. 

Plugins -> brushexport2

It's great 
gtkr1.5 has that tool as well, so it's been around for awhile. 
Thank You. 
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:

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.

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?

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 ... 
So How Do We Feel About N64 Quake Maps? 
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:
Still doesn't show in editor.
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.)
In editor each plane was enormous.
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.
Divided in 3 objects.
Those 2 broken cubes in the middle is one obect.
That worked a bit better - holes automatically capped, but middle part is missing.
Same as before, but each broken cube is separate object now.
Results in this:
Cube parts go to "infinity". At least far beyond the end of editor grid.

OBJ files: 
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... 

Try this one again:

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. :) 
I Dont Think They're BSP 
I believe they're their own proprietary format. Oddly when Quake was ported to Saturn, for example, it used the same engine as Saturn Duke and Saturn Exhumed... 
Cool article on reverse-engineering saturn quake: 
What confused me is that in some specific conditions it acts as if it had that functionality.
Specifically this
producing that

Capping aside, breaking geometry to group of convex shapes by hand, opens gate for human error. Not to mention might be extremely time consuming.
From the top of my head - I can't imagine a good way to break inverted hemisphere to chunks of valid geometry. 
It's just the way of it. OBJ2MAP isn't doing anything hardcore magical ... it's just converting one file format into another. So there is some burden on the modeler to make sure the geo is Quake friendly to begin with. 
until you add it you're going to be fielding these concerns until the end of time :)

see: everyone asking sleepwalkr why their map leaks or whatever "in trenchbroom" 
re: "this producing that", the black plane on the piece on the right side extends to seal off the solid.

Capping aside, breaking geometry to group of convex shapes by hand, opens gate for human error. Not to mention might be extremely time consuming.
Yeah, one possible way is build a bsp tree out of the concave geometry, which makes slices that gives you convex pieces. But the downside is it will probably make ugly slices that a human wouldn't choose. 
From What I Saw So Far 
in convex shapes with gaps, every open edge will be extended until it intersects with something.
In case of cube with one side removed, all faces a parallel, thus continue forever.

But say we remove top face of the cube and then scale up bottom face. This will produce a pyramid by extending faces until intersection point.
For me this is magic! That kinda blows my mind and imagination goes wild.

For example.
Maybe I'm completely wrong here and think that easy things are hard and vice versa, but I'd guess that tool is already creating geometry that wasn't there in OBJ file and if it can detect intersection the same way it can detect the ... uhm, lack of it, to create caps using last known finite vertices.

Alas my knowledge of magic is insufficient to imagine "perfect solution" for solving problem with concave geometry. 8/ 
"but I'd guess that tool is already creating geometry that wasn't there in OBJ file"

Technically, no. It's creating plane definitions in the resulting MAP file. The infinite geo and such that you're seeing is being created by the map editor you're loading that MAP file into ... 
not all faces are parallel, but their extrusion direction. 
Well now you destroyed all the magic, mate. 
Sorry. Just trying to interject some reality. :P

felt like reposting this again.

You can make valid cubes by just having 6 triangles. You need those cutting planes or indeed it goes on forever. Once you get the logic its easy to build brushes. 
Webpage To Download Is Gone 
There is nothing there at

Anywhere else to download the latest compiled version? 
"index Was Out Of Range" Error 
Hi, I created a terrain mesh in roblox studio and exported it out in order to test this tool, the unmodified version works just fine however it's very high poly so it creates a fuckton of brushes (about 5.6k) obviously I want less so I put it into blender and ran it through the remesh and decimate modifiers to reduce the poly count but this new low poly version won't convert, it just gives a "index was out of range. Must be non negative and less than the size of the collection" error and i don't quite know why, tested with both extrusion and spikes with depth of 1 
Error Message 
************** Exception Text **************
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at OBJ2MAP.MAPCreation.LoadOBJ(MainForm _MainForm, String[] fileLines, EGRP egrp, StreamWriter streamWriter, List`1& _Vertices, List`1& _Faces, List`1& _UVs, List`1& _Brushes, Single scale, Char[] separator1, Char[] separator2)
at OBJ2MAP.MainForm.GoButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) 
I have absolutely zero chance of being able to debug the code, and given how the download is served off I suspect nobody else will either. So my idea is to see if the bug can be worked around.

If you try running the Blender tool with a different level of decimate modifiers (maybe start with a very low level of alteration) does the same error still strike? If not, try incrementing the levels until the bug strikes or you have something you can work with.

If not, check if just importing into blender and re-exporting without any modifiers causes the crash. If so, might have to rule Blender out entirely, if not then alternative modifiers are the order of the day. 
Depth of 1 is the possible suspect. Try 8 or more.
The larger the faces, the higher the chance that a pyramid would end up as a degenerate brush (i.e. an original face coincides with one of its extruded ones). Since you're increasing face area, increase the depth accordingly.

Also make sure to triangulate the mesh, I don't think OBJ2MAP checks for planar faces. 
Try using this:

also few tips:
1) Triangulate whole mesh;
2) Set all normals outside;
3) UV it - can be automatic;
4) best to treat 1 blender unit as 1 quake unit, so scale your mesh properly;
5) apply position/rotation/scale before export

When you apply all changes above, you should get flawless conversions. 

Didn't realise there was a version that could do UVs. That's amazing. Going to port this into a Blender exporter after HWJam (unless that already exists as well). 
UVs works only in valve220 format 
As promised, here's a .map exporter for Blender 2.80

Exports either individual faces as pyramids, or objects as convex brushes. Uses material names for texture assignment and material image size for scaling. Supports UVs both in standard Quake and in Valve220 format (adapted from EricW's implementation for OBJ2MAP). Offers custom grid. Allows saving to clipboard.

The exporter ensures that the brushes are convex and the faces planar. You don't have to triangulate the meshes in advance, but in some cases it can help with UVs (e.g. with mid-edge vertices). There's room for improvement, but it should work fine as is.

Standard format UV export is lossy (no shearing). I don't really expect anyone to be using it over Valve220 anyway, but it should produce decent results for id1-style detailing. Single-axis curves should be fine, no miracles though.

Only tested in Trenchbroom for now. Might need to change precision for other editors. Let me know if it works/breaks elsewhere. 
That is an amazing plugin, Chedap! Thank you so much for what you do. It works really really well! 
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.