Possible Darkplaces bug ?

[LordHavoc]

[taniwha]

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

[jitspoe]

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

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

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