Bsp to vmf?

[Chimare]

Ive been making my own maps but id like to get that ceilinglmap from de_tides to my map. I downloaded de_tides to my computer but it came in .bsp that seems to be the play format that comes afther compiling map. Is there any way to get bsp to wmf? Any other suggestions how to get that lamp?

 

[Raeven0]

http://www.geocities.com/cofrdrbob/?200522

 

[The Dark Elf]

what the deuce? I always heard doing this was impossible, other than incredibly basic bsp to usable map. Thats pretty cool then they can be converted now

 

[Stigmata]

Don't you end up with a pile of split brushes? I always heard that it was possible, but any face that came in contact with another was split into two or more faces, effectively exponentially increasing the number of brushes in your decompiled map.

 

[Rof]

Unlike HL1 maps, HL2 bsp files contain almost all information that was in the original vmf file.

HL1 bsps contain mostly "face" data, and store only faces that have been through the BSP splitting stage, so many brush sides are split into multiple pieces. The compiling process also throws away (culls) faces which touch the void. That means a HL1 decompiler has to guess the layout of brushes, or fake them by using thin brushes extruded from every face.

HL2 bsps contain face data, but also "original face" data (the faces before the BSP splitting process) as well as the original brush and brushside data. Also, the brush data isn't culled where it touches the void. That makes it a relatively easy process to get back nearly every brush that was present in the original vmf file.

There are a few problems (for instance, the way the brushes are defined goes through three different formats in the Hammer->compile->decompile->Hammer process, so rounding errors creep in that lead to subtle problems with brush placement), but generally HL2 format is much more amenable to decompiling.

 

[Argyll]

Decompiling is evil.

 

[The Dark Elf]

Unlike HL1 maps, HL2 bsp files contain almost all information that was in the original vmf file.

HL1 bsps contain mostly "face" data, and store only faces that have been through the BSP splitting stage, so many brush sides are split into multiple pieces. The compiling process also throws away (culls) faces which touch the void. That means a HL1 decompiler has to guess the layout of brushes, or fake them by using thin brushes extruded from every face.

HL2 bsps contain face data, but also "original face" data (the faces before the BSP splitting process) as well as the original brush and brushside data. Also, the brush data isn't culled where it touches the void. That makes it a relatively easy process to get back nearly every brush that was present in the original vmf file.

There are a few problems (for instance, the way the brushes are defined goes through three different formats in the Hammer->compile->decompile->Hammer process, so rounding errors creep in that lead to subtle problems with brush placement), but generally HL2 format is much more amenable to decompiling.

Is there a way to edit the bsp to remove the original data, to prevent a usable decompile? For those who might not want their maps pulled apart like that?

 

[Rof]

Is there a way to edit the bsp to remove the original data, to prevent a usable decompile? For those who might not want their maps pulled apart like that?

That's a good question, and I don't know. There's probably a good reason for that data to be in there, otherwise it would be removed by the compile process. (For example, the "portal" data, which is used to construct the map's vis information, is removed after it's used by the VVIS program). From comments in the SDK source, I'm suspecting that the brush data is used in the physics/collision checking part of the engine somehow.

It may be possible for at least some of the data to be removed after compiling, which would make the job of decompiling much harder. The trick would be finding which bits aren't actually used by the game engine, but are needed to decompile.

I know there was a set of compile tools for HL1 maps that could break decompilers without compromising the ability to play the map. Something similar may be possible for HL2 maps once the custom compile tools start getting written.

I deliberately built features into the decompiler so that mappers can flag their maps as un-decompilable, but if someone else writes a decompiler they could simply ignore them. Plus a sufficiently skilled user can delete the "no-decompile" flags in the map, given enough knowledge.

There are aslo various anti-decompiling tricks that worked for HL1 maps that still work for HL2 (e.g., the entity property >256 characters bug), but these are fairly easily worked-around.

 

[The Dark Elf]

That's a good question, and I don't know. There's probably a good reason for that data to be in there, otherwise it would be removed by the compile process. (For example, the "portal" data, which is used to construct the map's vis information, is removed after it's used by the VVIS program). From comments in the SDK source, I'm suspecting that the brush data is used in the physics/collision checking part of the engine somehow.

It may be possible for at least some of the data to be removed after compiling, which would make the job of decompiling much harder. The trick would be finding which bits aren't actually used by the game engine, but are needed to decompile.

I know there was a set of compile tools for HL1 maps that could break decompilers without compromising the ability to play the map. Something similar may be possible for HL2 maps once the custom compile tools start getting written.

I deliberately built features into the decompiler so that mappers can flag their maps as un-decompilable, but if someone else writes a decompiler they could simply ignore them. Plus a sufficiently skilled user can delete the "no-decompile" flags in the map, given enough knowledge.

There are aslo various anti-decompiling tricks that worked for HL1 maps that still work for HL2 (e.g., the entity property >256 characters bug), but these are fairly easily worked-around.

okies, thanks for the info mate