That branch decodes REGN as a tetrahedral navmesh with strong checks and claims the POF0 fixup base is chunk+0x10, so every offset on this page was read 16 bytes early. I could not reproduce that on the one independently checkable thing here: the plane list gives 133573/133573 unit normals at the unshifted base and 0/133573 at +16, and n.p+d = 0 holds to float round-off unshifted. A 16-byte shift destroys it, so the blanket statement does not hold for this record. Likely reconciliation is bookkeeping: a 48-byte face whose plane fields sit at a different intra-record offset addresses the same bytes from a different origin. That is a guess and I am not adopting either wording until checked. Also confirmed: my own section-0 point test passes at 100% at BOTH bases, so it never had power to distinguish them and should not be cited as validating the offsets.