next »

[increpare]

time for hugs!

[slembcke]

@BorisTheBrave

Updated.

The post-solve callback is a really interesting idea! I've been fiddling around in the Chipmunk trunk code the past week implementing proper collision start/end callbacks. Chipmunk's collision callbacks previously worked by defining pairs of types. For instance, you would define a callback to happen a monster was hit by a bullet. It was passed the pair of shapes, and a set of contacts. The return value would decide if the collision was processed or discarded. The proposed changes pass you Chipmunk's collision pair object instead. I guess it's basically both the contact begin and pre solve callback in your API (You can find out if it's a begin event from the collision object). From this callback, you can assign a separation callback to the collision object. You can also add callbacks keyed to specific objects to allow you to remove objects from the space as soon as the solver loop finishes. The post-solve callback is a really neat idea to add to all constraints (collisions and joints) and really nicely would solve how to handle breakable joints.

Interesting to know about the unit/scale thing. I guess in Chipmunk, the only threshold or tolerance value that I use is how much allowed overlap there is between objects.

Interesting to hear about one way platforms in Box2D as well. I just made up a demo of that this morning. Ended up being really easy to make a generic solution for it in 20 lines now that I have proper collision begin/separate events. 

[weasello]

As one of the fantastic contraption guys (mentioned on page 1), I'll agree that precision is a big headache. We get complex saved games performing differently between even AMD/Intel chips because of Float precision errors. :/

[ChevyRay]

Wow, we have indie physics superpowers combining here. The results will blow our minds.




...or at least make our TumbleDrop ripoffs better!

[Martin 2BAM]

@nitram_cero

I wasn't just talking to you. I didn't even knew you where "the Chipmunk guy".
I don't like Chipmunk, others do, live with it.

Chipmunk is 6,660 lines ... C++ != simpler

You're comparing the guts with the interface.
I wouldn't mind the library having 2 million lines if I could call "doEverything()" and it would just work ^(tm)

To be fair, I checked Chipmunk about a year ago or more... So I don't really know the current state of it. I thought speed was a priority.
If I offended you, I'm sorry... I'm just speaking my mind.

I agree C could be a tool (hammer, as you said). But C++, if used correctly, could be nice organized toolboxes. Instead of having the tools all around, C++ helps joining them in a coherent and easy to find way.

I wrote exclusively C for 5 years (even after learning c++), 1 year of Point-Of-Sale machine (credit card machine thingy) C programming...
It's can be mandatory or even useful... but for big projects, it gets out of control.
Even John Carmack gave up on C after Quake 3 (in 1999!!!).

For instance, see the SFML interface. It's quite fantastic. It's object oriented, clean.
Compare it to SDL. SDL is easy enough but it's a pain in the ass to learn everything before doing. With SFML you check the Sprite class and you have everything you need right there (Again, IntelliSense helps if you have a cool IDE).
They key in SDL survival nowadays is it's fame and it's endless tutorials. People can copy, paste, analize, understand.

Perhaps Box2D isn't (or wasn't) that easy to understand at first, but has the potential to eventually have a decent easy-as-hell interface, because it's made in a OOP language.
I found the testbed code quite criptic :D, but at least it's a kick-ass resource for specific needs

that C, Ruby, Obj-C, C#, and Java don't already fill.

I'm not saying C++ is the best. I'm saying OOP is cleaner and easier than procedural if used right.
Ruby, C#, Java and Obj-C to some degree are OOP, and will surely do the job.
E.g. I'm loving AS3, been using it for about 6 months now. Reflective languages for prototyping are absolutely fantastic. But C is... well... "limited".



Regards (oh well, hugs too  )


EDIT:

(Box2D) Buoyancy ((flash demo) - part of the Contributed controllers framework.

[ChevyRay]

I don't like Chipmunk, others do, live with it.

 

I love all these physics videos, btw. I have to try picking up some physics engine sometimes and coding some cool prototypes with them.

[BorisTheBrave]

I'm suprised to see you complain about C++, from a C perspective. They share pretty similar short comings. I mean, you have to separate interface/implementation just as much in C, but you complain about it in C++?
Particularly as Chipmunk is very OO, once you look past the language. You could rewrite it to take light advantage of C++'s objects and overloading without actually harming the library in any way, the same way it's been done for dozens of other languages. I mean, you have "klass" variables, and getter/setter macros, how much more OO can you get?

Box2D's API failings are not to do with it's choice of language, imho. Erin actually has created the API he wanted, and it usually has good rationale behind each choice. They're just not the reasons anyone else would expect or want.

For example, your contact ideas still seem more developed than Box2D. That's because Box2D tries very hard to assert no specific behaviour beyond standard physics, so it doesn't really have different collision types built in (collision categories for filtering would be an exception, but that behaviour is completely over-ridable). None of the events do any sort of dispatch, because it's expected you'll handle that yourself. Which in practise means every box2d user has to write or crib much code. Like nitram_cero observes. But as part of a larger framework, it's beautiful.

Another good example is Box2D lacks springs. As far as I can tell, the main reason is they are not technically joints, as there's no other primitive that could represent them (controllers would do nowadays).

In terms of tolerances: there's the overlap as chipmunk has (actually anti-overlap for 2.1). There's also maximum speed (not required), 2 *other* distance tolerances used at different points in the library, sleep tolerance, and the bounce tolerance. Most of them are never touched.

Code bloat: CCD is pretty guilty here. It means Box2D essentially has two separate Solve functions. It causes duplications some body information in both a "swept" form, and a non-swept form. A lot of linked list stuff is unrolled too, probably unnecessarily. Virtually every method updates other parts of the system . Moving a body pings the broadphase, deleting a body deletes joints and fires events, that sort of thing. It's pretty scrupulous with memory management, while Chipmunk seems to leave more of that in the users hands (as it's irrelvant when using Python or Ruby anyway).
I hope that explains it a bit. I notice Box2D has like 5 times as many files too, which does make me wonder where it all goes.


Ooh, I just noticed chipmunk has unsafe operations. Swish. We should totally document which operations are physically unsound.

[slembcke]

They share pretty similar short comings. I mean, you have to separate interface/implementation just as much in C, but you complain about it in C++?

Right, and I was actually complaining about both in that regard. The point I was trying to make is that I don't really like C either, and for many of the same reasons. I find that the benefits to be found in C++ are far more plentiful in other languages such as Ruby with a ton of powerful language features, a very nice standard library, and a nice clean easy to read syntax. Having done so on several occasions, I've found there can be a lot of little headaches to make C++ code work with other languages. I guess I see, C sort of a Rosetta Stone. It tends to be the common denominator that you can count on being able to use from just about any other language. I am only willing to put up with C for those reasons. At the same time, I like to make it as OO and functional language friendly as possible, because those are the sort of languages where I actually intend to use it from. (Again, never written a game or significant sized program in C, and don't really want to)

Box2D's API failings are not to do with it's choice of language, imho. Erin actually has created the API he wanted, and it usually has good rationale behind each choice. They're just not the reasons anyone else would expect or want.

I guess things like the body and shape definition objects are just odd to me for example. Instead of wrapping that up in an object and adding more to the API, as both the developer and user of the library I'd rather just wrap up definitions in functions. I also started Chipmunk before Box2D was a real library, and all it had was... boxes! (surprise) So my API is less of an "I dislike Box2D's" and more of a "How do I want to do this starting from scratch?" frame of mind. Ideally I wanted Chipmunk to have as little API as possible. Oh and in my case, I don't always have a good rationale behind the choices. Heh. It's just what seemed to be the simplest at the time.

Another good example is Box2D lacks springs. As far as I can tell, the main reason is they are not technically joints, as there's no other primitive that could represent them (controllers would do nowadays).

I used to have a function that calculated damped spring forces. People always asked why it wasn't a joint. That was always my reply too until I realized about a year ago that the damping actually is a constraint (not a joint per say, but a constraint). Furthermore, not implementing the damping as a constraint that ran as part of the solver was actually causing some pretty serious stability problems with stiff springs. That was sort of a fun week actually as I realized a number of things that made constraints very programable and flexible. I even went as far as renaming the joints system to the constraint system.

Code bloat: CCD is pretty guilty here. It means Box2D essentially has two separate Solve functions. It causes duplications some body information in both a "swept" form, and a non-swept form. A lot of linked list stuff is unrolled too, probably unnecessarily. Virtually every method updates other parts of the system . Moving a body pings the broadphase, deleting a body deletes joints and fires events, that sort of thing. It's pretty scrupulous with memory management, while Chipmunk seems to leave more of that in the users hands (as it's irrelvant when using Python or Ruby anyway).

Interesting to know. I really wasn't trying to slam Box2D's code as being bloated, but just that a lot more has gone into it. I don't really get that much time/motivation to work on Chipmunk so I usually try to make the most of it. For me, part of that decision was to opt for a C99 implementation instead of trying to deal with C++ and bind it to a language I actually intended to write games in. The other part of it was targeting features with a high time/code to utility ratio. That's a big reason why I've never bothered with CCD. It's a lot of effort for something I don't really intend to use. (Though very very cool) Implementing CCD didn't sound like fun to me either.

Anyway, I'll leave yet another language war by saying that I'm very excited about the potential of OOC. An OO language that compiles very cleanly to C99 with garbage collection, no need for headers, a Java-like OO system, generics, efficiently implemented overloaded operators, consistent constructor semantics and manual stack/malloc() allocation when you want/need it. There are plans for closures, properties and metaclasses too. :D It's still pretty experimental, but being involved in the community has been a lot of fun so far. I'm probably going to give it a try for the upcoming assemblee competition.

[mcc]

I have used only Chipmunk and have had a great experience with it. I don't really know much about Box2D, though if we are talking about bullet-point comparisons it seems worth pointing out that box2d seems to be a little bit more widely ported. There is that javascript/actionscript version.

I would be actually slightly curious to see a comparison of Box2D or Chipunk to ODE, the Open Dynamics Engine (assuming one uses ODE as a 2D engine-- I know World of Goo did this). I have not used Box2D but from what I've seen of it it is actually fairly similar to Chipmunk. However I did some experiments with ODE and it seems to be EXTREMELY different.

On the whole floats/doubles thing (please excuse me if I veer off thread topic here)-- one thing I'd actually be slightly curious about is whether anyone has loooked into accelerating a Box2D or Chipmunk style physics engine by doing vector math with SSE or something like it. For example an x,y vector instead of being represented by two doubles could be represented by a single packed SSE register. You would then potentially get to do each vector math operation for the price of a single floating point op. I am thinking about this because I am currently porting a Chipmunk-based game to the iPhone and (although I'm pretty sure I may be doing some things wrong) Chipmunk at the moment is the performance bottleneck. In my preliminary profiling meanwhile I find more or less the biggest contributors to runtime seem to be constructing and performing simple arithmetic operations like adds and subtracts on cpVects. I know that the iPhone has a vector/SIMD unit called the VFP although, infuriatingly, there appears to be basically no documentation yet on how to use it. I don't know what the VFP's limitations are but it seems like speeding up adding a pair of floats would be basically what a chip like that would be made for. (Incidentally in my iPhone code I switched Chipmunk to using floats exclusively, no doubles, and it doesn't seem to make any difference in Chipmunk's behavior. I did this because the iPhone can handle floats as efficiently as it can doubles-- double checking this I find claims that the 3GS specifically is actually much faster with single-precision floats than double-precision ones, although I am not myself testing with a 3GS-- and making this change allowed me to avoid float<->double conversions elsewhere in the code.)

[bateleur]

In my preliminary profiling meanwhile I find more or less the biggest contributors to runtime seem to be constructing and performing simple arithmetic operations like adds and subtracts on cpVects.

Wow! Yet another example of why actually doing profiling is so much better than guessing. I'd have assumed that the cost of function calls would dominate the actual maths by some way.

[BorisTheBrave]

There are reasons for factory style way of creating classes, which I don't really want to get into. One of the most cogent is memory leaks - these are virutally impossibly in Box2D because it owns the memory for everything inside the world, and definitions are usually created on the stack. Box2D was really written for use in C++, with all the baggage that brings, while chipmunk not for use in C, hence these differences. Explains neatly why Box2D is more ported, and chipmunk more bound, to other languages.

A regular spring is not a constraint either, imho. Springs don't need any "solving to satisfy a constraint". You can calculate a spring's forces at once, and apply them. There are gains to be made for breaking up apply_impulse into several steps (for stiff springs, e.g.), but those are integration steps, not solver iterations iterations. I.e. as far as I can tell, your joints "converge" to the right solution, while your springs "accumulate" to the right solution. It doesn't make sense to mix these - during iteration 1, 2, you are solving when near no spring force is being counted, and during iteration n, there is some spring force (and veloicty change) in effect, so you are solving a different problem for each iteration. While joints will jump to a good approximation of the final solution after 1 iteration, so you are essentially iterating over the same problem, trying to converge on the best answer. Springs as joints may even hurt the ability of your solver.

I can understand that you'd like your velocity readings for springs to somehow represent how the velocity of the body changes over the course of frame, but conceptually, this is not what you are achieving by interspersing spring calls with joint calls.

mmc - adapting these libraries to use SIMD instructions would be complicated. You could change how the vector maths works in a few places, and the matrix inversion code, but as we're 2d i don't think you'll see huge gains. What would be needed would be to rip out the solver (which is the core component that essentially inverts a big nxn matrix) and put in a new one which does the same work with one less loop, using SIMD.

ODE doesn't look so different to me, though I only know it vaguely. What would say is different?

[mcc]

In my preliminary profiling meanwhile I find more or less the biggest contributors to runtime seem to be constructing and performing simple arithmetic operations like adds and subtracts on cpVects.

Wow! Yet another example of why actually doing profiling is so much better than guessing. I'd have assumed that the cost of function calls would dominate the actual maths by some way.

Well... again afraid to get too far off topic, but it also might be a sign profiling can be misleading.

What I actually mean is that the last time I tried this I found the most time spent in, like, cpv() (a method that just packs two floats into a cpVect structure) and cpvadd() or something. Since these are very simple methods it might be that the function calls were dominating the math-- the fact cpv() doesn't properly speaking do anything might be a clue of that. However if this is what is happening that does just mean I have set up the compiler wrong somehow, because the way I have things set up I would expect both those functions to be inlined. I really need to go back and explore this more, I unfortunately had to move on to something else before I could spend enough time on it to be sure of anything.

(Incidentally if anyone has had a chance to do serious profiling of a Chipmunk program, I'd be curious to hear what your results were.)

mmc - adapting these libraries to use SIMD instructions would be complicated. You could change how the vector maths works in a few places, and the matrix inversion code, but as we're 2d i don't think you'll see huge gains. What would be needed would be to rip out the solver (which is the core component that essentially inverts a big nxn matrix) and put in a new one which does the same work with one less loop, using SIMD.

Hm, okay, interesting.

ODE doesn't look so different to me, though I only know it vaguely. What would say is different?

Well... hm. I'm not sure I can actually justify what I said there It's of course fairly similar in terms of the way the world is constructed and how it behaves (although it does have a few more object types than either chipmunk or box2d seems to-- probably unsurprising given it's supposed to be 3D, although I think you could use the mesh type to create convex objects in 2D, and the "plane" type doesn't seem to have a 2d analogue in chipmunk). It seemed mostly different in terms of the programming interface, which seemed a lot more opaque in certain ways. Like with Chipmunk it feels like if you wanted to raycast you'd describe a ray and it would inform you via callback of a list of objects that collided, in ODE you'd do something like actually creating a ray object, putting it into the space and then testing for collisions with it-- like frequently the only way to get information out of the system is to interact with it. Now that I think about it this is maybe not that much of a difference. It might be just that the ODE programming interface is sort of baroque and I am not used to it.

[slembcke]

In my preliminary profiling meanwhile I find more or less the biggest contributors to runtime seem to be constructing and performing simple arithmetic operations like adds and subtracts on cpVects.

If you are seeing any of the vector functions come up in the profiler, it's because you didn't compile it to allow inlining. On the iPhone, Chipmunk works best if you compile it as a separate static library, disable thumb compilation, usef -ffast-math and -O3. I've seen as much as a 10x speedup between debug builds and optimized builds.

A regular spring is not a constraint either, imho. Springs don't need any "solving to satisfy a constraint". You can calculate a spring's forces at once, and apply them. There are gains to be made for breaking up apply_impulse into several steps (for stiff springs, e.g.), but those are integration steps, not solver iterations iterations. I.e. as far as I can tell, your joints "converge" to the right solution, while your springs "accumulate" to the right solution. It doesn't make sense to mix these - during iteration 1, 2, you are solving when near no spring force is being counted, and during iteration n, there is some spring force (and veloicty change) in effect, so you are solving a different problem for each iteration. While joints will jump to a good approximation of the final solution after 1 iteration, so you are essentially iterating over the same problem, trying to converge on the best answer. Springs as joints may even hurt the ability of your solver.

The spring itself is not a constraint no. It's force is only based on distance which does not change between solver iterations. The damping forces that you often apply along with spring forces are however. That was what I was talking about. I had a car demo with damped shocks that didn't quite react correctly in some cases when a high damping factor was used. Moving the damping force calculation into the impulse solver fixed it. There are other examples of constraints that aren't joints as well such as electric motors. The torque that they produce is almost linearly dependent on the current rotational speed. If you don't calculate the torque within the solver, you can end up with "creeping" behavior. The motor is stopped, so it produces it's maximum torque and moves the body a tiny bit during the step. Then a collision constraint reduces the rotational speed back to zero and the process repeats.

[Draknek]

This is a bit off-topic, but:

I love the way Yoshi in Yoshi's Island hugs the ground as he runs over a hill, instead of the momentum carrying him into the air.

The trick is to fool the physics into thinking that it's the correct behavior. For the example of Yoshi's ground hugging behavior, check if the player is near the ground and add an additional grounding force beyond normal gravity to keep them down. Cancel the force when they enter freefall.

Have you (or anyone) got any demos of doing this? I'm trying to do it right now and it's being as annoying as I was expecting it to be.

Just applying a grounding force made the player run down the other side of the hill far too quickly.

[slembcke]

You don't want the force to point straight down, but in the direction of the surface normal. That way it sticks to the surface but does not otherwise move.

If I was doing it in Chipmunk, I would do a short raycast down from the player. (Unity3D really made me fall in love with raycasts) The raycast will give you the normal of the surface that it hits. Another possible solution if you want sharp angles would be to use a joint to attach the player to a rail that is perpendicular to the current ground segment being stood upon. If the player touches more than one ground segment at a time (at a corner) disable the joint. If they are not touching any ground segments because they just flew off the top, use a raycast or something to check if they are near the ground below them and reattach the joint.

I've never done this specifically no, but I have had pretty good luck at faking various character controls in various Chipmunk prototype games and some contract stuff I've done in Unity3D. Mostly you just have to figure out what forces or constraints will get you the types of movement you want, and figure out a stable way to approximate them.

[mcc]

If you are seeing any of the vector functions come up in the profiler, it's because you didn't compile it to allow inlining. On the iPhone, Chipmunk works best if you compile it as a separate static library, disable thumb compilation, usef -ffast-math and -O3. I've seen as much as a 10x speedup between debug builds and optimized builds.

Thanks! I'll look into that. I have been meaning to ask about this over at your forum

[BorisTheBrave]

The damping forces that you often apply along with spring forces are however. That was what I was talking about.

Yes, now I look at your code I can see you are using them this way. I was assuming damping was done naively, based on a shallower reading of your code. You keep track of the target velocity to know how much impulse has already been applied - I was expecting something keeping track of the impulse itself, like with regular joints.

I need to redefine the term "constraint", I think. Damping constrains the solution to the equation F = k v, for F the total force emitted by the damping. All joint and motor constraints are only in terms of velocity and position, rather than forces, but there's no reason why we shouldn't allow that, or expect it to hinder convergence. Perhaps if we were using some other solver, it might.

[slembcke]

Yes, now I look at your code I can see you are using them this way. I was assuming damping was done naively, based on a shallower reading of your code. You keep track of the target velocity to know how much impulse has already been applied - I was expecting something keeping track of the impulse itself, like with regular joints.

I need to redefine the term "constraint", I think. Damping constrains the solution to the equation F = k v, for F the total force emitted by the damping. All joint and motor constraints are only in terms of velocity and position, rather than forces, but there's no reason why we shouldn't allow that, or expect it to hinder convergence. Perhaps if we were using some other solver, it might.

Yeah, the same "springs are not constraints" reasoning is why I held out so long at implementing it that way. I do however integrate and apply the spring force in the pre-step function which is admittedly sort of a hack. It's also not exactly true that motors, joints and collision constraints don't also produce forces. The forces they apply however, are simply applied as instantaneous impulses.

[partymetroid]

I'm not sure as to whether this will help or not... but game N implements raycasting...

And the developers show how they implemented it in the second part of a collision tutorial on metanetsoftware's site: http://www.metanetsoftware.com/technique/tutorialB.html.

The first part of the tutorial is here: http://www.metanetsoftware.com/technique/tutorialA.html -- but I think it contains things you most assuredly already know about.

Also, I'm a big fan of Chipmunk.  I think I may use it later on in one of my games.

[edit]Uh, I think I just made a fool of myself.

Oh well.

[edit2]Yay!  *feels better*

[BorisTheBrave]

Not foolish. Although both of us are aware of raycasting technique, the metanet tutorials are very good and relevant. They taught me much about this area, just a long time ago. The tutorial is pretty specific for the game they are making (lots of tile based short-cuts), but physics engines usually go for a more general approach.

Chipmunks spatial hashing is similar to metanets tile based approach, while Box2D's "dynamic trees" (I don't have a better name), is more similar to quadtrees and their ilk.