About BSP Viewer - NemPosted: Apr 17th, 2004 - 5:03:52 pm
About:

BSP Viewer is a utility designed for mappers for previewing Half-Life 1 .bsp files and technical information about how they are being rendered. This is meant to help mappers find problem areas in their BSP files that need to be optimized.

BSP Viewer has been superseded by Crafty, my new Half-Life 1 and Half-Life 2 .bsp, .gl, .map, .mdl, .rmf and .vmf viewer. Crafty can be found here.

Screenshots:

BSP Viewer

BSP Viewer

BSP Viewer

BSP Viewer

Features:
  • Optional rendering of textures, lighting, entities, special textures, transparent textures and sorting.
  • Edge viewing and clipping.
  • Optional use of VIS, frustum and backface culling.
  • Scene freezing.
  • Optional rendering of entities in special render modes.
  • Real time entity editing.
  • Entity picking.
  • GCF loading.
  • PTS loading.
  • Exports .3ds, .map, .xsi, .ent and .bmp files.
  • Scene information viewing.
  • Supports .bsp files without VIS or RAD information
  • Recent .bsp file menu.
  • Quick and easy setup.
  • 100% Free.
Modified: Aug 8th, 2006 - 3:49:03 pm[ 171606 Views ]

[ 1 2 3 4 ]

31. NemModified: Apr 3rd, 2006 - 11:03:53 pm
Ah, I see (I would have thought those tools could parse the white space, weird).

Anyways, the reason BSP Viewer exports 1 unit thick brushes is because the CSG process destroys the brushes you see in Hammer (or whatever editor you use) and converts them into a polygon soup. This process is NOT reversible. A brush (in Hammer) is a convex collection of planes that, when intersected, form polygons. When these planes are removed or split by the CSG process, the original brush is gone forever. BSP Viewer's approach is to say to hell with the brushes and construct a new brush for each face in the BSP (hence the 1 unit brushes). Other programs (such as WinBSPC) construct one large brush that engulfs the entire world, then "hollow" it out subtracting the BSP geometry and breaking up the brush into smaller convex brushes. This process creates more "brush like" results, but is still nothing close to how one would actually map.

This is why there are no good BSP decompilers, it is a really hard problem to solve. Half-Life 2 has a better BSP decompiler (VMEX) but only because the original brushes are stored in the BSP along with the CSG polygon soup.

32. redcometModified: Apr 3rd, 2006 - 11:49:09 pm
Yes I understand now, I read some of your comments on the Map file Format on VERC and looked at the source.

I understand that what you are doing is reading the bsp, constructing the normals and distances, etc, and building a brush. However, I do see an approach that can make good map files.

What I realized from looking at these map files you generate is that each section describes a face, not a brush. So when hammer loads it I assume it screws with it and forces it to be atleast 1 unit thick and then it interects with the other 'faces' you wrote to the map file. But why not do this instead of writing faces as if they were brushes.

You have good solids inside your program, and I know that the map file format is to read three points from the line, generate a normal and distance to get a plane, which it then used with the other 5 lines to calculate a volumn for the total brush. Your program does this, but when saving the map file it saves each face as a brush, with each face getting its own 6 line segment in the map file.
Why not instead, forget the original bsp, and make the map file off of your displayed map. For instance, I am not 100% sure on the process yet, but take a face on one of the solids, define three points somewhere on it, and write that line to the map file. Then move onto the next face, define three points on it, then write the next line. And do that for all 6 lines on a segment. That way when hammer goes to make the normals and planes, one brush is defined by 1 segment instead of 6, which causes the 1 unit thick walls.

Now that I know whats up, I downloaded your map view source, and though I will have a much harder time trying to convert a 6 segment solid into a 1 segment solid, I am going to start trying to write a program that will do it. It might take some tinkering, but I a sure that when a program that actually makes solids instead of faces will become imensly popular. I know me and my mod crew will use it a lot.

Which by the way, in your map view source, there is a typo.
In the MapViewer.rc file you incude resource2.h, and not resource.h which is what exsists, Resource2 doesnt. If doesnt compile right off the bat, but when I changed the MapViewer.rc file it worked.

33. NemPosted: Apr 4th, 2006 - 11:23:06 am
I'm not sure if I fully understand you (or maybe you don't fully understand me). Brushes, by nature, must be convex. But BSPs contain a polygon soup which is anything but convex. The only logical grouping of faces in a BSP is into leaf-nodes, which are collections of near by faces. However, these leaf-nodes are concave by nature and so can't be used to construct a brush. It's not just a matter of taking a bunch of faces and combining them into a brush, therein lies the problem!


BTW, MAP Viewer's source is old and quite poor.

34. redcometPosted: Apr 4th, 2006 - 11:56:07 am
I know that going from bsp to map is difficult, and most decompilers fail with their 1 unit walls. I discovered that what they are doing is describing each face in the map file. The regular map file format is supposed to start with a {, then go for 6 lines in which is describes 6 faces for a solid. Then when it loads the map it finds the normal, dot product, etc, you know all this.

What you and other decompilers do is instead of using those 6 lines to describe a full solid (like a wall) you use these sections, denoted by the {}'s to describe each face. So instead of this:

Code:

{
(a face)
(a face)
(a face)
(a face)
(a face)
(a face)
}


you generate this:

Code:

{
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
}
{
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
}
{
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
}
{
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
(a face of a face)
}
etc..


And together these 6 sections you create actually represent one solid. So in hammer's eyes it seems like you are creating numerous solids to build a solid. Instead of numerous faces to make a face.

I do not know if I can explain it better :( But thats sort of not important.

What I get, is that going from bsp to map is very hard.
But what I see is you creating a 3d world with the bsp.
A 3d world with vertices and planes and solid walls

So what I am saying is that instead of going bsp to map, go bsp to 3d world to map.

Use the coords you can pick up off of the display to go backwards through the vector normalize/dot product loop you described in VERC
http://collective.valve-erc.com/index.php?go=map_format

to build a good map file.

35. NemModified: Apr 5th, 2006 - 11:22:26 am
Well you clearly understand the problem, but the solution is a lot harder that simply combining the faces.

Consider a single brush crate. If this brush was made an entity then yes, all six faces of the bush would be present in the BSP and you could easily construct one brush for the decompiled faces. However, if the crate is on the ground and a world brush, it would only have five faces, and it if was also against a wall, it would only have four, and if it was also in a corner, it would only have three, and if it also had another crate on top of it, it would only have two. Ignoring the fact that it is hard to know which faces make up the crate, in each case where there is a face missing, there are infinitely many ways to add faces to create a brush, and adding these faces must be done in such a way that doesn't protrude into the BSP (and makes sense). A lot of the time brushes are reduced to just one face in the BSP.

This brings us to the other problem. How do you know which faces should be part of a brush if they exist in a polygon soup? There is no way to know. You can estimate by checking proximity and whether or not combining faces results in a convex solid, but it is still a tricky problem.

Furthermore, the faces in a BSP are even more mangled by because they are split by other geometry and to produce smaller concave nodes (think of how a staircase splits up). These faces must be reunited in a convex manor, but again there are many ways of doing this.

I'm not trying to deter you from trying, I'm just trying to make sure you understand the problem and why I have never spent a lot of time trying to get BSP Viewer to export usable MAP files. Good luck!

36. redcometPosted: Apr 5th, 2006 - 1:25:59 am
Well I did not know about the face deletion problem.

I really wish I could sit down and write a good converter, unfortunetly I am getting swamped with different projects and other garbage I thought was done a long time ago..

I will continue thinking about it and maybe contributing tio a program little by little. I hate having my mappers go through and move all the walls from being 6 faces 1 unit hollow brushes to full walls. Thats why I asked. Your program seemed to do a very good job of constructing the solids.

I am still debating, I am not sure which is easier, a program that will read bad map files and convert them, or a program that will read 3d vertices from your 3d view and construct brushes off of that..

I really like that hollowing idea that you told me about, I decompiled a few maps with that program and got considerably better results. Its just to bad it doesn't work for most maps.

37. edman747Posted: Nov 1st, 2007 - 10:21:16 am
hi, thanks Nem.
I really like bsb viewer. sometimes when loading one of the half-life single player maps(HLSP). using a pak0 everything is gray. so i just use the half-life.gcf then the map looks normal.

things like func_monsterclip, trigger_once and trigger_changelevel often have some weird texture applied to them? I have to fly through them to see the rest of the map.

now to the question: do you have a spawn point tool? Kinda like bsb viewer where I could fly to the spot where I want to put a spawn point and have a player model show up where each spawn point is.

if no, do you know of one? have used spawnpointeditor 1.3 by Michael.A.C.Pink
It has some utility but the wire frame display of the map. makes it hard to add multiple spawn points. very difficult on the HLSP maps where things can be kind of tight.

38. NemPosted: Nov 10th, 2007 - 12:04:43 pm
Kinda. In the entities tab, you can add and duplicate info_player_start entities using the context menu. Once you have added your new spawns, you can export a .ent file from the File menu, then import you entities back into your .bsp using ripent.

39. the-deadPosted: Feb 22nd, 2008 - 1:26:50 pm
I have a question to this program...
can i edit a map with it??? i have loded a bsp and now, i wanna edit and save. is this possible???


thx the-dead

40. EanModified: Jun 16th, 2008 - 9:24:09 am
how do you export lightmaps? milkshape wont import the meshes and ac3d wont import lightmaps. Also, I noticed the poly count is much higher in ac3d than bsp viewer (even with no culling)

41. NemPosted: Jun 17th, 2008 - 3:48:24 pm
BSP Viewer has been replaced by Crafty (which included the ability to export lightmaps).

42. BourneModified: Mar 13th, 2010 - 5:55:23 pm
Everytime i try to open a .bsp i get the following error message, :
"Error loading BSP file: Invalid Half-Life BSP file format."
i have done everything correct and it still says that. Please help!

but everything else is perfect!

43. mabanPosted: Mar 13th, 2010 - 6:42:09 pm
BSP Viewer hasn't been updated in 4 years. Use Crafty instead.

44. BournePosted: Mar 13th, 2010 - 7:40:51 pm
oh, alright. thanks i was in a rush at the time

45. Patrick StarPosted: Nov 20th, 2011 - 11:44:16 pm
i decompile a map but none of the func_walls show up

[ 1 2 3 4 ]

You must be logged in to post a comment.
New users can register here.
Nem's Tools v2.0 © 2006 Ryan Gregg.
Execution time: 0.094412s; Queries: 17.
dishes served.
Powered by The Wavelength.

Valid XHTML 1.0 Transitional Valid CSS
π