Implement proper collisional portal system

[vvs-]

In Temple of the Cat geometry should be passable from room 81 sector 3,2 to room 69 sector 1,4, but not vice versa.

[Lwmte]

Impossible to fix with current physics model.

[Lwmte]

The whole problem here is current collisional approach is "sewing" together all the rooms, leaving passages where the doors should be. While I and TeslaRus initially thought it's going to work, eventually it didn't. There are few examples for this, particularly this ticket and #11.

What may work is emulating original collisional approach, when each entity bear particular room ID, and only this room ID is processed for collision. When room is switched via portal sector, collision filter is re-applied and entity uses new room ID mesh for collisions.

The problem here, is we potentially have lots of entities in a level, and each entity must process its own collisional routines. Not all of them, but at least dynamic ones - boulders, ragdolls, activated Damocles swords, etc. Also, entities may not overlap when placed in different overlapped rooms. So we must think of a way to process each entity's collision on an individual basis, regarding its current room ID.

We may re-use current collisional room mesh generator for actual heightmap calculation, but that part of code which generates room borders and doors has to go.

[T4Larson]

Overlapping rooms seem to be pretty frequent throughout the levels, I've recently been flipped into the wrong room in hall.tr4 some times... I remember having read that CrystalSpace had similar problems using Bullet. Since it is a portal-engine, it would also allow overlapping rooms - it seems they are going to tackle this with an extra plugin: See http://www.crystalspace3d.org/docs/online/manual/Physics-Bullet.html :

At least one dynamic system should therefore be created. Usually, one would need one dynamic system per Crystal Space sector, the problem being to switch the dynamic systems when an object crosses a portal. This is not yet made automatically by the ‘Bullet’ plugin, this is however a feature of the WIP ‘physics2’ plugin.

IMO to get this right in OpenTomb, it is necessary to track each entities current room number (almost as the old engine does it), and probably for every raycast, to ensure the collision is filtered for the correct set of neighbouring rooms...

[Lwmte]

Hmm, so unfortunately it's Bullet who limits us here... But surely Erwin Coumans didn't take ancient sector-based pseudo-portalized engine into account when he programmed his physics! :laughing:

It may be not so serious. Currently, wrong room warping and/or camera warping happens because FindPosCogerrence function works or applied incorrectly. In all other cases, it works normally. Even UFO in Area 51 is processed correctly (execpt two tiny bugs). There should be a strict rule not to go into overlapping rooms until entity or camera passes through a portal sector pointing to exactly that particular room, and this should do the trick.

However, current collisional (not portal) approach is much more "half-baked". TeslaRus began to write his engine without taking collisional portal features into account, and in the process we made it (sorta) working by "sewing" all interconnected doors together. But it doesn't work in "special" cases, like #11 or case described in this issue.

So to solve this, we need to get rid of "sewing together" doors, and instead make each room isolated, but when an entity travels through the collisional portal, it should be forcibly transfered to another room. While it should be relatively easy to do with horizontal portals (since there is a "physical" door sector on which Lara can step), vertical portals may be much more difficult. We may remove collision from vertical portals, so Lara successfully travels through them, but at the same time we need to check her position related to floor/ceiling levels of this particular sector. If she's below floor level or above ceiling level, we must force her to transfer to another room.

And I'll say again, current heightmap terrain generator works almost perfectly (except some triangulation bugs, like #231), so we don't need to touch it again. Only collisional portals are causing major pain here.

[vvs-]

Related to #367.