Upcoming Physics changes

[tentus]

I don't know if anyone else is following the Box2D Update branch, but there's been some really interesting stuff being mentioned in the commits. For example, "World no longer has an explicit size".

I was hoping that some people more knowledgeable than I could comment a bit about what is being introduced/removed/changed, so that the rest of us can start thinking about what we will need to change for future releases. The example I cited above is very exciting for me, since it means that I can simplify and clean up some of my code... if I understand the commit correctly.

[slime]

It's being updated for box2d 2.2.1 (LÖVE has previously been using box2d 2.0.1), I'm sure there's info on the box2d website. anjo will probably tell us all about it once he's done updating.

Regardless, you'll have to rewrite large portions of your physics code (if not all of it) because tons of stuff has changed between box2d 2.0 and 2.2.

[bmelts]

I finally finished the bulk of the updating today - the rest will just be finding bugs and the like.

Basically, everything you know is wrong - Shapes now need Fixtures to attach to Bodies, Worlds have no explicit size, there are new kinds of shapes, new kinds of joints, new methods, new collision callbacks, and more. While people work on documenting the new API on the wiki, I strongly recommend referring to the Box2D docs for how to navigate this brave new physics world - the API hews very, very closely to Box2D's, with the exception of the Contacts in the collision callbacks. Those are different, but fairly intuitive - instead of getting information from the world manifold, you get it straight from the Contact.

[tentus]

I finally finished the bulk of the updating today - the rest will just be finding bugs and the like.

Basically, everything you know is wrong - Shapes now need Fixtures to attach to Bodies, Worlds have no explicit size, there are new kinds of shapes, new kinds of joints, new methods, new collision callbacks, and more. While people work on documenting the new API on the wiki, I strongly recommend referring to the Box2D docs for how to navigate this brave new physics world - the API hews very, very closely to Box2D's, with the exception of the Contacts in the collision callbacks. Those are different, but fairly intuitive - instead of getting information from the world manifold, you get it straight from the Contact.

Oh. Well ####.

[tentus]

...While people work on documenting the new API on the wiki...

Bump?

I am glad to help where I can, but I'm afraid of putting misinformation on the wiki. Other than trying to read through the Love source/Box2d docs and make wild guesses at how things work now, is there anything I can do to help?

Edit:
Wow, it hadn't really sunk in how different it all was until I started trying to make the physics tutorial work again. Updating old games is going to be quite an undertaking.

[The Burrito]

it hadn't really sunk in how different it all was until I started trying to make the physics tutorial work again.

It's not really that bad, here's my take on it:

Code: Select all

function love.load()
  world = love.physics.newWorld(0, 700,true,64) --the x component of the gravity will be 0, and the y component of the gravity will be 700, sleeping is allowed, and the height of a meter in this world will be 64px
  
  objects = {} -- table to hold all our physical objects
  
  --let's create the ground
  objects.ground = {}
  objects.ground.body = love.physics.newBody(world, 650/2, 650) --remember, the shape anchors to the body from its center
  objects.ground.shape = love.physics.newRectangleShape(650, 50) --make a shape with a width of 650 and a height of 50
  objects.ground.fixture = love.physics.newFixture(objects.ground.body,  objects.ground.shape, 0) --anchor the shape to the body, give it a density of 0 (infinite)
  
  --let's create a ball
  objects.ball = {}
  objects.ball.body = love.physics.newBody(world, 650/2, 650/2, "dynamic") --place the body in the center of the screen, it must be declared dynamic or it will be assumed to be immovable
  objects.ball.shape = love.physics.newCircleShape( 20) --the ball's shape has no offset from it's body and has a radius of 20
  objects.ball.fixture = love.physics.newFixture(objects.ball.body,  objects.ball.shape, 5 ) --the ball needs to be linked to the body and given a density 
  objects.ball.body:resetMassData() --this automatically recalculates the mass based on the shape and density values
  
    --initial graphics setup
  love.graphics.setBackgroundColor(104, 136, 248) --set the background color to a nice blue
  love.graphics.setMode(650, 650, false, true, 0) --set the window dimensions to 650 by 650 with no fullscreen, vsync on, and no antialiasing
end

function love.update(dt)
  world:update(dt) --this puts the world into motion
  
  --here we are going to create some keyboard events
  if love.keyboard.isDown("right") then --press the right arrow key to push the ball to the right
    objects.ball.body:applyForce(400, 0)
  elseif love.keyboard.isDown("left") then --press the left arrow key to push the ball to the left
    objects.ball.body:applyForce(-400, 0)
  elseif love.keyboard.isDown("up") then --press the up arrow key to set the ball in the air
    objects.ball.body:setY(650/2)
  end
end

function love.draw()
  love.graphics.setColor(72, 160, 14) -- set the drawing color to green for the ground
  love.graphics.polygon("fill", objects.ground.body:getWorldPoints(objects.ground.shape:getPoints())) -- draw a "filled in" polygon using the ground's shape points, offset by the ground's body position

  love.graphics.setColor(193, 47, 14) --set the drawing color to red for the ball
  love.graphics.circle("fill", objects.ball.body:getX(), objects.ball.body:getY(), objects.ball.shape:getRadius(), 20) -- we want 20 line segments to form the "circle"
end

for most projects it's a fairly small change, the biggest difference is more things are explicitly defined (which is a good thing). Heres some of the changes that will effect most projects:

-newWorld now looks like this: newWorld(gravX, gravY, allowsleep, setMeter).

-When creating a body, you must declare it "dynamic" or it will be static, use "kinematic" if the object is to be manually moved only (like a elevator or moving platform).

-When defining a shape, don't include a body parameter, and declare coordinates clockwise instead of counter-clockwise, otherwise this is the same.

-After making a shape, use a fixture to attach it to a body, and many of the former shape properties are now held by the fixture (density, masking, friction, restitution, etc.) so make sure you're using them with the right component.

If anyone knows how to use the raytracing from within Löve an example would be cool. I'd like to start playing with it as it seems like it would be a nice performance boost over the old testSegment.

[slime]

A few additions..

• the meter parameter isn't in love.physics.newWorld, you'll have to do that after world creation
• shapes are sort of like 'prototypes' now. When you 'attach' a shape to a body via a fixture, it really makes a copy of the shape. It's important to keep this in mind (and it can streamline your code). You can access the fixture'd shape via fixture:getShape().

• It's raycasting, not raytracing. :p
You can either do a rayCast check on a specific fixture or on the entire world. You'll usually want to do it on the entire world.
You can read more about the internal box2d implementation here. The LÖVE world method is:

Code: Select all

world:rayCast(x1, y1, x2, y2, callbackfunc)

where callbackfunc receives several things as arguments upon a raycast hit. It needs to return a number or Bad things will happen.
From the manual:

The world class calls your class with each fixture hit by the ray. Your callback is provided with the fixture, the point of intersection, the unit normal vector, and the fractional distance along the ray. You cannot make any assumptions about the order of the callbacks.

You control the continuation of the ray cast by returning a fraction. Returning a fraction of zero indicates the ray cast should be terminated. A fraction of one indicates the ray cast should continue as if no hit occurred. If you return the fraction from the argument list, the ray will be clipped to the current intersection point. So you can ray cast any shape, ray cast all shapes, or ray cast the closest shape by returning the appropriate fraction.

You may also return of fraction of -1 to filter the fixture. Then the ray cast will proceed as if the fixture does not exist.

[tentus]

@The Burrito:
Kurosuke has over thirty different kinds of physics entities which can vary wildly, about a fourth of which are sensors and most of which have special category rules. I don't even know how to do sensors in the new system (the word sensor does not occur in the source any more). I appreciate you sharing what you wrote though, it really helped me out! I had a rough time just realizing that shape:setData() had become fixture:setUserData().

[The Burrito]

the meter parameter isn't in love.physics.newWorld, you'll have to do that after world creation

Good to know, not sure where I read that it did.

shapes are sort of like 'prototypes' now. When you 'attach' a shape to a body via a fixture, it really makes a copy of the shape.

I sortof figured thats what it was doing but I hadn't tested it yet, seems like it would be a little messy for dynamically created shapes, but for anything that gets reused I guess I can just store the shapes in a reference table.

It's raycasting, not raytracing. :p

Derp, I have a few years more experience with 3D rendering than programming so raytrace comes to mind first, but I know the difference

I'm interested in the raycasting because it should be a significantly faster way for me to calculate the lighting in In The Dark. Does the callback function receive the same data as it normally would? like could it look something like this:

Code: Select all

function callbackfunc(fixture, pointX, pointY, normalX, normalY, fraction)
 if fixture:getUserData() == "no collision" then
 return -1
 else
 firstImpact = fixture
 impactX = pointX
 impactY = pointY
 return fraction
 end
end

Where the userdata is used to exclude certain shapes and every successful impact decreases the overall trace length?


No problem Tentus, I know everybody with projects relying on box2d is itching to upgrade to the latest version.

one more note: world:setMeter is now love.physics.setMeter this implies that it's now a global variable and would persist across creating multiple worlds but I haven't actually checked on this.

[tentus]

the meter parameter isn't in love.physics.newWorld, you'll have to do that after world creation

You wouldn't happen to know what's going on with meters, would you? I see setMeter/getMeter in wrap_Physics.cpp, but I can't get them to work to save my life.