Decompiler in C# with source for MOHAA

[MofoMan2000]

I've noticed all decompilers don't keep the texture coordinates on brushes (but do for patches and terrain), is this something that is intrinsic to brushes?

Map editors (like Hammer and Radiant) store texture coordinates using a set of axes, which are used to "project" the texture onto a surface. As I understand it, this was originally done to conserve space in the Quake 1 BSP format, since these axes are expressed as a two vectors with three components, X Y and Z, and two more numbers for the shift on each axis. Therefore, the texture alignment for an entire surface could be stored in eight floats, rather than as a set of UVs for every vertex on the surface, which is a small amount of space saved for any surface with more than four vertices. The UVs for each vertex would be calculated at load time instead. This could be done fairly quickly without increasing load times too much, by doing just a couple dot products for each vertex. These texture axes were copied almost exactly from the MAP into the BSP when compiled. This is the case for Quake 1, Quake 2, GoldSrc and Source engines.

The one exception is Quake 3 and engines based on it. Starting with Quake 3, UVs are stored directly in the data for each vertex, but Radiant is still using texture axes. A vector dot product isn't really an operation that can be done in reverse, but even if it were, there's no direct path to the surface definitions for a brush when you're looking at brush data in the BSP (unless you're looking at a BSP from Jedi Outcast or Soldier of Fortune 2). The fact we can get a texture for the brush at all is only because the texture is referenced. Patches come out fine because they are stored quite differently. They simply exist as part of the world (you find them by simply searching through every face in the map), and the data can be copied almost one-to-one from the BSP into the MAP. Radiant even expects the texture coordinates as UVs.

Doom 3 and Quake 4 are completely separate from any of this, since they don't use BSPs at all. Maps are stored in an uncompiled format. Really all you could want to do is convert them for an earlier engine.

That's a lot of text, and I realize it can be a bit dense if you're not familiar with some of the ways graphics hardware renders 3D scenes. It's not really as simple as "brushes are special" so much as the way Radiant expects texture coordinates is very different from how they're stored in a BSP in Quake 3 engines.

[chrissstrahl]

I have noticed ef2 (Überradiant) is not among the output formats, how likely is that to change ?
And how much work is that ?

It might be worth it for me to add that feature my self, so I don't have to use mohaa radiant, since I can work
much faster with über. The models should be compatible, I have not tested it.

Does anyone know what kind of textures they are what they do ?
common/bplaneclip
common/bspindleclip

I have figured out that common/vis is the same as common/hint for vis-compile.

[MofoMan2000]

For Überradiant you should be able to use the GTKRadiant output just fine. Really the only reason MoHRadiant gets its own output is because it notates detail brushes differently, and I guess it uses its own special terrain format too.

common/vis isn't quite the same as hint, vis is meant to be used with a visportal entity, but just comes out of the map as a world brush in decompiles. I'm not sure what happens to their properties or how they're used.

[chrissstrahl]

common/vis isn't quite the same as hint, vis is meant to be used with a visportal entity, but just comes out of the map as a world brush in decompiles. I'm not sure what happens to their properties or how they're used.

Thats odd, they are placed like hint brushes would be.

I'll try the GTK decompile option next time.

[1337Smithy]

Thanks for the explanation above. I know enough to make sense of it, it's just the details of bsp compilation I'm hazy on so it's good to get an insight.

Yeah I quite liked Doom 3 when it came to mapping because all their levels could be opened as is and inspected, though creating your own levels is another thing entirely, considering how complex and brush rich they are if you want them done right. I spent a huge amount of time getting a simple corridor or small room adequately detailed. It was always a love hate relationship with that game.

The VIS texture brushes are placed and then converted into a vis_leafgroup 'entity' from the menu, much like placing triggers. They envelop an area you want to cull when a player is in another specific vis_leafgroup(s). You select your desired leafgroup and connect them to every other that the player can't see from that location, so it isn't the same as hints as you're given complete control of when and where you render different locations (which is why it's called 'manvis' or manual VIS). It can send the VIS data through the roof though so I generally try not to use them at all, plus they are a pain to implement, especially when you have a large and intricate map.

Edit: found this http://homepage.tinet.ie/~abyrne/sdk..._tutorial.html

A more thorough explanation of how and when to use it.

[MofoMan2000]

Sounds like visportal entities get baked directly into the BSP tree, and there's probably no way to reliably recreate them. I could just remove them, they can tend to junk up a map quite a lot. Take a look at m2l2a through c. They're all entirely blocked out with these vis brushes, it must have been a real nightmare to set up.

[1337Smithy]

Yeah, the majority of the missions until maybe m6* use them I believe, because they are open with little to no farplane. When they did m6l1a (snowy forest) onwards they had a good excuse to use heavy fog, which is good because that level would not have been possible any other way. They really can be a nightmare to add and maintain. You really need your core geometry established for the entire map before even thinking about implementing them.

If you can then it would be good to remove them. When they are entities you can filter them out fine but as mere brushes you have to use the 'translucent' filter which also hides clips, triggers etc so it isn't ideal.

M1l1 must have taken a while to make because not only do they have these leafgroups, all the open terrain (rolling hills and cliffs) outside of the town were made by individual patch meshes. And of course these don't generate good collision so they had to be clipped which they did via tri-souped brushwork. I get a sinking feeling whenever I look at those levels because of the effort that must have been involved.

Oh, and how difficult would it be to remove the brushes left over from the collision models? I suppose if you decompile a map and then recompile you'll essentially have two sets of brushes for each model in your BSP?

Edit: found another 'bug': it seems func_barrel objects don't decompile properly. The entities are there but they show up as blue boxes in Radiant. I don't know if this is because they are made from patch meshes or because they are new to MOHAA so need extra work (they were used in early advertisement of the game because you can shoot them and liquid leaks from the 'holes'). func_crates decompile fine.

[chrissstrahl]

If you can then it would be good to remove them.

I disagree, they would have a positive impact even if they would just be like normal hint brushes.
At least from what I have seen so far.

When they are entities you can filter them out fine but as mere brushes you have to use the 'translucent' filter which also hides clips, triggers etc so it isn't ideal.

Is there not that hide hint surfaces option like pressing control + h or alt + h in the mohaaradiant ?
I know that option from other editors.

[1337Smithy]

I disagree, they would have a positive impact even if they would just be like normal hint brushes.
At least from what I have seen so far.

In some cases maybe in others not so much. I suppose I'm coming from a perspective of using the decompiled maps as a resource, so personally I wouldn't have them in. Ultimately giving an option on the interface would be best, or perhaps changing them all to hint by default (you can do the same in the editor to be fair using find/replace)? Though I can see potentially most of them being unnecessary with little to no added value. For instance, treating the vis_leafgroups as mere hints in say, m3l2 (which is being generous as it's fairly closed off by long 'corridors' so it gets the most benefit), the game renders and culls almost no differently when testing with and without them. In the beginning house section they are pointless as visibility isn't blocked by many structural walls so everything is rendered anyway. It's the reason why hints weren't used in the first place.

Then you get to levels like m2l1 (Norway) and it is so open they add no benefit from what I can tell.

Maybe they could be kept so it's easier to recommission them as leafgroups?

Ultimately, it will probably be down to personal choice.

Is there not that hide hint surfaces option like pressing control + h or alt + h in the mohaaradiant ?
I know that option from other editors.

Yes, but that hides hints not vis brushes in MOHRadiant. vis has its own filter but it doesn't recognise them when they aren't leafgroups.

[MofoMan2000]

I believe I can detect these vis brushes when I come across them, so I could put them into empty vis_leafgroup entities. They wouldn't be hooked up, but they'd be there for reference, and since they're entities they'd be easy to filter out and delete. That should make everybody happy.

Oh, and how difficult would it be to remove the brushes left over from the collision models?

Again, probably pretty easy. Those brushes tend to use shaders from the models directory rather than textures, so if I can't find them based on content flags then I can probably filter them out that way.

found another 'bug': it seems func_barrel objects don't decompile properly. The entities are there but they show up as blue boxes in Radiant.

Heh, I remember those things. Years ago when I actually played through the game I remember shooting the barrels and seeing the fluid pour out, and playing around with it, shooting higher or lower on the barrel to see what happened. I don't do anything special with these entities, like most things they just come out of the BSP as-is. How do they behave if you recompile the map? If they're still broken in that case then I can take a closer look, but I'd hate to spend too much time on that if it's just Radiant being stupid.