New Version of Phys2D

Game Mechanics
#1

New version of Phys2D available including:

  • Several Bug Fixes
  • New Joint contribution - SpringJoint
  • New Demo

http://www.cokeandcode.com/phys2d

Kev

#2

I have started working on collision detection for convex polygons. Since someone else is (or was) already working on non-convex I chose this as a compromise. If both are finished the library’s users have more choice. Maybe I’ll also write a simple partitioning algorithm to break any polygon into convex ones when the need arises. When writing this I ran into what seems to me a design error in the library. This occurs when a test is needed between two Shapes. A visitor pattern is used as follows:


public interface Shape {
    public abstract Collider getCollider(Shape other);

    public abstract Collider getColliderFor(Box box);
    public abstract Collider getColliderFor(Circle circle);
}

public class Box implements Shape {
    public Collider getCollider(Shape other) { return other.getColliderFor(this); }

    public Collider getColliderFor(Box box) { return new BoxBoxCollider(); }
    public Collider getColliderFor(Circle circle) { return new CircleBoxCollider(); }
}

public class Circle implements Shape { ... }

The upside of this use of the visitor patter obviously is the absence of casts and instanceof if-else constructs. However, there is a big problem with it as well: when I add a new shape, I have to edit not only Shape but also all classes that implement Shape. This basically makes extension of the library by the user impossible without editing the library itself. Furthermore, in the current setup it is difficult to follow due to the indirections.

I would propose to use a factory class to retrieve the correct collider. The factory method should be a singleton rather than rely on static methods because the user should be able to override it.

What do you think?

#3

It was originally a factory and got moved to being this way. So moving it back, if it’s really required sure. As long as it doesn’t introduce any reflection (or pseudo reflection, i.e. getClass()) then it’s cool with me. If you want the API to support users plugging in their own shapes and colliders then it might be better just to make a central registry that you can register shape pairs with a collider or something?

Singleton vs Static methods - I’d really rather not go down this discussion, it rarely seems to get anywhere. Which you use is up to you.

Kev

#4

Well, I’m not quite sure about wether or not users would add new colliders, but it would be nice I suppose. You really dislike reflection that much? Maybe there’s some caveats I’m unaware of? In these cases I usually just choose the simplest solution. What I dislike most about most uses of instanceof, is the fact that, in most situations, you still need to cast the object. I suppose I prefer C++'s way of dealing with it. But well, in my eyes both java’s and c++'s typing systems are quite primitive anyway.

Anyways, from the top of my head I don’t really see a solution without reflexion. Any ideas?

#5

I’m not keen on reflection mostly through old habbits when it was a performance issue to be calling the methods regularly. I’m not entirely sure if there’s still an issue - worth trying performance of getting a type ID against getClass() or something - if all’s fine just ignore me :slight_smile:

Kev

#6

I have made quite a lot of progress. Convex colliders are implemented and I expect to have support for non-convex object very soon as well. If anyone would like to have a look at the code, check out the svn repository of towship: http://sourceforge.net/svn/?group_id=117163.

@kevglass
I will send you a patch as soon as things have advanced some more, but if you can spare the time to have a look at what I’ve done… I would appreciate any comments.

There is one problem for which a solution is not entirely trivial though: I have to find an accurate penetration depth for collisions. The current algorithm only finds the intersecting faces from which I can get the intersection point and normal, but penetration is not as simple. Does anyone have any ideas how to solve this?

#7

I’m not sure about instanceof but the rest of Reflection is still pretty slow.

#8

I recently ran a speed test for instanceof and it was as fast as an int type identifyer check.

Marvin

#9

[quote]There is one problem for which a solution is not entirely trivial though: I have to find an accurate penetration depth for collisions. The current algorithm only finds the intersecting faces from which I can get the intersection point and normal, but penetration is not as simple. Does anyone have any ideas how to solve this?
[/quote]
You can do a greedy search with your vertex-edges pairs, starting at your intersection point. Its optimal for convex polyhedra.

#10

I might give that a try, but I’ll have to find an approximation method as well for non-convex polygons.

#11

That’s not true in all cases. E.g. using a final field containing a Method object and call this is only slower by about factor 3. Which is not that bad. It’s never as fast as a direct call, of course.

#12

That’s alright for individual calls, but if you want performance, that is a huge hit. I have a project that I started out using reflection with. I had a lot of method calls in a loop and it was bad. I didn’t think it would work, but I tried it anyway because it was cleaner that having a huge if…else.

#13

ok, but compared to, i.e., jdk1.3 or similar, where it was factor 300 and up, it’s fast now :slight_smile:

#14

this is the part where I wish java had function pointers ::slight_smile:

#15

Yes. There are times where that would come in handy.

@irrisor: That’s for sure.

#16

Well, I personally think that in this case the, apparently not so expensive, use of typeof won’t give any measurable performance hit because it will happen only a very limited number of times per frame. Let’s see, the number of narrow phase collision checks times two to be exact. So that’s peanuts compared the actual collision check. Not that the discussion isn’t interesting.

I really mis on the fly construction of (anonymous) functions, like lambda’s in functional languages. Of course you can make an anonymous class in java, but I’d like to have access to variables in the scope without making things final. C# allows those kind of functions to be created. But I suppose this concept is only very distandly related to function pointers :wink: so I’ll stop ranting.

#17

I was looking at the API for Phys2D and I note the collision system is very similar to JOODE’s. I am trying to implement some 2D functionality for JOODEat the moment and I was wondering whether you would mind me intergrating your Geoms, Space and colliders into JOODE (in about a months time).

Tom

#18

He doesn’t mind (bsd license). :slight_smile:

#19

What he said - have to note that gideon is doing some work for polygons at the moment which may effect the geoms. If JOODE could be stuck in 2D mode I’d be tempted just to use that anyway (though I haven’t looked at the code at all yet :))

Kev

#20

Its not quite ready to force into 2D mode yet, but soon…