Item save glitch

My memory of portal physics is a bit fuzzy. So some of this might be less than useful or outright incorrect. And I have no particularly strong desire to refamiliarize myself with the system at the moment.

The bouncy behavior most definitely seems like the work of the penetration solver in the physics system. It acts as a backup system to normal collision events. It works by detecting when 2 solid hulls are intersecting each other. Which should be theoretically impossible, so we're already in a situation with no "correct" solution.

To separate them, we apply a separating force (the bounciness of the chairs) to each. And since the world is "static", all the force is applied to the dynamic object. I believe we have to immediately mark the two object as not colliding with each other during that period so they can actually move away from each other. And at some point (a full second maybe?), the solver just gives up. I believe, but I'm not sure, that it just marks the two objects as not colliding with each other forever.

Portals cause penetration problems all the time due to constantly changing which objects collide with each other. It does this because we're trying to get objects in front of a portal to pass through objects on the other side of a thin wall (and pass through the wall itself).

One of the core problems with maintaining those collisions is that we cannot  properly solve for any concave shape, take a big letter "U" for example, that has one portion inside the portal, and one portion reaching behind the portal plane but outside the portal oval. If we were to imagine a large plank behind a thin wall behind the portal. We can easily imagine the case where the leg of the "U" inside the portal should not collide with the plank, but the leg outside the oval most definitely should collide with the portal. In portal we make the assumption that all objects are convex and that makes the intersection logic easier because we know that if any part of the object is intersecting the portal oval, then the rest of the object must be in front of the portal.

That still has the breakdown case of a portal at the edge of a wall. When the cube is visually cut in half, that's an indicator that the portal believes the object is intersecting the portal oval. The visual system can only apply a single plane with which to hide portions of the object.

When you bring the radio in from behind the portal plane. The collision system definitely believes the two objects should not collide. But as it transitions to being in front of the portal plane, the system changes its mind, but the two objects are already intersecting. So it immediately has to run the penetration solver on the two. But since the radio is held, it can't be forced out of the cube leading to an easy scenario for the solver to give up.

I'm not entirely sure why the solver gave up on trying to have the cube intersect with the world. But I believe it's rest by the loading of a save game which makes the cube solid again on the second part of the second video.

Anyway, I know that wasn't particularly useful, but that's sort of a brain dump of what's going on.

-Dave