Possible Darkplaces bug ?

[frag.machine]

Not sure if is DP specific, or if this is the best place to report (I'll forward this info to DP home site too, don't worry ) or even if it's a known bug/behavior, but anyway, I stumbled on this situation while working on my current project:





On this map you can see 2 perfectly equally lit armors, yet one of them shows completely black. The only difference is the map geometry under the black (unlit) armor:



As you can see, the unlit armor lays exactly over the junctions of 4 brushes, while the correctly lit armor lays in the middle of a single brush.

I reckon this is a bug related to the R_LightPoint () function, which leads me to believe is DP-specific since it was modified for .LIT support from the original code, but I can be wrong.

EDIT, Yup, seems DP specific. The same map in vanilla GLQuake works just fine:

[leileilol]

Does it happen in Engoo? That also uses the lightpoint code

[taniwha]

frag.macihe: the origin of the armor is directly over the junction? I'll do up a test map and check QF (unless you can get me your test map).

[LordHavoc]

It looks to me like a crack in the brushwork (visible under the armor) and the light sample is exactly in that valley, so it is legitimately in shadow.

Whereas original Quake's network protocol was not precise enough to represent this case and biased the network entity positions a bit if I recall correctly, so it ended up sampling one of the top polygons instead of the valley.

I'm more inclined to blame this on the map than the engine.

EDIT: actually upon further examination it looks like it is just exactly on a bsp plane, and that is something that is somehow offending the DP LightPoint implementation, but I'm not sure on the specifics.

[frag.machine]

[taniwha]

frag.macine: the problem is I am unfamilar with QuArK and thus not sure where the origin of the armor is wrt to the symbol.

rapidshare is being stubborn

[LordHavoc]

For taniwha: At a glance, the screenshot depicts 4 brushes which meet at a coordinate, presumably integer, the armor entity is precisely at the same coordinates (well, biased upward off the floor by droptofloor which puts it at +0.03125 on Z compared to the floor).

The only BSP node involved would be the floor, but there are 4 surfaces with a shared corner, and the armor lies directly on top of those 4.

Since DP would be looking at the floor BSP node and iterating the surfaces on that node, it should find the 4 surfaces that meet at this position, however DP relies on the extents of the lightmap area on the plane, not the polygon geometry, so it isn't actually concerned with whether the ray hits one of these polygons but rather whether it hits one of the lightmaps, and these lightmap regions overlap (padded by qbsp for lightmap filtering reasons - software quake had filtering on lightmaps after all).

My suspicions are on either a quirk with the lightmap regions (perhaps a black lightmap is being hit instead of the surface lightmaps it should be finding?) or the surfaces are being entirely missed (tracing through the floor, perhaps due to network compression of coordinates it would be exactly "on" the floor plane?).

This seems to be one of the rare instances where the bug shows up, in the past I fixed some other instances of it, so it is not new, but I'm not sure on the cause here.

[frag.machine]

[taniwha]

frag.machine: thanks. grabbed it and tested. QF lights both sets of armor properly, in all four renderers (mind you, they all use the same function (I merged lighting calculations)).

[r00k]

frag: put a plane under the model at 1 qu above the floor, see if that works, or under the floor. or overlap the 4 planes.... (alias models shouldnt render black... ever imho)
my suggestion isnt to fix the map, its to find the smallest denominator from broke to fixed that LH can discern a solution

[frag.machine]

[taniwha]

Any crack visible in a GL renderer is due to the texture sampler interpolating between texture and no texture. In QF's glsl and both sw renderers, no cracks are visible (though a bit of a seam is due to the textures not being perfectly tile-able).

[mh]

A sampler should never interpolate between texture and no-texture. In clamp mode it will "stretch out" the last row (or column) of texels to fill in any extra space needed, in repeat mode it will interpolate between the texels along opposite edges of the texture - if they're different enough (i.e. a non-tiling texture) then you're going to get what appears to be cracks but in reality it's just the sampler doing what it was told to do.

[frag.machine]

[taniwha]

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 .

[edit3] But the border param must be 0 for gles