Hi @rasmusbarr ! Wonderful project! Coding a mini physic engine in a single .cpp file must be a tough challenge!

However, I posted this just to say that I've compiled it for Linux (I'm using Ubuntu 16.04 LTS 64bits), with the following changes to main.cpp:

#ifdef __APPLE__
#include <GLUT/GLUT.h>
#include <OpenGL/gl.h>
#elif _MSC_VER
#include <GLUT/glut.h>
#include <gl/gl.h>
#else // linux
#include <GL/glut.h>
#include <GL/gl.h>
#endif
// Not sure about mingw (if it's like linux or like _MSC_VER)

I just used this command line from the example folder::

g++ --std=c++11 main.cpp -o main -I"./" -I"../" ../nudge.cpp -lglut -lGL
# Or:
# clang++ --std=c++11 main.cpp -o main -I"./" -I"../" ../nudge.cpp -lglut -lGL
#  optionally use --march=haswell (Using 8-wide AVX FMA: Enabled)

Without --std=c++11, g++ produces a lot of errors. Strangely, using clang It compiles with only the following warnings:

../nudge.cpp:2928:41: warning: default template arguments for a function
      template are a C++11 extension [-Wc++11-extensions]
template<unsigned data_stride, unsigned index_stride = 1, class T>
                                        ^              ~
../nudge.cpp:2973:41: warning: default template arguments for a function
      template are a C++11 extension [-Wc++11-extensions]
template<unsigned data_stride, unsigned index_stride = 1, class T>
                                        ^              ~
../nudge.cpp:3030:41: warning: default template arguments for a function
      template are a C++11 extension [-Wc++11-extensions]
template<unsigned data_stride, unsigned index_stride = 1, class T>

However these are just details. Thank you for this project!

Hi again.

Today I'm playing a bit with the nudge demo, and I've hit the assertion in the title when I increase the total number of bodies. The comment in nudge.cpp says:

// Too many colliders. 2^13 is currently the maximum.

The question is: Is it related to the number of bodies or to the number of collisions between bodies?

Basically my settings are:

#define NUM_BOXES 1024*4
#define NUM_SPHERES 1024*4 //1024*3 works fine
#define MAX_BODY_COUNT (NUM_BOXES+NUM_SPHERES+1) // +1 = ground box
static const unsigned max_body_count = MAX_BODY_COUNT;
static const unsigned max_box_count = NUM_BOXES+1;      // +1 = ground box
static const unsigned max_sphere_count = NUM_SPHERES;
#define ARENA_SIZE (32*MAX_BODY_COUNT*MAX_BODY_COUNT/4)

P.S. However if I use 1024*4 boxes and 1024*3 spheres it works perfectly. This is a .gif with:

#   define NUM_SIMULATION_STEPS 1
#   define NUM_SIMULATION_ITERATIONS 5 // These seem to be enough to me...
// I've also doubled all the body masses

This single .cpp physics library seems really powerful :+1: !

Hey,

Skimming through your code and found something that seemed a bit strange, though I don't understand the structure well enough yet to say its an error for sure. But in the loop around line 3778, I saw this:

		a -= colliders.boxes.count;
		b -= colliders.boxes.count;
		
		SphereCollider box = colliders.spheres.data[a];
		SphereCollider sphere = colliders.spheres.data[b];

I'd imagine it should be sphere in place of box in those lines?

Compiling with GCC 8 causes a compile error:

../../nudge.cpp:454:56: error: cannot convert ‘nudge::simd8_float {aka __vector(8) float}’ to ‘__m256i {aka __vector(4) long long int}’ for argument ‘1’ to ‘__m256i _mm256_permute2x128_si256(__m256i, __m256i, int)’ return _mm256_permute2x128_si256(x, x, i0 | (i1 << 4));

Using clang/LLVM 5 works just fine. Not yet sure if this is a bug in gcc or not.

@rasmusbarr in case it's not, would you like to give some pointers regarding the convex collisions, cache information about the previous contacts and other issues listed in your blog post under the "Future work" section?

It is not bug but I think it is somewhat misleading that boxCollider's real extent seem to be size*2. So it is analogous to sphere's radius. I have checked ODE box create gets real side lengths. Bullet's box collider gets halfExtent. https://github.com/rasmusbarr/nudge/blob/master/nudge.h#L57

This is not an issue, I just didn't manage to add a comment on your article with a twitter account...

I really like this lean and mean API design. Probably needs a higher level interface for adding removing bodies/colliders etc but it is very easy to add on top of this. And I think an interface like this is way better than traditional OO interfaces like bullet3d with a hundred .h files and tons of classes with public functions and of course ( with private/protected stuffz that a user didn't really care about)

About the multithreading, how about an interface like this?

generateJobs(JobsData* j); bool doJob(JobsData* j, int processJobCount); void waitForJobs(JobsData* j)

threads could call doJob so JobsData needs to be thread-safe, I think an atomic int could be enough for stepping. JobsData could also store number of finished jobs with atomic int for waiting, or could implementing with some higher level multithreading primitive to avoid spinning.

or instead of the two fuction ( doJob, waitForJobs) maybe bool doJob(JobsData* j, int processJobCount, bool waitForFinish);