Spark importing .BSP instead of .VMF

Andos

<div class="IPBDescription">Quicker, more stable and neater results.</div>I have had many crashes when trying to import my .vmf maps, but that aside I think that you should look at importing .BSP files instead as they will give you much much more "clean" data to work on (maybe after a little optimization at least).

.VMF files contain too many faces that we rely on the BSP compiler to remove and optimize away, especially the outer areas of the world which spark doesn't need.

For example I made a simple hollow room in Hammer and imported into Spark.
I got 6 brushes, each consisting of 6 faces = 36 faces.
I only needed 6 of them to make my room. :-P

If you made spark import .BSP files instead you would get:
- Much less faces to remove (in the room example above you would only get 6 faces imported as desired)
- Only the faces visible to the players in-game (as spark is meant to model)
- More stable importer as you have no invalid brushes or shapes that you didn't expect (BSP only have simple faces)
- Ability to import old NS maps where the source files were lost and make them work for NS2.

I know you have code ready to load standard half-life BSP levels as you demonstrated in the first dynamic infestation video, you would only need to merge together polygons with the same texture/rotation/offset into one face. Voila -> A stable, quick and neat level importer that should be relatively stable.

What do you think?

Chris0132

You shouldn't be importing maps, BSP compilation for source hacks everything into an abysmal mess of random tris.

You should be building it in the editor for the game you're using, to the requirements of the game you're using.

The source file is supposed to contain lots of unneccesary stuff which is not loaded ingame, it contains history, prefabs, guides, notes, lots of things, this is true for any sort of source file.

If you're remaking it, remake it, don't copy it, a remake should improve upon the original and change it enough to make it fresh and new, while maintaining all of the key enjoyable parts of the original.

Terr

As someone who has written code to interpret both textual VMFs and binary BSP internal details, I don't think it would be worth doing.

VMF is the real "cleaner" solution because you aren't discarding certain types of information and then getting stuck supporting a Valve-specific non-obvious (compared to plain text) file format (ex. the static prop gamelump) which could change umpteen ways without warning. I had to update the VDC wiki last time because an extra four bytes in a certain type of record was throwing everything off.

And if you don't have the VMF for the map... well, maybe you should be contacting the original author...

Kouji_San

In goldSRC the BSP is a real mess, only useful for the engine to render. I'd take it source is not much different?

Seker

You forgot that the engine is a bit old now, back then you didnt need optimizations... you could even count the polys by hand so yeah :P

Kouji_San

Counting as high as 800-1000 world polys is still a big task though, good thing we had r_speeds

However even back then, optimization was still a mandatory thing, goldSRC was never good at rendering none-optimized areas. Even on today's high end pc's, becausee the engine is the bottleneck, not the pc cpu/gpu ceiling

Because I never really dove into source mapping, I'm just curious about the compiled bsp for Source, if it is still the same mess only the engine can read, similar to goldSRC. I take it they optimized it. I read somewhere, you could still load a bsp into the editor and even recompile it?

Seker

The Bsp is still compiled but you willl get a better output after decompiling.

Terr

I don't know how it compares to Goldsrc, but unofficial decompilers (back to VMF) do exist for Source BSPs. However, certain features--especially certain hints and optimization entities--cannot be decompiled reliably due to how they are transformed or discarded during the compilation process.