Skip to content

Conversation

@mugamma
Copy link
Contributor

@mugamma mugamma commented Nov 19, 2025

This PR adds the geometry we scoped during our 11/16/2025 and 11/18/2025 meetings. Specifically, the PR provides:

  1. a Vec3D type for 3D vector geometry;
  2. a Rotation type representing 3D rotations;
  3. and a Pose type representing 3D rigid transformations.

Bindings and correctness fuzz tests against scipy are available in bindings.cu and test_geometry.py, respectively. To run the tests simply run pixi run test.

@mugamma mugamma changed the title Mugamma/geometry MET-30: Implement Geometry Primitives Nov 20, 2025
@linear
Copy link

linear bot commented Nov 20, 2025

@mugamma mugamma marked this pull request as ready for review November 20, 2025 16:11
Copy link
Contributor

@horizon-blue horizon-blue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Feel free to merge whenever you feel ready :)

from scipy.spatial.transform import Rotation as Rot

from genmetaballs import _genmetaballs_bindings as _gmbb
from genmetaballs._genmetaballs_bindings import geometry as geometry
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you feel about exposing the geometry module in genmetaballs.core similar to the other binding modules?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to do this!

.def_ro("x", &Vec3D::x)
.def_ro("y", &Vec3D::y)
.def_ro("z", &Vec3D::z)
.def("__add__", static_cast<Vec3D (*)(const Vec3D, const Vec3D)>(&operator+))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dumb question: is there a reason that we're preferring the explicit type casting rather than using the nb::self + nb::self shorthands? 👀

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, I was looking at the nanobind docs and it seemed like the shorthand creates an anonymous function which calls the add. Technically, this could create one extra call frame (calling the binding calls an anonymous function that calls operator+, but here the binding directly calls operator+). I think the performance will be negligible. Will switch to this pattern.

Rotation rot_;
Vec3D tran_;

CUDA_CALLABLE Pose(const Rotation rot, const Vec3D tran) : rot_{rot}, tran_{tran} {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is really minor but I wonder if we can accept references here? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this like 7 floats? Would a reference make a difference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not by much tbh, but I guess it wouldn't hurt either? ;)

-readability-avoid-const-params-in-decls,
-readability-braces-around-statements,
-readability-isolate-declaration,
-readability-math-missing-parentheses,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I bet this linting is getting annoying haha, i'm also always adding suppressions here just to get over the dumb linting checks. Good addition!

Copy link
Contributor

@arijit-dasgupta arijit-dasgupta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! just requesting that __rmul__ fix

.def("__sub__", static_cast<Vec3D (*)(const Vec3D, const Vec3D)>(&operator-))
.def("__neg__", static_cast<Vec3D (*)(const Vec3D)>(&operator-))
.def("__mul__", static_cast<Vec3D (*)(const Vec3D, float)>(&operator*))
.def("__rmul__", static_cast<Vec3D (*)(float, const Vec3D)>(&operator*))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch on the __rmul__, it was subtle to me, however I think this binding is incorrect. I checked and Python expects it to be in the same order as __mul__. I'll make a suggestion here that works, but i'd also suggest we add tests for these methods inside of test_vec3d_ops from test_geometry.py.

Suggested change
.def("__rmul__", static_cast<Vec3D (*)(float, const Vec3D)>(&operator*))
.def("__rmul__", static_cast<Vec3D (*)(const Vec3D, float)>(&operator*))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch to you sir! Catch of the day award! I used the nanobind idiom as @horizon-blue suggested so this should be fixed now too!

@arijit-dasgupta
Copy link
Contributor

Actually, nvm, i'll approve so that you can merge asap after fixing the __rmul__

@mugamma
Copy link
Contributor Author

mugamma commented Nov 23, 2025

@arijit-dasgupta @horizon-blue I've made the following modifications based on your suggestions:

  1. The geometry primitives are now available under the core module
  2. The bindings are expressed via the nanobind operator binding paradigm (this also fixes the __rmul__ signature issue Arijit found).

@mugamma mugamma merged commit 039ba52 into master Nov 23, 2025
1 check passed
@mugamma mugamma deleted the mugamma/geometry branch November 23, 2025 02:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants