Bullet Physics

[slimsag]

From @slimsag on August 9, 2014 0:28

For 3D physics and collision, Azul3D could provide a Go wrapper to the Bullet Physics engine.

Copied from original issue: azul3d-legacy/issues#16

[slimsag]

From @comaldave on August 9, 2014 13:10

I want it all. Not sure what to say about priority, physics is required, sprites are are so useful, fonts are a very basic need, blender is great but I have other assets that I would also like to use.

Whichever you do first, I am willing to help testing them. Thanks!

[slimsag]

From @ianremmler on August 31, 2014 15:2

It's not Bullet, but I just wrote a Go wrapper for the development version of Open Dynamics Engine. Honestly, I don't even have a use in mind for it yet, but it seemed like something that ought to be done. It covers all the main bits of the API, but at the moment it is not well tested. Anyway, if it's useful, feel free to use and abuse it. It's great to see Go being used for this sort of development.

[slimsag]

@ianremmler Great news! I actually saw your post on Reddit earlier and commented on it as well.

I'd really like to see the wrapper flourish -- the more we can do with games in Go the better!

If you wouldn't be opposed to it -- I would absolutely love to have it become a part of Azul3D. That would mean:

• Versioned import paths for when API-breaking changes must be made.
• It could be imported via azul3d.org/native/ode.v1
• You would have full access to the repository, obviously.
• I would review a lot of the code and see what can be improved.
• I could eventually write examples of using it with Azul3D (obviously the wrapper wouldn't have any dependencies on Azul3D and could be used independently as it is now).
• It would receive auto-documentation at http://azul3d.org/native/ode.v1

A lot of these things I intend to do with your wrapper regardless of whether or not you want to move it into the Azul3D organization here on GitHub -- so it's totally up to you and if you want to keep it in your private repository I completely understand =).

We'll leave this issue open for Bullet support in the future though (two physics engines! :D)

Stephen

[slimsag]

From @ianremmler on September 1, 2014 14:15

Hi Stephen,

On Sun, Aug 31, 2014 at 04:43:35PM -0700, Stephen Gutekanst wrote:

If you wouldn't be opposed to it -- I would absolutely love to have it
become a part of Azul3D.

I would be happy for people to use it! All of the stuff I do in Go at
this point is just tinkering, so I don't have any big plans for the ODE
stuff. I was just surprised that no one had wrapped it yet, so I
thought I'd give it a shot.

Please do include it Azul3D. I'll probably keep my repo around, but the
Azul3D version can be the "main" version, and I'll direct any effort to
improve it there first.

• I would review a lot of the code and see what can be improved.

Please do, and if you need to change anything to make it fit in better
with the rest of Azul3D, feel free. My ODE wrapper is influenced by a
Chipmunk wrapper that I forked and (I think) improved:
https://github.com/ianremmler/chipmunk. I took a quick look at your
Chipmunk wrapper, and you guys did things a bit differently (objects are
structs containing a C pointer vs. using a uintptr as the object, for
example). So, if you'd prefer to change the ODE stuff to be consistent
with your other packages, or whatever, go for it.

And other than the one example in my repo, there really hasn't been any
testing. So there might be a bunch of dumb bugs and typos lurking. :)

Looking forward to using Go for doing more cool stuff!

- Ian.

[slimsag]

From @comaldave on September 1, 2014 15:34

@ianremmler Thanks.

I have read only about half of the manual for the ODE and I would have to say that I am very excited. Here, i have created all these meshes to display in Azul3d, how do I get them to interact? Your timing is perfect! Looking forward to test driving the new code.

[slimsag]

Lets move ODE discussion over to #21 so we can keep this issue Bullet related.

[slimsag]

I haven't had a chance to really dig in and take a look yet, but @hydroflame sent me an email regarding his Bullet and Awesomium Go wrappers. They might be worth checking out for anyone interested in this issue.

[slimsag]

From @Jragonmiris on November 13, 2014 2:49

I think in the long term it may be more useful to port Bullet rather than wrap it.

[slimsag]

From @shurcooL on November 13, 2014 4:31

I would definitely give a 👍 to that... If someone does it, it would indeed be great. :P

[slimsag]

From @Jragonmiris on November 13, 2014 4:56

I plan on doing it, but I'm waiting for stuff to be finalized with mathgl/go.math whenever that happens. I've been reading and making notes on the Bullet code (which is a huge pain due to all the conditional compilation let me tell you).

[slimsag]

From @shurcooL on November 13, 2014 5:14

My dream is to have the functionality available in the http://www.geometrictools.com/ libraries... be available as native Go packages one day.

[slimsag]

A highly agree with what has been said here: Go needs better physics, collision detection, and general purpose geometric packages, written in Go -- not C and C++.

When mathgl becomes go.math (or however it works out) sometime in December (hopefully) it will provide us with a standardized base for writing such packages, this is mainly what #27 is about as well.

Short term, @hydroflame's bullet wrapper looks pretty useful, but of course it's extremely hard to wrap all of Bullet because it's a Go -> C and C -> C++ wrapper, which is not easy.

There are also the Chipmunk (azul3d/native-cp) and ODE (azul3d/native-ode) bindings, which are just C libraries. The ODE ones need a good review, and both make use of a lot of callbacks which will break badly during Go 1.5's GC changes. I am waiting to improve these bindings until we know what will happen there, mostly.

[slimsag]

From @Jragonmiris on November 13, 2014 10:10

Luckily, Bullet's speed mostly comes from algorithmic choices rather than hacky optimization. In fact, from a pedantic performance perspective, a lot of Bullet is templated and virtual, which means Go's interfaces are likely comparable.

Of the important hacky optimization, 99% of that is clever SSE2, which is almost all centered on the direct linear algebra code, which we're planning for go.math. Even things like bounding box collision tests are written in pure C++, so to get in the avenue of Bullet we probably don't even have to cheat.

As I said, the biggest issue with Bullet is a lot of indirect template usage (having to dig through three files to figure out what one class does), and a ton of conditional compilation (especially for debugging). For templates, luckily as far as I can tell none of the templates take in user types -- all of them are used internally, meaning there's a finite number of permutations and we don't have to worry about losing generality due to Go's lack of templated generics.

[ghost]

I tried to make a port of bullet ... it was ... way too freaking hard, It's actually easier to start from scratch and build everything you need. (github.com/luxengine/tornago)