Correct calculation in ProjectPointToPlane (backport #702) #703
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🦟 Bug fix
Summary
Use unit normal for projection in
gz::math::ProjectPointToPlane
.Before this change the function used the unnormalised normal to calculated the projection of the interpolation point onto one of the grid parallelpiped surfaces. This caused the
gz::math::TrilinearInterpolate
to return an incorrect interpolated value. These functions are used in theTimeVaryingVolumetricGrid
, which in turn is used by the Environment system. The upshot is that this system incorrectly interpolates data whenever the trilinear interpolant is used. It is apparent when examining volumetric data using the PointCloud GUI widget, as the ranges displayed in the widget do not correspond to the underlying data provided to the Environment preload system.After this change the PointCloud display is consistent with the input data.
The unit test
InterpolationPoint_TEST
does not catch this case, because the data is provided for a unit cube, and the normals calculated for this cube all have unit length, so the effect of scaling the normal is not tested. This is also the case for the environmental system tests in gz-sim. It may be better to use non-unit grids for testing systems that involve geometric calculations involving vector operations that depend on normalisation.There is a work-in-progress example here (https://github.com/srmainwaring/gz-math/tree/prs/volumetric-grid-example) that highlights the issue for a 4 x 4 x 4 grid sampled from a wind field.
Checklist
codecheck
passed (See contributing)Generated-by: Remove this if GenAI was not used.
Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
andGenerated-by
messages.This is an automatic backport of pull request #702 done by Mergify.