Skip to content

BUG: Fix INodeGeometry0D::getBoundingBox upper-corner initialization#1649

Merged
imikejackson merged 1 commit into
BlueQuartzSoftware:developfrom
jmarquisbq:fix/INodeGeometry0DBBMin
Jul 1, 2026
Merged

BUG: Fix INodeGeometry0D::getBoundingBox upper-corner initialization#1649
imikejackson merged 1 commit into
BlueQuartzSoftware:developfrom
jmarquisbq:fix/INodeGeometry0DBBMin

Conversation

@jmarquisbq

Copy link
Copy Markdown
Contributor

getBoundingBox() seeded the upper-right corner with std::numeric_limits::min() -- the smallest POSITIVE normal float (~1.18e-38), not the most-negative value. For any node geometry whose maximum coordinate on an axis is <= ~0 (e.g. centered at or below the origin), the max corner never updated during the vertex walk, producing a wrong/oversized bounding box. Geometries lying entirely in positive space happened to work, which masked the bug.

Seed the upper corner with std::numeric_limits::lowest() so the max is computed correctly regardless of where the geometry sits.

(cherry picked from commit f474d86)

Naming Conventions

Naming of variables should descriptive where needed. Loop Control Variables can use i if warranted. Most of these conventions are enforced through the clang-tidy and clang-format configuration files. See the file simplnx/docs/Code_Style_Guide.md for a more in depth explanation.

Filter Checklist

The help file simplnx/docs/Porting_Filters.md has documentation to help you port or write new filters. At the top is a nice checklist of items that should be noted when porting a filter.

Unit Testing

The idea of unit testing is to test the filter for proper execution and error handling. How many variations on a unit test each filter needs is entirely dependent on what the filter is doing. Generally, the variations can fall into a few categories:

  • 1 Unit test to test output from the filter against known exemplar set of data
  • 1 Unit test to test invalid input code paths that are specific to a filter. Don't test that a DataPath does not exist since that test is already performed as part of the SelectDataArrayAction.

Code Cleanup

  • No commented out code (rare exceptions to this is allowed..)
  • No API changes were made (or the changes have been approved)
  • No major design changes were made (or the changes have been approved)
  • Added test (or behavior not changed)
  • Updated API documentation (or API not changed)
  • Added license to new files (if any)
  • Added example pipelines that use the filter
  • Classes and methods are properly documented

getBoundingBox() seeded the upper-right corner with
std::numeric_limits<float>::min() -- the smallest POSITIVE normal float
(~1.18e-38), not the most-negative value. For any node geometry whose
maximum coordinate on an axis is <= ~0 (e.g. centered at or below the
origin), the max corner never updated during the vertex walk, producing a
wrong/oversized bounding box. Geometries lying entirely in positive space
happened to work, which masked the bug.

Seed the upper corner with std::numeric_limits<float>::lowest() so the
max is computed correctly regardless of where the geometry sits.

Signed-off-by: Jessica Marquis <jessica.marquis@bluequartz.net>
(cherry picked from commit f474d86)
@jmarquisbq jmarquisbq self-assigned this Jul 1, 2026
@jmarquisbq jmarquisbq added the bug Something isn't working label Jul 1, 2026
@imikejackson
imikejackson self-requested a review July 1, 2026 22:06
@imikejackson
imikejackson merged commit a31beeb into BlueQuartzSoftware:develop Jul 1, 2026
6 checks passed
@imikejackson
imikejackson deleted the fix/INodeGeometry0DBBMin branch July 1, 2026 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants