Singh D brought up this issue with the Cochem castle.

[Peter Grosserhode]

During the initial testing of the Cochem Castle model, the viewer suffered from severe navigation constraints because the model’s coordinate center (pivot point) was offset from the actual physical structure. This alignment mismatch caused the camera's orbit logic to stall, locking up the zoom and freeze-framing the two-finger panning sensitivity when approaching the castle. Compounding this, the camera controls felt counter-intuitive because the one-finger rotation direction was set to a camera-centric view instead of a model-centric "globe" rotation, meaning swiping left moved the scene to the right. Furthermore, any attempt to zoom in close triggered strict near-plane clipping parameters and high-pass filters, which instantly vaporized the stone walls or smeared them with blur.

To resolve these flight limits, the camera math was completely overhauled through a series of rapid-fire code iterations. The one-finger rotation axis was inverted (cam.az += dx) so that the castle now moves naturally with the drag of a finger, and the panning floor speed was boosted 2.5x to keep close-up navigation fast and responsive. Crucially, the zoom logic was rewritten into a "two-speed" dolly zoom that seamlessly transitions from proportional orbit zooming to a constant, pixel-based translation once the camera gets within $0.025$ units of the target. By combining this dynamic forward flight with drastically lowered near-cull clipping boundaries and a reduced low-pass filter, the "invisible wall" was mostly demolished. The latest version of the viewer that allows users to seamlessly orbit, pan, and fly  through the castle walls. Initially it slows the zoom and when it changes the method when closer in, it will zoom very fast. Not perfect yet but I spend pretty much all day on this and will improve together with other updates and improvements from your feedback.