View source for Talk:VMF (Valve Map Format)

== 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... 
::[[User:PeterBrett|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. --[[User:Angry Beaver|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 --[[User:Angry Beaver|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 --[[User:Dutchmega|dutchmega]] 04:56, 28 Jul 2006 (PDT)
:This is for VMF not VMT
Gosh.. Maybe I should sleep more then only 4 hours... --[[User:Dutchmega|dutchmega]] 06:47, 28 Jul 2006 (PDT)
== Subdiv ==
Is there any point to this boolean ("Subdiv" in [[VMF_documentation#DispInfo|DispInfo]])? Resetting it to 0 after doing a subdivision on several surfaces does not appear to affect the map or Hammer at all. --[[User:Kateye|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? &mdash;[[User:Kateye|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? --[[User:Angry Beaver|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... &mdash;[[User:Kateye|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:
<pre>
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
</pre>
(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:
<pre>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}
</pre>
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) &mdash;[[User:Kateye|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 --[[User:Angry Beaver|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. &mdash;[[User:Kateye|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. --[[User:Nem|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. &mdash;[[User:Kateye|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. &mdash;[[User:Kateye|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. --[[User:Nem|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. &mdash;[[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.) --[[User:Nem|Nem]] 10:58, 31 Oct 2006 (PST)

::::::That makes perfect sense; when tesselating meshes you have to take extra care at the edges where they meet other meshes. It also explains why I can still move the "disabled" vertices. Too bad, being able to automatically lerp the extra verts would have been nice. Now that it's been more or less figured out I can implement it. [[User:Kateye|&mdash;Kateye]] 11:18, 31 Oct 2006 (PST)

::::::I tested the theory on sdk_vehicles and you can definitely see the expected tessellation with mat_wireframe 1. --[[User:Nem|Nem]] 12:05, 31 Oct 2006 (PST)
:::::::Huh, I don't see displacement maps ''at all'' with mat_wireframe 1. However, I ''have'' seen that even though the "disallowed" vertex leaves a gaping hole between the two wireframes, in game it doesn't.[[User:Kateye|&mdash;Kateye]] 10:02, 1 Nov 2006 (PST)
:::::::[[:Image:Dispverts inhammer.jpg|Take a look]] at the [[:Image:Dispverts inhl2.jpg|differance]][[User:Kateye|&mdash;Kateye]] 10:25, 1 Nov 2006 (PST)
::::::::I wasn't going to upload the screenshot because I kind of thought it was a waste, but here is the one [[:Image:Tessellation.jpg|I took]]. --[[User:Nem|Nem]] 16:55, 1 Nov 2006 (PST)
::::::Ohhhhhhhhhhhhhhhhhhhh That WOULD make sense... Could of sworn i Tested different sized displacements sewed... maybe I just missed that test file when writing that part :( --[[User:Angry Beaver|Angry Beaver]] 16:09, 31 Oct 2006 (PST)

==Logical Pos==
Two new properties have appeared: bShowLogicalGrid under [[VMF documentation#viewsettings|<code>viewsettings</code>]] and LogicalPos under [[VMF documentation#editor|<code>editor</code>]]. LogicalPos appears to only exist for the <code>editor</code> subclass of an <code>entity</code> class and consists of 2 floats (which tend to be integers but don't have to be) enclosed in square brackets. However, neither of these properties appear to do anything in Hammer except be preserved on save.

As a vector2 they certainly aren't a 3d position, so what could logical mean? I can't seem to get it to change in Hammer.

Anyone have any ideas? [[User:Kateye|&mdash;Kateye]] 22:20, 31 Oct 2006 (PST)
:So far it seems like every creation increments the logical position by 500. That is, if you make a point entity, brush, or convert a brush to an entity or to world it increments by 500. But once it's set it doesn't change. [[User:Kateye|&mdash;Kateye]] 22:27, 31 Oct 2006 (PST)
::Yeah I forgot to mention I played with that when you first brought it up, came to pretty much the same conclusion. I even compiled a few maps but nothing seemed to change. I'm tempted to think it might have to do with some internal optimizations in speed but *shrug* my other guess is physics. Its like the nijna of Hl2, don't know what happened, was nijas.. I mean physics :P --[[User:Angry Beaver|Angry Beaver]] 18:56, 1 Nov 2006 (PST)

==Feedback==
Could anyone please explain about those sides in solid? A cube consists of 6 sides, each has one plane with three points. And that's what confuses me, shouldn't it be four points? It creates six triangles and what with the rest? {{unsigned Falco}}

: Not everything is a cube, the VMF format works by creating planes (infinte 2D "sheets of cardboard" rotated in a 3D world) and then finding their intersections. From that process it then creates the faces edges and vertecies used in game and editor. This is why theres such things as invalid brushes. Now in order to represent any orientation in 3D space you can use 3 points, imagine if you had 3 sticks all different lengths all positioned in different places. You take a sheet of cardboard and then lay it on top of them, no matter what positions the sticks are put in or what lengths they have the carboard will always come to rest sitting atop all 3. Knowing this you can store a Faces orientation and position in terms of these 3 points. Now if you have multiple planes unless they are all parralel will intersect. Where the planes intersect edges and vertecies are formed for use in game and in editor. Now we've got that concept lets try and optimize it. If the entire point of these planes is to intersect and generate vertecies and edges why not use the vertecies themselves as the points used to define that plane, the only reason why not is because a plane must ALWAYS be defined by three points. So as a comprimise 3 points are selected from a face and stored as the defenition of the plane. Thats why Hammer "fixes" invalid brushes for you when you save and then load a map, it has no way to keep track of most invalid brushes. --[[User:Angry Beaver|Angry Beaver]] 22:52, 20 May 2007 (PDT)

==Organization==
I am going to organize the documentation in a logical manner, which is likely going to involve separate pages.--[[User:Aybraus|Aybraus]] 21:20, 14 May 2009 (UTC)
:Moving contents to seperate pages and only having a small link thats barely noticable makes it less organised especially when only one section was moved to a separate page. Either all sections should be seperate pages(Which is bad imo) or all should be on one page. --[[User:Stucuk|Stucuk]] 19:00, 21 June 2010 (UTC)