Godot Quake BSP Importer Tool + Tutorial 

I mean, it is for a game called KOOK! 😁

Hopefully I can find time to make a video about this!

I still need to explore how clip brushes are handled. Hopefully I can make it so they're just collision with no mesh.

​@@jitspoe One of the things I noticed is that skip tends to remove adjacent faces on brushes

@@sockeater193 Do you have an example map with this issue? Also, which version of qbsp are you using?

Thanks! I grew the mustache myself!

@@jitspoe as oppose to those people getting surrogate mustaches?

Are you using the QBSP vis data to do visibility in Godot?

@@jitspoenah, I'm implementing my own binary space partitioning thing so it can be reused if i ever decide to make a separate map editor

The map is more optimal if it's sealed, but will still function unsealed (tends to have a lot more unnecessary extra splits and external surfaces, though). You can always make a material for the sky that just draws nothing with a shader like this: void fragment() { discard; }

@@jitspoe Thank you, I'm not very experienced with shaders and did not consider that as a option.

@@one-wingedshiba Oh, you can also use the skip texture which will seal the map and create collision but not make a mesh.

It just imports the mesh to take advantage of the CSG aspect of qbsp. Would be cool to support things like visibility and such, but that would require some significant engine modifications, I'm pretty sure.

I'll have to investigate this. That's a strange error considering the mesh definitely has normals for lighting. I could possibly just use the Quake lightmap UVs, though that might only be there for lit maps.

@jitspoe figured out the normals error, it was coming from the beta 4.2-4 release, the prior beta didn't do that. I wasn't sure if there was a way to include the lightmap uvs from quake when you compile a map, I'm assuming they use uv2 as well but I couldn't find any reference to this and when it's imported it doesn't seem to be there so maybe that's not the case. I'm real noobish to quake mapping, wish I gotten into it a long time ago haha. thanks again.

@@hpbecraft Yeah, just figured that out. Was about to let you know. Going to look into automatically generating UV2's in any case though.

@@hpbecraft I've update the BSP importer to generate UV2's for baking!

Wow awesome man, checking it out right now. @@jitspoe edit* works great so far, if anyone is reading this make sure to reimport your original bsp and have lightmaps set in project settings for scene import. Assuming that's how your code works from my quick look at it.

Uh-oh. What version of Godot are you using?

This is typically caused by the textures not being written to the bsp file. Currently the importer needs those to get the resolution for proper UV's. I think it assumes 64x64 otherwise. Are you using a .wad file for the textures?

@@jitspoe Okay yeah i think that was the issue, i included a wad with all the textures and built the bsp this time with trenchbroom and it loads perfectly fine. My only other question is culling, i guess any surface that touches will be culled and a map ive imported has a lot of missing faces, so the maps in turn must have much simpler geometry as opposed to using map files directly with the likes of funcgodot?

@@Ver2ion As long as the map is sealed properly (check to make sure you don't have any "leaked" messages when compiling), all the faces touching geometry or the outside of the world should be completely removed. There's an option in the import settings for occlusion culling which will use the level geometry to occlude things, so models and lights and such behind walls should stop rendering.

@@jitspoe i had another issue was some of the mesh's doing the weird culling, the materials had transparency enabled, i turned it off and it looks good ! Got everything working. Thanks so much for this and the help

Try TrenchBroom. It's what many people are using these days. It's relatively easy to set up a game definition for it, and there's some pretty good tutorials about it. It also has pretty decent documentation. Inside TB's folder there's a "games" folder, you can create your own game definition there, and you only need three files in it: - GameConfig.cfg - game.fgd (name it whatever you want, you refer to in GameConfig.cfg -> "entities") - icon.png (this may be optional, I dunno) I'm not the best person to explain how these things work, though. The .fgd file is where you define all your entities. Look up "level design fgd format", there's some good articles about it. It's actually pretty simple, so it should be a quick read. I can't really help you much about the cfg file (I got mine from using the Qodot plugin, which generates one for you, but it's not trivial to setup). You can try looking at the ones that already exist, maybe even duplicate one of them. Or ask on trenchbroom discord. The best editors out there, though, as far as I know, are NetRadiant-custom, and DarkRadiant. The only issue is NRC is not as easy to setup game definitions for, and DR only supports quake 3+ and doom 3 formats, which this BSP importer doesn't support yet. Imo, DR is the very best that's out there, but it's very much tailored for The Dark Mod, so some of the tools aren't useful to other games. But it's in many ways superior to everything else I've tried so far. Someone ought to fork it and adapt it for general use.

Usually you can add a new game project. Like copy the Quake directory in the games directory of Trenchbroom, edit the config files to match your game name or whatever, and you're good to go! Or just use an existing game. The games are mostly for the entity definitions and palette. "Best" is subjective. A lot of people like Trenchbroom. I used BSP for a long time. I think Netradiant still sees some use as well.

@@jitspoe yea, to be clear, when I say _"best"_ I mean _"those whose tools make editing easier and more comfortable"._ E.g, NRC's _Surface Inspector_ tops TB's texturing tools. You align textures in different ways just at a single click of a button, or even fit to an entire face (very useful for doors, windows, decals, etc). And then DR tops that by having the same _Surface Inspector,_ but also a Texture Tool which allows more finer control if needed (though it has a few quirks that need fixing). DR allows visually placing origin spawnargs, just like moving a vertex in the 2D/3D views. This is tremendously useful for doors, windows, or anything that needs to define a pivot point for rotation. TB doesn't do that. You either set the numbers by eye, or you create a point entity, place it where you want the origin, and copy/paste its origin values over to the door entity, then delete the point entity, and then take a deep breath. :) I just found out that NRC doesn't do it either. Even worse, in NRC, changing the origin of a brush entity also changes the positions of the brushes that compose the entity, which is terrible. :( There are many more reasons why I think DR is the very best that's out there. Many quality of life improvements too. I wish someone forked it and adapted it for general use with modern engines.

@@skaruts Interesting. Wonder why everybody seems to be using Trenchbroom, then. I hadn't heard about Dark Radiant until recently. Is it not possible to build Quake1 maps with it?

@@jitspoe No, iirc only quake 3 and 4, and doom 3. I get the appeal of TB, tbh. It's fairly easy to get up and running and not intimidating (doesn't have a lot of buttons). It looks nice and clean. And tbf, if you're mapping for Quake (and maybe Quake 2, Hexen2, etc), then I think TB is your best bet. I will also say this: TB does geometry manipulation like no other. It tops everything else in that. It also perfectly prevents invalid brushes, vertex drifting, etc. (I've had lots of issues with the former in Hammer, and sometimes have issues with the latter in DR). But then if you're mapping for something else than Quake, it may start falling short. I don't think it supports patches or anything like that, for example. As far as DR goes, I suspect it's not even on most people's radar. Maybe it doesn't get talked about because it's tucked away in the The Dark Mod niche, or because it doesn't support many map formats, or because it's very much tailored for TDM. It comes with tools that aren't relevant outside of TDM mapping: all sorts of editors for objectives, readables, conversations, materials (of the doom3 kind), stim-responses, etc, etc. It can also render lighting in the 3D view. I don't know if that would be useful outside of TDM mapping either. DR also supports scripting, which is nice. One thing it doesn't have is a tool for compiling maps, like TB and NRC have, because Doom3/TDM maps are compiled by the game itself. I don't know if it could be done through scripting. But this is one of the reasons I think it ought to be forked and adapted. Tbf, I've only recently started thinking about this too, so I haven't tried to use it for another game yet. So I don't actually know how easy or hard it may be to set up a game config. I've been meaning to dig into it, but still haven't.

The Quake format should be plenty to support a game like Thief. There are mods for Quake that supported rotating doors, but importing the bsp files is mostly just to get geometry and collision. You can do whatever you want with them once they're in Godot. Worst case, you can build the level and add the doors within Godot. Never tried DarkRadiant. Might have to look into that.

@@jitspoe hey, thanks for replying. I'm quite interested in this, then. :) I'm having some issues with it, though, I described them on github.

@@jitspoe for DarkRadiant you'll need quake 3 format, btw. (Or Doom 3. TDM is the doom 3 engine.)

Only supports Quake BSP files so far, but hopefully I can add support for HL and other games, too.

Currently only Quake1 BSP files are supported, but support for other formats might be added in the future. I think I saw another Godot importer for Source BSP files, but it might have been for Godot 3.