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]

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.

@taniwha: Yes, the armor origin is exactly over the junction of 4 brushes. You can see it by the top view from the map tool (QuArK).
@LH: AFAIK there's no "crack" or leak in the map (at least it passes the VIS without errors). I am providing the test map below.
@leileilol: Didn't tried Engoo, but I uploaded the map so you guys can test it.

[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]

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

Indeed, I had to try a couple times to login to rapidshare, too. I'll try to upload it to quaketastic then.

EDIT: and here is the link.

[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]

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

rook: the sample map I provided already does something like that. As additional information: the .map file isn't storing coordinates as floating point values, so there's no chance of existing a 0.0001 qu wide "crack" between the brushes (unless QBSP is making this by itself, but then I believe the VIS tool would complain).

[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]

Here is the used texture:





And here, how it was suposed to look in the map:



As we can see, there is no seam marks in the texture. But the black seam is visible on GlQuake, too.

This is confusing, because looking at the .map file one cannot find reasons for "cracks" (all brushes coordinates are expressed as integers an perfectly aligned), and both QBSP and VIS treat the map as a perfectly sealed room.

Code: Select all

(...)
 {
  ( 128 256 0 ) ( 128 128 0 ) ( 128 128 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 256 256 -32 ) ( 256 128 -32 ) ( 256 128 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 256 128 -32 ) ( 128 128 -32 ) ( 128 128 0 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 256 0 ) ( 128 256 0 ) ( 128 256 -32 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 256 -32 ) ( 128 256 -32 ) ( 128 128 -32 ) speedbz_crv4 -256 128 0 1 1
  ( 256 128 0 ) ( 128 128 0 ) ( 128 256 0 ) speedbz_crv4 -256 128 0 1 1
 }
 {
  ( 0 256 0 ) ( 0 128 0 ) ( 0 128 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 256 -32 ) ( 128 128 -32 ) ( 128 128 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 128 -32 ) ( 0 128 -32 ) ( 0 128 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 256 0 ) ( 0 256 0 ) ( 0 256 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 256 -32 ) ( 0 256 -32 ) ( 0 128 -32 ) speedbz_crv4 -128 128 0 1 1
  ( 128 128 0 ) ( 0 128 0 ) ( 0 256 0 ) speedbz_crv4 -128 128 90 1 1
 }
 {
  ( 0 128 0 ) ( 0 0 0 ) ( 0 0 -32 ) speedbz_crv4 0 -32 0 1 1
  ( 128 128 -32 ) ( 128 0 -32 ) ( 128 0 0 ) speedbz_crv4 0 -32 0 1 1
  ( 128 0 -32 ) ( 0 0 -32 ) ( 0 0 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 128 0 ) ( 0 128 0 ) ( 0 128 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 128 -32 ) ( 0 128 -32 ) ( 0 0 -32 ) speedbz_crv4 -128 0 0 1 1
  ( 128 0 0 ) ( 0 0 0 ) ( 0 128 0 ) speedbz_crv4 -128 0 180 1 1
 }
 {
  ( 128 128 0 ) ( 128 0 0 ) ( 128 0 -32 ) speedbz_crv4 0 -32 0 1 1
  ( 256 128 -32 ) ( 256 0 -32 ) ( 256 0 0 ) speedbz_crv4 0 -32 0 1 1
  ( 256 0 -32 ) ( 128 0 -32 ) ( 128 0 0 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 128 0 ) ( 128 128 0 ) ( 128 128 -32 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 128 -32 ) ( 128 128 -32 ) ( 128 0 -32 ) speedbz_crv4 -256 0 0 1 1
  ( 256 0 0 ) ( 128 0 0 ) ( 128 128 0 ) speedbz_crv4 -256 0 270 1 1
 }
 {
  ( 128 0 0 ) ( 128 -96 0 ) ( 128 -96 -32 ) speedbz_crv4 128 -32 0 1 1
  ( 256 0 -32 ) ( 256 -96 -32 ) ( 256 -96 0 ) speedbz_crv4 128 -32 0 1 1
  ( 256 -96 -32 ) ( 128 -96 -32 ) ( 128 -96 0 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 0 0 ) ( 128 0 0 ) ( 128 0 -32 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 0 -32 ) ( 128 0 -32 ) ( 128 -96 -32 ) speedbz_crv4 -256 -128 0 1 1
  ( 256 -96 0 ) ( 128 -96 0 ) ( 128 0 0 ) speedbz_crv4 -256 -128 0 1 1
 }
 {
  ( 0 -96 0 ) ( 0 -128 0 ) ( 0 -128 -32 ) speedbz_crv4 128 -32 0 1 1
  ( 96 -96 -32 ) ( 96 -128 -32 ) ( 96 -128 0 ) speedbz_crv4 128 -32 0 1 1
  ( 96 -128 -32 ) ( 0 -128 -32 ) ( 0 -128 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 96 -96 0 ) ( 0 -96 0 ) ( 0 -96 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 96 -96 -32 ) ( 0 -96 -32 ) ( 0 -128 -32 ) speedbz_crv4 -128 -128 0 1 1
  ( 96 -128 0 ) ( 0 -128 0 ) ( 0 -96 0 ) speedbz_crv4 128 128 90 1 1
 }
 {
  ( 0 -160 0 ) ( 0 -256 0 ) ( 0 -256 -32 ) speedbz_crv4 256 -32 0 1 1
  ( 128 -160 -32 ) ( 128 -256 -32 ) ( 128 -256 0 ) speedbz_crv4 256 -32 0 1 1
  ( 128 -256 -32 ) ( 0 -256 -32 ) ( 0 -256 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 -160 0 ) ( 0 -160 0 ) ( 0 -160 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 -160 -32 ) ( 0 -160 -32 ) ( 0 -256 -32 ) speedbz_crv4 -128 -256 0 1 1
  ( 128 -256 0 ) ( 0 -256 0 ) ( 0 -160 0 ) speedbz_crv4 -128 256 180 1 1
 }
 {
  ( 160 -128 0 ) ( 160 -160 0 ) ( 160 -160 -32 ) speedbz_crv4 256 -32 0 1 1
  ( 256 -128 -32 ) ( 256 -160 -32 ) ( 256 -160 0 ) speedbz_crv4 256 -32 0 1 1
  ( 256 -160 -32 ) ( 160 -160 -32 ) ( 160 -160 0 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 -128 0 ) ( 160 -128 0 ) ( 160 -128 -32 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 -128 -32 ) ( 160 -128 -32 ) ( 160 -160 -32 ) speedbz_crv4 -256 -256 0 1 1
  ( 256 -160 0 ) ( 160 -160 0 ) ( 160 -128 0 ) speedbz_crv4 -512 0 270 1 1
 }
 {
  ( 160 -96 0 ) ( 160 -128 0 ) ( 160 -128 -32 ) speedbz_crv4 128 -32 0 1 1
  ( 256 -96 -32 ) ( 256 -128 -32 ) ( 256 -128 0 ) speedbz_crv4 128 -32 0 1 1
  ( 256 -128 -32 ) ( 160 -128 -32 ) ( 160 -128 0 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 -96 0 ) ( 160 -96 0 ) ( 160 -96 -32 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 -96 -32 ) ( 160 -96 -32 ) ( 160 -128 -32 ) speedbz_crv4 -256 -128 0 1 1
  ( 256 -128 0 ) ( 160 -128 0 ) ( 160 -96 0 ) speedbz_crv4 -256 -128 0 1 1
 }
 {
  ( 128 -160 0 ) ( 128 -256 0 ) ( 128 -256 -32 ) speedbz_crv4 256 -32 0 1 1
  ( 256 -160 -32 ) ( 256 -256 -32 ) ( 256 -256 0 ) speedbz_crv4 256 -32 0 1 1
  ( 256 -256 -32 ) ( 128 -256 -32 ) ( 128 -256 0 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 -160 0 ) ( 128 -160 0 ) ( 128 -160 -32 ) speedbz_crv4 -256 -32 0 1 1
  ( 256 -160 -32 ) ( 128 -160 -32 ) ( 128 -256 -32 ) speedbz_crv4 -256 -256 0 1 1
  ( 256 -256 0 ) ( 128 -256 0 ) ( 128 -160 0 ) speedbz_crv4 -512 0 270 1 1
 }
 {
  ( 0 0 0 ) ( 0 -96 0 ) ( 0 -96 -32 ) speedbz_crv4 128 -32 0 1 1
  ( 128 0 -32 ) ( 128 -96 -32 ) ( 128 -96 0 ) speedbz_crv4 128 -32 0 1 1
  ( 128 -96 -32 ) ( 0 -96 -32 ) ( 0 -96 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 0 0 ) ( 0 0 0 ) ( 0 0 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 128 0 -32 ) ( 0 0 -32 ) ( 0 -96 -32 ) speedbz_crv4 -128 -128 0 1 1
  ( 128 -96 0 ) ( 0 -96 0 ) ( 0 0 0 ) speedbz_crv4 128 128 90 1 1
 }
 {
  ( 0 -128 0 ) ( 0 -160 0 ) ( 0 -160 -32 ) speedbz_crv4 256 -32 0 1 1
  ( 96 -128 -32 ) ( 96 -160 -32 ) ( 96 -160 0 ) speedbz_crv4 256 -32 0 1 1
  ( 96 -160 -32 ) ( 0 -160 -32 ) ( 0 -160 0 ) speedbz_crv4 -128 -32 0 1 1
  ( 96 -128 0 ) ( 0 -128 0 ) ( 0 -128 -32 ) speedbz_crv4 -128 -32 0 1 1
  ( 96 -128 -32 ) ( 0 -128 -32 ) ( 0 -160 -32 ) speedbz_crv4 -128 -256 0 1 1
  ( 96 -160 0 ) ( 0 -160 0 ) ( 0 -128 0 ) speedbz_crv4 -128 256 180 1 1
 }
(...)

[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 a way.

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