Replace Box2D with Chipmunk

[slime73]

Original report by mm (Bitbucket: _maki, ).

---

So I was thinking that because Löve is going to mobile devices, and we want as much performance as possible for these more constrained devices, that we should move from Box2D to Chipmunk, which includes ARM NEON optimizations and an optional multithreaded solver.

In addition, Löve would benefit from easier error handling (no C++ exceptions to worry about, as it is written in C), and IMO the API is easier to understand. This would require a complete rework of love.physics, but this might be a welcome change, as currently, the Box2D API is rather confusing and verbose.

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

I'm not familiar with Chipmunk's API so I can't comment on that part, but one thing box2d has going for it is that it's used all over the place. Even Unity uses it (for 2D physics.) Apple's SpriteKit framework for iOS uses box2d as well, I believe.

The big performance hits in physics engines are usually related to the amount of physics objects calculated (example: https://code.google.com/p/box2d/issues/detail?id=212) rather than specific SIMD optimizations, so that kind of thing might not be as big of a performance gain as one might think at first.

[slime73]

Original comment by mm (Bitbucket: _maki, ).

---

Cocos2D-x uses Chipmunk, and that is also fairly well used. My thought is that this might be a Löve 0.11.0 feature rather than a 0.10.0 feature, because it would require a lot of rewriting code.

On your notes about performance: even if NEON doesn't help that much, it certainly does not hurt. In addition, the multithreaded solver would allow us to better use multiple cores without needing to write any multithreaded code ourselves.

In addition, there are things that Box2D cannot do, while Chipmunk can, such as autogeometry. This can also use data directly from images.

My notes on the simpler API have more to do with the fact that there are no fixtures: just bodies, which can have multiple shapes appended to it. I believe löve used to do something similar back in the 0.7.x days, but was changed because fixtures were more inline with how Box2D works. This change would allow löve to provide a simpler physics API, while having a simpler implementation behind the scenes.

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

I believe löve used to do something similar back in the 0.7.x days, but was changed because fixtures were more inline with how Box2D works.

Older box2d versions used to behave like that, but the box2d version in LÖVE was updated from 2.0 to 2.2 for LÖVE 0.8.0, which brought a lot of API changes.

[slime73]

Original comment by adn adn (Bitbucket: adonaac, ).

---

I think it's easier to just disable love.physics (I assume disabling it in conf.lua is enough?) and then just using Chipmunk via LuaJIT's FFI. Someone has already tried or done this (haven't tested it) https://github.com/luapower/chipmunk so you could look there for some guidance.

[slime73]

Original comment by mm (Bitbucket: _maki, ).

---

I assume disabling it in conf.lua is enough?

My purpose in making this issue is that I want 3 things to happen to love.physics: I want auto geometry and a simpler API by default, and the simplest way to do this in my mind would be to make the switch. If we get performance improvements as well, then that is an added bonus.

via LuaJIT's FFI

I mean, technically, you can fix any problem in Löve by just rewriting the method you are trying to use with FFI, so, by your logic, why bother filing any issue report then? Why bother ever adding a feature to Löve?

[slime73]

Original comment by Minh Ngo (Bitbucket: mngo, GitHub: mngo).

---

I wouldn't like such a drastic change unless chipmunk is much faster than box2d. Both serve the same purpose of a powerful 2d physics engine.

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

I heard (but haven't verified) that chipmunk won't always produce the same output given the same inputs, on different platforms / devices – unlike box2d. I assume it's because chipmunk has ARM-specific codepaths for its physics calculations (using SIMD via NEON.)

[slime73]

Original comment by Josh Wood (SK83RJOSH) (Bitbucket: sk83rjosh, GitHub: sk83rjosh).

---

As far as I know Box2D isn't deterministic on different platforms either.

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

It doesn't use explicit platform-specific SIMD instructions (and it isn't compiled with -ffast-math), at least.

[slime73]

Original comment by Josh Wood (SK83RJOSH) (Bitbucket: sk83rjosh, GitHub: sk83rjosh).

---

In that regard I'm 100% in agreement with you, was just clarifying that Box2D wasn't exactly deterministic either. :P

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

As far as I know it produces the same output given the same inputs. Of course, when you pass in a varying delta time to world:update that won't be the same inputs, so you'll need to use a fixed update rate (e.g. an accumulator-based approach) for that to hold true.

[slime73]

Original comment by Josh Wood (SK83RJOSH) (Bitbucket: sk83rjosh, GitHub: sk83rjosh).

---

You're correct, but it varies between the Box2D version and the platform it's being ran on.

Which means the value of determinism is kind of lost in a cross-platform framework such as Löve, since you'd usually want determinism to hold up on both ends regardless of platform. Especially with certain types of networking, where you'd expect the same inputs to give the same output (as you said above).

I'm really not a big supporter of a sweeping change such as this for the sake of ARM devices either way though. I was just reading through the comments is all and figured I'd bring it up since it was mentioned.

Anywho, didn't mean to stir anything up, and if I'm wrong feel free to correct me -- I just know that this was the case with Box2D the last time I looked into this.

[slime73]

Original comment by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

it varies between the Box2D version and the platform it's being ran on.

Well, any given version of LÖVE uses the same version of Box2D on all platforms, at least. The varying platforms will produce very slightly different outputs for the same floating point operations / functions though...

[slime73]

Original comment by Josh Wood (SK83RJOSH) (Bitbucket: sk83rjosh, GitHub: sk83rjosh).

---

Yeap yeap. I blew this out of proportion and none of this really pertains to the scope of this issue, so no worries, there's plenty of other things to worry about. :sweat_smile:

[slime73]

Original comment by mm (Bitbucket: _maki, ).

---

I'm pretty sure that any differences between platforms is minor enough that there is not anything for us to worry about in either physics engine. I don't think it will be that much more unreasonable.

I'm really not a big supporter of a sweeping change such as this for the sake of ARM devices either way

My purpose is not really doing this just for ARM devices. I just think that the feature set and ease of use of chipmunk are better suited to Löve than Box2D, especially with auto geometry.

And this proposal, while a lot of work, is relatively minor in how it should be prioritized, and, as Löve 0.10 seams like it will be a big enough release as is, so I don't think that this should be in that release. Can we get a Löve 0.11 tag for this?

[slime73]

Original comment by Anders Ruud (Bitbucket: rude, GitHub: rude).

---

Heh.

Fun fact: the very first (never released) version of love.physics used Chipmunk. It was awkward to work with, the simulation was unstable, and did generally not work very well. I was really happy when I discovered the superior quality and physics stability of Box2D, and when I re-implemented love.physics using Box2D (no small task even then), everything worked much better.

To be fair, this was ages ago. I'm sure Chipmunk has improved a lot since then. Also, I was probably using it in a non-recommended way, i.e. varying simulation timestep.

Still, given the widespread use and stability of Box2D, arguments for replacing it with Chipmunk would need to be extremely compelling.

So replacing using Box2D with Chipmunk gets a big fat -1 from me.

However, I agree that the love.physics/Box2D API is complicated. I would propose instead to:

• Implement additional, easier APIs on top of the existing love.physics/Box2D, and/or:
• Make it easier/sexier to use custom modules with LÖVE. (Whatever that means).

[slime73]

Original comment by mm (Bitbucket: _maki, ).

---

Perhaps moving forward, we should design what we want our physics API to look like (i.e. what features it will have, how the classes will be structured), and choose whatever backend library suits these needs better. That way, we can focus on making it usable and testable going forward.

[slime73]

Original comment by coffeecat (Bitbucket: coffeecat, GitHub: coffeecat).

---

If our own physics API is to be designed, I'd mention that particles may be useful.

LiquidFun is a Google's extension to Box2D, which adds particles.

[slime73]

Original comment by Landon “Karai” Manning (Bitbucket: karai17, GitHub: karai17).

---

@rude I do some monkey patching with love3d that executes both love's and love3d's commands of the same name. Example: love.graphics.translate can be used for both 2d and 3d stuff.

I am also currently working on a Bullet Physics API (using a C wrapper over FFI) in pure Lua since I need a 3d physics engine for love3d. It would be nice to be able to release it as a first class module instead of a library, but those aren't necessarily too different to begin with. Maybe instead of using FFI I'd be able to compile bullet straight form C++ and have a Love-compatible Lua binding to drop in? that'd be neat.

Anyway, I am way off topic here but thought I'd bring it up.

[slime73]

Original comment by coffeecat (Bitbucket: coffeecat, GitHub: coffeecat).

---

@karai17 I am against 3D features. Supporting 3D would make LOVE much more complicated to develop and to use. It is more than physics engine, but every aspect of LOVE will need to support 3D as well.

Why don't you use a working 3D engine like UE or Unity?

[slime73]

Original comment by Landon “Karai” Manning (Bitbucket: karai17, GitHub: karai17).

---

You're welcome to be against it but that is not going to stop me from working on it. I have no intentions of requesting that love3d be merged into love proper so it has no effect on love whatsoever. FWIW, love3d isn't all that complicated and it doesn't effect love's api at all, even when you enable monkey patching.

As for why don't I use Unity or UE4, I like Lua and I like love. Love is a great framework and its limitations are mostly superficial (it runs on OpenGL so doing 3d isn't exactly a problem).

[slime73]

Original comment by coffeecat (Bitbucket: coffeecat, GitHub: coffeecat).

---

@karai17 Sorry, but I meant no offence. You can of course work on whatever you like. Good luck to you. :)

[slime73]

Original comment by adn adn (Bitbucket: adonaac, ).

---

Not sure if it's too relevant still but I made a library that IMO makes working with love.physics/Box2D a little easier. https://github.com/adonaac/hxdx Just thought I'd post this here in case anyone needs any ideas regarding a simpler physics API

[slime73]

Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).

---

As indicated, we should probably think of what we want in a physics api, so I've opened #1130 to discuss that. If we ever decide to come back to Chipmunk, we can, of course, reopen this ticket.

[slime73]

Original comment by Anders Ruud (Bitbucket: rude, GitHub: rude).

---

1389 was marked as a duplicate of this issue.