Improvements and ideas

[louis-langholtz]

From @Genbox on April 2, 2017 11:46

Hi Louis,

I've seen you active around the Box2D project, and it seems like you are keen to improve it and add features. I'm working on Velcro Physics, which is a Box2D port in C#, but extended with many new features such as path generators, better performance, concave polygons etc.

I'm interested in your port as it seems like you made some improvements and new features, but I have a hard time going through hundreds of files and look for them, so could we have a discussion here on what improvements you have made?

Copied from original issue: louis-langholtz/Box2D#12

[louis-langholtz]

@Genbox Thank you for contacting me and expressing your interest in my fork of Box2D!

I've been using the top-level REAME.md file to provide an overview of the changes that I've made in my fork. I believe it should be the file that GitHub presents at the top-level of the fork. Sounds like this information isn't as easy to find however as I'd like it to be.

Here's the "run-down" that I've mentioned in that file:

• Exported symbols are now within the library namespace of box2d and are no longer preficed by b2.
• Mutable global variables in the library have been removed or replaced with runtime-time parameters.
• Preprocessor defines, except those used for include guards, have been replaced with C++ solutions or removed from the API.
• Rounded corner collisions.
• Capsule shapes (using 2-vertex PolygonShape instances).
• More stable polygon stacking.
• Shared shapes with friction, density, and restitution moved into them (from Fixture class) for reduced memory usage.
• Support for C++11's range-based loops and constant expressions.
• Unit tested via Google Test and over 400 tests.
• Compile-time support for double and long double floating-point types and 32-bit and 64-bit fixed-point types (in addition to float).
• Fully per-step run-time configurable (via StepConf).
• In-depth per-step return value statistics (via StepStats).
• Increased construction-time configurability of world instances (via World::Def).
• Various methods have been rewritten to be non-member non-friend functions.
• Various functions and procedures have been rewritten to be "pure functions".
• Testbed enhancements: per-step configurability, per-step statistics, ability to manipulate bodies while paused, and more.
• Testbed test additions: Half Pipe, iforce2d's Topdown Car, Orbiter, Newton's Cradle, and Spinning Circles.

I've been considering putting this information into a CHANGES file in the hopes of making it easier to find. Please let me know if you have any suggestions to this effect. Another place on GitHub where I've been documenting this kind of info is in the Projects tab. Hmm... maybe the Wiki would be even better for this.

[louis-langholtz]

From @Genbox on April 6, 2017 20:38

@louis-langholtz I should have clarified. I read the list of changes you made in the readme, but I just expect there to be more hidden in the ~1400 commits you have made. There always are :)

Your list is a place to start. Velcro Physics is written in C# where many of the changes you have made (namespaces, solution, global variables, non-member function etc.) is best practices, so I already did them way back in 2007 when I first ported Box2D. However, I'm very interested in rounded corner collisions, stable stacking and the physics stuff, as I think it can really improve the physics experience.

I'd also be very interested in the unit tests you wrote (wow - 400 seems like a lot). I am a big fan of formal verification, and I always planned to have code contacts implemented, but since Microsoft pretty much killed it along with XNA (the framework I used for drawing in Farseer Physics Engine), I have to fall back to comprehensive unit tests instead.

[louis-langholtz]

Thank you for the clarification.

Erin Cato wrote about the mathematics he used in publications that I've read which have impressed me. I'd like to do the caliber of formal mathematical analysis that he's done but I'm afraid my math skills right now aren't up to his level (particularly in regards to differential equations - ODEs and PDEs). If they were, I'd love to relate what I did regarding rounded corner collisions and other physics stuff that way.

I have made some posts in which I discussed the physics changes in what I suppose could be called more like "layman's terms". My posts haven't been comprehensive either as really I've been having a blast working on evolving the C++ library into my own vision for it and haven't paid much attention to documenting about it; perhaps at least not as much as I should.

What do you see a conversation about the physics changes looking like or what would you like that to look like?

[louis-langholtz]

From @Genbox on April 7, 2017 22:43

I guess I will have a better idea once I dive into the code and dig up some of the changes. For now, I have to go though ALL of Box2D and synchronize my port with changes made the past 4 years. After I'm done with that, I'll come back here and take a deeper look into what changes you made.

As for the formal verification, I'm much like you. Eric is on a level I can only dream of, so most of the formal verification will be against a specification based on behavior rather than the math. It is more setting up some constraints on what input/output a method works with, and then have a static analysis tool sit in the background and analyse if you break those rules at any point in time, while developing.

[louis-langholtz]

Just an FYI update to this thread: I just added compile-time support for strongly-typed physical units. So no more needing to guess what the units are supposed to be for any given functions (unless they required unit-less, a.k.a. dimensionless, value like ratios). So for example, if the function or method took a length, it now takes that parameter as a Length type where Meter defines the unit of that parameter.

[louis-langholtz]

From @Genbox on April 13, 2017 11:0

Are those some sort of type constraints in newer versions of C++? I mean, like functional languages where you can define an integer to have only the numbers from 5 to 10?

[louis-langholtz]

This new units interface places no restrictions on the range of the values; only on the types of the values.

That said, I've also been working on ideas and code for doing range restrictions. Some of which is already in place. Like for iteration count types such as ts_iters_t which is for time step iterations and restricts the range to positive integers between 0 and 255. That just trivially uses an underlying unsigned 1-byte data type (std::uint8_t) however.

[louis-langholtz]

From @Genbox on April 13, 2017 22:17

I've just stumbled upon one of the things I made this issue for.
I ported over some of your unit tests for AABB and noticed it failed. However, my code was right and it failed in Box2D as well, so I looked other places where you had differences, and finally found that you do some reordering in the AABB constructor.

Since the engine itself would never give an AABB in the wrong order, I think it would be for the better to implement it only for user supplied data for performance reasons.

[louis-langholtz]

From @Genbox on April 13, 2017 22:32

I only now notices that Box2D never uses the constructor itself, only user supplied data goes in the constructor.

[louis-langholtz]

Is there an improvement you have in mind for the AABB class then? I'm not sure that I understand your last two comments about the AABB implementation/design but would like to be sure. :)

[louis-langholtz]

Just looked at the use of the AABB class more. Yes, there are places in the code where the AABB gets initialized with already minimized and maximized points only to have the constructor recheck that to ensure it's invariant about that.

I am updating the AABB interface to avoid this recheck while still being able to enforce the invariant.

[louis-langholtz]

Update: with commit d361c51, I've just introduced what I consider a major change to the Manifold calculation mechanism.

By design, this change does away with need of "ghost-vertices" at least for level surfaces. For a tutorial on what "ghost-vertices" are and why they were necessary see iforce2d's Box2D C++ tutorials - Ghost vertices.

A shortcoming with the "ghost-vertices" solution was that it only solves the polygon getting stuck while being dragged across chained edge-shapes problem. It doesn't apply to dragging a polygon across a level floor made of rectangles for instance. The new manifold calculation mechanism though solves this problem for any shapes forming a level surface.

[louis-langholtz]

Commit a952a62 introduces vertex-radius respecting RayCast functionality for all shapes now (not just for circle shapes anymore).

[louis-langholtz]

From @Genbox on April 30, 2017 9:28

Wow Louis.

I have a couple of questions:

1. I'd love to get rid of ghost vertices. They create confusion for the users and should really be an internal thing. I've gotten rid of most of the confusion by creating a factory that assembles chainshapes and hook up vertex0/3 automatically. I'm sure Erin is very interested in your solution.

2. What does vertex-radius respecting raycast mean? I thought radius (in Box2D) was mainly used for the CCD.

3. It seems DistanceProxy etc. exist to create a clean separation between algorithms. It seems you are removing them in your refactorings - is there a reason for that?

[louis-langholtz]

From @Genbox on April 30, 2017 9:44

I tested the performance of different line intersection algorithms, I found that it is sometimes faster to do a quick AABB check before the intersection code. The AABB check is just a couple of range comparisons compared to at least 2 div instructions and sometimes sqrt. It might be different with C/C++ compilers though which are usually more aggressive in their optimizations compared to C#.

[ninnghazad]

dynamic/relative penetration/slop sounds nice. maximum usable scale differences are of importance to me at least - and proper interaction between something human-sized and possibly moon-sized (or at least multiple magnitudes larger) sounds awesome. i'd gladly trade performance for possibility in that case.
as @Alan-FGR said, it might be an edge-case. then again - as long as it isn't easily possible, of course it is.
think kerbal-space-program in 2d, surely would be fun. they use some heavy tricks to simulate at largely different scales - would be nice to be able to do something like that with an out-of-the-box physics lib and without rescaling the whole world or the like. but yeah, space-stuff mainly i guess.
a dynamic approach to penetration/slop however i'd image to be beneficial aside from the whole stellar-scales thing. maybe i am imagining it wrong, but having TOI-overlap relative to colliders' size seems like a good idea.

[Hexlord]

I've seen some interesting idea in gpu-physics.js by schteppe: gif maybe interpreting small objects as radius-vertex geometry instead of volume geometry when interacting with big objects can ease resolving the conflict, maybe even consider a group of small objects as an area-rectangle interacting with big object, but that for sure will require lots of nancy stuff, just the extra thoughts.

Relative slop & penetration may help, but the performance hit is still tremendous for TOI when huge asteroid of 500 fixture-triangle geometry flies upon 100 tiny triangles. I know very few how this stuff works, but the TOI not being optimized for multiple contacts incoming is an experimental observation as it lags all the way since small stuff is radius-close to the big object, that's when TOI starts to predict solving equation or something. That is not a very common scenario yet it happens.

[ninnghazad]

@Hexlord performance hit: huge astroid could be represented by single/few chain shapes or chained boxed just representing it's surface. worked way faster for me when doing some tests with box2d a while ago. and the 100 tiny triangles, should they all be of equal size, could be done using particlesystem like in liquidfun. if it's 100 unique objects, i guess that'll be slow(er) even without any astroids around.
EDIT: well, the triangles would have to be round triangles also ;)

[Hexlord]

@ninnghazad yep, but chain shapes do not support holes. triangles are just the result of triangulation of geometry with holes, so liquidfun solution sadly won't work. 100 small objects work just fine if they meet small objects like eachother... Well that seems to be quite another problem as one mentioned before, yet still.
Thank you for the note, I'll try to optimize it by splitting geometry to be hole-less with multiple chain shapes connected, maybe this will actually help in a way.

[louis-langholtz]

Incidentally, I've been considering what it'd take to implement a "negative" of a shape for implementing holes. I'd like that very much as we could for example have an inner disk (circle) shape be the negative of an outer one and have fully round rolling without jagged approximations.

I believe that the plausibility of negative shapes has some corroboration in the implementation of the false condition of the joint collide connected property. It may be a while to implement negative shapes though since I first want to refactor contacts and joints into being subclasses of a constraint base class and then develop a better understanding of how ordering effects simulations. Ordering I can see then begetting constraint hierarchy which seems necessary for negative shapes.

[louis-langholtz]

@Hexlord Help me understand what you're describing in:

Also wanted to note that an option (#define or smth) to disable vertex radius collision would be priceless in scenarios where performance is extremely important as it is the only extra functionality of playrho that you pay for with your very blood.

Do you mean simulating only velocity and acceleration and not simulating collisions? If you could reference specific code perhaps, that'd help me a bunch!

Also, it's absolutely critical to make sure that we're using a release build of the library — i.e. with compiler optimization enabled to the fullest (-O3) and assert's disabled with the NDEBUG pre-processor macro defined — when looking into any speed related performance issues.

[Hexlord]

@louis-langholtz Sorry for my puzzling description of what I mean. I did not inspect the new code very precisely, but it seems like some checks are unavoidable even if all vertices of all the bodies have 0 radius, slowing the performance. They seem relatively cheap for 0-radius case, but still that is the only misstep from max-performance way, so that probably should be optional (#ifdef PLAYRHO_VERTEX_RADIUS or smth).

I support run-time configuration, but this functionality is high-load and four if-s can really mess the cpu performance...

[louis-langholtz]

@Hexlord I agree that four if's looks concerning but how concerning is it on a given hardware architecture in terms of reliably measurable performance loss? I ask because I don't know.

My hope is that the Benchmark application will be increasingly used to measure these places (by calling the existing routines) and also to measure alternative coding strategies. Alternative functions can be added directly within the Benchmark itself to start with and possibly get migrated into the library as they prove useful.

In terms of preprocessing out some of the GetFaceManifold code like you're suggesting, I believe that could change the operational semantics in ways that become less consistent. The TOI code for instance needs to be in sync with the concept of the skin. If the skin shape changes, then the TOI calculating code also needs to be updated to reflect this shape. Part of what got me to do the rounded corner skin shapes to begin with was a concern that was growing for me that the TOI calculating code in Box2D was measuring as though the skin was rounded while the manifold generating code wasn't returning manifolds that reflected similarly rounded corners. This reminds me that I've been meaning to revisit the PlayRho unit test code to ensure this kind of consistency.

Incidentally, what I'm more sure of is that I really dislike the length and complexity of the GetFaceManifold function starting with its parameters (8 of them and I blame myself in part for its length and complexity). I want to believe that the whole way it's doing its stuff could be done more simply and that refactoring it can improve execution speed too.

As another related side note, the alternative method for detecting almost equal that you'd provided for instance showed itself to be faster (which I saw after I increased the sensitivity of many of the tests in the benchmark application). It or the almost equal related unit tests however need some tweaks worked on since they don't match up exactly and can only be used on platforms where float and double are is_iec559 compliant I believe (in case you're interested in that 😄 ).

[Hexlord]

@louis-langholtz
I would reference Migdalskiy' talk, slide 46 proves it to be a maximum of ~60 extra ticks due to misprediction (4 connected if branches), which is, given random Radius distribution between being zero and non-zero would give aprxly 30 * num_vertex extra ticks per frame, given 3 GHz cpu and 10000 vertices processed that is an extra 0.1 ms.

Actually if you always use zero radius that would be just one tick thanks to prediction, so not a problem at all...

Cool stuff! Could be an experimental feature, but probably its win is not considerable in the whole simulation.

[NauticalMile64]

Just for reference, I'll note that Algodoo gives the ability to use shapes to clip one another, kind of like Snipperclips. Closed source code though :(

[Alan-FGR]

@NauticalMile64 yes but it converts those clipped shapes into polygon shapes, so basically it's just a way to edit polygon shapes; internally it doesn't support a colliders described by booleans I think (I'm pretty sure).

[iderik]

Hi, it seems flipping (vertically) bodies in Box2D is an obstacle for many users, since its quite common for 2D games with a side perspective.

I did recently came into this problem, which feels like a dead end for my project. Imagine I have an excavator with multiple joints (wheels and a boom, which has a bucket jointed to it). If its facing a direction and then wants to move the other way, it has to flip/mirror/reflect vertically.

Currently, the only solutions are quite complex. Recreating all the bodies, shapes, fixtures and joints, plus all the joints' bodies. Or having pre-created bodies of both directions and "hide" one of the direction from the Box2D and switch when a flip needs to happen.

I was wondering what do you think about this and if a feature to simplify this would have a chance to be implemented. It would really help us less experienced users and may be migrate more Box2D users over to PlayRho.

[louis-langholtz]

@iderik Hello and thanks for your suggestion!

Here's some thoughts that come to me at the moment regarding your proposal.

The flipping that you're asking about sounds in part like a reflection transformation matrix applied to the coordinates of the shapes in order to derive reflected shapes. A free function operating over an iterable range of shapes that mutated those shapes per the transformation sounds doable and appealing to provide.

This could probably benefit from extending the Shape concept to include a transform operation. I've created issue #283 now to add this extended functionality to the Shape class. Such work may also help with issue #276. I've also created issue #285 for adding code that produces the reflection matrices needed for transforming shapes against a given direction through the origin.

Reflecting joints sounds like another part to what you're asking for. I think it'd be a more involved than the former part of this and probably has to be done on a joint type by joint type basis. I've been considering a redesign of joints to replace the use of public inheritance with the same kind of on-use polymorphic design that Shape now uses. I mention that because it may be worth waiting till that gets done to tackle this other part of what you're asking for.

I suspect the overall functionality would still need to effectively do the complex solution. I like the idea of providing free function code that takes care of those details however so to the user this at least looks simpler.

[louis-langholtz]

From @Genbox on April 2, 2017 11:46
...
I'm interested in your port as it seems like you made some improvements and new features, but I have a hard time going through hundreds of files and look for them, so could we have a discussion here on what improvements you have made?

I've just merged in pull request #346. This introduces some new changes that I'm very excited about and greatly improve this library in my opinion. Here's a partial list of these improvements:

• Switched to value semantics. User code no longer deals with pointers to bodies, fixtures, contacts, nor joints. The API instead uses strong-typed indexes to reference them. Besides value-semantics being easier to reason about, this has opened the doors to more contiguous - i.e. cache friendly - memory accesses.
• Moved the implementation behind a compilation firewall. The World class is now just a PIMPL holding wrapper. This will facilitate future optimization work with less need to change the binary interface to user applications.
• Extended the use of polymorphic values to joints. The Shape class design was already providing a polymorphic value type and now the Joint class does as well. Derived classes of Joint - like RevoluteJoint - have been replaced with the instantiation of the Joint type with the value of any type supporting the Joint concept. So, for example, now creating a RevoluteJoint is instead done by creating a joint with a RevoluteJointConf value.
• Behind the scenes, low level implementation details have moved to the WorldImpl class and there are no longer any friend classes that co-mingle in the implementation.

[louis-langholtz]

Just an update to this topic...

My most recent experimental work has been on a redesign of the fixture-and-shape types. If you're interested in what the actual code changes may look like, please take a look at the shape-id-design branch.

Fixtures have historically been like body specific customizations of shapes. Another way to look at fixtures, is as attributes, that all attachments of parts to bodies, have in common. Things like: the mass-data (such as mass-areal density), filter-properties, and the shape-body pair that this data associates with.

In software I've already release, I'd begun moving some of these attributes around and had for instance shifted the mass-data to the Shape class. Motivation for this change came from trying to share more data, based on more common usage patterns, and reduce the overall memory requirement for a more typical simulation. And as a consequence, also speed up results.

This redesign has taken this idea further by eliminating the Fixture type (or FixtureConf type in PlayRho terms), altogether. I've moved all the FixtureConf data now into the Shape polymorphic value type. So in this branch, one would no longer create fixtures to associate shapes with bodies. Instead, one would create the shape with all its fixture-like properties, and then associate it with the body. Currently, the function name for create the shape is CreateShape, and the function name for associating it with the body, is Attach. Like existing create functions, CreateShape returns a strongly-typed identifier (for the shape newly copied to the world). Attach is then called as Attach(bodyID, shapeID). This effectively updates the world's notion of shapes associated with the identified body - i.e. updates the world's broad phase collision system in addition to remembering the new association.

With this redesign, memory-wise, instead of each reference to a shape basically taking 16 bytes (on clang-LLVM based builds), the new identification based references take only 2 bytes. That's not so much for a single shape but for say a simulation with 1000 bodies each formerly having 1 fixture and all using the same shape, this represents a change from 1000 * 1 * 16 = 16,000 bytes to 1000 * 1 * 2 = 2,000 bytes. I.e. we get a savings of seven-eighths (7/8) of memory usage over the current design just in terms of referencing shapes. Additionally, because IDs are used to reference shapes, the Shape polymorphic value type uses a std::unique_ptr instead of the std::shared_ptr (as used in the current master branch). That saves an additional 8 bytes per shape.

Speed-wise so-far, for at least the TilesRestPlayRho benchmark, this turns out to be a performance loss however. That's been disappointing to me but I believe that:

1. The TilesRestPlayRho test is an atypical, if not misleading, simulation in that the ground body used is effectively a rectangle even though it's made up of 2000 unique shapes (or fixtures or attachments). The whole could more simply just be a single rectangular polygon shape.
2. The implementation of the shape-ID is that of using the integer index value into an array of shapes where each shape - as a polymorphic value type - is implemented using a std::unique_ptr. I suspect that instead of just simply always using a pointer to the type erased concept type, I could make use of a small buffer optimization to avoid having the pointer dereference of the shape ID to the underlying pointer to the underlying data for many cases which should help improve memory cache efficiency/locality.

So things are far from finished but I'm leaning towards eventually merging this change in and calling the result PlayRho 2.0.

[louis-langholtz]

Per point 1, here's benchmark numbers...

Master branch (with the combo ground setup):

Benchmark                               Time           CPU Iterations
----------------------------------------------------------------------
TilesRestPlayRho/12              15177255 ns   15161409 ns         44
TilesRestPlayRho/20              55322913 ns   55291500 ns         12
TilesRestPlayRho/36             404504642 ns  404429000 ns          2

The shape-id-design branch (with Box2D numbers also in it):

Benchmark                               Time           CPU Iterations
----------------------------------------------------------------------
TilesRestComboGroundPlayRho/12   25184685 ns   25168000 ns         24
TilesRestComboGroundPlayRho/20  130868469 ns  130816000 ns          5
TilesRestComboGroundPlayRho/36 1564876413 ns 1558970000 ns          1
TilesRestOneGroundPlayRho/12     18331436 ns   18321865 ns         37
TilesRestOneGroundPlayRho/20    107552081 ns  107516000 ns          6
TilesRestOneGroundPlayRho/36   1282195111 ns 1281744000 ns          1
TilesRestComboGroundBox2D/12     19332388 ns   19331765 ns         34
TilesRestComboGroundBox2D/20    120749830 ns  120710667 ns          6
TilesRestComboGroundBox2D/36   1389137492 ns 1388882000 ns          1
TilesRestOneGroundBox2D/12       17454538 ns   17443205 ns         39
TilesRestOneGroundBox2D/20      116607937 ns  116600333 ns          6
TilesRestOneGroundBox2D/36     1496316231 ns 1496031000 ns          1

This does appear to support the hypothesis that having the ground body made up of 2000 individual shapes is slowing things down in PlayRho. The difference however between ground as 2000 shapes v. ground as 1 shape doesn't fully account however for entire difference with the master branch PlayRho code which is unexpected. I'm continuing to investigate this.

I'm very curious now to see if a small-buffer-optimization of the Shape implementation data will account for the remaining difference and possibly be faster than the master branch code.

[louis-langholtz]

This new design also has appeal in terms of interaction with the broad-phase mechanism. In this context, storing the body-shape-child triplet seems more organic than storing a fixture-child pair or a body-fixture-child triplet. That's because, when storing a fixture-child pair, the body and shape invariably have to be looked up anyway. And, when storing the body-fixture-child, the fixture is effectively only half useful anyway since we already have the body and only the shape needs to be looked up.

Then there is also synergy with respect to body movements and broad-phase synchronization.

Conceptually, all of these synergies should add up to overall faster performance.

[louis-langholtz]

With the latest changes I've committed through commit ef285b19a, besides having more benchmark data to go on, I'm now seeing numbers that I'm happier about:

Run on (8 X 2600 MHz CPU s)
2021-05-25 14:30:22
-----------------------------------------------------------------------------
Benchmark                                      Time           CPU Iterations
-----------------------------------------------------------------------------
WorldStepPlayRho                              84 ns         84 ns    7192323
WorldStepBox2D                               442 ns        441 ns    1657860
WorldStepWithStatsStaticPlayRho/0             85 ns         85 ns    8114061
WorldStepWithStatsStaticPlayRho/1             94 ns         94 ns    7695352
WorldStepWithStatsStaticPlayRho/10           126 ns        126 ns    5285013
WorldStepWithStatsStaticPlayRho/100          501 ns        501 ns    1307776
WorldStepWithStatsStaticPlayRho/1000        5273 ns       5269 ns     127602
WorldStepWithStatsStaticPlayRho/10000      67783 ns      67758 ns       9917
WorldStepWithStatsStaticBox2D/0              413 ns        413 ns    1683352
WorldStepWithStatsStaticBox2D/1              424 ns        424 ns    1686093
WorldStepWithStatsStaticBox2D/10             466 ns        466 ns    1367455
WorldStepWithStatsStaticBox2D/100           1177 ns       1176 ns     547354
WorldStepWithStatsStaticBox2D/1000         20154 ns      20154 ns      35135
WorldStepWithStatsStaticBox2D/10000       327377 ns     327365 ns       2124
DropDisksPlayRho/0                            70 ns         70 ns    9720062
DropDisksPlayRho/1                           299 ns        299 ns    2221996
DropDisksPlayRho/10                         2812 ns       2812 ns     241981
DropDisksPlayRho/100                       34772 ns      34764 ns      20173
DropDisksPlayRho/1000                     379603 ns     379603 ns       1786
DropDisksPlayRho/10000                   3885011 ns    3884444 ns        180
DropDisksBox2D/0                             414 ns        414 ns    1674573
DropDisksBox2D/1                             789 ns        788 ns     840609
DropDisksBox2D/10                           5855 ns       5853 ns     106579
DropDisksBox2D/100                         77911 ns      77880 ns       9162
DropDisksBox2D/1000                       880560 ns     880400 ns       1238
DropDisksBox2D/10000                     5956764 ns    5944540 ns        100
AddPairStressTestPlayRho400/0            2364001 ns    2363605 ns        281
AddPairStressTestPlayRho400/10            733854 ns     733350 ns        938
AddPairStressTestPlayRho400/15            841933 ns     841521 ns        819
AddPairStressTestPlayRho400/16          15010743 ns   15010298 ns         47
AddPairStressTestPlayRho400/17          30706462 ns   30704136 ns         22
AddPairStressTestPlayRho400/18          49208583 ns   49206167 ns         12
AddPairStressTestPlayRho400/19          19338088 ns   19329200 ns         35
AddPairStressTestPlayRho400/20          14429098 ns   14424660 ns         50
AddPairStressTestPlayRho400/30           4429703 ns    4429157 ns        159
AddPairStressTestBox2D400/0              1456020 ns    1455928 ns        458
AddPairStressTestBox2D400/10              840024 ns     839786 ns        833
AddPairStressTestBox2D400/15             1168910 ns    1168590 ns        603
AddPairStressTestBox2D400/16            21608680 ns   21608032 ns         31
AddPairStressTestBox2D400/17            55894055 ns   55890545 ns         11
AddPairStressTestBox2D400/18            99562014 ns   99560833 ns          6
AddPairStressTestBox2D400/19            96094429 ns   96082000 ns          7
AddPairStressTestBox2D400/20            52133560 ns   52131500 ns         10
AddPairStressTestBox2D400/30             5530537 ns    5529619 ns        126
TilesRestComboGroundPlayRho/12          22695751 ns   22695767 ns         30
TilesRestComboGroundPlayRho/20         122353684 ns  122349200 ns          5
TilesRestComboGroundPlayRho/36        1419067505 ns 1418470000 ns          1
TilesRestOneGroundPlayRho/12            16729293 ns   16729316 ns         38
TilesRestOneGroundPlayRho/20           100405596 ns  100395571 ns          7
TilesRestOneGroundPlayRho/36          1187888722 ns 1187447000 ns          1
TilesRestComboGroundBox2D/12            19165748 ns   19164114 ns         35
TilesRestComboGroundBox2D/20           118326007 ns  118264000 ns          6
TilesRestComboGroundBox2D/36          1351758814 ns 1351423000 ns          1
TilesRestOneGroundBox2D/12              16535138 ns   16534976 ns         41
TilesRestOneGroundBox2D/20             114056124 ns  114047667 ns          6
TilesRestOneGroundBox2D/36            1457592303 ns 1457242000 ns          1
Program ended with exit code: 0

Here we're seeing that the shape-id-design branch of PlayRho (with the most recent commits), is almost always faster than Box2D and often significantly so.

These commits introduced some buffer usage improvements but not the small buffer optimization (SBO) I'd mentioned previously. Given how few different shapes many simulations use, I'm less enthusiastic now about trying an SBO out.

What still has me wondering, is why performance of the master branch TilesRestPlayRho benchmarks checked against the supposed-to-be comparative TilesRestComboGroundPlayRho benchmarks (in the new branch), continue being so different - for example the 12 case of 15,177,255 ns vs. 22,695,751 ns respectively. That the newer numbers look closer to what I'm seeing in Box2D (19,165,748 ns in the 12 case but even closer in the higher cases) suggests to me that maybe the newer benchmarks are actually simulating more accurately and that perhaps the old sims were somehow bugged. Or perhaps these benchmarks aren't as apples-to-apples comparable as I'd intended them to be.