Page 1 of 1

Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Wed Apr 24, 2013 11:01 pm
by jitspoe
I often run into an issue when I make small brushes where the compiler will try to snap them or something and end up messing them up. Does anybody know of a qbsp3 version that fixes this?

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Thu May 09, 2013 2:12 am
by jitspoe
Also, does anybody know which compilers would make good starting points if I wanted to make modifications to fix some things like this? I'd probably start with Geoffrey DeWan's compilers unless somebody knows of some better ones?

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Sun May 19, 2013 10:47 am
by SlapMap
What editor are you using? Sounds like you map off grid and either editor rounds down to ints when it saves to map or your compiler doesn't understand floats. Try to snap to integer grid whn you map to avoid problems. If your editor supports float coordinates (ei Quark) then compiler with floats support will help

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Mon May 20, 2013 3:58 pm
by jitspoe
Nope, it's all on-grid with integers. I'm using BSP.

For example, if I make a brush that's 1 unit x 1 unit x (some length), then put a 45 degree angle at the end and join it up with another brush like that, something like this:
__________
|\________
| |
| |
| |

Sometimes it will round the 45 degree angle and make the polygons overlap, or do other weird things. It's worse if I try to do things like small cylinders. It doesn't always happen, though.

Maybe a compiler that uses floating points would handle it better? Which one would you recommend?

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Mon Nov 25, 2013 11:44 pm
by jitspoe
I've been digging around a bit trying to figure out what exactly is causing this.

Here's my test case:

Map file: http://jitspoe.com/temp/_smallbrushtest2.map

Screen shot:
Image

The brush should be symmetrical, but the left side of it is mangled. This only seems to happen when brushes get split. In this case, the left part of the brush is on an axis, so it got split there, and it looks like some of the points rounded toward the axial plane.

I can't seem to track down where this is happening, though. The windings on the original brush are good. The windings on the final portals (not sure why they're called portals) are jacked up. I've tried eliminating all the epsilons I can find, but still no luck...

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Sat Nov 30, 2013 10:38 pm
by jitspoe
Finally tracked down what was causing it. There were a couple places that checked if a brush volume was less than 1. The way the compiler works, even areas outside of the actual brushes are measured this way, so if you have a 1-unit thick bush, with an angled edge, that outside area will sometimes be discarded, resulting in a square edge (depending on how the planes split things up).

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Thu Dec 05, 2013 8:16 pm
by jitspoe
I've posted a fixed qbsp3 here: http://dplogin.com/forums/index.php?topic=26664.0

I need to figure out what license I can release the code under. I tried to get in touch with Geoffrey DeWan, but the email in the readme files is dead.

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Thu Feb 20, 2014 4:40 pm
by jitspoe
I've posted another fix. Some of the epsilons were too small before, resulting in micro-cracks between some brushes and unnecessary polygons.

http://dplogin.com/forums/index.php?topic=26664.0

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Thu Feb 20, 2014 5:08 pm
by gnounc
excellent work on not only finding the issue, but releasing a fix!

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Fri Feb 21, 2014 3:29 am
by qbism
Just patch and release under same terms as DeWan? Basically ID code dump, don't try to sell the tool itself.
kmquake2 qbsp3 is also based on DeWan.

Strange, no upgraded compilers based on the GPL release of the tool? Maybe q2world but port lightmap stuff back in.

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Sat Feb 14, 2015 1:29 am
by jitspoe
Since somebody was asking for it, here's the source I modified:

http://dplogin.com/files/mapmaking/util ... _jitr2.zip

I think just the QBSP stuff has proper changes. The rad stuff is probably messed up, so I'd just ignore that. Don't think I changed the vis. I just zipped the whole source dir to make sure I included everything necessary.

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Tue Feb 17, 2015 2:55 pm
by Jay Dolan
Would you mind posting a couple gists of the actual changes? I'd love to merge these fixes into Q2WMap. :D

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Wed Feb 18, 2015 5:53 am
by jitspoe
Hm, I thought I already had. Guess not.

----------------------
qbsp.h:

Made this global:
#define PLANESIDE_EPSILON 0.001

-----------------------
brushbsp.c
I removed the local #define PLANESIDE_EPSILON

In CreateBrushWindings():

I changed:
ChopWindingInPlace (&w, plane->normal, plane->dist, 0); //CLIP_EPSILON);
To:
ChopWindingInPlace(&w, plane->normal, plane->dist, PLANESIDE_EPSILON);

(not sure how important this one is)

In SplitBrush():

float d, d_front, d_back;
To:
vec_t d, d_front, d_back; // jit (use higher precision, if enabled)

And
ChopWindingInPlace (&w, plane2->normal, plane2->dist, 0); // PLANESIDE_EPSILON);
To:
ChopWindingInPlace(&w, plane2->normal, plane2->dist, PLANESIDE_EPSILON); // jit - reenabled epsilon (was 0)
(multiple instances of this -- reenabled the epsilon on all of them)


******* THIS IS THE IMPORTANT ONE ********

v1 = BrushVolume (b);
if (v1 < 1.0)

to:
v1 = BrushVolume(b);
if (v1 < microvolume) // jit - allow for smaller brush volumes


----------------
csg.c:

MakeBspBrushList():
float dist;
to:
vec_t dist; // jit (use higher precision, if enabled)


----------------
faces.c:

#define POINT_EPSILON 0.5
#define OFF_EPSILON 0.5

To:
#define POINT_EPSILON 0.04 // jit, was 0.5
#define OFF_EPSILON 0.04 // jit, was 0.5

GetVertexnum():
for (vnum=hashverts[h] ; vnum ; vnum=vertexchain[vnum])
{
p = dvertexes[vnum].point;
if ( fabs(p[0]-vert[0])<POINT_EPSILON
&& fabs(p[1]-vert[1])<POINT_EPSILON
&& fabs(p[2]-vert[2])<POINT_EPSILON )
return vnum;
}

To:

for (vnum = hashverts[h]; vnum; vnum = vertexchain[vnum])
{
vec3_t diff;
vec_t length_sq; // jit

p = dvertexes[vnum].point;
VectorSubtract(p, vert, diff); // jit
length_sq = VectorLengthSq(diff); // jit

if (length_sq < POINT_EPSILON * POINT_EPSILON)
return vnum;
}


---------------------
map.c:

ChopWindingInPlace (&w, plane->normal, plane->dist, 0); //CLIP_EPSILON);
To:
ChopWindingInPlace(&w, plane->normal, plane->dist, PLANESIDE_EPSILON); // jit, was 0); //CLIP_EPSILON);


---------------------
qbsp3.c

*********** ALSO IMPORTANT (relates to the other microvolume change) *******************
vec_t microvolume = 1.0;
vec_t microvolume = 0.02f; // jit - was 1.0, but this messes up small brushes

---------------------
mathlib.h

#ifdef QBSP3 // only do this for qbsp, leads to stack overflows on qrad3.
#define DOUBLEVEC_T // jit - might as well be more accurate, and sometimes doubles are even faster on modern hardware, anyway...
#endif

*NOTE* I had to do this only for QBSP3, because if you do it for qrad3, it will stack overflow.

------------------------------------

I think that covers everything. The microvolume is the one that fixes the biggest issue. The other fixes may or may not be necessary, but I think I fixed a lot of issues with near infinitely-small triangle creation.

Re: Q2 QBSP3 That Properly Handles Small Brushes?

Posted: Sun Mar 01, 2015 10:56 pm
by jitspoe
After some Internet sleuthing, I finally got in touch with Geoffrey DeWan, and this was his response:
Man, I didn't even know that still existed. I am not sure exactly what I can release it as. The copy of the source code I originally grabbed from id software was released without any license at all but I am pretty sure they didn't put it into the public domain, so it is kind of in a gray area. I don't have a problem with it, I just can't guarantee id won't. If id has since released licensed source, I wouldn't have a problem if you merged my changes in.
I'm going to try to take the GPL tools (they did release them under the GPL, right?) and merge his changes in.

I'm working on improving the sun lighting code now.