Physics APIs (C vs C++)

[BGB]

well, not sure how 'informed' of a post this will be...


ok, general info:
I am part of that bizarre minority apparently who generally prefers to use C over C++.
reasons are technical mostly, partial reasons include:
C++ IMO does not offer that much "essential" for what I do (nice, but not mandatory);
I tend to do a lot of my own tweaky stuff (compiling and linking code to the main app image at runtime), and at this point only really support C (linking/relinking C++ code involving a whole lot more than is needed for C, and C++ necessarily having a far more complicated compiler...);
...


now, at the time (around late 2004/early 2005), faced with the tendency of most physics engines to use a C++ API, and my general preference for doing things myself, I wrote my own physics engine.

at the time, I implemented a generic rigid-body physics engine with a few general constraint handlers. it had for the solids: AABB, OBB, sphere, cylinder, capped-cylinder, convex hull, tri-mesh, and BSP-trees. it also had for the constraints: weld, ball, hinge, and I think a few others.

but, there are no soft-bodies or similar.

since then, I had on-off used the thing in my projects, but not that much actively developed it,
and over the past few years many bugs have crept in that I have not fixed...


now, of course, my intention is not to flog off my project, but there was a relevant aspect of the design:
I had used a highly abstract OpenGL-like API.

so, there are no structs or function pointers (albeit I have been on-off tempted to add something analogous to GL shaders).

one instead sets and retrieves values by using get/set calls (like GL, macros hold numeric constants representing the vars), and the API is not particularly OO (it uses a good deal of handles and binding).

I had reasons for this though, in particular I had imagined it as possible that the engine could be running in another thread, or possibly in another process or on another computer, so I felt it made sense to use an API where operations could be bundled (some kinds of operations are already bundled via hierarchical begin/end pairs, namely object construction, albeit the majority of operations are much more "direct"), or the entire scene state could be "delivered", without fundamentally changing the interface (that or the API could be implemented via an IPC mechanism with another node or process).

likewise, I had felt that all this would also simplify wrapping potentially different physics engines.

another design goal was to be able to be like GL, and largely decouple the frontend API from the backend internals, where I had also felt that the common approach of sharing structs or classes between the frontend and backend generally crapped all over this.

another thing:
like GL proper, the API is very spartan (it does not provide math utility functions or other such "niceties"). however, it does provide explicit settable units (one can use calls which set the current units used in getting/setting properties, which are auto-converted to the correct types), this being mostly a convenience for dealing with the issue of different parts of my code operating with different units (inches vs meters, ...), and also making it possible to conveniently use base units with non-square relations (inch, pound, gallon, ...).

internally, the base units are kept as: meter, megagram, meter^3, newton, and second.


now, very recently I have come across the Bullet SDK, which looks like a generally far more mature and supported project than any of my stuff (I am the only developer in my case), and I also notice that it seems to lack much in the lines of a C API.

it is possible I could make a version of my frontend which could use Bullet as the backend (still under consideration, it is that or me continuing to use my existing library as is), and so am left wondering if this is anything anyone could be possibly interested in (if in-fact I were to do this...).

oh well, any thoughts or comments?...

[Dirk Gregorius]

Bullet has a C-API or it least it is work in progress. Just search for C-API in the forum or have a quick look through sources. There were several requests for this in the past time so I can imagine that zour help would be highly appreciated...

[BGB]

Bullet has a C-API or it least it is work in progress. Just search for C-API in the forum or have a quick look through sources. There were several requests for this in the past time so I can imagine that zour help would be highly appreciated...

yes, ok.

I may investigate things further then.
yes, I found a header, and am aware of the C-API already in place.


actually, it is likely that what I would provide would be an alternate API, since I am starting from the position of already having a physics engine with some amount of code using it. however, keeping around and extending the existing C-API (or possibly providing for both being usable together) are also options.

well, I can talk with people and provide specific information as needed, and will be open to any suggestions (the codebase I have using my existing library is not so large as to be non-amendable, and changes are likely to be the case anyways given differences in terms of respective feature sets and general approach).

actually, even as is, my physics library internals and the frontend API differ somewhat, with the internals using one naming convention and passing around pointers and such, and the API using an abstract interface and integer-based handles and properties.


example of how it could look (my existing API):

//how units are set up
bsdeSetWorldAttrI(BSDE_UNIT_LENGTH, BSDE_UNIT_INCH);
bsdeSetWorldAttrI(BSDE_UNIT_VOLUME, BSDE_UNIT_INCH); //1in^3
bsdeSetWorldAttrI(BSDE_UNIT_MASS, BSDE_UNIT_POUND); //0.4525kg
bsdeSetWorldAttrI(BSDE_UNIT_FORCE, BSDE_UNIT_POUND); //4.45N

bsdeSetWorldAttrF(BSDE_GRAVITY, 32); //unit conversion automatic

bsdeBegin(BSDE_SOLID_SPHERE);
bsdeAttr3F(BSDE_ORIGIN, 0, -12, 6);
bsdeAttrF(BSDE_RADIUS, 4.0);
bsdeAttrF(BSDE_MASS, 45.0);
hdl=bsdeEnd(); //as an oddity, handles are usually returned from the final end pair...

the above is the newer approach (originally added for passing in types such as models and BSPs).

there is also an older/imperative approach:
hdl=bsdeNewSphere(4.0);
bsdeSetAttr3F(hdl, BSDE_ORIGIN, 0, -12, 6);
bsdeSetAttrF(hdl, BSDE_MASS, 45.0);


possible design changes:
final 'F', 'I', amd 'FV' suffixes made lower-case (more like in GL);

rename some constants:
BSDE_UNIT_LENGTH -> BSDE_LENGTH
BSDE_UNIT_INCH -> BSDE_INCH
BSDE_SOLID_SPHERE -> BSDE_SPHERE

...


well, I guess for now I will go forward and see what happens...

[Oscar Civit Flores]

Hi BGB,

I agree with you on the benefits of having a decoupled API layer and an "internal" implementation of the physics engine. That simplifies a lot user-code, engine extensibility and parallelization, in my opinion. I am currently implementing not one but two engines concurrently (not in parallel, I'm single-brained ) , and both have independent APIs wrapping internal C++ implementations.

One of the APIs I've implemented is quite OpenGL-inspired as yours, with begin-end blocks and enumerated properties as well as an asynchronous "command buffer" to send requests from the API to the core engine. This API is weakly-object-oriented... I mean, API entities are C++ classes (rigid, universe, particle...) that gather all functionality local to that entity and hold some API state (last applied force, last object configuration...), but not using unnecessary C++ complex features. A C++ API does not need to be complex in order to offer the advantages of OOP, while forcing a C API may be more "compatible" but a bit unflexible to work with.
In the other API I've implemented we used a PIMPL pattern, so that the internal engine object and the API object are the same instance with different interfaces (API and Core), the API-interface implemented directly on the Core-interface exclusively. This is quite efficient as well as simple to implement and debug.
For me the PIMPL approach speeds up development while maintaining the API decouplement, while the other approach, API entities with state and asynchronous command-buffers, is clearly more flexible but has a very high overhead in complexity, though not necessarily in speed.

As a conclusion, I think that a C++ API has numerous advantages over a plain-C one, but it's clearly a good idea to think about the API as something decoupled from the internal algorithms and classes.

[mreuvers]

Ah... a C vs C++ discussion

oh well, any thoughts or comments?...

Well, for starters why does someone want to use C if there is C++? What's not to like: classes, OOP, inheritance, polymorphism, operator overloading, namepaces, templates, smartpointers...? The list is endless

And if your code is setup correctly, the resulting code will be much better readable/understandable than a C project, more intuitive, less error/bug prone, less lines of code and, if you know what you're doing, even faster.

So IMO it makes perfect sense for engines, physics or other, to make the switch to C++. A lot of developers out there also expect you to do so. In fact we don't use C anymore, we only use C++.

[BGB]

Ah... a C vs C++ discussion

oh well, any thoughts or comments?...

Well, for starters why does someone want to use C if there is C++? What's not to like: classes, OOP, inheritance, polymorphism, operator overloading, namepaces, templates, smartpointers...? The list is endless

And if your code is setup correctly, the resulting code will be much better readable/understandable than a C project, more intuitive, less error/bug prone, less lines of code and, if you know what you're doing, even faster.

So IMO it makes perfect sense for engines, physics or other, to make the switch to C++. A lot of developers out there also expect you to do so. In fact we don't use C anymore, we only use C++.

actually, I have already switched to C++ for the engine internals (figuring it 'justifiable'), but I am inclined to keep to C for the external API.

for the most part though, I am sticking to C-like conventions in case it may be necessary to switch back (for example, due to issues given below).


admitted, a C API is a little more awkward from C++ code than a C++ one, but ease of use was not as high of a priority in my case. actually, I had figured before that I could wrap the C API with a C++ OOP one, partly as a kind of add-on, but I never really maintained it, me using primarily the C one.

most of my front-end code also tends to be in C as well.


now, in my case a big issue is actually a lot more subtle:
not all of my code is compiled or linked with conventional compilers (such as GCC or MSVC), but some of it is compiled and linked at runtime;
a C++ compiler is, internally, far more complicated than a C compiler;
linking C++ involves far more subtle issues than C code (special cases for initializers, constructors/destructors; ...);
issues like name mangling, object memory layout, ... are horribly non-standardized (for example, on windows GCC and MSVC use different calling conventions for C++, ...), wheras for C, the calling convention is de-facto standardized on nearly all 32-bit x86-based OS's (although there are many calling conventions for 16-bit x86, and several for x86-64).

the issue then is that though dynamically compiling and linking C code is reasonably straightforwards, dynamically compiling or linking C++ code is not.


likewise, for many specialized JIT compilers, it is far easier to interface with C functions than C++ ones (due in large part to the variety of calling conventions and name mangling schemes).



so, in my case, it is possible that, not all of the code that will be using my physics engine, will have been statically compiled (of course, using C++ does require the engine to have been statically compiled and linked with the main app binary).


likewise, most scripting engine FFI's can also readily interface with many C-based APIs, but FFI's capable of linking with C++ are rare (although GCJ is weird, where GNU decided to make GCC's Java FFI be C++ based...).

or such...