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. 

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? 

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 

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? 

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.. 

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..? 

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. 

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. 

yeah

Plugins -> brushexport2

It's great 

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.