[LibGDX] Box2DWorld scale is incredibly small and hard to see [solved]

Hey all! I’ve messed with libGDX before, and recently decided to come and mess with it and box2D. I’ve read that your not supposed to do a 1:1 pixel to meter ratio, and that box2D coords are in meters. So everywhere I lok I’ve seen “use a Pixel to Meter constant!”, and so I did. The result howver, is that the box2D world is incredibly small! I can’t really see anything in the debug renderer, and, while the renderer won’t be used in the final version, it’s small, because all of my objects are small. Meaning that the light (from box2DLights library) isn’t rendering over my tilemap like it should. If that doesn’t make any sense, here’s a picture:

Here’s the code I’m using now:


               for (x in 0..layer_wall.width - 1) {
                    for (y in 0..layer_wall.height - 1) {
                        if (layer_wall.getCell(x, y).getTile().id != Tiles.NULL) {
                            if ((layer_wall.getCell(x - 1, y)?.getTile()?.id ?: Tiles.NULL) == Tiles.NULL ||
                                    (layer_wall.getCell(x + 1, y)?.getTile()?.id ?: Tiles.NULL) == Tiles.NULL ||
                                    (layer_wall.getCell(x, y - 1)?.getTile()?.id ?: Tiles.NULL) == Tiles.NULL ||
                                    (layer_wall.getCell(x, y + 1)?.getTile()?.id ?: Tiles.NULL) == Tiles.NULL) {
                                shape = new PolygonShape()
                                shape.setAsBox(layer_wall.getTileWidth()/2/Tiles.PPM as float,
                                               layer_wall.getTileHeight()/2/Tiles.PPM as float,
                                                new Vector2((x + 0.5F) * layer_wall.getTileWidth()/Tiles.PPM as float,
                                                            (y + 0.5F) * layer_wall.getTileHeight()/Tiles.PPM as float), 0)
                                body.createFixture(shape, 1)
                                shape.dispose()
                            }
                        }
                    }
                }

That code loops through a TiledMapLayer and finds tiles with a ceertain ID, if it finds them, it adds their shape to the body for the collision of the map. (If more code is needed I can post it, I’m just not sure what is needed and what is not needed)

I have a wrapper for my rendering that would allow me to have a split screen, there’s an array of camera, and I render them each with this method


public void renderPerCamera(int cameraNum){
        renderer.setView(camera.get(cameraNum))
        renderer.render()
        player.render(camera.get(cameraNum))
        handler.setCombinedMatrix(camera.get(cameraNum))
        handler.updateAndRender()
        particleEmitterBox2D.update(Gdx.graphics.deltaTime)
        debugRenderer.render(world, camera.get(cameraNum).combined)
        batch.begin()
        batch.setProjectionMatrix(camera.get(cameraNum).combined)
        particleEmitterBox2D.draw(batch)
        batch.end()
    }

The renderer is my TileMapRenderer, player simply renders a sprite at the location of a body (I can post that too if need be)

To be frank, this is what I’d expect from having to scale down the size of the box2D world so that 64 pixels is equal to 1 meter, a smaller world to render, so I’m not quite sure what I’m missing. Is there something about the PPM process I don’t understand? Or is there some code that needs to be done to let the world be scaled? I’ve looked at countless other examples and not seen a difference between their process and mine, and yet while there’s works, mine doesn’t.

Any help is greatly appreciated!
Thanks!

The reason is that with box2d, you don’t want your 32x32 pixel sprite to be treated as though it were a 1000+ square meters. Also, you would quickly find that you need obscenely high forces to get the desired movement…

If you had put up some of the box2d code I could have quickly pointed out what to change, but I’m not that advanced with it… but ya, once you scale down your graphics and get everything lined up, then it’s just a matter of thinking in meters.

If you are intending on using box2d strictly for collision detection, I don’t think it would matter, but I could be wrong there as well, because you would be dealing with a world that is (scale) times larger, and might take more resources.

Sorry I can’t help better, I’m at best novice with box2d.

Thanks for the tips, I got it to work (or at least, I think it’s working) by using my PPM constant when the screen resizes and in the scale of the tilemap. The box2D bodies are small, but the tile map is also small, and therefore it looks fine.

You don’t even need to scale objects according to the size of the tiles, you might want to have 1m to be 1.5 tiles for example.

One thing that will benefit performance for you, and will cause a bit less grief concerning ghost collisions is to minimize the number of bodies you have…

I might be wrong, but it looks like alot of your terrain is made up of bodies that are the tile bounds. If you want to have piles of boxes or moveable / breakable objects that may be necessary, but you generally want to minimize the number of bodies that need to be cycled through, even static bodies add up.

Anyway, I haven’t used box2d a whole lot (I could not get the desired motion), but those were some early warnings I came across.

If you are making a platform game, box2d might do some good, but when it comes to “arcade” physics, like most platformers, it will be a benefit to use box2d only for collision detection, though others might disagree.

Oh yeah, I just wanted them at that scale, but thanks for the info. :slight_smile:

As for the collisions, that was a weird thing, when it scaled to that size, it looked like it was being filled, but at normal size, it only does the surrounding edges.

For platformers, I have gone without box2D physics, this is a top down game, which could still go without box2D, but I want to experiment with box2D a bit, see what I can do with it and then assess if I can do the same with no libraries. Thanks for the help though!