Why bsp format, not map like in qodot plugin?

[skullbulb]

Hi, i'm trying to figure out about benefits for using bsp format over map. For me, bsp looks like an overhead, because it requires compile step before exporting to godot, also bsp contains less of usable meta from the editor

Can you explain your choice please? May be i'm missing something

[jitspoe]

Sure! The bsp compilation process does CSG operations to remove all the invisible polygons. It also cleans up the intersections of polygons so there are proper vertices where things connect so you don't get little edges of things flickering and such.

Take this level for example:

I've made some details with alternating stones along the corner. If we just use the .map file and change the display to show overdraw, we get this:

Which is super unoptimal. You can see those corners and a staircase create TONS of surface that is completely invisible.

Now if I compile it and import the .bsp file, I get this:

Note how much less we have to render!

[skullbulb]

Thanks a lot for explanation! I suspected that CSG union is crucial for rendering performance. I have been working for a while on map importer to avoid extra compilation step. I have tried Qodot and similar solutions, but it seems a bit awkward to me. My solution is based on vanilla gdscript, it works pretty well even with large map files. The only thing i've not finished yet is CSG. I'll post the result there later, if you don't mind

[jitspoe]

Sure! There are a ton of edge cases to deal with, so I figured it'd be best to let some more robust tools that have had a lot of testing do the heavy lifting for me. Godot technically has CSG geometry, but it's not really designed to do anything complex. Also, it does a really bad job of splitting and explodes the triangle count. For example, if you have a cube intersect another cube, the diagonal line from the triangles will also create a split.

A agree on Qodot. It seems unnecessarily complicated, and GDScript is fast enough to not need a c++ map importer. Trying to do CSG in GDScript might be a bit slow, though.

[Calinou]

Bare BSP compilation is very fast compared to the VIS and light steps (which this plugin doesn't use), so I'd say it's worth it.

It does require installing an extra program, but I'd say TrenchBroom should provide a bundled release with ericw-tools at some point (at least on Windows) 🙂

TrenchBroom could also gain "compile on save" functionality to make the workflow smoother. This could also be viable for Quake mappers who want to be able to preview their map at any time, even if it has no lighting (or -dirtdebug lighting, which is very fast).