Talk:Valve Map Format

From Valve Developer Community
Revision as of 01:26, 31 October 2006 by Nem (talk | contribs)

Jump to: navigation, search

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)
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)