search

opentomb / OpenTomb

An open-source Tomb Raider 1-5 engine remake
http://opentomb.github.io/
GNU Lesser General Public License v3.0
1.38k stars 143 forks source link

Collision test is highly unstable #234

Open stohrendorf opened 9 years ago

stohrendorf commented 9 years ago

Particulary the ray test is the root for many collisions problems when you run over surfaces with small gaps with a high FPS, as the probability of the ray shooting into the gaps and putting lara into free-fall mode is very high. You can experience this in Caves on the plank bridges when you can get OpenTomb to run at (I guess) more than 300 FPS. Lara constantly goes to free-fall mode when running over the gaps between the bridge tiles. It occassionally happens already at about 80-100 FPS.

Also, a higher frame rate seems to be responsible for the shimmying bug, where Lara stops at "virtual" obstacles; with low FPS, the collision boxes "jump over" the edges between triangles, while at high FPS, they usually get caught there.

vvs- commented 9 years ago

It happens even at 60 FPS.

Lwmte commented 9 years ago

Confirmed, I have buggy bridges as well.

Generally, physics code is very asynchronous with animations, and no any special workarounds are used to compensate "losing" physical time; it happens not only with high FPS, but with low FPS as well. If framerate drops below 60, lots of funny bugs may happen - like Lara stuck at falling state right above the floor, etc.

stohrendorf commented 9 years ago

I have hacked around a bit by replacing all simple ray tests with convex sweep tests, using a btSphereShape with a radius of 16, and the shimmying and "free fall" bugs disappeared. Unfortunately, she now stumbles down even the slightest height difference, and sometimes refuses to step up little heights, but I guess these problems can be solved by refining (not necessarily refactoring) checkNextStep.

Gh0stBlade commented 9 years ago

I believe the whole collision system has many flaws. Especially when it comes to jumping, grabbing ledges. Lara should slide down geometry regardless, in some cases she can actually appear ontop of ledges or even switch to a completely different state.

I have no clue how the original collision system worked, I thought it was basic collision boxes, nothing complex. However, OpenTomb seems to have a collision mesh for each part of Lara's body last time I checked? Is this correct? Will it turn out the same? I think one of the biggest issues right now is the collision system.

vvs- commented 9 years ago

As far as I understand, Lara has collision checks on the model, then she has a collision mesh and yet she has ghost objects. So, she has three different types of collisions. Additionally she has hardcoded logic like in Character::checkNextStep.

The problem is that animations are hardcoded and have no collision checks at all. All collision checks are performed asynchronously and then the rigid body is updated from rendered model. Otherwise there would be too many glitches and incompatibilities with the original.

stohrendorf commented 9 years ago

I remember reading an interview with a TR developer some years ago who talked about how the collision system actually worked and why it sometimes was a bit buggy. I tried to find it, but without luck. Yet I remember that there was basically no real collision system, but rather some sort of "ray cast 2D" system working with only the sector information, which caused Lara to penetrate walls, especially when diving.

vvs- commented 9 years ago

OpenTomb has the same sort of problems until recently when collision system was overhauled. Then it changed again several times.

It should be fairly simple to recreate an original collision system which doesn't use real geometry. But OpenTomb aims at being a superior engine far beyond that.

Lwmte commented 9 years ago

True, there is no "real" collision system in classic Tomb Raiders. "Soft" collisions with static objects and entities are not counted - there are completely different routines for them (actually, each entity has its own collision check routine assigned, which is silly).

This is the reason why TRs generally had no way to stand on top of entities. Even pushable blocks modify sector height information to appear "solid". And each trapdoor/crumbling floor/etc. MUST have had either dummy or any other type of trigger below them, so "collision" calculation function is called.

Funny thing that corner bug and all of its variations is only possible with classic collision setup. They had a breakout code which pushed Lara at the floor level in case her own coordinate was way lower than floor coordinate.

Similar breakout code was done for "illegal" sector heights (i. e. walls, illegal doors, etc.) - it forced Lara to smash and stop, like she collided with something, albeit there was no "real" collision there - which made possible such setups as #11. Unfortunately, we should either reproduce original behaviour, or somehow modify current physics model to make it properly work.