trap_R_inPVVS is not used

[illwieckz]

Thetrap_R_inPVVS function is not used, I don't know if we want to keep it for potential modes being ported to Dæmon, but actually this is just something not used by Unvanquished.

[illwieckz]

I've just checked ioq3, Smokin'Guns, RTCW, ET:Legacy, q3rally, OpenJK and WorldOfPadman and while all have a trap_R_inPVS function like us, none of them actually define trap_R_inPVVS and then don't make use of it. UrbanTerror used ioq3 or proprietary q3 one so we are safe to say they didn't used trap_R_inPVVS, and mods like True Combat or ET:Fortress could not use it if the engine didn't have it. I seen that Spearmint don't have it either, which excludes Turtle Arena at the same time.

[illwieckz]

And none of XreaL, ET-XreaL, and RBQUAKE-3 have trap_R_inPVVS. Same for Qio and various OpenWolf trees I grepped.

[illwieckz]

commit c761047
Author: Matthias Bentrup <***@***>
Date: Sun Nov 4 16:25:58 2012 +0100

Add visvis calculation and cgame trap.

Visvis is similar to vis, but while vis indicates if there is a direct
line of sight between two clusters, visvis indicates that there is an
indirect line of sight (i.e. there is a common point from where there are
lines of sight to both clusters).

The computation of visvis used here is not geometrically exact, but if
it differs from the definition given above, it's always the case that
it may indicate an indirect invisibility where none exists, so it is
still safe to use it for culling. In practise the differences are not
important.

I wonder what's for. Maybe we can make use of this feature for some interesting trick, but for now it's not used.

[slipher]

According to Git history, alien sense blips and old human radar could only detect entities in the PVVS.

[illwieckz]

Ah, that's an useful feature then. I would like to have blips, at least as an option.

[DolceTriade]

PVVS would also be useful for bot calculations to rank targets

[Viech]

If I remember correctly, PVVS in practice felt just random. PVS is already a crude outer approximation for the visible set: it's normal that it allows you to "see" through heavy walls. PVVS would be even larger and could extend to parts of a map that are hardly connected. I wouldn't be surprised if it incorporates most of a map, or an arbitrarily large portion of it. I see no good use for it, and it could be demanding computationally.

[DolceTriade]

Note that PVVS is a one time computation just like PVS (at least that's how I understand it...)

[slipher]

I'd say delete it since if we want to do it again we should do it in the gamelogic without a trap call. There's already e.g. G_CM_inPVS

[Viech]

Note that PVVS is a one time computation just like PVS (at least that's how I understand it...)

It still produces a dense graph, possibly the initial computation (on every map load?) could produce a lag and the queries could be slower than for PVS.

[VReaperV]

This sounds like it could be useful to cull shadow-casting lights, but IIRC the old shadowmap code does something else to ensure correct culling. It's also probably easier to just cull light frustum or sphere (or possibly a parallelepiped for directional lights).

[VReaperV]

The trap call is slated for removal, see Unvanquished/Unvanquished#3157. The engine functionality is something I'll evaluate for shadowmaps.

[VReaperV]

Done in #1428. The remaining engine functionality is being tracked in #1209.