New addons ofxRaycaster


Hello, I have improved this addon and I think it is pretty stable now.

f you want to use rays in your #openFrameworks app, maybe this is for you:

  1. It contains a minimal definition of a ray in 2D and in 3D. It checks for the intersection of a ray with a segment, a sphere, a triangle, a plane, an ofPrimitive, an ofPolyline an with an ofMesh.

  2. Whenever it is possible, it uses the GLM methods, like glm::reflect and glm::intersectRayTriangle, without re-inventing the wheel (and the math).

  3. It runs continuous integration testing on mac, linux and windows. and

  4. All the public methods are documented in the README file, and linked to the example where they are used.

  5. It contains a mouse picker to easily identify meshes, spheres, ofPrimitives under your mouse cursor in a 3d space.

  6. Last but not least, all the example have animated gifs, so that you do not need to compile them in order to find what you are looking for.


Awesome! Thanks. I will need this soon on an upcomming project. :smiley:


Wow! Cool!
What is the benefit of lay based mouse picking compare to the default GL one? ( I remember ofWorldToScreen() or something is included in oF. )

I imagine Laycaster can find front object if there is another one behind? But how about performance?


The core functionality of this addon is testing ray intersection against polylines, meshes etc… Mouse picking is just a little functionality added at the end, and it uses internally screenToWorld as @roymacdonald was suggesting in the forum a while ago.

There are 2 ways to do mouse picking in openGL, one is ray casting, what I have used in this addon, and the other one is to render the scene in another buffer , and in this buffer each object has an identifier. More info here ->
I prefer the ray picking because it does not involve an additional render pass.

Chapter performances: A ray stores only two glm::vec3, the memory footprint is therefore low. What is not performant at the moment is the ray mesh intersections method. This is because it simply tests the intersection of a ray with every triangle composing a mesh, without any optimization. There are two kind of optimization that I could add:

  • A simple bounding box. Instead of testing the intersection of a ray with a triangle, I could simply test the intersection of a ray with the box containing the triangle. This is fast but not so really precise, you can easily imagine all the false positive that you can have testing the intersection of a ray with a tree using a bounding box containing a tree. There is an old PR here, any feedback is welcome.
  • Using more sophisticated spatial algorithm to represent the mesh, like a A BVH tree, Bounding Volume Hierarchy tree. Basically, smaller details are enclosed into smaller boxes, and those boxes are ordered in a tree structure. There are already other addons covering this topic (like by @kylemcdonald and by @bakercp ), so I would probably simply add a method that accepts those data structure as a parameter instead of adding those algorithms into this addon.


Very nice.
Would it be possible to check where two spheres are intersect with each other? Ideally get the circle that discribes this intersection.



Hello Stephan. No, the addon contains just intersection methods between a ray and other primivitives. What you are looking for is probably some library that does boolean operation between solids, like

To get the intersection between two sphere should not be difficult by the way. You get the position of the centers of the 2 spheres, if the distance between the 2 points is less than the sum of the radius of the two spheres, there is an intersection. The next step would be to identify where exactly those points are. On the wolfram website there is a tutorial about it.