Dr Creating Leaks

[OrbWeaver]

I did a simple test of loading mansion_alpha, saving to a new filename and then compiling the newly-saved version in DoomEdit, and a leak was created. Compiling the original version has no leak.

 

Looking through the created map files with Beyond Compare, there are the usual floating-point differences which are to be expected (although still rather worrying, since it is possible this could create errors), but more concerning are some missing bruch faces, such as this:

 

Original:

 

// primitive 91
{
brushDef3
{
 ( 0 0 1 -224 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 59 ) ) "textures/common/caulk" 0 0 0
 ( 0 -1 0 -1680 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( 0 1 0 1360 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( 1 0 0 -192 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( -1 0 0 64 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( 0 0.4472135901 -0.8944271803 722.6971435547 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 62.1305236816 ) ) "textures/common/caulk" 0 0 0
 ( 0 -0.4472135901 0.8944271803 -779.9404907227 ) ( ( -0.0312500037 0 67.5 ) ( 0 0.03125 62.1305236816 ) ) "textures/common/caulk" 0 0 0
}
}

 

DR saved version:

 

// primitive 91
{
brushDef3
{
 // missing line here
 ( 0 -1 0 -1680 ) ( ( -0.03125 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( 0 1 0 1360 ) ( ( -0.03125 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( 1 0 0 -192 ) ( ( -0.03125 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( -1 0 0 64 ) ( ( -0.03125 0 67.5 ) ( 0 0.03125 66 ) ) "textures/common/caulk" 0 0 0
 ( 0 0.4472140074 -0.8944270015 722.6970214844 ) ( ( -0.03125 0 67.5 ) ( 0 0.03125 62.1305007935 ) ) "textures/common/caulk" 0 0 0
 ( 0 -0.4472140074 0.8944270015 -779.9400024414 ) ( ( -0.03125 0 67.5 ) ( 0 0.03125 62.1305007935 ) ) "textures/common/caulk" 0 0 0
}
}

 

 

@greebo: Does this occur on your build as well? It is possible that we might have different versions of the map, so maybe it wouldn't happen anyway.

[greebo]

I'll check it out right now, I'm still compiling my own build. What I can imagine is, that the brush maybe is defective.

 

It looks like this is a seven-sided brush and there are two faces that are parallel to the xy-plane, maybe there are bogus plane definitions in there. But as the leaks are absent in the original file, this may of course be wrong...

[greebo]

Ok, there is something serious going on. I opened the map file that I synced from CVS a few weeks ago, so I guess this is the latest version, as Dram is away at the moment. This map was 8.00 MB large.

 

I saved under mansion_alpha_dr.map and this map file has now 6.74 MB (nearly 1.3 megs smaller)! WTH? I'll have to look what this large difference is about and where DarkRadiant "saved" so much drive space .

[OrbWeaver]

OK, glad it's not just me. I'll raise a defect for this. EDIT: raised as #38.

[greebo]

There are several differences I notice:

 

- The DoomEdit version has indentation using up to two spaces. As the map has approx. 150k lines, this would explain a few hundred kilobytes difference in space.

- The DoomEdit version saves the primitve comments as "// primitive 1" whereas DarkRadiant saves it as "// brush 1" (for both patches and brushes, which is wrong), so this would explain another 4*5500 ~ 22 kiBytes in size.

 

I'll dive in a bit further.

[OrbWeaver]

The difference between my mansion_alpha original and saved is only about 300k, which may be explained by these formatting issues.

[greebo]

Another difference is the floating point representation:

 

DoomEdit (see entity 1248, func_static):

brushDef3
{
 ( 0 0 -1 -180 ) ( ( -0.0000000042 0.0312500037 74.5 ) ( 0.0312500037 0.0000000042 -26.5000019073 ) ) "textures/common/caulk" 0 0 0
 ( 0 0 1 -156 ) ( ( -0.000000001 -0.0078125 5.6249980927 ) ( -0.0078125 0.000000001 7.3750004768 ) ) "textures/darkmod/wood/floor/boards_old_004" 0 0 0
 ( 1 0.0000001341 0 -113 ) ( ( 0.0037499955 -0.0000000012 -0.3599985838 ) ( -0.0000000009 -0.0029761903 -0.2857137024 ) ) "textures/darkmod/ceramic/wall/stucco_001_grey" 0 0 0
 ( 0.0000001348 -1 0 47.9999389648 ) ( ( -0.0312500037 0 74.4999923706 ) ( 0 0.03125 3 ) ) "textures/common/caulk" 0 0 0
 ( -1 -0.0000001341 0 33 ) ( ( 0.0037499955 -0.0000000012 6.720000267 ) ( -0.0000000009 -0.0029761903 -0.2857162058 ) ) "textures/darkmod/ceramic/wall/stucco_001_grey" 0 0 0
 ( -0.0000001348 1 0 -95.9999389648 ) ( ( 0.0037499955 -0.0000000012 5.8799877167 ) ( -0.0000000009 -0.0029761903 -0.2857154608 ) ) "textures/darkmod/ceramic/wall/stucco_001_grey" 0 0 0
}

DarkRadiant uses exponential notation sometimes, which may confuse Doom3 (I'll have to check Bonehoard for such a notation).

brushDef3
{
( 0 0 -1 -180 ) ( ( -4.2e-009 0.03125 74.5 ) ( 0.03125 4.2e-009 -26.5 ) ) "textures/common/caulk" 0 0 0
( 0 0 1 -156 ) ( ( -1e-009 -0.0078125 5.625 ) ( -0.0078125 1e-009 7.375 ) ) "textures/darkmod/wood/floor/boards_old_004" 0 0 0
( 1 1.341e-007 0 -113 ) ( ( 0.00375 -1.2e-009 -0.359999 ) ( -9e-010 -0.00297619 -0.285714 ) ) "textures/darkmod/ceramic/wall/stucco_001_grey" 0 0 0
( 1.348e-007 -1 0 47.9999 ) ( ( -0.03125 0 74.5 ) ( 0 0.03125 3 ) ) "textures/common/caulk" 0 0 0
( -1 -1.341e-007 0 33 ) ( ( 0.00375 -1.2e-009 6.72 ) ( -9e-010 -0.00297619 -0.285716 ) ) "textures/darkmod/ceramic/wall/stucco_001_grey" 0 0 0
( -1.348e-007 1 0 -95.9999 ) ( ( 0.00375 -1.2e-009 5.87999 ) ( -9e-010 -0.00297619 -0.285715 ) ) "textures/darkmod/ceramic/wall/stucco_001_grey" 0 0 0
}

[angua]

Ok, there is something serious going on. I opened the map file that I synced from CVS a few weeks ago, so I guess this is the latest version, as Dram is away at the moment. This map was 8.00 MB large.

 

I saved under mansion_alpha_dr.map and this map file has now 6.74 MB (nearly 1.3 megs smaller)! WTH? I'll have to look what this large difference is about and where DarkRadiant "saved" so much drive space .

Just tested it, the old Darkradiant 0.7.1 does that too.

[greebo]

I checked the floating point formatting in bonehoard.map and there are brushes using exponential format as well (which doesn't seem to harm Doom3, which is at least good to know).

 

However, these floating points seem to be used for values below 1e-8 (which may be considered as 0 by Doom3 anyway, but that's just a wild guess).

[OrbWeaver]

Just tested it, the old Darkradiant 0.7.1 does that too.

 

Well, at least it means this bug doesn't have to block the release, assuming it only affects a few maps.

 

@greebo: My DarkRadiant uses "// primitive" not "// brush" when saving. EDIT: Actually, no it doesn't, that is because Doom 3 re-saves the map when you BSP it. I will do another comparison before the BSP is done, so that we are comparing the DR-saved version with the original.

[OrbWeaver]

Without using BSP, I now see the size difference you are seeing. Apart from the formatting issues, I suspect this is cause by loss of precision and the use of exponents, rather than very long numeric values.

 

My first missing line is at worldspawn primitive 69. Also at 72, 94. This seems to be a common problem.

[greebo]

I had a look at that brush and it appears to be six-sided in DarkRadiant (and it looks valid). My guess is that this *was* a seven-sided brush once and has one degenerate face. The (0 0 1 0) face is touching the brush only on the top edge, hence it's defining a face with inifinitely small area.

 

The Brush class has some code that is checking for this degenerate faces and is discarding them, so we could try to produce an globalErrorStream() output if such things happen (these faces may also appear during a clipping process, so the code has to be there).

 

edit: yep, it's Brush::removeDegenerateFaces() which does that job.

[OrbWeaver]

I see, so this is meant to happen (presumably it corresponds to Doom 3's "removed degenerate" output message). Doesn't explain the leak though. I guess I will have to use the pointfile to find out where the leak actually is.

[greebo]

It's in the uppermost and rightmost area of the map, but it's not obvious, but you may have more luck than me.

 

There are four brushes with degenerate faces it seems (this is the debug output of the aforementioned method):

Removed degenerate face: <0, 0, 1> - 0
Removed degenerate face: <0, 0, 1> - 0
Removed degenerate face: <0, -0.452865, 0.891579> - -139.567
Removed degenerate face: <0, -0.452865, 0.891579> - -139.567

So the one plane is definitely degenerate, as I suspected.

 

However, this should not produce a leak, as you said.

[sparhawk]

Are such degenerate faces, just artifacts of the math, or are these burshes that should have been there but are somehow mangled up? In case of the latter, wouldn't it be good to highlight them with some box so that mapper can see where these faces are, and do something about it?

[greebo]

Those are faces that consist only of two points and are therefore only an edge, so they don't contribute to the volume in any way. This can happen when you clip a brush or move one edge on top of another (making a four-sided brush to a three-sided one). They are artifacts or leftovers of a clipping or dragging operation, so to say.

 

Its data object (= face plane) is still part of the parent brush, but it's degenerated to an edge. Theoretically you would be able to make the face reappear by dragging the edge away again, but this is technically not possible by means of mouse clicks.

[angua]

There are some brushes with undefined shader in this area.

 

This was in the unsaved map:

// primitive 656
{
brushDef3
{
 ( 0.0000001341 1 0 -3904.0002441406 ) ( ( -0.0312500037 0 47.8749885559 ) ( 0 0.03125 -0.375 ) ) "textures/common/caulk" 0 0 0
 ( 1 -0.000000135 0 -1795.9995117188 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_default" 0 0 0
 ( -0.0000001341 -1 0 3328.0002441406 ) ( ( -0.0312500037 0 -47.8749885559 ) ( 0 0.03125 -0.375 ) ) "textures/common/caulk" 0 0 0
 ( -1 0.000000135 0 1783.9995117188 ) ( ( -0.0312500037 0 -178.1250305176 ) ( 0 0.03125 -0.375 ) ) "textures/common/caulk" 0 0 0
 ( 0 0 1 1348 ) ( ( 0.0000000042 -0.03125 -47.8750076294 ) ( -0.03125 -0.0000000042 177.7500152588 ) ) "textures/common/caulk" 0 0 0
 ( 0 0 -1 -1636 ) ( ( 0.0000000042 0.0312500037 -47.8750114441 ) ( 0.0312500037 -0.0000000042 -178.5000152588 ) ) "textures/common/caulk" 0 0 0
}
}

 

and this is how it looks like after it has got saved in DarkRadiant:

 

// brush 656
{
brushDef3
{
( 1.341e-007 1 0 -3904 ) ( ( -0.03125 0 47.875 ) ( 0 0.03125 -0.375 ) ) "textures/common/caulk" 0 0 0
( 1 -1.35e-007 0 -1796 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
( -1.341e-007 -1 0 3328 ) ( ( -0.03125 0 -47.875 ) ( 0 0.03125 -0.375 ) ) "textures/common/caulk" 0 0 0
( -1 1.35e-007 0 1784 ) ( ( -0.03125 0 -178.125 ) ( 0 0.03125 -0.375 ) ) "textures/common/caulk" 0 0 0
( 0 0 1 1348 ) ( ( 4.2e-009 -0.03125 -47.875 ) ( -0.03125 -4.2e-009 177.75 ) ) "textures/common/caulk" 0 0 0
( 0 0 -1 -1636 ) ( ( 4.2e-009 0.03125 -47.875 ) ( 0.03125 -4.2e-009 -178.5 ) ) "textures/common/caulk" 0 0 0
}
}

 

 

Looks like D3Ed puts _default if there is no texture defined, but DR puts _emptyname, which is not used for sealing and therefore produces a leak.

[OrbWeaver]

Good find, I thought it might have something to do with textures since the missing geometry seemed to be a red herring. I thought _default would lead to a leak also, but in case it doesn't I guess we had better start using this instead of _emptyname.

[angua]

_default also only gives the red "shader image missing" in dark radiant instead of the blue "shader not found"

[OrbWeaver]

Excellent, that has solved the problem. I just did a global search and replace changing "_emptyname" to "_default" and now the saved map compiles fine.

[New Horizon]

So in D3Ed, if I'm understanding correct, _default is the caulk texture I take it? Speaking of which, one of my early requests for DR was to have caulk be the starting texture every time you start a new brush, or at least when you first start DR. Just simplifies things a bit so you don't have to go looking for untextured areas.

[OrbWeaver]

No, _default is used when there is no texture. My belief was that this would cause a leak, because it is not the same as caulk, but apparently not in this case.

 

I remember the suggestion to use caulk when dragging out a new brush, I will add this to the list of feature requests.