Flexible Collision Library


FCL -- The Flexible Collision Library

Linux / OS X Build Status Windows Build status Coverage Coverage Status

FCL is a library for performing three types of proximity queries on a pair of geometric models composed of triangles.

  • Collision detection: detecting whether the two models overlap, and optionally, all of the triangles that overlap.
  • Distance computation: computing the minimum distance between a pair of models, i.e., the distance between the closest pair of points.
  • Tolerance verification: determining whether two models are closer or farther than a tolerance distance.
  • Continuous collision detection: detecting whether the two moving models overlap during the movement, and optionally, the time of contact.
  • Contact information: for collision detection and continuous collision detection, the contact information (including contact normals and contact points) can be returned optionally.

FCL has the following features

  • C++ interface
  • Compilable for either linux or win32 (both makefiles and Microsoft Visual projects can be generated using cmake)
  • No special topological constraints or adjacency information required for input models – all that is necessary is a list of the model's triangles
  • Supported different object shapes:
  • box
  • sphere
  • ellipsoid
  • capsule
  • cone
  • cylinder
  • convex
  • half-space
  • plane
  • mesh
  • octree (optional, octrees are represented using the octomap library http://octomap.github.com)


Before compiling FCL, please make sure Eigen and libccd (for collision checking between convex objects and is available here https://github.com/danfis/libccd) are installed. For libccd, make sure to compile from github version instead of the zip file from the webpage, because one bug fixing is not included in the zipped version.

Some optional libraries need to be installed for some optional capability of FCL. For octree collision, please install the octomap library from https://octomap.github.io/.

CMakeLists.txt is used to generate makefiles in Linux or Visual studio projects in windows. In command line, run

mkdir build
cd build
cmake ..

Next, in linux, use make to compile the code.

In windows, there will generate a visual studio project and then you can compile the code.


Before starting the proximity computation, we need first to set the geometry and transform for the objects involving in computation. The geometry of an object is represented as a mesh soup, which can be set as follows:

// set mesh triangles and vertice indices
std::vector<Vector3f> vertices;
std::vector<Triangle> triangles;
// code to set the vertices and triangles
// BVHModel is a template class for mesh geometry, for default OBBRSS template
// is used
typedef BVHModel<OBBRSSf> Model;
std::shared_ptr<Model> geom = std::make_shared<Model>();
// add the mesh data into the BVHModel structure
geom->addSubModel(vertices, triangles);

The transform of an object includes the rotation and translation:

// R and T are the rotation matrix and translation vector
Matrix3f R;
Vector3f T;
// code for setting R and T
// transform is configured according to R and T
Transform3f pose = Transform3f::Identity();
pose.linear() = R;
pose.translation() = T;

Given the geometry and the transform, we can also combine them together to obtain a collision object instance and here is an example:

//geom and tf are the geometry and the transform of the object
std::shared_ptr<BVHModel<OBBRSSf>> geom = ...
Transform3f tf = ...
//Combine them together
CollisionObjectf* obj = new CollisionObjectf(geom, tf);

Once the objects are set, we can perform the proximity computation between them. All the proximity queries in FCL follow a common pipeline: first, set the query request data structure and then run the query function by using request as the input. The result is returned in a query result data structure. For example, for collision checking, we first set the CollisionRequest data structure, and then run the collision function:

// Given two objects o1 and o2
CollisionObjectf* o1 = ...
CollisionObjectf* o2 = ...
// set the collision request structure, here we just use the default setting
CollisionRequest request;
// result will be returned via the collision result structure
CollisionResult result;
// perform collision test
collide(o1, o2, request, result);

By setting the collision request, the user can easily choose whether to return contact information (which is slower) or just return binary collision results (which is faster).

For distance computation, the pipeline is almost the same:

// Given two objects o1 and o2
CollisionObjectf* o1 = ...
CollisionObjectf* o2 = ...
// set the distance request structure, here we just use the default setting
DistanceRequest request;
// result will be returned via the collision result structure
DistanceResult result;
// perform distance test
distance(o1, o2, request, result);

For continuous collision, FCL requires the goal transform to be provided (the initial transform is included in the collision object data structure). Beside that, the pipeline is almost the same as distance/collision:

// Given two objects o1 and o2
CollisionObjectf* o1 = ...
CollisionObjectf* o2 = ...
// The goal transforms for o1 and o2
Transform3f tf_goal_o1 = ...
Transform3f tf_goal_o2 = ...
// set the continuous collision request structure, here we just use the default
// setting
ContinuousCollisionRequest request;
// result will be returned via the continuous collision result structure
ContinuousCollisionResult result;
// perform continuous collision test
continuousCollide(o1, tf_goal_o1, o2, tf_goal_o2, request, result);

FCL supports broadphase collision/distance between two groups of objects and can avoid the n square complexity. For collision, broadphase algorithm can return all the collision pairs. For distance, it can return the pair with the minimum distance. FCL uses a CollisionManager structure to manage all the objects involving the collision or distance operations.

// Initialize the collision manager for the first group of objects. 
// FCL provides various different implementations of CollisionManager.
// Generally, the DynamicAABBTreeCollisionManager would provide the best
// performance.
BroadPhaseCollisionManagerf* manager1 = new DynamicAABBTreeCollisionManagerf(); 
// Initialize the collision manager for the second group of objects.
BroadPhaseCollisionManagerf* manager2 = new DynamicAABBTreeCollisionManagerf();
// To add objects into the collision manager, using
// BroadPhaseCollisionManager::registerObject() function to add one object
std::vector<CollisionObjectf*> objects1 = ...
for(std::size_t i = 0; i < objects1.size(); ++i)
// Another choose is to use BroadPhaseCollisionManager::registerObjects()
// function to add a set of objects
std::vector<CollisionObjectf*> objects2 = ...
// In order to collect the information during broadphase, CollisionManager
// requires two settings:
// a) a callback to collision or distance; 
// b) an intermediate data to store the information generated during the
//    broadphase computation.
// For convenience, FCL provides default callbacks to satisfy a) and a
// corresponding call back data to satisfy b) for both collision and distance
// queries. For collision use DefaultCollisionCallback and DefaultCollisionData
// and for distance use DefaultDistanceCallback and DefaultDistanceData.
// The default collision/distance data structs are simply containers which
// include the request and distance structures for each query type as mentioned
// above.
DefaultCollisionData collision_data;
DefaultDistanceData distance_data;
// Setup the managers, which is related with initializing the broadphase
// acceleration structure according to objects input
// Examples for various queries
// 1. Collision query between two object groups and get collision numbers
manager2->collide(manager1, &collision_data, DefaultCollisionFunction);
int n_contact_num = collision_data.result.numContacts(); 
// 2. Distance query between two object groups and get the minimum distance
manager2->distance(manager1, &distance_data, DefaultDistanceFunction);
double min_distance = distance_data.result.min_distance;
// 3. Self collision query for group 1
manager1->collide(&collision_data, DefaultCollisionFunction);
// 4. Self distance query for group 1
manager1->distance(&distance_data, DefaultDistanceFunction);
// 5. Collision query between one object in group 1 and the entire group 2
manager2->collide(objects1[0], &collision_data, DefaultCollisionFunction);
// 6. Distance query between one object in group 1 and the entire group 2
manager2->distance(objects1[0], &distance_data, DefaultDistanceFunction);

For more examples, please refer to the test folder:

  • test_fcl_collision.cpp: provide examples for collision test
  • test_fcl_distance.cpp: provide examples for distance test
  • test_fcl_broadphase.cpp: provide examples for broadphase collision/distance test
  • test_fcl_frontlist.cpp: provide examples for frontlist collision acceleration
  • test_fcl_octomap.cpp: provide examples for collision/distance computation between octomap data and other data types.
  • fcl 0.5 release with octomap 1.8 support

    fcl 0.5 release with octomap 1.8 support

    Hey everyone,

    over at MoveIt! we just realized we need a version of fcl that supports octomap 1.8, because ROS' kinetic distribution features the new octomap. See here What's your plan for the next release? Is there anything we can do to facilitate a release?

    opened by v4hn 34
  • Fix FCL's EPA implementation, when calling libccd solver.

    Fix FCL's EPA implementation, when calling libccd solver.

    This PR aims at computing the signed distance function with option solver_type == GST_LIBCCD, which is the only solver in FCL that can compute the nearest points when the objects penetrate.

    Prior to this PR, the implementation in FCL has several flaws.

    1. As described already in #301, that the distance from the boundary of the polytope to the origin, is computed using an un-normalized vector. Also the termination criteria is incorrect. This issue is caused by libccd's implementation, and also reported in a libccd issue.
    2. FCL doesn't extract the nearest points correctly. What it did before is to loop over all the vertices of the polytope, and pick the one that is closest to the origin. But due to the convexity of the polytope, it is proved that unless the origin is on one of the vertex, the closest point from the boundary of the polytope to the origin, is always an interior point of the triangle. Thus the closest point should not be a vertex.
    3. When expanding the polytope in the EPA algorithm, FCL (and LIBCCD, where the code comes from) only delete the face where the closest point lives, and then add three faces which connects the new vertex to the edges of the removed triangle. This operation does not preserve the convexity of the expanded polytope. As a result, in many cases, the closest point from the boundary of the polytope to the origin, lies on an edge of the (nonconvex) polytope, instead of an interior point of the triangle. The correct way is to remove all the faces in the old polytope, that can be seen from the new vertex.

    This PR also adds unit tests to the EPA implementation.

    This change is Reviewable

    opened by hongkai-dai 30
  • When will there be a new release of master?

    When will there be a new release of master?

    Hi everyone, in particular @jslee02 @sherm1 @SeanCurtis-TRI, I guess.

    I guess I ask this in the general interest of the ROS/MoveIt community.

    There were lots of contributions to the library (many labeled "fixes"), that are currently in upstream master but not released. The last published release is 0.3.4 - a backport release @jslee02 did last year. 0.5.0 was released over two years ago.

    In ROS kinetic there are unofficial custom snapshots via https://github.com/wxmerkt/fcl_catkin , but even they are not up to date anymore.

    Ubuntu 18.04 (and thus ROS melodic) at the moment use 0.5.0 (https://packages.ubuntu.com/bionic/libfcl-dev), which is older than the snapshots mentioned above.

    There has been quite a bit of discussion on problems with FCL and possible advantages of the Bullet checker in MoveIt lately and outdated code probably makes things worse.

    What's the situation? Does it not make sense to do a new release because you broke the whole API and it's not settled yet? Do you miss the developers to do a release? Did performance only decrease since 0.5.0 and you struggle to improve on it again?

    opened by v4hn 25
  • Using the Eigen library for math operations

    Using the Eigen library for math operations


    I have experimented integrating the Eigen library and I'm wondering whether you are interested in the resulting code. Below are more details.


    The greatest advantage in using Eigen in FCL is that it avoids creating non-necessary temporary matrices (and vectors). The following code:

    Vec3f a, b;
    Vec3f c = a + b;

    is, with FCL vectors, compiled as:

    tmp <- a.operator+(b);
    c <- tmp

    whereas, with Eigen vectors:

    c <- a.operator+(b)

    This becomes more interesting on more complex expressions. See this for more details on temporary elimination and lazy assignment.

    Preliminary results

    So far, I have only integrated Eigen in Vec3f and Matrix3f and the improvements are mostly marginal, from 1% to 10% on the basic tests I did. The advantages of the method are:

    • No copy required for users needing Eigen in a library which depends on FCL.
    • A greater gain can be expected by relying on Eigen for other math classes such as Quaternion3f... I did not do any profiling to check what could be done.

    Implementation details

    There are very few impacts in the current code. Three parts of the code needs to be changed, whenever the prepocessor variable FCL_HAVE_EIGEN is 1:

    • Classes Vec3f and Matrix3f (so far) are declared based on Eigen, with the exact same interface. (the main problem is the inplace transpose in FCL)
    • Class TVector3 needs one additional operator*
    • Conditional operator ?:; does not work with expressions of matrices. For instance, b = (condition)?a:-a; must be changed in if (condition) b = a; else b = -a;
    opened by jmirabel 23
  • Templatize FCL for scalar type

    Templatize FCL for scalar type

    This PR templatize FCL objects on the scalar type so that we can take advantage of Eigen's automatic differentiation module as suggested by @sherm1 . A simple unit test that computes the gradient of distance w.r.t. the object position using Eigen's AutoDiff Module is included.

    To make FCL working fine with Eigen::AutoDiffScalar, I had to templatize most of the FCL classes and global functions. Now there are only 7 files not templatized over ~180 files, which are not used anyways. I would suggest making FCL header only project as future change.

    In this work, the major challenge was the resolving circular dependencies as all the implementations of templated classes should be placed in the same file with the declarations. To resolve the problem, I split those header files in circular dependencies into several files. Also, some files are split for easier maintenance (e.g., geometric_shapes.h is split per each shape class).

    One caveat is the increased compilation time, which is the nature of header only project.

    PR: Will merge soon unless anyone has an objection 
    opened by jslee02 21
  • error: missing binary operator before token

    error: missing binary operator before token "("

    When making make in the build directory, using sudo make, make or make -j4 It gives me the error home.../fcl/octree.h error: missing binary operator before token "(" #if OCTOMAP_VERSION_AT_LEAST(1,8,0) ^

    .... and it follows

    I change it to #if OCTOMAP_VERSION_AT_LEAST(1.8.0) but it didn't worked Anyone with same problem that knows how to fix it?

    Thanks in advance!

    opened by dblanm 21
  • libccd EPA expandPolytope:

    libccd EPA expandPolytope: "this should not happen"

    As noted in https://github.com/flexible-collision-library/fcl/pull/305#discussion_r205945024, I have encountered the "should not happen" logic error:

    RuntimeError: FCL expandPolytope(): This should not happen. Both the nearest point and the new vertex are on an edge, thus the nearest distance should be 0. This is touching contact, and we should not expand the polytope for touching contact.

    Here are details on how to reproduce:

    • fcl::distance call between a box (o1, GEOM_BOX) and a cylinder (o2, GEOM_CYLINDER).
    • The box dimensions are: .05 0.39 1.47
    • The cylinder dimensions are: length=0.18, radius=0.18
    • The box transform is: xyz=0.8 -0.385 0.735; wxyz=0.707107 0 0 0.707107
    • The cylinder transform is: xyz=0.4 -0.4 0.93; wxyz=0.991445 0 0 -0.130526

    I have been able to reliably reproduce it (as part of a larger process - caught and extracted the above from it).

    cc @hongkai-dai

    opened by wxmerkt 20
  • Return the correct nearest points from `distance(...)`

    Return the correct nearest points from `distance(...)`

    This PR fixes issues in both the CCD-based and the independent GJK solvers, which caused distance to return erroneous values for the nearest points.

    • CCD-base solver: Currently the most recently computed support points are returned as the nearest points, which is incorrect. The nearest points lie in the convex-hull of the points contained in the simplex variable. The points on the original shapes can be computed from the simplex and the nearest point to the origin on the Minkowski difference, dir.
    • Independent solver: Currently, p2 is not properly transformed to its shape's (shape1) frame. toshape0 converts points from shape1 frame to shape0 frame. The points extracted from the GJK simplex are in shape0 frame, so the inverse of toshape0 needs to be applied.

    The test_fcl_capsule_box_* tests contained lines that failed due to the issues described above. This PR uncomments those lines and modifies the tests to exercise both solvers.

    This PR also adds a distance_tolerance member to fcl::DistanceRequest, which corresponds to the distance_tolerance and gjk_tolerance members in GJKSolver_libccd and GJKSolver_indep respectively. @jslee02, is this an appropriate way to expose this knob to the user? I didn't use abs_err because the default for that was 0.0, whereas the defaults for distance_tolerance and gjk_tolerance are 1e-6.

    opened by avalenzu 20
  • Change convex shape constructor

    Change convex shape constructor

    Based on comments related to the convex shape to take std::shared_ptr<aligned_vector<Vector3<S>>> and std::shared_ptr<std::vector<int>> I decided to move forward and make the changes.

    I originally went down the route of changing all Vector<S>* to const aligned_vector<Vector3<S>>& but this quickly took me down a rabbit hole. I have a different branch where I left off, so if this is desirable I will continue working it and create a pull request. This PR does the minimum to integrate the use of new types.

    This change is Reviewable

    opened by Levi-Armstrong 19
  • Cylinder half space bug fix

    Cylinder half space bug fix

    There is a bug with the penetration query for cylinder vs half space. This is reported in RobotLocomotion/drake#8049.

    This PR fixes this bug and implements a new unit test that without the fix would not pass.

    This change is Reviewable

    opened by amcastro-tri 19
  • Revert bug introduced in cylinder/half-space intersection.

    Revert bug introduced in cylinder/half-space intersection.

    We introduced a new bug in #255 when "simplifying" an if statement. A separate unit test should've been introduced in that PR for that change but we didn't and therefore we introduced a bug.

    This change is Reviewable

    opened by amcastro-tri 18
  • how to get tow collide objs contacts

    how to get tow collide objs contacts

    hello my friends I noticed that getting the contact points of two colliding objects was wrong,as bellow is my testing codes

    fcl::CollisionResult<S> local_resul;

    local_result.clear(); std::vector<Contact<S>> contacts; contacts.clear();

    detail::MeshCollisionTraversalNode<BV> node; ``` if (!detail::initialize( node, m1, pose1, m2, pose2, CollisionRequest<S>(num_max_contacts, true, num_max_contacts, true), local_result)) { return -1; }

               ` node.enable_statistics = true;`
               ` detail::collide(&node);`
              `  if (local_result.numContacts() > 0) {`
                 `   /*local_result.getContacts(contacts);`
                `    std::sort(contacts.begin(), contacts.end());*/`
                  `  local_result.clear();`
                  `  CollisionRequest<S> request(num_max_contacts, true);`
                 `   int num_contacts = collide(&m1, pose1, &m2, pose2, request, local_result);`
                `    local_result.getContacts(contacts);// `
    local_result.getContacts(contacts);  is not right to get the contacts
    could you tell us how to get these contact points by use the function getContacts
    opened by myagen 0
  • How to check if the geometric wrap meets expectations?

    How to check if the geometric wrap meets expectations?


    I have wrapped my robot links with fcl::Capsule and the code snippet is shown below.

      std::shared_ptr<fcl::CollisionGeometry<double>> capsule_geo (new fcl::Capsule<double> (radius, height));
      fcl::Transform3<double> t = fcl::Transform3d::Identity();
      t.linear() = this_mat.block<3, 3>(0, 0);
      t.translation() = this_mat.block<3, 1>(0, 3);
      auto *b = new fcl::CollisionObject<double> (capsule_geo, t);

    When robot links collide with obstacles that are represented by octree, however, cdata.result.isCollision() returns false.

    The octomaps of obstacles are obtained with sensor and these poses can be guaranteed.

    For fcl::CollisionObject, if its base frame is different from my robot base, then the above process will result in a wrong transformation to capsules.

    So, my question is, how to check the base frame of fcl::Capsule. If it is different from my robot base frame, then how can I modify it?


    opened by QUIlToT 1
  • How to make one concave geometry outside of another concave geometry by a set distance threshold

    How to make one concave geometry outside of another concave geometry by a set distance threshold

    Is your feature request related to a problem? Please describe. We now have such a problem: We want different components of the robot (eg: arm, C-type-tool, etc.) and different parts of the table (eg desktop, table legs, etc.) to maintain the set safe distance threshold; We use ros fcl interface distance() to get the minimum distance from the robot to the table manager.manager_->distance(object.collision_objects_[i].get(), &drd, &collision_detection::distanceCallback); image

    For the first time, when we try to move the C-type-tool up, we can control it to slow down and stop based on the minimum distance between the C-type-tool and the table; When the C-type tool moves to the point where it is not allowed to continue upward movement, we try to move the tool to the right, and a collision occurs, because the obtained distance is always the minimum distance until the C-type-tool is closer to the table;

    Describe the solution you'd like We want one concave polygon to move in all directions to another concave polygon, always staying outside the distance threshold we set, without collision The equidistant collision model is not applicable because we set different distance thresholds and we cannot create an equidistant collision model for each distance threshold image

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    Additional context The motion control of the object has a certain overshoot due to the large speed, so we need to be able to obtain the distance in all directions between a concave polyhedron and another concave polyhedron to control deceleration and stop We're curious how such issues are addressed in the game Looking forward to your reply and solution Thanks!

    opened by KingWang569 0
  • Point inside given shape

    Point inside given shape


    I have a static closed STL shape in 3D (for example, a tetrahedron). I am sampling points randomly in 3D space. I need to consider points that are inside the shape.

    Is it possible to implement using the FCL library?

    opened by ravijo 0
  • Segfault in fcl::distance when doing geom-mesh or geom-octree distance

    Segfault in fcl::distance when doing geom-mesh or geom-octree distance

    If compiled in debug, instead the assert here is hit: https://github.com/flexible-collision-library/fcl/blob/master/include/fcl/narrowphase/distance-inl.h#L163

    It looks like in certain cases the distance measurements can come up as negative, but when the collision call returns no contact points it overruns bounds.

    It's assumed that there must have been contact points if the distance was negative, but the two functions have different tolerances, so it ends up reporting as not in collision but it ends up segfaulting when accessing a contact point at size_t::max here: https://github.com/flexible-collision-library/fcl/blob/master/include/fcl/narrowphase/distance-inl.h#L181

    opened by levonavagyanagility 0
  • Using fcl::Convexd meshes with broadphase collision managers

    Using fcl::Convexd meshes with broadphase collision managers

    I'm currently using FCL to perform collision detection on non-convex shapes, which I have broken down into several convex meshes. I then group together these convex meshes into fcl::BVHModel<fcl::OBBRSSd> models to create rigid bodies, and perform the collision checks using the fcl::DynamicAABBTreeCollisionManagerd broadphase collision manager (these are the settings which I have found to have the highest speed).

    I recently noticed while rereading the documentation that fcl supports a fcl::Convex<> primative type. Presumably, this would use a better support function at the narrowphase level, and give a pretty significant speed boost compared to assuming the meshes may be non-convex. However, I cannot seem to find a way to add a convex mesh file into any broadphase collision managers?

    Basically, my current code looks something like this:

      using Model = fcl::BVHModel<fcl::OBBRSSd>;
      // Creation of the collision objects:
      for (int i = 0 ; i < number_of_rigid_bodies ; ++i) {
        auto rigid_body = std::make_shared<Model>();
        for (for const auto& mesh_file : mesh_files) {
          // Load in the object_geometry geometry:
          rigid_body->addSubModel(mesh_file.vertices, mesh_file.triangles);
        // Use the meshes above to create a new collision object
        rigid_bodies[i] = new fcl::CollisionObjectd(rigid_body, Eigen::Matrix4d::Identity());
        // Compute the axis-aligned bounding box of the new object as a whole:

    And I would like to tell fcl to treat the lowest level meshes as convex, so changing this line:

    rigid_body->addSubModel(mesh_file.vertices, mesh_file.triangles);

    to something like this:

    rigid_body->addSubModel(fcl::Convexd(mesh_file.vertices, mesh_file.triangles));


    opened by JeffHough 1
  • 0.7.0(Sep 10, 2021)

    This release adds the following breaking changes as well as other features and bug fixes documented in the Changelog

    • Breaking changes

      • Macros FCL_SUPPRESS_MAYBE_UNINITIALIZED_BEGIN and FCL_SUPPRESS_MAYBE_UNINITIALIZED_END defined in fcl/common/warning.h have been removed: #489
      • Require CMake 3.10: #506
      • Check SSE support and enable SSE if support is found: #506 #514
    Source code(tar.gz)
    Source code(zip)
  • v0.6.1(Feb 26, 2020)

    This release represents some minor bug fixes in build and execution that were discovered on the heels of the release of 0.6.0.

    For the full details, see CHANGELOG.md

    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Feb 10, 2020)

    The change from 0.5.0 to 0.6.0 is huge. It includes:

    • Dependency on Eigen and templatized computation scalar
    • Reorganization of code
    • Increase in tests on narrowphase calculations to improve the quality of calculations
    • and more...

    For full details, view the CHANGELOG.md.

    Source code(tar.gz)
    Source code(zip)
  • 0.3.4(Jul 21, 2017)

  • 0.3.3(Jul 22, 2016)

  • 0.5.0(Jul 20, 2016)

    • Added safe-guards to allow octree headers only if octomap enabled: #136
    • Added CMake option to disable octomap in build: #135
    • Added automatic coverage test reporting: #125, #98
    • Added CMake exported targets: #116
    • Fixed API to support Octomap 1.8: #129, #126
    • Fixed continuousCollisionNaive() wasn't resetting the returned result when no collision: #123
    • Fixed uninitialized tf in TranslationMotion: #121
    • Fixed fcl.pc populated incorrect installation paths: #118
    • Fixed octree vs mesh CollisionResult now returns triangle id: #114
    • Fixed minor typo: #113
    • Fixed fallback finding of libccd: #112
    • Fixed a nasty bug in propagate propagateBVHFrontListCollisionRecurse(): #110
    • Fixed test_fcl_math failures on Windows 64 bit due to non-portable use of long: #108, #107
    • Fixed compilation in Visual Studio 2015, and suppressed some warnings: #99
    • Fixed build when libccd package config not found: #94
    • Removing dependency on boost: #108, #105, #104, #103
    Source code(tar.gz)
    Source code(zip)
Loki is a C++ library of designs, containing flexible implementations of common design patterns and idioms.

Last update: Novmber 16, 2005 Directions: To use Loki, simply extract the files from the archive, give your compiler access to their include path:

Stefan Naewe 207 Dec 29, 2022
Lightweight, Portable, Flexible Distributed/Mobile Deep Learning with Dynamic, Mutation-aware Dataflow Dep Scheduler; for Python, R, Julia, Scala, Go, Javascript and more

Apache MXNet (incubating) for Deep Learning Apache MXNet is a deep learning framework designed for both efficiency and flexibility. It allows you to m

The Apache Software Foundation 20.2k Dec 31, 2022
A flexible, high-performance serving system for machine learning models

XGBoost Serving This is a fork of TensorFlow Serving, extended with the support for XGBoost, alphaFM and alphaFM_softmax frameworks. For more informat

iQIYI 128 Nov 18, 2022
The dgSPARSE Library (Deep Graph Sparse Library) is a high performance library for sparse kernel acceleration on GPUs based on CUDA.

dgSPARSE Library Introdution The dgSPARSE Library (Deep Graph Sparse Library) is a high performance library for sparse kernel acceleration on GPUs bas

dgSPARSE 59 Dec 5, 2022
C-based/Cached/Core Computer Vision Library, A Modern Computer Vision Library

Build Status Travis CI VM: Linux x64: Raspberry Pi 3: Jetson TX2: Backstory I set to build ccv with a minimalism inspiration. That was back in 2010, o

Liu Liu 6.9k Jan 6, 2023
Edge ML Library - High-performance Compute Library for On-device Machine Learning Inference

Edge ML Library (EMLL) offers optimized basic routines like general matrix multiplications (GEMM) and quantizations, to speed up machine learning (ML) inference on ARM-based devices. EMLL supports fp32, fp16 and int8 data types. EMLL accelerates on-device NMT, ASR and OCR engines of Youdao, Inc.

NetEase Youdao 179 Dec 20, 2022
The Robotics Library (RL) is a self-contained C++ library for rigid body kinematics and dynamics, motion planning, and control.

Robotics Library The Robotics Library (RL) is a self-contained C++ library for rigid body kinematics and dynamics, motion planning, and control. It co

Robotics Library 656 Jan 1, 2023
A GPU (CUDA) based Artificial Neural Network library

Updates - 05/10/2017: Added a new example The program "image_generator" is located in the "/src/examples" subdirectory and was submitted by Ben Bogart

Daniel Frenzel 93 Dec 10, 2022
Header-only library for using Keras models in C++.

frugally-deep Use Keras models in C++ with ease Table of contents Introduction Usage Performance Requirements and Installation FAQ Introduction Would

Tobias Hermann 926 Dec 30, 2022
simple neural network library in ANSI C

Genann Genann is a minimal, well-tested library for training and using feedforward artificial neural networks (ANN) in C. Its primary focus is on bein

Lewis Van Winkle 1.3k Dec 29, 2022
oneAPI Deep Neural Network Library (oneDNN)

oneAPI Deep Neural Network Library (oneDNN) This software was previously known as Intel(R) Math Kernel Library for Deep Neural Networks (Intel(R) MKL-

oneAPI-SRC 3k Jan 6, 2023
A lightweight C library for artificial neural networks

Getting Started # acquire source code and compile git clone https://github.com/attractivechaos/kann cd kann; make # learn unsigned addition (30000 sam

Attractive Chaos 617 Dec 19, 2022
LibDEEP BSD-3-ClauseLibDEEP - Deep learning library. BSD-3-Clause

LibDEEP LibDEEP is a deep learning library developed in C language for the development of artificial intelligence-based techniques. Please visit our W

Joao Paulo Papa 22 Dec 8, 2022
A c++ trainable semantic segmentation library based on libtorch (pytorch c++). Backbone: ResNet, ResNext. Architecture: FPN, U-Net, PAN, LinkNet, PSPNet, DeepLab-V3, DeepLab-V3+ by now.

中文 C++ library with Neural Networks for Image Segmentation based on LibTorch. The main features of this library are: High level API (just a line to cr

null 310 Jan 3, 2023
Using PLT trampolines to provide a BLAS and LAPACK demuxing library.

libblastrampoline All problems in computer science can be solved by another level of indirection Using PLT trampolines to provide a BLAS and LAPACK de

Elliot Saba 54 Dec 7, 2022
A C library for product recommendations/suggestions using collaborative filtering (CF)

Recommender A C library for product recommendations/suggestions using collaborative filtering (CF). Recommender analyzes the feedback of some users (i

Ghassen Hamrouni 254 Dec 29, 2022
An open source machine learning library for performing regression tasks using RVM technique.

Introduction neonrvm is an open source machine learning library for performing regression tasks using RVM technique. It is written in C programming la

Siavash Eliasi 33 May 31, 2022
a generic C++ library for image analysis

VIGRA Computer Vision Library Copyright 1998-2013 by Ullrich Koethe This file is part of the VIGRA computer vision library. You may use,

Ullrich Koethe 378 Dec 30, 2022
OpenPose: Real-time multi-person keypoint detection library for body, face, hands, and foot estimation

Build Type Linux MacOS Windows Build Status OpenPose has represented the first real-time multi-person system to jointly detect human body, hand, facia

null 25.6k Dec 29, 2022