[dundysm]

fixes dimforge/rapier#1069

what

a ray parallel to a cell line of a 3d HeightField (the report uses straight down) that lands exactly on that line missed the heightfield on whole lines whenever the cell count along that axis was not a power of two.

cell_at_point computes the cell from (scaled + 0.5) / unit_cell_width, while the cell's triangles are built from -0.5 + unit_cell_width * j. the two roundings disagree right on a line, so the ray can start in the cell on the other side of the line from the triangles that contain it; both triangles miss, and since dir.x == 0 (or dir.z == 0) the traversal never steps into the neighbor. power-of-two counts divide exactly, which is why 64 x 64 never missed.

this nudges the starting cell by one when the clip point lies outside its x_at/z_at bounds, so the cell matches the triangles. rays that do cross cells still step as before.

tests

• new crates/parry3d/tests/issue_1069_heightfield_ray_cell_line.rs, mirroring the report's repro: vertical rays at every quarter-cell point of several heightfields (64 x 64, 48 x 48, 24 x 24, 16 x 48, 48 x 16, 16 x 17, plus 1 m and 0.5 m cells). on master it fails with 48 x 48 (cell size 2): 4488 rays missed, the same count as the report; with the fix every ray hits.
• cargo test -p parry3d passes (lib, integration and doc tests).

not included

• a ray exactly on the heightfield's outer boundary edge can still miss in rare cases (2 of 9409 rays for 24 x 24 at 2.5 m cells, also on master); that comes from the triangle ray test on an edge, not from cell selection.
• the 2d HeightField ray cast has a related miss when a vertical ray lands on a vertex; it needs a separate fix (segment parameter tolerance), so i left it for a follow-up.

[dundysm]

@sebcrozet fix for dimforge/rapier#1069; the heightfield ray cast now starts in the cell whose triangles actually contain the clip point, so vertical rays on cell lines stop missing. regression test reproduces the report's counts on master. would appreciate a look when you have time.