DP_EF_NODEPTHTEST

[Ghost_Fang]

Quick question about DP_EF_NODEPTHTEST, does or can Darkplaces detect whether or not its rendering an entity with this effect through walls or not? Like if its rendering through a wall, could it be known to the engine so I could give the entity a different effect for being shown through walls. Or could this effect be achieved through some other way? The goal is to get all the clients (or frikbots) to always been seen even through walls, much like Left 4 Dead does, but with an outline or a sort of wireframe possibly. Or am I looking more towards some CSQC to get this effect?

EDIT: Hmmm, my mistake, wrong subforum, meant to put this in engine...

[Baker]

[Spike]

you need a shader with a weird depthtest flag, so that its only drawn if its obscured, with your normal model drawn if it isn't obscured. But note that you may need to pay attention to drawing order/shader sorting to avoid drawing it behind fleshy objects.

the engine doesn't know if its obscured, and even if it is obscured, it might not be fully obscured. checking if the entire thing is obscured is a little slow, and probably not very useful (unless you want a corona?..).

[Arkage]

What about checking with a traceline? I
If it makes it all the way remove the effect otherwise add the effect. Should be able to do it in CSQC too.

[Spike]

tracelines won't work correctly for partially obscured entities.

[Ghost_Fang]

Hmmmm that would work wouldn't it? Like make a traceline check using find(), loop it, and sending a traceline from origin to the other 3 player's origin found using find(). Is that how I would go about doing it? That would even work with SSQC.

Thanks arkage

[Ghost_Fang]

[Arkage]

Ah yea, what about trace-box then?

[Ghost_Fang]

[Spike]

[r00k]

[mh]

Traces are also incredibly expensive operations - you certainly don't want to be doing too many of them. (You have a problem, you say "I know, I'll use traceline", now you have two problems.)

[mh]

[Baker]

[Spike]

BSP code is fairly straight forward really, the complications come from precision.
See the pointcontents code for a primer - it just goes down through the tree until it finds the leaf.
Well, traces are basically the same, except they have two points.
Go down the tree, favouring the start side every time, so that you can early out properly. When you've got a node between the points, it has to go down both. If its solid on the other side of the node (quake actually uses a pointcontentsalike for that) then you have an impact, figure out the fraction and return up the tree to the caller.
There's quite a few things that make this costly.
1: Its a tree, which has hopefully been balanced somewhat to try to limit the maximum cost. On huge maps, this can still get quite high.
2: the balancing probably left node positions with somewhat random ordering so each node will give you a new cache miss... or more... cache misses are slow, and they get slower (proportionally) the faster the cpu is.
3: Trees suffer from the same inefficincy as lists, that is ptr = ptr->next; foo = ptr->field; contains a memory fetch in the first statement with the second directly depending upon its result. The cpu has to wait on the result of the first before it can evaluate the second. When iterating a list, the index is already in a register, thus idx = idx + 1; has no memory fetch, thus the second instruction no longer needs to wait for as long. X86 CPUs can generally reorder instructions with some small tolerances, but its not magic.
4: quake uses pointcontents to determine solidity on the other side of the node! this means that for every node, its walking down its immediate children twice... 5 nodes means that its walking down to the same leaf 32 times! A couple of engines have a fix for this, but the precision aspect makes it clumsy. Really though this issue isn't quite as bad as it sounds - those nodes will at least be cached.
A couple of engines have a fix for this, but its still fairly expensive.
5: It uses floating point. Floating point operations are more expensive than integer operations. An x86 has multiple floating point units nowadays and can crunch multiple numbers simultaneously to reduce the effective cost down to only a couple of cycles, assuming the compiler can interleave enough integer operations in there to give the float operations time to finish. An ARM chip often doesn't actually have an FPU and thus quite a lot of programs for arm are built to emulate floats with ints... which is rather slow (but faster than compiling for an FPU and having the operating system emulate it whenever it detects an illegal instruction...).

anyway, tracelines are slow. 1000 a frame and you'll notice, and have people shouting at you, even with a fixed/optimised traceline.
[ontopic]
tracelines are slow, you can add some timer and recalculate it only every halfsecond or so, but that gets awkward in tracking *which* player can see each marker, which requires at least two .floats for quakeworld (only one for NQ's traditional max of 16 players, which kinda highlights the awkwardness of tracking players with a bitmask).
[/ontopic]