Static reflections issues

[VReaperV]

This is to keep track of issues with static cubemap reflections, since there's multiple of them.

To enable reflections, use /r_normalMapping 1; r_deluxeMapping 1; r_specularMapping 1; r_reflectionMapping 1; r_physicalMapping 0/, then /buildcubemaps. Material system currently also won't select the correct cubemaps since that requires the core feature to work properly first. Use /r_showCubeProbs 1 to see where they are placed.

Primary issues:

• Cubemap placement is broken:
  
  
  This issue is mostly fixed now by converting the probe lookup to use a grid instead, but the selection of cube probes and where they're placed still needs to be improved.
• The nearest cubemap is not selected correctly most of the time: usually it's not found at all, you have to get really close to a probe for it to work. This can be easily seen with r_showCubeProbs 1, which highlights the nearest and second nearest probes.
• The second nearest cubemap seems to never be selected at all.
• Doesn't work with PBR at all.
• All cubemaps are rendered as pitch black or all white (mostly the former).
• It should be possible to view the actual contents of cubemaps when using r_showCubeMaps 1.

Secondary issues:

• The required cvar combinations to use static reflections are unclear unless you look at the code.
• Cubemaps can only be built after loading a map.
• Cubemaps are not cached.

[VReaperV]

Perhaps it's better to distribute cubemaps more uniformly and access them through e. g. an octree. When building the cubemaps we'd need to somehow check if each spot is "inside" the map.

[slipher]

The second nearest cubemap seems to never be selected at all.

It can happen. It's just rare because the lookup only checks a 100x100x100 box and the probes are too sparsely distributed. In most voxels there isn't even one.

[VReaperV]

Increasing the area it checks did indeed make the second lookup yield some probes.

[VReaperV]

On map thermal, for example:
5 probes together in a space that you can't even go to without noclip:

Here most probes are in the same area, yet there are none above the platform:

And here you can see how the probes are bunched up to one side:

The current algorithm used to place probes just goes through every BSP node and places the probes there. It attempts to skip nodes in the void, but fails to actually do so.

[VReaperV]

A few possible solutions to that:

1. Place probes on a grid. For better distribution, we can still use the loop over BSP, but "snap" the probes to the grid.
2. We can use the solution for shadow-castng lights reconstruction proposed in Possible solution to reconstruct light entities from lightmaps #1298 to find voxels (or, indeed, places on a grid) that have the most light rays going through them and perhaps distance to surfaces (i. e. a voxel that is close to some surfaces is less likely to be a probe candidate).
3. There's also this paper: https://www.cs.cit.tum.de/fileadmin/w00cfj/cg/Research/Publications/2011/Assisted_environment_probe_placement/aepp.pdf, which explores the use of a combination of irradiance fields and image comparison to remove extra probes.

[VReaperV]

Placing probes on a grid would also speed the lookup up by a lot, since right now it's quite slow while at the same time not even finding any probes a lot of the time.

[VReaperV]

Something like 128 or 256 seems to be a reasonable probe spacing that balances the amount and distribution. With 128 some of the largest maps that we have (e. g. https://users.unvanquished.net/~sweet/pkg/map-voxelworld0_0.dpk) it'd only be a ~500 KB array. On regular maps it will be something like ~138 KB on the larger maps. We can also just put it in a cvar or parse it as an optional keyword in worldspawn.

[slipher]

Did you mean MB? If a probe uses 6 * 32*32 * 3 bytes that's 18K so you could only store a handful of them with that much memory.

[VReaperV]

Did you mean MB? If a probe uses 6 * 32*32 * 3 bytes that's 18K so you could only store a handful of them with that much memory.

I meant for the lookup array. That array would just have an index corresponding to a cubemap, and different elements of that array can point to the same cubemap. The point of using it is to make the lookup fast.

[VReaperV]

Cubemaps can only be built after loading a map.
I don't quite remember what I meant by that, but probably that cubemaps can't be distributed in a dpk. Given the features added on #1355 this seems infeasible:

• Probe placement and quality can be changed, and this requires rebuilding them.
• If probe placement and quality become independent of user settings, this can be changed, but so far that is not planned.
• Cubemaps would take up way too much space as they currently, resulting in drastically increased download times, and more memory required to run a server with such feature.