Difference between revisions of "Talk:Valve Map Format"

From Valve Developer Community
Jump to: navigation, search
(allowed_verts)
m (Forgot my sig.)
Line 62: Line 62:
 
::::I can't yet confirm ''what'' it does, but I can confirm that the cause is two faces on the same brush sharing an edge, when one is higher power than the other. I just got Hammer to do produce the different allowed_verts with a brand new map. I haven't gotten it to do this for two differing powers on different brushes. —[[User:Kateye|Kateye]] 09:28, 31 Oct 2006 (PST)
 
::::I can't yet confirm ''what'' it does, but I can confirm that the cause is two faces on the same brush sharing an edge, when one is higher power than the other. I just got Hammer to do produce the different allowed_verts with a brand new map. I haven't gotten it to do this for two differing powers on different brushes. —[[User:Kateye|Kateye]] 09:28, 31 Oct 2006 (PST)
  
:::::Alright, I took a look at the VBSP source and while it doesn't read the allowed_verts structure from the .vmf (at least it doesn't seem to use it, the actual reading code isn't available), it does seem to generate them in disp_common.cpp.  The allowed_verts are then passed to TesselateDisplacement(), so I think what they are used for is to match triangle tessellation between two displacement maps.  That is, if you have two adjacent displacement maps of a different power, you don't want to generate vertices in the higher power displacement map along the border with the lower power displacement map where the lower power displacement map doesn't have any vertices so you don't end up with a vertex in one displacement map halfway along the edge of another.  The generation of these vertices would result in visual artifacts due to triangle rasterization and other rounding errors.  (Hope that makes sense, kind of hard to put into words.)
+
:::::Alright, I took a look at the VBSP source and while it doesn't read the allowed_verts structure from the .vmf (at least it doesn't seem to use it, the actual reading code isn't available), it does seem to generate them in disp_common.cpp.  The allowed_verts are then passed to TesselateDisplacement(), so I think what they are used for is to match triangle tessellation between two displacement maps.  That is, if you have two adjacent displacement maps of a different power, you don't want to generate vertices in the higher power displacement map along the border with the lower power displacement map where the lower power displacement map doesn't have any vertices so you don't end up with a vertex in one displacement map halfway along the edge of another.  The generation of these vertices would result in visual artifacts due to triangle rasterization and other rounding errors.  (Hope that makes sense, kind of hard to put into words.) --[[User:Nem|Nem]] 10:58, 31 Oct 2006 (PST)

Revision as of 18:58, 31 October 2006

Plane specification

In the section on the plane specification, it says that, "The vertices used to define a plane need to coincide with the vertices of the brush, otherwise invalid brushes will be formed as the edges will not be clearly defined for the brush."

Surely even if the points used to define the plane do not coincide with the vertices of the brush, the vertices of a valid brush can be found by working out where the planes intersect?

The Quake II build tools don't even try to use the plane specification points as brush vertices...

PeterBrett 23:49, 26 Jul 2006 (PDT)

I belive you a right sir, i worte this pretty much all at once, I'll take a closer look when i get a moment to reword it. TY for the heads up. --Angry Beaver 15:08, 27 Jul 2006 (PDT)

Okay, tell me if thats better. I'm pretty sure it is but you never know i'm nto at ym ampping system right now --Angry Beaver 16:55, 27 Jul 2006 (PDT)

Phong shading

What about adding the phong shading-stuff? It seems the engine has support for it and you can see the phong shading settings in DoD:S' VMTs --dutchmega 04:56, 28 Jul 2006 (PDT)

This is for VMF not VMT

Gosh.. Maybe I should sleep more then only 4 hours... --dutchmega 06:47, 28 Jul 2006 (PDT)

Subdiv

Is there any point to this boolean ("Subdiv" in DispInfo)? Resetting it to 0 after doing a subdivision on several surfaces does not appear to affect the map or Hammer at all. --Kateye 20:52, 21 Oct 2006 (PDT)

IDs

Other than VisGroups and Groups, are the IDs on other objects refered to anywhere else in the file? IOW, is there any reason that a side's ID should be what the file specified instead of a new unique ID? —Kateye 11:41, 25 Oct 2006 (PDT)

YES, certain things like cubemaps reference specific sides in a level. Brush IDs... I'm unsure but better safe than sorry no? --Angry Beaver 18:21, 25 Oct 2006 (PDT)
Hmm. If you modify the level, though, shouldn't you have to rebuild cube maps anyway? Eh well, I'll put in a boolean to disable ID Range Compression... —Kateye 19:32, 26 Oct 2006 (PDT)

allowed_verts

The docs currently say that allowed_verts must be "-1 -1 -1 -1 -1 -1 -1 -1 -1 -1"; However, when I ran some Valve provided maps through my VMFLib, I got this:

Warnings for "D:\Games\Steam\SteamApps\kateye\sourcesdk_content\hl2\mapsrc\sdk_d1_town_03.vmf":
Warning (40262): allowed_verts's 10 property was an unexpected value: -131073 -2097161 -129 -1 -1 -1 -1 -1 -1 -1
Warning (40478): allowed_verts's 10 property was an unexpected value: -131073 -2097161 -129 -1 -1 -1 -1 -1 -1 -1

(For the record, the number in paranthesis is the line number)

You also said that Hammer would revert the values, but this does not seem to be the case for these values as after opening and resaving the file in Hammer I get:

Warnings for "D:\Projects\Maps\sdk_d1_town_03.vmf":
Warning (16): Unrecognized property name for a viewsettings: bshowlogicalgrid
Warning (40604): Unrecognized property name for a dispinfo: flags
Warning (40696): Unrecognized property name for a dispinfo: flags
Warning (40772): allowed_verts's 10 property was an unexpected value: -131073 -2097161 -129 -1 -1 -1 -1 -1 -1 -1
Warning (40823): Unrecognized property name for a dispinfo: flags
Warning (40915): Unrecognized property name for a dispinfo: flags
Warning (40991): allowed_verts's 10 property was an unexpected value: -131073 -2097161 -129 -1 -1 -1 -1 -1 -1 -1
Warning (41433): Unrecognized property name for a dispinfo: flags
Warning (58524): Unrecognized property name for a dispinfo: flags
Warning (60964): Unrecognized property name for a dispinfo: flags
Warning (61352): Unrecognized property name for a dispinfo: flags
Warning (65756): Unrecognized property name for a dispinfo: flags
Warning (66072): Unrecognized property name for a editor: logicalpos
{snipped 1062 repeats of the above line with different line numbers}

So it looks like allowed_verts is going to need more research. (oh, and we have some new properties and classes to take a look at too) —Kateye 14:25, 30 Oct 2006 (PST)

Interesting, I don't belive I said they had to be -1... I said changing them to anything different changed nothing visibly and was overwritten whenever I saved after opening. If I had some ideas as to what thosoe values should be doing I could investiagte more but right now I'm snowed under with school work. So I'll get round to it sometime after thursday --Angry Beaver 17:14, 30 Oct 2006 (PST)
I must have misunderstood; from the "resetting to -1 on save" I thought Hammer was saying it had to be -1. Anyway, Hammer didn't reset the values to -1. —Kateye 17:51, 30 Oct 2006 (PST)
Maybe they're flags indicating which vertices are active? The SDK docs say: "This is built based on the layout and sizes of our neighbors and tells us which vertices are allowed to be active.". Indeed 131073 is 2^17 + 2^1, 2097161 is 2^21 + 2^3 + 2^1 and 129 is 2^7 + 2^1. Unfortunately, what "active" means isn't described anywhere. Also, there are a maximum of (2^4 + 1)^2 = 17^2 = 289 vertices and there are 10 entries in allowed_verts with 32 bits 10 * 32 = 320 which is the minimum number of entries * 32 bits needed to have one bit per vertex in the maximum case. --Nem 17:26, 30 Oct 2006 (PST)
That's my guess as well, although the -1 is actually 0xFFFFFFFF or all bits true, while -131073 is 0xFFFDFFFF or all bits except the 18th. Similarly, -209716 is 0xFFDFFFF7 or all except the 22nd and 4th. Finally, -129 is 0xFFFFFF7F or all but the eighth. So in general, all bits are set. The question then is, what does the flag being off mean? I'm actually looking at the faces right now in Hammer and see nothing special at all. —Kateye 17:54, 30 Oct 2006 (PST)
Upon further inspection, I've noticed that both of the surfaces are power 3 and are "sewn" to a power 2 surface. 2^3+1 is 9 vertices, and 2^2+1 is 5 vertices. That's a differance of 4 verts on the edge, exactly the same as the number of bits that are 0 in the "allowed_verts". My guess is that these four verts are "disabled" so that the map developer doesn't have to maintain their precise position. I'll experiment to determine if this is the case in a little while, but I just thought I'd throw the theory out there. If it's true, it's pretty nice, and I want to find a way to make Hammer do this. —Kateye 21:42, 30 Oct 2006 (PST)
If this is the case, why is the allowed_verts data compiled into the BSP? You could be right (perhaps the flagged vertices are calculated through interpolation). Maybe it has something to do with how they're rendered? I could be wrong though, I don't have the VCSG code on hand to check that the structure in the BSP file is indeed the allowed_verts data. I seem to remember that the structure in the BSP file is larger 17^2 longs, but I'll have to double check when I have the source at hand. If that size is right, then perhaps it's a clue or maybe even a programming error. --Nem 02:02, 31 Oct 2006 (PST)
I can't yet confirm what it does, but I can confirm that the cause is two faces on the same brush sharing an edge, when one is higher power than the other. I just got Hammer to do produce the different allowed_verts with a brand new map. I haven't gotten it to do this for two differing powers on different brushes. —Kateye 09:28, 31 Oct 2006 (PST)
Alright, I took a look at the VBSP source and while it doesn't read the allowed_verts structure from the .vmf (at least it doesn't seem to use it, the actual reading code isn't available), it does seem to generate them in disp_common.cpp. The allowed_verts are then passed to TesselateDisplacement(), so I think what they are used for is to match triangle tessellation between two displacement maps. That is, if you have two adjacent displacement maps of a different power, you don't want to generate vertices in the higher power displacement map along the border with the lower power displacement map where the lower power displacement map doesn't have any vertices so you don't end up with a vertex in one displacement map halfway along the edge of another. The generation of these vertices would result in visual artifacts due to triangle rasterization and other rounding errors. (Hope that makes sense, kind of hard to put into words.) --Nem 10:58, 31 Oct 2006 (PST)