Page MenuHome

Bmesh bvh py-wrapper

Authored by Dan Eicher (dna) on Dec 24 2013, 4:58 AM.



Did a quick wrapping around BMBVHTree to test it out, everything seems to work ok (ray casting, closest vert, intersecting face) so...

Still needs doc strings and (maybe) some reorganization to better fit within the bmesh py-api.

Not really sure how to take a non-editmesh and toss it into a BMBVHTree using BKE_bmbvh_new() since I couldn't find any examples but I think that'd be a lot better way to do it -- if possible, the header's probably called editmesh_bvh for a reason...

Diff Detail

Event Timeline


BMesh depends on mathutils, theres no need to define a new float parsing function, check use of mathutils_array_parse


Id rather not depend on editmesh, it could be optional, Either use editmesh (and its looptri's), or calculate our own looptris and call with BKE_bmbvh_new, the Python Object would have to own them and free on exit.

Since we may want to use this for editmesh tools OR our own bmeshes that has no links to a blender mesh/editmesh - I think its worth supporting both.


not sure why this is done?


Prefer using PyTuple_New, PyTuple_SET_ITEM.


Prefer to return the number of args in the success case, but None, so (None, None, None)

This way you the scripter can do:

f, dist, co = bvh.ray_cast(...)
if f is not None:

Otherwise you have to check the return isnt None, then unpack which gets annoying.


This should be a mathutils.Vector

Campbell Barton (campbellbarton) requested changes to this revision.Dec 24 2013, 8:44 AM

Prefer use Py_Tuple_New() like we do in most other areas of blender (faster which my make some small difference for ray casting many rays).

I would love to see this patch applied. The ability to use the BMBVHTree for the operations mentioned(ray casting, closest vert, intersecting face) on any given bmesh would be great.

For the contours and polystrips retopology addons, we use bmesh data that doesn't need to be linked to the scene, except that we often create temporary blender objects for ray_casting and closest point on mesh operations.

I am not familiar with the c code, but perhaps I can A) test and/or B) help with docstrings


I think this functionality should be re-worked to be more generic.

  • Make BVH its own module, like KDTree is now.
  • Expose BMesh module (so BMesh can return a BVH but needs not be aware of BMesh data types)

This would allow:

  • Create a BVH Tree (from own geometry data, unrelated to bmesh)
  • Create a BVH Tree (from a BMesh)

BVH Tree API Should support:

  • ray-cast
  • nearest point on surface (optionally)
  • overlap with another BVH Tree (optionally)
by optionally I mean its not needed for initial patch.
Dan Eicher (dna) abandoned this revision.Jul 29 2015, 6:55 PM

Closed by D966 (however one closes one of these differential things)