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: https://bitbucket.org/ericwa/obj-2-map/commits/all , 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. 

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?

Otherwise:
(reaction.gif) 

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.