Code Monkey home page Code Monkey logo

reactphysics3d's Introduction

ReactPhysics3D
ReactPhysics3D

ReactPhysics3D is an open source C++ physics engine library that can be used in 3D simulations and games.

www.reactphysics3d.com

Build

Drawing

Features

  • Rigid body dynamics
  • Discrete collision detection
  • Collision shapes (Sphere, Box, Capsule, Convex Mesh, Static Concave Mesh, Height Field)
  • Multiple collision shapes per body
  • Broadphase collision detection (Dynamic AABB tree)
  • Narrowphase collision detection (SAT/GJK)
  • Collision response and friction (Sequential Impulses Solver)
  • Joints (Ball and Socket, Hinge, Slider, Fixed)
  • Collision filtering with categories
  • Ray casting
  • Sleeping technique for inactive bodies
  • Multi-platform (Windows, Linux, Mac OS X)
  • No external libraries (do not use STL containers)
  • Documentation (user manual and Doxygen API)
  • Testbed application with demos
  • Integrated profiler
  • Debugging renderer
  • Logs
  • Unit tests

Documentation

You can find the user manual and the Doxygen API documentation here.

Branches

The "master" branch always contains the last released version of the library and some possible hot fixes. This is the most stable version. On the other side, the "develop" branch is used for development. This branch is frequently updated and can be quite unstable. Therefore, if you want to use the library in your application, it is recommended to checkout the "master" branch.

Questions

If you have any questions about the library and how to use it, you should use Github Discussions to read previous questions and answers or to ask new questions. If you want, you can also share your project there if you are using the ReactPhysics3D library.

Questions/Discussions

You can use the Discussions section to ask your questions or answer questions from other users of the library. Please, do not open a new issue to ask a question.

Issues

If you find any issue with the library, you can report it on the issue tracker here. Please, do not open a new issue to ask a question. Use the Discussions section for your questions.

Author

The ReactPhysics3D library has been created and is maintained by Daniel Chappuis.

License

The ReactPhysics3D library is released under the open-source ZLib license.

Sponsorship

If you are using this library and want to support its development, you can sponsor it here.

Credits

Thanks a lot to Erin Catto, Dirk Gregorius, Erwin Coumans, Pierre Terdiman and Christer Ericson for their amazing GDC presentations, their physics engines, their books or articles and their contributions on many physics engine forums.

Thanks to all the contributors that have reported issues or have taken the time to send pull requests.

reactphysics3d's People

Contributors

breautek avatar centucore avatar colingilbert avatar costashatz avatar danielchappuis avatar dimhotepus avatar dorian-k avatar edvn0 avatar eisenwave avatar hugopeters1024 avatar jingqi avatar jrouwe avatar macro-255 avatar manuel5975p avatar mhwdvs avatar mrakh avatar peu77 avatar slavicpotato avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

reactphysics3d's Issues

Assertion fails when destroying rigid body

Assertion mNbNonUsedMovedShapes <= mNbMovedShapes (in function BroadphaseAlgorithm::removeMovedCollisionShape) fails seemingly at random upon destroying rigid bodies.

Edit: I don't know if this helps but if I create 3 rigid bodies and destroy them each before creating the next one, the assertion always fails when the third rigid body is destroyed.

fluid sph

Are you planning some fluid or particles simulation ?

Assertions for length tests should not use MACHINE_EPSILON

As one example, see the getUnit method of Vector3. It has the line assert(lengthVector > MACHINE_EPSILON). This causes an error when the length is less than that value, which does not seem like what we want. Instead, it should just test that the length is non-zero, as zero can be represented exactly by all floating point numbers.

Comparison with other libraries?

Hello,

Great project! Thanks for sharing!

I want to ask you whether you have made some comparisons with other libraries. For example:

  • Physics quality and speed compared to Bullet or ODE
  • Collision detection quality and speed compared to other collision libraries (e.g., FCL, ccd, Bullet, ODE)

Thanks,
Konstantinos

Weird use of assert() in codebase

The code is full of seemingly useless lines like "assert(foo >= 0);" where foo is an unsigned int. Why? It drives GCC mad with -Wtype-limits. If you could shed some light on this, it'd be great. I'm interested in using the library (which looks very nice, btw) in my project. Thanks.

cleanup ConcaveMeshShape?

when I clean up my shapes is there a way of getting the TriangleMesh that created the ConcaveMeshShape? Do I just keep track of those myself?

Also, if I delete the TriangleMesh I go through each TriangleVertexArray part it used and delete those separately. Does that make sense?

Do I need to delete the ProxyShape(s) created by rigidbody->addCollisionShape?

Idea exception handling

Its just an idea and probably a matter of personal feelings but I had an idea about setting up the Assert error handler to behave like OpenGL does if possible and instead of breaking the program Logging all errors to be retrieved by an error handler. Obviously major errors would still crash it but if its a matter of small, like one of the objects is 0,0,0 or something is off then to Assert to the Log and continue on ignoring that specific object, I just feel like this might be easier to get ones feet wet if they had SOMETHING working instead of nothing. I have been three days now of nothing but one Assert after another as I attempt to learn my way through this. Dont get me wrong. I love this library I find it intuitive but I have been having issues with no way to turn and its almost impossible to debug because we can not see directly the real bounding boxes and have to break and step through while looking at the number. Anyway. just a suggestion I am sure you could come up with something better then what I am thinking but it would be a nice optional feature if it were there.

Third-party collision-detection library - Might be worthwhile

Hi,

I have been looking a lot at all sorts of physics libraries, and one that seems to be a potential winner was D-Collide (http://d-collide.ematia.de/): Its API is quite nice, and it supports both multithreading and soft-body simulation (including self-collision.)

It is also apparently quite fast and support building broadphase trees with an arbitrary number of cutting planes per subdivision volume. It required a couple of minor changes (add a couple of std headers, switch to -fpermissive) to compile on my system, so I made a mirror of it at https://www.github.com/ColinGilbert/d-collide. It is designed to be plugged into existing physics engines, but can also be used by itself.

It uses pthreads and pthread-mutexes, so it may stand to be brought up to C++11 standards in order to increase compatibility with non-posix systems (ie: Windows.) As I am using a C++11 serialization library, I am quite interested in a pure C++11 physics engine. If you're into it (as it can quickly bring soft-body functionality to reactphysics3d) I would be glad to work alongside you wrt. this library.

Hope you like it!

Automatically Destroying Bodies, etc in Collision/Dynamics World's Destructors

As title, I'm curious what the reason is for requiring the user to manually destroy all Bodies and Joints. The objects are created by using methods of a World object, and immediately added to it - they can never live longer than the World object. Thus, it makes no sense to require the user to manually delete them. In many cases, it requires a great deal of effort to keep track of them. To make things worse, the sets of pointers that the World objects already store are protected, making it impossible to destroy them in the destructor of the object containing the World.

This also applies to Bodies and Shapes, in that a ProxyShape can never outlive the Body, so requiring that it be destroyed manually is pointless.

I propose that CollisionWorld and DynamicsWorld both be modified to automatically destroy all of their Bodies and Joints, and Bodies their Shapes. This would be a far more reasonable design that would allow immense amount more flexibility for end users.

A contactpoint can get an invalid normal (0, 0, 0), which will cause an assert.

This happens when I create identical spheres in identical locations.

See ContactManifoldSet::computeCubemapNormalId for example where it may assert:

short int ContactManifoldSet::computeCubemapNormalId(const Vector3& normal) const {

    assert(normal.lengthSquare() > MACHINE_EPSILON);

    // ...

I resolved this by patching SphereVsSphereAlgorithm::testCollision, adding a Vector3 collisionNormal variable that I made sure was sane, and used that instead of just the vectorBetweenCenters.getUnit(). It falls back to Y+ in case it's invalid.

There may be other collision algorithms that need fixes as well, I have only tested spheres.

See patched function here (too lazy to make a pull request, as my local copy has some substantial application-related changes):

void SphereVsSphereAlgorithm::testCollision(const CollisionShapeInfo& shape1Info,
                                            const CollisionShapeInfo& shape2Info,
                                            NarrowPhaseCallback* narrowPhaseCallback) {
    
    // Get the sphere collision shapes
    const SphereShape* sphereShape1 = static_cast<const SphereShape*>(shape1Info.collisionShape);
    const SphereShape* sphereShape2 = static_cast<const SphereShape*>(shape2Info.collisionShape);

    // Get the local-space to world-space transforms
    const Transform& transform1 = shape1Info.shapeToWorldTransform;
    const Transform& transform2 = shape2Info.shapeToWorldTransform;

    // Compute the distance between the centers
    Vector3 vectorBetweenCenters = transform2.getPosition() - transform1.getPosition();
    decimal squaredDistanceBetweenCenters = vectorBetweenCenters.lengthSquare();

    // Compute the sum of the radius
    decimal sumRadius = sphereShape1->getRadius() + sphereShape2->getRadius();
    
    // If the sphere collision shapes intersect
    if (squaredDistanceBetweenCenters <= sumRadius * sumRadius) {
        Vector3 centerSphere2InBody1LocalSpace = transform1.getInverse() * transform2.getPosition();
        Vector3 centerSphere1InBody2LocalSpace = transform2.getInverse() * transform1.getPosition();
        Vector3 intersectionOnBody1 = sphereShape1->getRadius() *
                                      centerSphere2InBody1LocalSpace.getUnit();
        Vector3 intersectionOnBody2 = sphereShape2->getRadius() *
                                      centerSphere1InBody2LocalSpace.getUnit();
        decimal penetrationDepth = sumRadius - std::sqrt(squaredDistanceBetweenCenters);
        
        Vector3 collisionNormal = vectorBetweenCenters.getUnit();
        if (collisionNormal.length() < MACHINE_EPSILON)
        {
          collisionNormal = Vector3(decimal(0.0), decimal(1.0), decimal(0.0)).getUnit();
        }

        // Create the contact info object
        ContactPointInfo contactInfo(shape1Info.proxyShape, shape2Info.proxyShape, shape1Info.collisionShape,
                                     shape2Info.collisionShape, collisionNormal, penetrationDepth,
                                     intersectionOnBody1, intersectionOnBody2);

        // Notify about the new contact
        narrowPhaseCallback->notifyContact(shape1Info.overlappingPair, contactInfo);
    }
}

RigidBody could benefit from getCenterOfMass methods

Currently, it seems that the centre of mass cannot be retrieved from a RigidBody. In several cases, it can be useful to be able to retrieve the automatically generated value from the body to use elsewhere. Is there a reason that such functions don't exist, or am I missing something? It seems like they should, as there are functions to retrieve the mass and inertia tensor.

Optimization opportunity - priori_cast

There is an interesting writeup on a so-called priori cast, a dynamic cast replacement that works very quickly at casting from a base type to a derived typed for when the info is known at compile-time. It seems ideal for creating joints. Drawback is the upcasting is slower, but that isn't a usecase I saw in the examples.

http://www.codeproject.com/Articles/609598/Priori-A-Fast-dynamic-cast-Alternative

http://digitalinblue.github.io/Priori/

http://www.helleboreconsulting.com/index.php/articles/117-priori-a-fast-dynamic-cast-alternative

Getting post-update position: User Manual is out of date.

In section "9.3 Updating a Rigid Body", the code sample provided calls a non-existent "getInterpolatedTransform" method on RigidBody.

// Get the interpolated transform of the rigid body
rp3d::Transform transform = body->getInterpolatedTransform();

Is it now RigidBody::getTransform()? This unexpectedly holds all zeros for me. But that could be some other mistake I'm making.

Networked Physics

Would this library be suitable in a networked environment where multiple clients share an approximation of a singular host simulation?

Multithreading?

First of all, nice job on this library! The 37 pages of documentation really makes it stand out.

I've looked at the source code (nice job on the cleanliness and modularity btw!) and noticed that there wasn't (yet) any multithreading for the solver/collision detection. Is this in the works for a future release?

Excessive CPU usage

The examples take up all available CPU resources. I looked at the setup code and the physics world's timestep seems to be set correctly. Furthermore, when I (hackishly) set the GLFW main loop to only update the physics world once every 1/N (N = 60 to 120) seconds, CPU usage went back down to something reasonable.

Inconsistent physics time with VSync enabled/disabled in testbed

Hello,
I tried out your testbed, and I really liked what I saw, but there is something which I find weird.
For example in the Cubes Scene, with Vsync disabled I have a physics-time of mostly 0.0 ms (shown on the GUI), but when enabling Vsync, the physics-time reaches nearly 1 ms.
The same happens in the other demos, and is especially noticeable in the concave mesh Scene, where physics-time reaches sometimes nearly 4 ms!
Do you know what happens here, and is there a way to mitigate this?
Here are the corresponding profiling statistics taken with one run of the Cubes Scene:
without VSync:

---------------
| Profiling : Root (total running time : 13152.3 ms) ---
|   0 -- DynamicsWorld::update() : 0.856368 % | 0.145144 ms/frame (776 calls)
|   1 -- RigidBody::updateBroadPhaseState() : 2.90041e-05 % | 4.91585e-06 ms/frame (7 calls)
|   2 -- CollisionShape::computeAABB() : 0.000208467 % | 3.53327e-05 ms/frame (155 calls)
| Unaccounted : 13039.6 ms (99.1434 %)
   ---------------
   | Profiling : DynamicsWorld::update() (total running time : 112.632 ms) ---
   |   0 -- DynamicsWorld::updateSleepingBodies() : 0.235388 % | 0.000341651 ms/frame (776 calls)
   |   1 -- DynamicsWorld::updateBodiesState() : 11.433 % | 0.0165944 ms/frame (776 calls)
   |   2 -- DynamicsWorld::solvePositionCorrection() : 0.0273067 % | 3.9634e-05 ms/frame (776 calls)
   |   3 -- DynamicsWorld::integrateRigidBodiesPositions() : 1.72328 % | 0.00250124 ms/frame (776 calls)
   |   4 -- DynamicsWorld::solveContactsAndConstraints() : 43.0237 % | 0.0624463 ms/frame (776 calls)
   |   5 -- DynamicsWorld::integrateRigidBodiesVelocities() : 5.97487 % | 0.00867217 ms/frame (776 calls)
   |   6 -- DynamicsWorld::computeIslands() : 1.60114 % | 0.00232397 ms/frame (776 calls)
   |   7 -- CollisionDetection::computeCollisionDetection() : 34.5061 % | 0.0500836 ms/frame (776 calls)
   | Unaccounted : 1.66154 ms (1.4752 %)
      ---------------
      | Profiling : DynamicsWorld::updateBodiesState() (total running time : 12.8772 ms) ---
      |   0 -- RigidBody::updateBroadPhaseState() : 72.4223 % | 0.012018 ms/frame (21211 calls)
      | Unaccounted : 3.55124 ms (27.5777 %)
         ---------------
         | Profiling : RigidBody::updateBroadPhaseState() (total running time : 9.32598 ms) ---
         |   0 -- DynamicAABBTree::updateObject() : 35.4203 % | 0.00425682 ms/frame (21211 calls)
         |   1 -- CollisionShape::computeAABB() : 23.1107 % | 0.00277745 ms/frame (21211 calls)
         | Unaccounted : 3.86739 ms (41.469 %)
      ---------------
      | Profiling : DynamicsWorld::solveContactsAndConstraints() (total running time : 48.4583 ms) ---
      |   0 -- ContactSolver::solve() : 80.8535 % | 0.05049 ms/frame (68880 calls)
      |   1 -- ContactSolver::initializeForIsland() : 9.73683 % | 0.00608029 ms/frame (4592 calls)
      | Unaccounted : 4.55976 ms (9.40964 %)
      ---------------
      | Profiling : CollisionDetection::computeCollisionDetection() (total running time : 38.8649 ms) ---
      |   0 -- CollisionDetection::computeNarrowPhase() : 94.912 % | 0.0475353 ms/frame (776 calls)
      |   1 -- CollisionDetection::computeBroadPhase() : 4.78311 % | 0.00239555 ms/frame (776 calls)
      | Unaccounted : 0.118494 ms (0.304887 %)
         ---------------
         | Profiling : CollisionDetection::computeNarrowPhase() (total running time : 36.8874 ms) ---
         |   0 -- GJKAlgorithm::testCollision() : 73.0947 % | 0.0347458 ms/frame (12970 calls)
         | Unaccounted : 9.92465 ms (26.9053 %)
            ---------------
            | Profiling : GJKAlgorithm::testCollision() (total running time : 26.9628 ms) ---
            |   0 -- GJKAlgorithm::computePenetrationDepthForEnlargedObjects() : 29.3262 % | 0.0101896 ms/frame (880 calls)
            | Unaccounted : 19.0556 ms (70.6738 %)
               ---------------
               | Profiling : GJKAlgorithm::computePenetrationDepthForEnlargedObjects() (total running time : 7.90715 ms) ---
               |   0 -- EPAAlgorithm::computePenetrationDepthAndContactPoints() : 83.567 % | 0.00851517 ms/frame (877 calls)
               | Unaccounted : 1.29938 ms (16.433 %)
   ---------------
   | Profiling : RigidBody::updateBroadPhaseState() (total running time : 0.0038147 ms) ---
   |   0 -- DynamicAABBTree::updateObject() : 50 % | 2.45792e-06 ms/frame (7 calls)
   |   1 -- CollisionShape::computeAABB() : 0 % | 0 ms/frame (7 calls)
   | Unaccounted : 0.00190735 ms (50 %)

With VSync:

---------------
| Profiling : Root (total running time : 10658.8 ms) ---
|   0 -- DynamicsWorld::update() : 3.45046 % | 0.587506 ms/frame (626 calls)
|   1 -- RigidBody::updateBroadPhaseState() : 2.90786e-05 % | 4.95118e-06 ms/frame (7 calls)
|   2 -- CollisionShape::computeAABB() : 0.000266181 % | 4.53224e-05 ms/frame (155 calls)
| Unaccounted : 10291 ms (96.5492 %)
   ---------------
   | Profiling : DynamicsWorld::update() (total running time : 367.779 ms) ---
   |   0 -- DynamicsWorld::updateSleepingBodies() : 0.249323 % | 0.00146479 ms/frame (626 calls)
   |   1 -- DynamicsWorld::updateBodiesState() : 11.125 % | 0.0653602 ms/frame (626 calls)
   |   2 -- DynamicsWorld::solvePositionCorrection() : 0.0227541 % | 0.000133682 ms/frame (626 calls)
   |   3 -- DynamicsWorld::integrateRigidBodiesPositions() : 1.72102 % | 0.0101111 ms/frame (626 calls)
   |   4 -- DynamicsWorld::solveContactsAndConstraints() : 44.0885 % | 0.259022 ms/frame (626 calls)
   |   5 -- DynamicsWorld::integrateRigidBodiesVelocities() : 5.54708 % | 0.0325895 ms/frame (626 calls)
   |   6 -- DynamicsWorld::computeIslands() : 1.41471 % | 0.00831152 ms/frame (626 calls)
   |   7 -- CollisionDetection::computeCollisionDetection() : 34.4902 % | 0.202632 ms/frame (626 calls)
   | Unaccounted : 4.93336 ms (1.34139 %)
      ---------------
      | Profiling : DynamicsWorld::updateBodiesState() (total running time : 40.9155 ms) ---
      |   0 -- RigidBody::updateBroadPhaseState() : 72.425 % | 0.0473371 ms/frame (20011 calls)
      | Unaccounted : 11.2824 ms (27.575 %)
         ---------------
         | Profiling : RigidBody::updateBroadPhaseState() (total running time : 29.633 ms) ---
         |   0 -- DynamicAABBTree::updateObject() : 36.1284 % | 0.0171022 ms/frame (20011 calls)
         |   1 -- CollisionShape::computeAABB() : 22.2238 % | 0.0105201 ms/frame (20011 calls)
         | Unaccounted : 12.3415 ms (41.6478 %)
      ---------------
      | Profiling : DynamicsWorld::solveContactsAndConstraints() (total running time : 162.148 ms) ---
      |   0 -- ContactSolver::solve() : 80.5709 % | 0.208697 ms/frame (68880 calls)
      |   1 -- ContactSolver::initializeForIsland() : 9.90343 % | 0.0256521 ms/frame (4592 calls)
      | Unaccounted : 15.4457 ms (9.52569 %)
      ---------------
      | Profiling : CollisionDetection::computeCollisionDetection() (total running time : 126.848 ms) ---
      |   0 -- CollisionDetection::computeNarrowPhase() : 94.8878 % | 0.192273 ms/frame (626 calls)
      |   1 -- CollisionDetection::computeBroadPhase() : 4.84082 % | 0.00980906 ms/frame (626 calls)
      | Unaccounted : 0.344276 ms (0.271409 %)
         ---------------
         | Profiling : CollisionDetection::computeNarrowPhase() (total running time : 120.363 ms) ---
         |   0 -- GJKAlgorithm::testCollision() : 77.102 % | 0.148246 ms/frame (12970 calls)
         | Unaccounted : 27.5607 ms (22.898 %)
            ---------------
            | Profiling : GJKAlgorithm::testCollision() (total running time : 92.8023 ms) ---
            |   0 -- GJKAlgorithm::computePenetrationDepthForEnlargedObjects() : 30.6504 % | 0.0454382 ms/frame (880 calls)
            | Unaccounted : 64.358 ms (69.3496 %)
               ---------------
               | Profiling : GJKAlgorithm::computePenetrationDepthForEnlargedObjects() (total running time : 28.4443 ms) ---
               |   0 -- EPAAlgorithm::computePenetrationDepthAndContactPoints() : 83.3426 % | 0.0378693 ms/frame (877 calls)
               | Unaccounted : 4.73809 ms (16.6574 %)
   ---------------
   | Profiling : RigidBody::updateBroadPhaseState() (total running time : 0.00309944 ms) ---
   |   0 -- DynamicAABBTree::updateObject() : 38.4615 % | 1.9043e-06 ms/frame (7 calls)
   |   1 -- CollisionShape::computeAABB() : 30.7692 % | 1.52344e-06 ms/frame (7 calls)
   | Unaccounted : 0.000953674 ms (30.7692 %)

Assert crash in GJK code

EDIT: Forgot to add: This is on the master branch. Currently testing develop
EDIT 2: Fails on develop as well. I am also raycasting every frame. Code that does raycasting on comment below.

There is a crash that occurs once in a while, usually after about a minute. I isolated it to the GJK code. Body's shape is a capsule.

Here is gdb output:

/home/noob/noobgame/engine/lib/reactphysics3d/src/collision/narrowphase/GJK/Simplex.cpp:48: void reactphysics3d::Simplex::addPoint(const reactphysics3d::Vector3&, const reactphysics3d::Vector3&, const reactphysics3d::Vector3&): Assertion `!isFull()' failed.

Here is a backtrace:

#0  0x00007ffff3a89a17 in raise () from /lib64/libc.so.6
#1  0x00007ffff3a8adaa in abort () from /lib64/libc.so.6
#2  0x00007ffff3a8288d in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff3a82942 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000007d96be in reactphysics3d::Simplex::addPoint (this=0x7fffffffd510, point=..., suppPointA=..., suppPointB=...)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/narrowphase/GJK/Simplex.cpp:48
#5  0x00000000007cca9d in reactphysics3d::GJKAlgorithm::raycast (this=0x16b81c0, ray=..., collisionShape=0x1c17bf0, raycastInfo=...)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/narrowphase/GJK/GJKAlgorithm.cpp:456
#6  0x0000000000798136 in reactphysics3d::ConvexMeshShape::raycast (this=0x1c2c6a0, ray=..., raycastInfo=..., proxyShape=0x1c17bf0)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/shapes/ConvexMeshShape.cpp:242
#7  0x000000000079d79d in reactphysics3d::ProxyShape::raycast (this=0x1c17bf0, ray=..., raycastInfo=...) at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/ProxyShape.h:261
#8  0x000000000079d58d in reactphysics3d::RaycastTest::raycastAgainstShape (this=0x7fffffffdc50, shape=0x1c17bf0, ray=...)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/RaycastInfo.cpp:38
#9  0x00000000007902fc in reactphysics3d::DynamicAABBTree::raycast (this=0x16b8170, ray=..., raycastTest=..., raycastWithCategoryMaskBits=65535)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/broadphase/DynamicAABBTree.cpp:651
#10 0x00000000006780de in raycast (raycastWithCategoryMaskBits=65535, raycastTest=..., ray=..., this=<optimized out>)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/broadphase/BroadPhaseAlgorithm.h:182
#11 raycast (raycastWithCategoryMaskBits=65535, ray=..., raycastCallback=0x7fffffffdca0, this=<optimized out>)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/CollisionDetection.h:239
#12 raycast (raycastWithCategoryMaskBits=65535, raycastCallback=0x7fffffffdca0, ray=..., this=<optimized out>)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/engine/CollisionWorld.h:195
#13 noob::character_controller::update (this=0x1b379a0) at /home/noob/noobgame/engine/common/CharacterController.cpp:26
#14 0x00000000006936fc in noob::actor::update (this=<optimized out>) at /home/noob/noobgame/engine/common/Actor.cpp:13
#15 0x000000000068dcbf in noob::stage::update (this=this@entry=0x16b8130, dt=dt@entry=1.1769868966740179e-316) at /home/noob/noobgame/engine/common/Stage.cpp:36
#16 0x000000000066b042 in noob::application::update (this=this@entry=0x16b8090, delta=1.1769868966740179e-316) at /home/noob/noobgame/engine/common/Application.cpp:51
#17 0x000000000066b2f2 in noob::application::step (this=0x16b8090) at /home/noob/noobgame/engine/common/Application.cpp:93
#18 0x000000000062c6a8 in main () at /home/noob/noobgame/engine/platform/nix/EngineDesktop.cpp:425

Full backtrace:

(gdb) bt full
#0  0x00007ffff3a89a17 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff3a8adaa in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007ffff3a8288d in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007ffff3a82942 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4  0x00000000007d96be in reactphysics3d::Simplex::addPoint (this=0x7fffffffd510, point=..., suppPointA=..., suppPointB=...)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/narrowphase/GJK/Simplex.cpp:48
        __PRETTY_FUNCTION__ = "void reactphysics3d::Simplex::addPoint(const reactphysics3d::Vector3&, const reactphysics3d::Vector3&, const reactphysics3d::Vector3&)"
#5  0x00000000007cca9d in reactphysics3d::GJKAlgorithm::raycast (this=0x16b81c0, ray=..., collisionShape=0x1c17bf0, raycastInfo=...)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/narrowphase/GJK/GJKAlgorithm.cpp:456
        epsilon = 9.99999975e-05
        v = {x = 0.0189624038, y = 0.00210423698, z = 0.0570573546}
        vDotW = -8.48199558
        vDotR = -0.792089462
        w = {x = -94.4290924, y = 0.000972747803, z = -117.274887}
        pointA = {x = -nan(0x7fdc10), y = 4.59163468e-41, z = 1.14531991e-38}
        suppA = {x = 5.57090759, y = 3.00097275, z = -17.274889}
        localToWorldTransform = {mPosition = {x = 0, y = -20, z = 0}, mOrientation = {x = 0, y = 0, z = 0, w = 1}}
        worldToLocalTransform = {mPosition = {x = 0, y = 20, z = 0}, mOrientation = {x = -0, y = -0, z = -0, w = 1}}
        rayDirection = {x = 0, y = -1, z = 0}
        lambda = 0.791116774
        pointB = {x = 5.57090235, y = 2.99999976, z = -17.4416027}
        suppB = {x = 100, y = 3, z = 100}
        machineEpsilonSquare = 1.42108547e-14
        point1 = {x = 5.57090759, y = 3.79208946, z = -17.274889}
        n = {x = -1.27999999e-06, y = 0.792089462, z = -7.67999973e-06}
        point2 = {x = 5.57090759, y = 2.79208946, z = -17.274889}
        simplex = {mPoints = {{x = -94.4290924, y = 0.792089462, z = -117.274887}, {x = -94.4290924, y = 0.000972747803, z = 82.7251129}, {x = 105.570908, y = 0.000972747803, 
              z = -117.274887}, {x = 105.570908, y = 0.000972747803, z = 82.7251129}}, mPointsLengthSquare = {22670.8789, 15760.2979, 24898.6172, 17988.6602}, 
          mMaxLengthSquare = 24898.6172, mSuppPointsA = {{x = 5.57090759, y = 3.79208946, z = -17.274889}, {x = 5.57090759, y = 3.00097275, z = -17.274889}, {x = 5.57090759, 
              y = 3.00097275, z = -17.274889}, {x = 5.57090759, y = 3.00097275, z = -17.274889}}, mSuppPointsB = {{x = 100, y = 3, z = 100}, {x = 100, y = 3, z = -100}, {x = -100, y = 3, 
              z = 100}, {x = -100, y = 3, z = -100}}, mDiffLength = {{{x = 0, y = 0, z = 0}, {x = 0, y = 0.791116714, z = -200}, {x = -200, y = 0.791116714, z = 0}, {x = -200, 
                y = 0.791116714, z = -200}}, {{x = -0, y = -0.791116714, z = 200}, {x = 0, y = 0, z = 0}, {x = -200, y = 0, z = 200}, {x = -200, y = -0, z = -0}}, {{x = 200, 
                y = -0.791116714, z = -0}, {x = 200, y = -0, z = -200}, {x = 0, y = 0, z = 0}, {x = -0, y = -0, z = -200}}, {{x = 200, y = -0.791116714, z = 200}, {x = 200, y = 0, z = 0}, {
                x = 0, y = 0, z = 200}, {x = 0, y = 0, z = 0}}}, mDet = {{0.920738995, -0.185574993, 0, -0.0274467953}, {1, 0.977887094, 0, 5.57090759}, {-16.2079124, 1, 1, 
              1.11207046e-41}, {16545.0234, 23455.6035, 4.59163468e-41, 4.3260505e-38}, {0, 6.59177075e-38, 1, 0.938853025}, {21114.1816, 0.0964297354, 18886.4453, 0.34322238}, {
              0.920738995, 44569.1562, 35430.8438, -0.0274467953}, {-93631744, 938227008, 755454976, 4.20389539e-45}, {-16.2079124, 4.20389539e-44, 0, 1}, {37659.2031, 4.20389539e-45, 0, 
              42341.4219}, {0, 21114.1816, 0, 18885.8184}, {661800960, 182779584, 0, 755444608}, {1.54142831e-43, 0, 16545.0234, 23454.9766}, {844567296, 1.66754517e-43, -182755904, 
              938213760}, {-16.2079124, 844567296, 661800960, 93631872}, {1441792, 530579456, 415236096, 60817408}}, mNormSquare = {{-16.2079124, 40000.625, 40000.625, 80000.625}, {
              40000.625, 0.979474306, 80000, 40000}, {40000.625, 80000, 0, 40000}, {80000.625, 40000, 40000, -6.42588997}}, mBitsCurrentSimplex = 15, mLastFound = 2, mLastFoundBit = 4, 
          mAllBits = 15}
        distSquare = 0.00361954235
        nbIterations = 6
#6  0x0000000000798136 in reactphysics3d::ConvexMeshShape::raycast (this=0x1c2c6a0, ray=..., raycastInfo=..., proxyShape=0x1c17bf0)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/shapes/ConvexMeshShape.cpp:242
No locals.
#7  0x000000000079d79d in reactphysics3d::ProxyShape::raycast (this=0x1c17bf0, ray=..., raycastInfo=...) at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/ProxyShape.h:261
No locals.
#8  0x000000000079d58d in reactphysics3d::RaycastTest::raycastAgainstShape (this=0x7fffffffdc50, shape=0x1c17bf0, ray=...)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/RaycastInfo.cpp:38
        raycastInfo = {worldPoint = {x = 0, y = 0, z = 0}, worldNormal = {x = 0, y = 0, z = 0}, hitFraction = 1.11178263e-38, body = 0x0, proxyShape = 0x0}
        isHit = 193
#9  0x00000000007902fc in reactphysics3d::DynamicAABBTree::raycast (this=0x16b8170, ray=..., raycastTest=..., raycastWithCategoryMaskBits=65535)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/broadphase/DynamicAABBTree.cpp:651
---Type <return> to continue, or q <return> to quit---
        rayTemp = {point1 = {x = 5.57090759, y = -16.2079105, z = -17.274889}, point2 = {x = 5.57090759, y = -17.2079105, z = -17.274889}, maxFraction = 1}
        hitFraction = 0
        nodeID = 3
        node = 0x16b5fe8
        maxFraction = 1
        endPoint = {x = 5.57090759, y = -17.2079105, z = -17.274889}
        rayAABB = {mMinCoordinates = {x = 5.57090759, y = -17.2079105, z = -17.274889}, mMaxCoordinates = {x = 5.57090759, y = -16.2079105, z = -17.274889}}
        stack = {mInitArray = {2, 3, -9392, 32767, 7950348, 0, 1064327341, 0, 7950348, 0, 0, 0, -9632, 32767, 7952463, 1036352754, 1044252509, 1064982223, -9472, -1048169206, -1049223086, 
            1086280000, -9384, 32767, -9632, 32767, 8151244, 0, -9632, 32767, -9392, 32767, -9408, 32767, -9584, 32767, -9264, 32767, 7951267, 0, 1062417542, 1056930776, -9168, 32767, 
            -9200, 32767, 29440816, 0, -1098907648, -1086324736, -1098907648, 0, 1048576000, 1061158912, 1048576000, 0, -1093614087, -1085066106, -1090552872, 0, 1064982223, 1044252509, 
            1036352754, 0, 1045712093, 1064023438, 1051278449, 32767, -9200, 32767, 23813972, 0, 1053869561, 1062417542, 23813952, 16777216, -9376, 32767, 7921662, 0, -9216, 32767, -9200, 
            32767, 1021368346, 0, 23822704, 0, 1084569728, -1048034447, -1047645976, 0, 1086280000, -1049223086, 2090833408, 602201166, 16095056, 0, 29440816, 0, -9312, 32767, 7914006, 0, 
            -9216, 32767, -9200, 32767, 29457216, 0, 23822704, 0, 1021368346, -1103231139, -9200, 32767, -9264, 32767, 7936033, 0, -9216, 32767, -9200, 32767, 29457216, 0, -9216, 32767}, 
          mElements = 0x7fffffffd9d0, mNbElements = 1, mNbAllocatedElements = 128}
#10 0x00000000006780de in raycast (raycastWithCategoryMaskBits=65535, raycastTest=..., ray=..., this=<optimized out>)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/broadphase/BroadPhaseAlgorithm.h:182
No locals.
#11 raycast (raycastWithCategoryMaskBits=65535, ray=..., raycastCallback=0x7fffffffdca0, this=<optimized out>)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/collision/CollisionDetection.h:239
        rayCastTest = {userCallback = 0x7fffffffdca0}
#12 raycast (raycastWithCategoryMaskBits=65535, raycastCallback=0x7fffffffdca0, ray=..., this=<optimized out>)
    at /home/noob/noobgame/engine/lib/reactphysics3d/src/engine/CollisionWorld.h:195
No locals.
#13 noob::character_controller::update (this=0x1b379a0) at /home/noob/noobgame/engine/common/CharacterController.cpp:26
        from = {v = {_M_elems = {5.57090759, -16.2079105, -17.274889}}}
        to = {v = {_M_elems = {5.57090759, -17.2079105, -17.274889}}}
        ray = {point1 = {x = 5.57090759, y = -16.2079105, z = -17.274889}, point2 = {x = 5.57090759, y = -17.2079105, z = -17.274889}, maxFraction = 1}
        ground_cb = {<reactphysics3d::RaycastCallback> = {_vptr.RaycastCallback = 0xf20750 <vtable for noob::character_controller::groundcast_callback+16>}, grounded = false, from = {v = {
              _M_elems = {5.57090759, -16.2079105, -17.274889}}}, to = {v = {_M_elems = {5.57090759, -17.2079105, -17.274889}}}, slope = {v = {_M_elems = {0, 0, 0}}}}
#14 0x00000000006936fc in noob::actor::update (this=<optimized out>) at /home/noob/noobgame/engine/common/Actor.cpp:13
No locals.
#15 0x000000000068dcbf in noob::stage::update (this=this@entry=0x16b8130, dt=dt@entry=1.1769868966740179e-316) at /home/noob/noobgame/engine/common/Stage.cpp:36
        actor_it = {first = "player-character", second = std::shared_ptr (count 3, weak 0) 0x1b37880}
        __for_range = std::unordered_map with 1 elements = {["player-character"] = std::shared_ptr (count 3, weak 0) 0x1b37880}
#16 0x000000000066b042 in noob::application::update (this=this@entry=0x16b8090, delta=1.1769868966740179e-316) at /home/noob/noobgame/engine/common/Application.cpp:51
No locals.
#17 0x000000000066b2f2 in noob::application::step (this=0x16b8090) at /home/noob/noobgame/engine/common/Application.cpp:93
        timeNow = {tv_sec = 963611, tv_nsec = 828192335}
        uNowNano = <optimized out>
        delta = <optimized out>
#18 0x000000000062c6a8 in main () at /home/noob/noobgame/engine/platform/nix/EngineDesktop.cpp:425
        info = {movement = false, translation = {v = {_M_elems = {0, 0, 0}}}, rotation = {v = {_M_elems = {0, 0, 0}}}}
        window = 0x14fa300

Opening ReactPhysics3D built for Visual Studio 2013 produces make_pair errors.

After building ReactPhysics3D with CMake for Visual Studio I get an intellisense error coming from the ConvexMeshShape.h file:

1   IntelliSense: no instance of function template "std::make_pair" matches the argument list argument types are: (reactphysics3d::uint, std::set<reactphysics3d::uint, std::less<reactphysics3d::uint>, std::allocator<char32_t>>) c:\LocalProjects\CollisionDetection\reactphysics\reactphysics3d-0.5.0\reactphysics3d\src\collision\shapes\ConvexMeshShape.h 227 36  reactphysics3d

NaN's while using SphereShape

Hi,

I was writing up my engine and came across a NaN issue while using a SphereShape. I think the problem is linked specifically to the SphereShape as CapsuleShape (which I was using previously) works fine. Currently using master branch, will switch to develop and report upon the error once I test it.

Colin

Testbed app fails to build on FreeBSD

/usr/ports/devel/reactphysics3d/work/reactphysics3d-a2705f1/testbed/nanogui/src/layout.cpp:327:21: error: out-of-line definition of 'AdvancedGridLayout' does not match any declaration in
      'nanogui::AdvancedGridLayout'
AdvancedGridLayout::AdvancedGridLayout(const std::vector<int> &cols, const std::vector<int> &rows)
                    ^~~~~~~~~~~~~~~~~~
In file included from /usr/ports/devel/reactphysics3d/work/reactphysics3d-a2705f1/testbed/nanogui/src/common.cpp:25:
/usr/include/sys/dir.h:39:2: warning: "The information in this file should be obtained from <dirent.h>" [-W#warnings]
#warning "The information in this file should be obtained from <dirent.h>"
 ^
/usr/include/sys/dir.h:40:2: warning: "and is provided solely (and temporarily) for backward compatibility." [-W#warnings]
#warning "and is provided solely (and temporarily) for backward compatibility."
 ^
/usr/ports/devel/reactphysics3d/work/reactphysics3d-a2705f1/testbed/nanogui/src/screen.cpp:40:9: error: out-of-line definition of 'Screen' does not match any declaration in 'nanogui::Screen'
Screen::Screen(const Vector2i &size, const std::string &caption,
        ^~~~~~
1 error generated.
/usr/ports/devel/reactphysics3d/work/reactphysics3d-a2705f1/testbed/nanogui/src/glutil.cpp:151:16: error: out-of-line definition of 'uploadAttrib' does not match any declaration in
      'nanogui::GLShader'
void GLShader::uploadAttrib(const std::string &name, uint32_t size, int dim,
               ^~~~~~~~~~~~
/usr/ports/devel/reactphysics3d/work/reactphysics3d-a2705f1/testbed/nanogui/src/glutil.cpp:197:16: error: out-of-line definition of 'downloadAttrib' does not match any declaration in
      'nanogui::GLShader'
void GLShader::downloadAttrib(const std::string &name, uint32_t size, int /* dim */,
               ^~~~~~~~~~~~~~

Wrong scaling in ConcaveMeshShape

Hi,

scaling seems to be wrong in ConcaveMeshShape. Please see attached a patch:

diff --git a/ext/reactphysics3d/src/collision/shapes/ConcaveMeshShape.cpp b/ext/reactphysics3d/src/collision/shapes/ConcaveMeshShape.cpp
index 79c431e0..4864e56d 100644
--- a/ext/reactphysics3d/src/collision/shapes/ConcaveMeshShape.cpp
+++ b/ext/reactphysics3d/src/collision/shapes/ConcaveMeshShape.cpp
@@ -64,9 +64,15 @@ void ConcaveMeshShape::initBVHTree() {
             triangleVertexArray->getTriangleVertices(triangleIndex, trianglePoints);
 
             // Apply the scaling factor to the vertices
-            trianglePoints[0] *= mScaling.x;
-            trianglePoints[1] *= mScaling.y;
-            trianglePoints[2] *= mScaling.z;
+            trianglePoints[0][0] *= mScaling.x;
+            trianglePoints[0][1] *= mScaling.y;
+            trianglePoints[0][2] *= mScaling.z;
+            trianglePoints[1][0] *= mScaling.x;
+            trianglePoints[1][1] *= mScaling.y;
+            trianglePoints[1][2] *= mScaling.z;
+            trianglePoints[2][0] *= mScaling.x;
+            trianglePoints[2][1] *= mScaling.y;
+            trianglePoints[2][2] *= mScaling.z;
 
             // Create the AABB for the triangle
             AABB aabb = AABB::createAABBForTriangle(trianglePoints);
@@ -88,9 +94,15 @@ void ConcaveMeshShape::getTriangleVertices(uint subPart, uint triangleIndex,
     triangleVertexArray->getTriangleVertices(triangleIndex, outTriangleVertices);
 
     // Apply the scaling factor to the vertices
-    outTriangleVertices[0] *= mScaling.x;
-    outTriangleVertices[1] *= mScaling.y;
-    outTriangleVertices[2] *= mScaling.z;
+    outTriangleVertices[0][0] *= mScaling.x;
+    outTriangleVertices[0][1] *= mScaling.y;
+    outTriangleVertices[0][2] *= mScaling.z;
+    outTriangleVertices[1][0] *= mScaling.x;
+    outTriangleVertices[1][1] *= mScaling.y;
+    outTriangleVertices[1][2] *= mScaling.z;
+    outTriangleVertices[2][0] *= mScaling.x;
+    outTriangleVertices[2][1] *= mScaling.y;
+    outTriangleVertices[2][2] *= mScaling.z;
 }
 
 // Return the three vertex normals (in the array outVerticesNormals) of a triangle

Best regards
Andreas

Assertion error

I'm not sure if this is because I'm using the library wrong, or if this is a bug. I managed to reproduce it with this code:

#include "reactphysics3d.h"

using namespace rp3d;

int main(int argc, char *argv[])
{
    DynamicsWorld *world = new DynamicsWorld(Vector3(0, -9.81, 0));
    // floor
    {
        BoxShape *shape = new BoxShape(Vector3(10, 1, 10));
        RigidBody *body = world->createRigidBody(Transform(Vector3(0, 0, 0), Quaternion(0, 0, 0, 1)));
        body->setType(STATIC);
        body->addCollisionShape(shape, Transform(Vector3(0, 0, 0), Quaternion(0, 0, 0, 1)), 90);
    }
    // box
    {
        BoxShape *shape = new BoxShape(Vector3(2, 2, 2));
        RigidBody *body = world->createRigidBody(Transform(Vector3(0, 10, 0), Quaternion(0, 0, 0, 1)));
        body->setType(DYNAMIC);
        body->addCollisionShape(shape, Transform(Vector3(0, 10, 0), Quaternion(0, 0, 0, 1)), 90);
    }
    while(true) {
        world->update(1.0f/60.0f);
    }
    return 0;
}

And the error:

Assertion failed: (wDotv > 0.0), function computePenetrationDepthAndContactPoints, file deps/reactphysics3d/collision/narrowphase/EPA/EPAAlgorithm.cpp, line 391.
Abort trap: 6

You can't see it in the command line, but in my game It errors the instant the box collides with the floor.

I think it's because I add the 2x2x2 box's shape to the body at (0, 10, 0) instead of (0, 0, 0) as it probably wants. Because if I put (0, 0, 0) for the position in addCollisionShape, it works as expected.

Also, if you don't do that and instead set the 2x2x2 box's size to 1x1x1, it stops crashing and works as expected.

Edit:

Also, another bug: If you try to update the dynamics world when it has no bodies, it crashes, presumably because it wants always to have bodies in it.

Thanks.

[Feature request] concave meshes

Hi,

I have been using rp3d for a while, and a big thing that makes life difficult is having to run V-HACD upon my meshes in order to bring them into convex shapes. It takes forever and the result isn't completely accurate. Concave meshes would be really neat, especially for things such as terrain.

Thanks
Colin

Quaternion constructor should construct identity quaternion

As the title states. Right now it constructs an invalid quaternion, which would result in an assert if you were to use a default-constructed quaternion in the transform for a collision shape.

// Constructor of the class
Quaternion::Quaternion() : x(0.0), y(0.0), z(0.0), w(1.0) {

}

Btw, thank you for a splendid library! Very clean API, a breeze to work with 💯

EventListener seems to miss collisions

I'm trying to detect collisions between certain objects using a class that extends EventListener. I pass an ID of an object into the mUserData variable when creating a ProxyShape.

Each frame, the listener saves the ID of the two objects colliding in the newContact method. These two IDs are then checked outside to see if they match (if the player has collided with an enemy for example).

The code seems to work sometimes in Debug mode (collisions between certain objects are not always picked up), and doesn't work at all in Release.

Apologies if I'm using the library wrong as I'm still rather new to using physics engines.

Thanks

Can this library determine whether two objects in the three-dimensional space intersect?

Can this library determine whether two objects in the three-dimensional space intersect?
I use this library to test to determine whether two cylinders intersect in 3D space, I used rp3d :: CollisionWorld world;
I assume three cylinders: 1: the starting point is (0,0,0) the ending point is (10,0,0) the radius is 0.4; 2: the starting point is (10,0,0) and the ending point is (15,0,0 ) Radius of 0.4; 3: starting point (5,0,0) ending point (15,0,0) radius of 0.4;
Test results 1 and 2 Contact, 1 and 3not Contact.

Feature request: Locking movement along axes

Hi,

I am working on a dynamic character controller, and it would be great to be able to lock linear/rotational movement along certain axes for a given object. Something along the line of

body->setAngularFactor(rp3d::Vector3(0.0, 0.0, 1.0));
body->setLinearFactor(rp3d::Vector3(1.0, 0.0, 1.0))

Would be really, really handy.

Thanks!

Suggestion for soft-body physics: ShapeOp

I have found an interesting toolkit that should run very quickly and accurately and its API is quite nice.

http://shapeop.org/

It's a rather easy to use constraint solver with a tidy API. It's got a brief example and the code is self-documenting. It's MPL-licensed, which seems quite reasonable. Also of interest might be http://www.gecode.org/ but its far bigger and more full-featured and it can be somewhat difficult to grasp. However, its MIT-licensed and also offers far more features (not necessarily limited to topology and physics sim) and volumes of documentation.

I would be up for collaboration in mid-July.

Ray Collision

The project is very good but it misses Ray Collision with other Bodies or Rays. It would be great if it could be implemented.
And thank you for this wonderful project

addCollisionShape() fails assert in debug build

Using GCC 4.9.3 (on Gentoo.) Both master and develop branches exhibit this behaviour. Works fine for release builds.

/home/noob/noobgame/engine/lib/reactphysics3d/src/body/RigidBody.cpp:216: virtual reactphysics3d::ProxyShape* reactphysics3d::RigidBody::addCollisionShape(const reactphysics3d::CollisionShape&, const reactphysics3d::Transform&, reactphysics3d::decimal): Assertion `mass > decimal(0.0)' failed.

Please ask if you need more info.

Implement a plug-in to use ReactPhysics3D in PEEL evaluation tool

PEEL is a tool designed to evaluate, compare and benchmark physics engines written by Pierre Terdiman.

You can find a description of PEEL here.

It would be very useful to develop a plug-in to be able to use ReactPhysics3D in PEEL.
This way, we would be able to evaluate and compare ReactPhysics3D with other physics engines.
It would also allow us to find parts of the engine that need to be optimized.

The source code of PEEL is available here.

If anyone is interested in implementing this plug-in, please let me know.

Some questions about your document, Constraints Derivation for Rigid Body Simulation in 3D

With the help of my friends out of China, I can read your document, finally. But I still get some questions about this document.

  1. In your document, you just write about how to solve constraints on the velocity level.
    void BallAndSocketJoint::solveVelocityConstraint(const ConstraintSolverData& constraintSolverData) {

    In the source code, you also give us the solution on the position level.
    void BallAndSocketJoint::solvePositionConstraint(const ConstraintSolverData& constraintSolverData) {

    And I found Jan Bender use the same manner to deal with position constraints in his project which is a implementation of his paper.

I want to know if you have the derivations on the position level.

  1. In your document, you just write in page 6 that

In general, the velocity constraint looks like this: Equation (16).

Why does velocity constraints look like Equation (16)?

inconsistent description about collision shape

User Manual:

First note that when you add a collision shape to a body, the shape will not be copied internally. You only give a pointer to the shape in parameter. The shape must exist during the whole lifetime of the body. This way, you can create a collision shape and reuse it for multiple bodies. You are also responsible to destroy the shape at the end when the bodies are not used anymore.

Testbed Code Comment (common/Sphere.cpp):

// Create the collision shape for the rigid body (sphere shape)
// ReactPhysics3D will clone this object to create an internal one. Therefore,
// it is OK if this object is destroyed right after calling RigidBody::addCollisionShape()
mCollisionShape = new rp3d::SphereShape(mRadius);

The User Manual and code is consistent. But the comment is expired.

Possible EPA Algorithm Issues #2

There is one more issue with the EPA I've discovered and that is when case 4 falls through to case 3. When it attempts to fix the bad vertex (line 249) it will set it to a point that never exists (point #5). It never exists because we jumped to case 4 because we knew we got 4 points from the simplex. I'm not sure how C++ handles this if you would get a null pointer of if the array was initialized to contain all dummy objects. This case of it falling through from 4 into 3 only seems to happen for cylinders for me and is very rare so it is difficult to reproduce.

Got 3 from the simplex.
Case 3 is starting.
Case 3 is falling through breaking out of the switch.
Normal: (x= -6.16584E-5, y= -1.0, z= -8.335716E-6) Depth: 0.63282037
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex 0.
Got 4 from the simplex.
Case 4 is starting.
Case 4 had bad vertex less 4: 1
Case 4 is falling through to case 3.
Case 3 is starting.
Oct 06, 2014 11:40:19 PM net.smert.jreactphysics3d.framework.Application$1 run
java.lang.NullPointerException
at net.smert.jreactphysics3d.mathematics.Vector3.subtract(Vector3.java:238)
at net.smert.jreactphysics3d.collision.narrowphase.EPA.EPAAlgorithm.computePenetrationDepthAndContactPoints(EPAAlgorithm.java:323)
at net.smert.jreactphysics3d.collision.narrowphase.GJK.GJKAlgorithm.computePenetrationDepthForEnlargedObjects(GJKAlgorithm.java:197)
at net.smert.jreactphysics3d.collision.narrowphase.GJK.GJKAlgorithm.testCollision(GJKAlgorithm.java:309)

Assert crashes if trying to update an empty physics world

A simple check at the top of the update function fixes this for me:

// Update the physics simulation
/**
 * @param timeStep The amount of time to step the simulation by (in seconds)
 */
void DynamicsWorld::update(decimal timeStep) {

    if (mBodies.size() < 1)
    {
      return;
    }

    // Rest of function goes here ...

FixedJoint (and SliderJoint) don't seem to work when bodies are rotated with non-identity transform

Hello,

I'm trying to implement the Fixed/Slider joint as described in your article:

http://danielchappuis.ch/download/ConstraintsDerivationRigidBody3D.pdf

and I'm running into issues trying to implement the rotation constraint when the bodies have an initial relative rotation other than identity (mInitOrientationDifferenceInv != identity).

I then tried the same in your code to see what happens and it looks like it has the same problem. If you add the following lines in JointsScene::createFixedJoints:

...
mFixedJointBox1 = new Box(boxDimension, positionBox1 , BOX_MASS, mDynamicsWorld);

// NEW CODE!
rp3d::Vector3 initPosition(5, 7, 0);
rp3d::Quaternion initOrientation = rp3d::Quaternion(0.4f * PI, 0, 0);
rp3d::Transform transform(initPosition, initOrientation);
mFixedJointBox1->getRigidBody()->setTransform(transform);

// Set the box color
...

You will see that the box that is being spinned around on the propeller starts jittering heavily (the closer you get to half PI the more is starts to jitter, but a rotation of 0.1f * PI misbehaves too).

I have the feeling that eq 129 is not the same as SliderJoint.cpp:

const Vector3 errorRotation = decimal(2.0) * qError.getVectorV();

So far I've been unable to put my finger on what is going wrong. Do you have any idea?

Regards,

Jorrit.

Optimization opportunity: OpenMesh

Hi,

I have looked at the implementation for convex shapes, and they use an std::map.

The TriMesh class from OpenMesh (http://www.openmesh.org/) uses a more efficient (array-based) data structure and has O(1) nearest-neighbour circulators. It also has excellent decimation/subdivision algorithms, which may come in handy as a potential optimization.

It recently got relicensed to BSD.

AngularDamping seems unable to stop a rotating Sphere

As title, it seems that a RigidBody with only a ShapeSphere will never stop spinning due to only AngularDamping. The damping is working, in that it slows fast-spinning spheres, but only to a certain point. This is difficult to explain, but you can see the effects by placing some spheres with 0 friction on to a large surface with also 0 friction and moving them. They will move until they gradually stop due to VelocityDamping, but they will never stop spinning. In fact, they always seem to settle on specific spinning speed unrelated to what you actually have AngularDamping set to.

This issue can also be seen when you do have friction on, where spheres will instead roll forever at the same constant speed. Am I missing something, or is this a bug / not yet implemented feature?

Missing collision resolving/reporting for some static rigid bodies with dynamic rigid bodies.

Hi,

I am integrating RP3D 0.7.0 into my 3d engine TDME2. Everythings starts to work. This is nice.

But I have issues with some static rigid bodies that do not seem to be taken into account if a dynamic rigid body collides with them.

I have an example video where you can see the issue:

I have extracted a simple test case using capsules here:

It spawns 6 static capsules(with a height of 20m) and 2 dynamic(one small, one bigger) which can be moved by arrow keys. The place where the big dynamic capsule spawns 2 of those 6 static capsules will be used for collisions, all the others not - if you move the dynamic rigid bodies into them. You can change the code easily to spawn those 6 static capsules as dynamic and then all works.

Related files for capsule, creating rigid bodies and world management can be seen here:

My observations:

  • this seem to happen with larger static rigidbodies/objects
  • collision is computed if another larger dynamic rigid body is spawned at near by positions of those static rigid bodies
  • collision is computed if I spawn those static rigid bodies as dynamic rigid bodies(also setting a non rotation inertia inverse tensor(not sure about the name) and infinite mass (then they behave like static objects, but computation of large world is not working anymore performance wise)
  • I have debugged and tried a lot(RP3D AABBs seem correct, capsule height and radius seem correct, ...)

If you have any questions please do not hesitate to ask.
BTW. If spawning them all as dynamic rigid bodies like described above all my problems seem to be gone with our game prototype. So maybe its a stupid issue only.

I am looking forward to hearing from you soon:

Best regards
Andreas

Hit an assert in DynamicsWorld::integrateRigidBodiesVelocities

Hi,

I am hitting an assert when moving a dynamic rigid body into a static rigid body(also into a collision body).

Assertion failed: (mSplitLinearVelocities[indexBody] == Vector3(0, 0, 0)), function integrateRigidBodiesVelocities, file ext/reactphysics3d/src/engine/DynamicsWorld.cpp, line 297.

The game crashes then. Also when disabling asserts.

The backtrace looks like:

(gdb) bt
#0  0x00000000005c0030 in reactphysics3d::CollisionBody::updateProxyShapeInBroadPhase ()
#1  0x00000000005bfe1d in reactphysics3d::CollisionBody::updateBroadPhaseState ()
#2  0x00000000005a993c in reactphysics3d::DynamicsWorld::updateBodiesState ()
#3  0x00000000005a88c7 in reactphysics3d::DynamicsWorld::update ()
#4  0x00000000004709a4 in tdme::engine::physics::World::update ()
#5  0x00000000004172f6 in asw::ASWClientGameLogicThread::run ()
#6  0x00000000004f055a in tdme::os::threading::Thread::pThreadRun ()
#7  0x0000000801ef9bc5 in pthread_create () from /lib/libthr.so.3
#8  0x0000000000000000 in ?? ()

I will try to get a backtrace of debug build soon too.

Best regards
Andreas

Possible EPA Algorithm Issues

I've ported your physics library to Java and I've discovered what I think is a bug. I've double checked my code a few times on a few different occasions and didn't discover any errors. What I have discovered is that the EPA algorithm doesn't seem to handle all the cases correctly though I lack understanding to fix it myself. The error is also present when I build your library from source but for the case of cylinders it doesn't visually show any problems. It is only the case of a cone in your library do I see the same glitches. The other shapes such as boxes, capsules, spheres seem to never hit EPA and don't suffer from the issue.

I've narrowed it down to case 3 of the EPA algorithm were we have a triangle from the simplex and we are going to be adding to more points to create a hexahedron. When that case occurs for cylinders or cones I always end up with a very large penetration depth (1.0-2.5) and the collision object bounces very noticeably. When we get out of the switch statement it seems that "!triangle->computeSilhouette" (line 380) eventually is false and that is how we break out of the loop. There are new face candidates being added too (line 388) and the amount differs. It seems like the other cases that start with 4 vertices work well break out above during computing the error (line 369). This appears to happen in all of the cases I've seen and I've done it quite a number of times. Hopefully knowing the path of the code through the failure case is helpful.

If I comment out case 3 from my code completely the jitter is gone and everything appears to be well. There are still a few cases where previously stable objects are unstable (seen boxes jitter, and cones sitting on their base, though rare) because that case no longer exists (I assume). Commenting out the code fixes much more of the problem than it causes.

I'm not sure what it is about the face candidates from case 3 that causes the issues. I can also keep all code in my port except for adding the 6 faces (lines 310-315) before it exits from the switch statement and it will be just as stable as well.

To reproduce this issue you must enlarge the floor to at least 50x50.

reactphysics3d-epa-bug

In my code I set a flag when case 3 occurs and printed out the normal and penetration depth. I've used my own demo Collision Test to rotate the cylinder laying horizontal and move it across the floor

reactphysics3d-epa-my-port

Normal: (x= 6.2596635E-5, y= -1.0, z= -2.7572327E-5) Penetration depth: 2.5595193
Normal: (x= 1.0021483E-5, y= -0.9990377, z= 0.043859735) Penetration depth: 1.332282
Normal: (x= 3.6370513E-4, y= -0.9999998, z= -3.652762E-4) Penetration depth: 2.4280725
Normal: (x= 0.06166201, y= -0.99787545, z= -0.021030152) Penetration depth: 1.5822806
Normal: (x= -0.025286067, y= -0.9986612, z= 0.045127083) Penetration depth: 1.1724211
Used memory: 8% 78MB of 910MB
Normal: (x= -6.6948305E-5, y= -1.0, z= 1.19019205E-5) Penetration depth: 2.5640886
Normal: (x= -2.457223E-5, y= -0.99926066, z= -0.03844618) Penetration depth: 1.6300646
Normal: (x= 0.011597331, y= -0.99966383, z= 0.023188038) Penetration depth: 0.5759545
Normal: (x= 0.017189197, y= -0.9987077, z= 0.047828164) Penetration depth: 0.94106925
Normal: (x= -0.03228135, y= -0.99944663, z= 0.008018183) Penetration depth: 1.1154096
Normal: (x= 2.4790124E-6, y= -1.0, z= 3.3053498E-6) Penetration depth: 2.3081958
Used memory: 8% 81MB of 910MB
Normal: (x= -8.2760596E-7, y= -1.0, z= -5.7932416E-6) Penetration depth: 2.304658

In case you need to see my code it is available at: https://github.com/kovertopz/jReactPhysics3D

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.