-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returning mesh faces #33
Comments
One thing I'd be wary of is what happens when it hits an edge or vertex - already a dicey situation #3 . On the rust side, the library knows whether it's a face, edge, or vertex which has been hit (and the index of it), so if there's a nice way to express that to the python user we could use that but otherwise it's a whole other array to return. Returning all faces means a ragged array which isn't as nice to cross the rust/python barrier with. Is this whole algorithm, or some subset of it something broadly useful enough to go in the library directly, or at least to make a distinct-enough method? |
Edges are are also dicey in embree (I think they just don't count as a hit, actually, at least in standard 'performance' mode), but a nice thing about SDF is that you cast a lot of rays and average them so unless you're very, very unlucky you can throw out outliers. I think if I were in your shoes, I'd make this an optional output and return both I'm borrowing the algorithm itself from CGAL, but the advantage of doing the implementation myself is that I can only run it on a subset of the mesh (e.g. along a path along the mesh) for performance, since neuronal meshes can be very large and radii are smoothly varying. I'd be more than happy to just call an SDF function, though, if you wanted to implement it! All I'd ask is that having an optional list of vertices to compute SDF from would be handy. |
Looks like the underlying rust library will return the normal directly, so a more useful function for your use case might be something with the same arguments as |
The dot product of the ray with the face normal would be amazing, even better for this purpose! I think the feature type sounds generally useful, but obviously that would be important depending on how the dot product is returned for such values. My SDF implementation is here on the meshparty repo. I'd also recommend reading the CGAL documentation, as I'm sure there are some implementation decisions one has to make and I wouldn't be surprised if I cut a corner or two relative to the CGAL version, since my use case was fairly specific. |
Ah yes, that looks a bit more involved than I have time for at the moment - how about a private(ish) method:
Because in this case we expect most of the rays to intersect and all we'd be using the feature ID and intersection location for is to get the distance and dot norm anyway. Then your python could hook into that (ideally to be upstreamed here). |
That would be awesome, I would use that immediately! |
Not to put myself out of a job, but if you haven't checked it out already it may be worth looking into embreex in case it saves a larger porting effort. As it stands, though, I've got a PR up #34 with this internal method - if you have any test data from your current implementation that would be handy to have. |
I have no clue how I missed that, having made a number of searches for exactly something like that. Thanks for the link. That said, I also like the idea of not having Intel in the loop given that a cursory search suggests they aren't working too hard on Apple Silicon optimization. It's not urgent, nor would it be more than a couple of line tweak for porting, so I think it'll be fun to port over to what you've been working on. Plus it's always nice to work with those you know. :) |
Thanks for making this package! I think we're going to start using it more and more.
One thing that I'd like to use this package for is to compute the shape diameter function for vertices on a mesh. The way I had been doing it with pyembree (RIP), involved casting a cone of rays from each mesh vertex inward to the other side. I then want to weight the rays by the dot product of the ray with the face normal that it hits (i.e. I want to weight 90-degree hits more heavily than glancing hits). With pyembree, this was easy because the ray intersector class returned the index of the mesh face that was hit. Here, I get the locations but no face index. This can probably be massaged to do what I want, but would it be possible to add the mesh face index to the responses in Volume.intersects, in addition to the exact location point?
The text was updated successfully, but these errors were encountered: