I have been using Box2d (Todd’s version found in this post) and a snapshot of oF [from early January]. So far everything seems to run as expected.
Today I moved the same project to oF006 [current version from the svn]. The project is compiling fine, and works. But the ‘scaling’ from Box2D is not reacting the same. All the bodies are now smaller, but their properties stayed the same.
Found why. It’s due to a change in the method ofEllipse. The Width and Height of the created ellipse are multiplied by 0.5 when the vertex array is created.
ahh yeah the 006 version the more correct as previously the ellipse radius was base don width and height - where is it should have been half width and half height.
looks good todd… and thanks for the example ascorbin !
can I ask if it’s cool to use .cpp and .h files for the core parts of ofxBox2d ?
I know that it’s quicker to program just one time, like java in an h file.
but the reason is simple – it’s much, much easier to read and since there’s no documentation the “h” file kind of works for an instruction manual. also, it’s potentially a quicker compile, since there is less copying of text around (h files should be thin for that reason alone).
at one point I found a crazy script that does this – splits an h file definition into .h and c++. I can’t seem to find it, but I remember trying to get theo into it too since he loves h file programing
cool ! I’ve been experimenting and it seems that keeping the body def around (instead of just using it in setup) means that various aspects of an object can be adjusted. for example, I wanted to make a joint that I can expand and contract:
there doesn’t seem to be a better way to alter an object like a joint besides removing it and re-adding it. for shapes, I’ve foind a way to remove the shape from the body and add a new shape, which means I can make rectangles that expand and contract.
take care!
zach
edit - ps, the new example is great! I learned alot…
struct b2ContactPoint
{
b2Shape* shape1; ///< the first shape
b2Shape* shape2; ///< the second shape
b2Vec2 position; ///< position in world coordinates
b2Vec2 velocity; ///< velocity of point on body2 relative to point on body1 (pre-solver)
b2Vec2 normal; ///< points from shape1 to shape2
float32 separation; ///< the separation is negative when shapes are touching
float32 friction; ///< the combined friction coefficient
float32 restitution; ///< the combined restitution coefficient
b2ContactID id; ///< the contact id identifies the features in contact
};
this is cool, because you can define a maxForce for joints and then they ‘crack’. I had fun with that. I mean its all here ->http://www.box2d.org with docs and forum and wiki and stuff, but not so ‘of-ish’ so i thought it could be interesting for you.
@ zach I know its a really annoying thing about box2d drives me crazy. I wanted to just change the radius of a shape and it was a major hack. I will add that to the baseShape class and post to the svn.
a) having non ofGetWidth() / ofGetHeight() for the default ofxBox2d allocation (I was doing box2d into a pbuffer, for example) and altering based on that the AABB points.
b) revoluteJoints are nuts, it was fun to play with. maybe a base joint class?
c) there seemed to be missing some “dead = false” in the start up of objects, to that killing them and restarting meant dead was still true.
d) growing shapes is kind of tricky too, because if you do it close to the edge you can get a nasty crazy crash – I had to play with the AABB stuff a bit.
e) i’ve found simpler then growing shapes, just attaching a new larger object to a box with a stiff revoluteJoint. it’s ghetto but seemed to work
I’ll try to keep track of changes as I go and merge back in.