Easy collisions without box2d about ige

[Irrelon]

The main thing is... you can do basic collision detection but what if the moving object is going fast? Then you need to factor vectors in, then what about pixel-based as you said... then you need to create collision polygons instead of basic rectangles... then you need to cut the polygons up so that they are not concave, then you need to build a broad phase check so that you're not checking collisions against the entire set...

And on and on and on...

PS, are you finding box2d is bad in some way which makes you want a "simple" solution? If I can understand the problem there might be an easier solution that still involves using box2d... :)

[goldfire]

Basically, we don't need all the physics that go along with box2d. We don't want players to bounce off of each other, or bounce off of buildings. Ideally we just want to have buildings or other objects that occupy space on the tilemap (iso) and can't be walked through. If the player walks into it, he just stops. If the player clicks on the other side, he'll walk around.

Sorry if I'm not explaining this very well, it has been a long week. I'm taking tomorrow off, so I'll have a clear mind on Sunday and can try to explain better if needed.

[Irrelon]

Bouncyness is a value in the body definition (can't remember the exact name right at this moment) so you can set it so that objects don't bounce at all.

That said, if you are using a click to tell the player where to go... this is path-finding, not physics. Tiles on the map that the player is not allowed to walk through get marked as such so that when the path-finder is asked to come up with a path, it will route around those tiles.

[goldfire]

Okay, so maybe path-finding is all we are really needing. However, am I right in assuming that it doesn't work with pixels instead of tiles?

[Mavor]

Box2d is a very light library already, and you can use filters and options to cut the actual physics processing down to a minimum.

[goldfire]

I wouldn't exactly call 430kb and 11,000 lines of code "light." I realize box2d is very fast, but it doesn't make sense if we are using just one or two of the many features it is offering and calculating on each tick.

[Irrelon]

I think you'll struggle to get any solution that works with pixels and is still performance optimised. There is just too much data to efficiently scan through on each item if it's down to the pixel level. You really need to work with vectors instead of pixels to get any decent performance.

As I mentioned above the path-finding solution would work for you, but it won't be based on pixels, it will be based on tiles. Keep in mind that you could make your tiles quite small to add extra levels of detail to the tile map but you will trade A* performance for more accurate paths which will likely be the same or very similar to the paths you'd get from A* with larger tiles anyway.

Do you need pixel-perfect collision? :)

[goldfire]

We don't need pixel-perfect collision (we don't really need collision at all, just don't want players walking through solid objects), but we also don't want to restrict players to one per tile. Would it make sense to calculate the path based on the tile they click on, and then translate them to the pixel position they actually clicked?

[Irrelon]

@goldfire I see where you're coming from and the issue you're trying to solve now. That's a difficult one since the end-point of a path is the center of a tile... BUT I think (will need to check the code) that you can override a path point so you could place the final point as the exact co-ordinates that the player clicked and since you've already created a path you know that the tile in question is not occupied.

That said you don't want to move the player to a point where their 3d bounds intersect the 3d bounds of another object because this will throw the depth-sorting system off. I'm working on a simple collision system that will resolve 3d bounds intersection by moving the offending entity back along its movement vector until it is no longer intersecting but it's not there yet. I think you could probably get away with it if you set the player's 3d bounds to 1, 1, 1 .. then it will still depth-sort but is unlikely to intersect other objects unless the path-finder is acting up (which it still does sometimes - separate bug).