Spark importing .BSP instead of .VMF
Andos
Join Date: 2003-10-17 Member: 21742Members
Join Date: 2003-10-17 Member: 21742Members
<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?
.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?
Comments
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.
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...
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?