Possible Darkplaces bug ?

[LordHavoc]

Ok, the seams I saw in glsl, sw and sw32 in QF are there in the texture (the central tile).

For gl, it's the edge-of-texture sampling that causes the visible seams that should not be there. This is because the hardware is interpolating between the texels and black (beyond the texture). Isn't there a sampling mode that extends the last texel out? I know there's repeat (required for automatic tiling (eg, water), and clamp (I believe both to black and to white), but isn't there extend as well?

[edit]Hmm, seems not: just border color can be set for clamp mode.

[edit2] Or maybe there is a way.

Just FYI, GPUs hate GL_CLAMP and GL_CLAMP_TO_BORDER modes, only GL_CLAMP_TO_EDGE is nice-performing, and I'm talking about GPUs across all generations, not merely the ones from the 1990s and early 2000s, modern ones hate those too.

[taniwha]

That explains why gles doesn't support it (edit3, which you seem to have missed) and why the feature seems to be deprecated. I can imagine the extra texels making life miserable for the hw engineer.

[jitspoe]

So I've tracked down exactly what the issue is, and it's super easy to reproduce. It is, as others have pointed out, entities that are exactly on the edge of a brush will not hit a lightmap. It doesn't even have to be the edge of a brush, actually. They just have to be on the edge of a split from the compiler. The simplest example is to make a small room and put an entity at 0,0 (z doesn't matter).

So, what's happening?

Code: Select all

if (dsi >= 0 && dsi < lmwidth - 1 && dti >= 0 && dti < lmheight - 1)

In this situation, it finds the surface, but when it's checking the lightmap bounds, it's right on the edge. dsi == lmwidth - 1 or dti == lmheight - 1 exactly. I was starting to write a special edge case (literally), but I found simply changing the < to a <= fixes the problem. I'm not sure if it will have other side effects. I haven't seen any yet (though I'm testing in Quake2, not Quake1). If issues show up, I could do a more substantial fix.

Entities being snapped to the grid right where the BSP splits, or right on the edge of a brush seems like it would be a common thing, so I'm surprised more people haven't noticed this. It happened a lot in Paintball2 since the flags tend to be centered on an axis.

[frag.machine]

I think it's the kind of bug that either is just tolerated as "quakish behavior" or "some bizarre behavior on XPTO engine". Glad to see it's an actual bug.

[LordHavoc]

Entities being snapped to the grid right where the BSP splits, or right on the edge of a brush seems like it would be a common thing, so I'm surprised more people haven't noticed this. It happened a lot in Paintball2 since the flags tend to be centered on an axis.

Actually the netcode in quake snaps to 1/8th unit precision and biases by +0.5 when it decodes the values, so the result is that all entities are at 0.0625 past a snapped coordinate (which is 0.125, 0.25, 0.375, etc...). Never lands on an integer value.

However darkplaces networks as float and thus preserves all those item origins that are exactly on integer...

And it suffers from this bug.

I think you found the solution but I haven't had a moment to examine my code and fix it.

[jitspoe]

I don't think Quake2 has that +0.5 bias (just the 1/8 snap). I ported the code to Quake2, which is where I was seeing the issue.

On a side note, how much additional bandwidth is used with floating point precision? Are you using a 32bit float? I guess that'd doble the bandwidth for positions (it was 16 bits before, right?) Not sure how much that affects things overall..

[Spike]

Vanilla Quake has no +0.5 either, and presumably if it did then it should be server-side(aka sender-side) rather than client-side, to cover the rounding error where it is made instead of being an arbitary bias but which of course would not prevent coords from being integer values.

regarding jitspoe' sidenote:
DP's networking resends only on new data or packetloss.
vs QW/Q2 which resends every single packet until acknowledged.
vs NQ which resends. just that. it resends. constantly.
DP could use 256bit coords and still have smaller packets than NQ... at least until someone starts firing a nailgun anyway.
for me the real killer is spammy nailguns (which could be predicted instead) and super-shotgun blasts (12 pellets each with their own set of 3d coords). either of these have viable technical solutions available via csqc, but sadly depend upon the mod doing all the work in order for it to be reliable. raw coordinate size overheads are somewhat insignificant compared to those.
either way, people have better internot connections than 56k modems nowadays. we can afford to splash out a little.

[goldenboy]

I've often encountered this bug in q1bsp because my maps used a lot of decorative models. Quite often some of the models would be black.

http://spawnhost.files.wordpress.com/2012/03/ao_6.jpg

Extremely nasty bug.

[jitspoe]

I found one more bug. It's possible for ds or dt to be negative, but dti and dsi to be 0 (ex: -0.98), which can result in a negative value from the bilinear interpolation calculation. I'm not sure how often this happens (only happened on a specific area of one map that I know of), but it ultimately resulted in some bad values for me, since some math I was doing later assumed positive values. The fix is simply:

Code: Select all

if (ds >= 0.0f && dsi < lmwidth && dt >= 0.0f && dti < lmheight)

I actually rearranged things a little, since there's no need to check the width/height bounds if the ds and dt aren't >= 0:

Code: Select all

            // location we want to sample in the lightmap
            ds = ((x * surface->texinfo->vecs[0][0] + y * surface->texinfo->vecs[0][1] + mid * surface->texinfo->vecs[0][2] + surface->texinfo->vecs[0][3]) - surface->texturemins[0]) * 0.0625f;
            dt = ((x * surface->texinfo->vecs[1][0] + y * surface->texinfo->vecs[1][1] + mid * surface->texinfo->vecs[1][2] + surface->texinfo->vecs[1][3]) - surface->texturemins[1]) * 0.0625f;

            if (ds >= 0.0f && dt >= 0.0f)
            {
               int dsi = (int)ds;
               int dti = (int)dt;

               lmwidth = ((surface->extents[0] >> 4) + 1);
               lmheight = ((surface->extents[1] >> 4) + 1);

               // is it in bounds?
               if (dsi < lmwidth && dti < lmheight)

Don't think it makes it any faster in practice, though.

[frag.machine]

*BUMP*

So... Any chances to get a fix or workaround for the totally black models ? This is becoming really hard to ignore in more complex maps.

On the above image the whole plat is actually a func_wall covering a dark well. There's a light source just above, but the weapon model is rendered pitch black.

[jitspoe]

I posted a potential fix -- just need to get LH or somebody to put it in.

[Cobalt]

Wow, good find, and hopefully the fix is put into a test build so we can give it the test.

I had noticed this on DM4 for a while now with an armor.....

[Cobalt]

Not sure if it matters, or if this bug has been repaired in newer DP versions, but I am bumping this up, and also, Frag Machines initial images of the bug seem to have expired.

UPDATE: Lord Havoc says nothing has been done on this as of yet.

During my experiments today with QC and getlight () for these occurences, it seems other light sources in proximity may contribute to this depending on the map. I increased r_ambient by about 5 values, and the armor in the screenshot I supplied can be seen alot better, the actual color of the armor is visible.

[jitspoe]

Tell LH to Ctrl+C Ctrl+V

[LordHavoc]

I'm actually doing a deep audit on all the collision code to improve the use of clip epsilons, I've got the lightmap fix integrated too, it's just not committed yet.

Expect an update in a few days.