Make portals usable and intuitive

[madblade]

Portals

Two different portal guns should be available:
One that opens a window that is automatically linked to another world (implemented).
One that links two portal ends (p1p2) on-demand (like in Valve’s game, not yet implemented).

Needed to make the system robust and usable

A rendering system that solves some level of portal recursion, and also that uses stencil masks for performance, is already available, but the following bricks are still missing.
These are somewhat long-term bricks:

• two portals linking in the same scene/world

• on-demand portals (p1p2)

• portal camera rotation, when p1’s rotation differs form p2’s

• compute the chain transformation for recursive rendering: position (trivial) + rotation (less trivial)

• compatibility with scene shadows (this will be tough to get working)

Needed first

These are the more "pressing" issues:

• Performance: (This is a bug!) combining self-model interpolation + world switch. The self-model position is updated every server tick, and smoothly interpolated client-wise. But when a world-switch update is received client-wise, the world switch happens at the next render (so no interpolation takes place, and there will be a small jump!) The client should instead continue interpolating, for a few frames (~48ms), until the portal collision is detected client-wise and the scene switch can take place, at the exact right frame.

Therefore we need client-wise portal collision detection (just copy the code from the server), and to check for portal collision in the interpolation routine, when a flag needsToSwitchScene is set.

• Performance: pre-allocate scenes, render target and composers to avoid lag when crossing a portal for the first time.

• Make a portal helper (with the raycaster on close chunks).

[madblade]

Fixed scene switch compatibility with the interpolation routine!
(This does not need to be done for other entities, just for the main camera).

[madblade]

Update:
There is a performance issue that prevents the efficient use of portals in a single scene (in other words, rendering multiple times the same scene from different camera positions). This also applies to water reflection.

Materials are being unnecessarily rebuilt at every frame by Three, slowing down the render call (experimentally by a factor > 2). More about it here:
mrdoob/three.js#14121

Portals linking between the same scene won’t be available before this performance issue is addressed.

[madblade]

Removed support for water reflexion in Firefox due to this.
Perhaps there should be an option to build materials only once?

[madblade]

So there is a workaround to fix this performance issue: do material instancing.

• create 2 material instances for each world (scene) with m.clone()
• store them as a map (wid -> mat1, mat2)
• for each object, switch between materials before each 'water camera' render
• switch back after rendering

(-> 3x speedup!)

Similarly, for looping portals, use as many different materials as there are different portal cameras:

• create a new material linked to the screen composer
• switch materials before and after every bufferRender in renderer.js
• investigate the 1f latency / (stencil scene?) and jittering artifact
• don’t forget the copy/fxaa pass

[madblade]

Fixed water reflection performance in 7ec5b19 (this also fixes the 1-frame latency for 1-involution portals!)

Remaining to do:

• Portal transforms (rotation + position)
• Bindings for conservation laws in the physics engine (notably enforce new player rotation)
• Fix collision detection in cubic worlds

(perf:)

• getConnectivity BFS performance / cache