Godot Quake BSP Importer Tool + Tutorial
Вставка
- Опубліковано 18 вер 2024
- I've made an importer for Godot to convert compiled Quake BSP files.
Godot Quake BSP Importer Github: github.com/jit...
Trenchbroom: trenchbroom.gi...
BSP: bspquakeeditor....
ericw qbsp: ci.appveyor.co...
Wally: valvedev.info/...
KOOK: store.steampow...
#GodotEngine #gamedev #leveldesign
More videos about this would be nice!
You the Man!!! This is so excellent, be proud. I hope you flesh out the code ongoing.
Concise. Effective. Exactly what I needed. This is going to level up my Godoodling now that I have the power to import bsp files. Thanks!
This is super cool, im planning on making a game with a more old style, and I have been making maps with hammer editor for years, so this will help a lot to make levels quickly for it!
I feel that I'm too green to fully understand and utilize this, but i appreciate all of the information 🙏
You are an excellent person, generally, but also because of this. Thank you for your hardwork and great asset!
Thanks for posting this! I'd love to see an overview of your mapping workflow between Trenchbroom and Godot. I'm looking to do something simlar.
Hopefully I can find time to make a video about this!
This is insane in the best way!
I mean, it is for a game called KOOK! 😁
I'm adding another comment if only to bump this for the algorithmic overlords. Thanks for this tool!
You got the sub for many reasons, but the biggest one was that you pronounced Godot differently every time you said it, which tickled me each time.
Thank you so much for this tool! I hate that I had to download the Mono version of Godot to use it in 4.2. I did some messing around with adding "games" in Trenchbroom and made a custom FGD file, so I don't have to store my textures in WAD. Adding a support for "clip" texture would be quite nice, but other than that your tool works flawlessly!
UPD: adding a material for clip texture and making it transparent seems to work, but I don't think that's efficient.
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?
please make a in depth tutorial about the full workflow!
Great tutorial! I like it almost as much as that mustache.
Thanks! I grew the mustache myself!
I much enjoy these news
2:16 Mathematically Z for up and down is mathematically correct
Thank you so much!
Good video
This is amazing! Thanks.
More of these please 👍
your amazing thank you so freaking much
Do you build the maps without a sky ceiling? I don't have access to quake so i've used the hammer editor with Half-Life 1 and i wasn't sure if there was a way to use the sky texture from that. I'm trying to figure out if i should just build hte maps without any ceiling so that the godot sky shows through or if there's a shader that works like how Half-Life renders the sky.
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.
hey same hat! ive been working on something similar but vis calculation all done in godot instead. Cool stuff!!!!
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
how do you make use of a bsp tho? does it add any advantages, or is it purely just import into godot so it can use it.
(bsps would be really cool for a ray tracer OwO)
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.
can't get uv2 to unwrap for lightmapping, keeps saying normals are needed even after making the mesh unique, which isn't exactly wanted anyway. Is there a setting to enable automatic lightmap creation when inheriting the bsp, I tried enabling the godot lightmap setting for scene import but doesn't want to work like regular meshes imported. thanks for the plugin, seems really great so far.
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.
My UV's dont seem to match what they look like inside qbsp once i import the file, got everything and the correct textures loaded but not their uv's
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.
godot crashes every time I attempt to enable it :(
Uh-oh. What version of Godot are you using?
Cool map .bsp Halflife Counter Strike in godot
Only supports Quake BSP files so far, but hopefully I can add support for HL and other games, too.
how you use BSP editor without a game? .. seems they all ask for a game to make a map for... but i wanna make geometry for my own game...
what is best BSP editor? i used it alot for making wolfET and Call of Duty 2 and 4, cod waw maps.. i think was called gtkRadiant .. been soo many years, but i prefered that workflow to meshes in blender
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.
Isn't quake format a little limited for more complex games? My goal is to work toward a Thief clone, which requires some stuff that I'm not sure quake supported, like rotating doors, AI path nodes, and some other complex stuff.
Although Trenchbroom is not good for that stuff either... You can't set a pivot point for a door without using a separate entity, for example. I've been looking into NetRadiant-Custom. Not sure it can do that either, but it's actually better than TB in many respects. (I'm used to DarkRadiant for The Dark Mod, and tbh everything else is way far behind it... 😞)
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.)
Do Source BSPs work?
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.
Martinez Barbara Taylor Robert Martinez Anthony