Box2D Discussions

[erincatto]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[simonvanbernem]

Hi!

My name is Simon and I'm using box2d to make a 2D multiplayer space game with realtime physics, that is loosely inspired by FTL. You build ships, you shoot them into pieces, you scavange other ships for their parts and so on. The movement is entirely physics-based and the ships can be arbritrary polygonal shapes, which leads to some interesting problems.

This is also why I'm super thankful for the engine and the and the community! I didn't have a lot of knowledge about physics engines prior to working with box2d, and being able to just have a robust engine at hand and ask questions to people also interested in the topic is super helpful! You can get stuck quite hard when developing alone, so another set of eyes/ears is invaluable. Being able to look at the source also helps: It enabled me to extend box2d in places, spot performance problems and get a better understanding about physics engines in general.

I'm glad that you made this engine Erin, and that this community exists!

Two concrete things I'm doing with the engine right now that might be interesting:

• I added a hierarchical body-system on top of box2d. In my game, every spaceship is a single rigid body with many conceptual pieces (door, wall, engine, gun, floor, shield, ...), so thinking in terms of fixtures was not very intuitive. With the abstraction I can treat those things as individual bodies, attach/detach them from other bodies and set their absolute and relative position and rotation. The heart of the inner workings are the information about the hierarchie and a routine that transforms a set of fixtures. I was quite surprised how complicated the whole thing was to implement given that simple description.
• You can tell a spaceship to move in a certain direction in my game, and the spaceship will figure out how it has to actuate the (rocket-)engines it has, to make that movement happen (remember, all movement is physical, so the ship only accelerates through forces applied by the engines!). The engines might be at arbitrary positions and rotation on the ship, so this is non-trivial. I modelled this as a linear program and wrote a simplex-solver for it, which does pretty well. This becomes interesting in terms of physics, when AI comes into play: To make decisions, it has to predict where it will end up in the future. I did this prediction using newtons laws of motion, but discovered they were slightly off and would lead to the ship oscillating around the position it should come to rest at (because it overshot all the time). Turns out: This happenend due to box2d being a physics engine and not the real world: The time steps are discrete not continuous, and the prediction has to accomodate that. I was able to find a closed-form equation that can predict the position correctly at discrete time steps in the future for a given delta-time, which made the prediction error go down to insignificance. That was a really fun deep dive into the engine (I stepped through the integrator to understand what was happenening) and the math behind it, when constructing the closed form of the series!

Thats it for now. I'm looking forward to seeing some interesting stuff on here!

[thegrb93]

@simonvanbernem what's the name of the game? I've had a similar idea before and would be interested in checking it out.

[simonvanbernem]

The working title is "spaced". It's not public yet since I am still doing ground-work and have invested 0 hours into visuals so far. It's really more of a tech-demo currently, with partly unfinished tech.

[mgerhardy]

Hi, I'm using box2d for a classic 2D platformer (single- and multiplayer).

http://www.caveproductions.org/

I've recently updated to box2d 2.4.1. If you are looking for things that must have been adopted, check out the commits at: https://github.com/mgerhardy/caveexpress.

I've updated the buoyancy controller by Chris Campbell to 2.4.1, too: https://github.com/mgerhardy/caveexpress/blob/master/src/caveexpress/server/entities/Buoyancy.h

[simonvanbernem]

FYI: I get to some sort of admin panel when following the first links. Looks like the site is a bit broken (I also get SSL warnings).

[PressStart10]

hey, can i install via apt?

[PressStart10]

just wanna know

[mm-longcheng]

https://github.com/mm-longcheng/box2dc
Box2d is a great project. I port it by c. It's passed unit-test and testbed.
I compare and checking code so many time, and need more unit tests.
The library size smaller, and runtime speed almost the same.
Box2d never use any stl, project clean and simple. But some time we need pure c for develop. So i do this.

[erincatto]

Very nice port! I'm currently working on v3 of Box2D here: https://github.com/erincatto/box2c

The goal is to have a pure C API. Most of the code is C but I'm doing a lot of multithreading, so I'm not sure if it will be all C internally.

[vkensou]

Maybe we can give b2AllocFcn and b2FreeFcn a attached parameter: userdata.

typedef void* b2AllocFcn( unsigned int size, int alignment, void* userdata );
typedef void b2FreeFcn( void* mem, void* userdata );
B2_API void b2SetAllocator( b2AllocFcn* allocFcn, b2FreeFcn* freeFcn, void* userdata );

I would prefer to transfer allocFcn and freeFcn to b2WorldDef. But it seems that too many changes are needed.

[vkensou]

Given that the allocators are global, then the userData could be global as well? So basically this shifts a global from user code to Box2D code.

If you don't want every world to have an allocator, then the userdata should also be global.

I didn't want per world allocators because things like b2DynamicTree can be used without a world and need allocation. Are you wanting to use an arena allocation strategy?

Sometimes users may want to set up different allocators or pools for different systems, so that different strategies can be used. And if the user uses allocator like C++'s std:: allocator, passing in a userdata is required.

[erincatto]

I guess my point is that user data is only meaningful if it is per world/dynamic tree/etc. Otherwise you would have to have the same global in the calling code.

I'll think about the per world allocator. As I said, there are other things that can allocate. And this would require potentially a lot of plumbing.

Do you currently have a use case for having different allocators for different worlds? What problems would it solve for you?

[vkensou]

Honestly, I haven't quite figured out the specific use cases for allocation by worlds. I haven't used multiple worlds in box2d, so I can't definitively answer that question.

Just based on experience, whenever I create a big object, I tend to pass an allocator into it (using C++, I pass memory_desource). I just unlike the global state.

Maybe we can start by passing a userdata to the global allocator?

[vkensou]

make a pr
#799

[erincatto]

I've mentioned a few times now that the user data as a global in Box2D doesn't make much sense. The pointer must already be a global in the client code. Context doesn't matter when it is global.