New Version of Phys2D

Game Mechanics
#21

I think it’s a great idea to have proper support for 2d in JOODE. All my work on phys2d is under the phys2d license as well so you can copy whatever you need. However, isn’t there something to be said for a small 2d collision detection library as well? I mean, suppose JOODE has all the functionality for 2d that phys2d has at some point, would there still be a reason to maintain phys2d?

I was also wondering whether there is/will be a lot of shared code in the 2d and 3d stuff of JOODE, other than general math (vectors/matrices) and containers (hashmaps/lists). If there is not that much overlap, wouldn’t it be good to have two separate libraries?

Then a small update on my progress. I’ve made significant progress for the convex polygon collisions. It seems to be working completely (also with lines, circles and boxes), but I have not thoroughly tested it yet and some optimizations remain. As I said before the methods I employ should work for non-convex polygons just as well (a little less efficiently though). I’ll give that a try tomorrow or tonight.

I’m also in the process of allowing lines to be moving colliders, but haven’t quite finished that. Unfortunately it means I will have to dive into the old code which is, imho, ugly and unreadable (not just because it’s not my code).

#22

The line shape was a dirty hack in place of proper polygon support. Might be best to just rip it out altogether and only replace it if it’s actually required for your project. Most things I want to do with the library won’t need lines if polygon support is in there.

EDIT: Finally got around to looking at the code - looks great. I wonder if the collider factory might be tidier has a mapping table between pairs of shape classes to collider instances - less methods and comparisons that way. Just look up the pair, it could handle subclasses of shapes using the equals method of the pair wrapper also. Can’t wait to see this running.

Kev

#23

I like the idea of sharing code between the projects for the time being. I hope sincerely that Phys2D keeps simplicity and speed, while I’d like to see JOODE become highly configurable and full-featured, with several choose-able integrators and a priori detection. Both projects can benefit from going down slightly different paths.

#24

Seems like a good idea. I’ll have to keep that in mind, since I have the more or less natural tendency to keep adding features/complexity it will be difficult :slight_smile: for me.

Again a small update, I have colliding polygons now, but I discovered some bugs in the process. Some of which are very nasty, especially finding the collision ‘features’ proves to be a royal pain. These features are the entry and exit point of one polygon into the other. These can be simple, i.e. where the first polygon just penetrates the other’s hull or complex when the first polygon goes all the way through the other polygon.

Not only does the contact point stabilization depend on these collision pairs but also the penetration depth calculation.

Hmm, who exactly am I explaining this to? ;D … Well at least you know I’m still working on it.

I’ll see what I’ll do with the lines, my first thought is to leave them in because they can be a lot more efficient in some cases, for example when polygons have very different sizes like walls colliding with objects. Also because the current implementation of polygons doesn’t allow non-closed polygons, I’d leave them in. Maybe it’s an idea to simplify them a little (the Line class I mean).

Then finally I have one question. I really need some containers here an there, sorted and otherwise. So far I’ve managed to restrict myself to a HashSet from the standard library. In the end however, these dependencies need to be cut. Does anyone have some good util classes under a BSD compatible licence?

–gideon

#25

??? Why do you need to not depend on the standard Java libraries?

#26

I’ve got the polygon support more or less ready. There are still many bugs to find/fix, optimizations to be made and code to be cleaned up and better documented (although it is quite alright). Bottom line, no patch yet but you can get the current stuff from my project’s svn server (which I mentioned in some earlier post in this thread).

To tease you, here’s a picture of a nice demo (yes, it really runs perfecty):

http://gideon.home.fmf.nl/polygonCollisions.gif

Is there really no good BSD licenced util package out there? Because I’ve had to use some more standard java stuff.

Well it wasn’t really my choice, but Kevin put some effort into making it independent so I suppose I should keep it that way. There are some very clear advantages to having less dependencies though:

  • no problems when the java api changes and the library will work with any java api
  • it should be fairly easy to make a stand alone package which is light weight
  • you don’t have to deal with someone else’s bugs (which is a minor issue with the standard libraries)
  • … probably more…
#27

Indepenent of AWT only - most of the rest of the JDK is fine.

Infact dragging in an additional library for containers etc would be more of an issue to me - it’s about distribution size and ability to compile with GCJ and cut down JDKs…

Kev

EDIT: Looks frickin amazing btw :slight_smile: Any ideas when the patch will be available - obviously it makes phys2d a much more viable project if polygon support is added.

#28

yeah. bring on the poly support!

#29

Really impressive man. I’ll be looking forward to have some release quality code so that I can provide support for Phys2D from Xith3D (efforts from physics are currently being made).

#30

Wow, the more I see this unfold, the more I’m tempted to make the jump to this! But I can’t at this point…

Nevertheless, great job. I look forward to seeing this in action. :slight_smile:

#31

That looks amazing, well done, really impressive.

I can’t wait to see it in action!

#32

A small update: I am still working on the collision detection, it’s mostly a long and painfull process of debugging. There are quite a lot of problems with floating point rounding errors which are not easy to solve. While many examples work perfectly, like the gear system I showed before, however some simple examples exhibit very strange (jumpy) behaviour.

Movable line support is coming along nicely, although I will have to seriously alter the collision detector’s structure to properly implement line-line collisions and allowing one way pass-though lines. For both problems, I need to know on what side (of a line) the other body was in the last frame. Just making the collision detector statefull isn’t enough; it will have to be updated each frame as well. But I’m talking to myself.

Currently I’m planning to

  • get the most apparant bugs fixed or work around them
  • get movable line support working except for line-line collisions and pass-through lines
    … and release a patch. After that I’ll continue with optimizations and getting the line-stuff working, but that will be another patch.

I still update my project’s svn fairly regularly: http://sourceforge.net/svn/?group_id=117163, in case you can’t wait any longer.

#33

Sorry to state this if you already knew, but you could do all your calculations as doubles then cast the result…I know Intel FPUs have 80bit precision so a double takes roughly the same time as a float to calculate (there are a few other issues).

DP

#34

Using doubles only makes the problem more rare: very small penetrations will simply always be there, I have to deal with them some way or another.

#35

Did you check the performance impact of using doubles instead of floats? (Of course correctness should be of higher priority than performance.)

Marvin

#36

Why should it? As long as everything looks ‘natural’ I’m ok with it. In any case, I haven’t had any need for doubles yet; the problems that I encounter are usually more related to picking the right collision normal and penetration depth.

There might be some trouble up ahead though. I haven’t properly tested the accuracy yet, for example placing object very far from the origin and using very small objects. Most certainly things will go wrong somewhere, if it turns out we need more ‘space’ (determined by the minimum objects size and maximum distance from the origin) switching to floats isn’t really big a deal.

Maybe fixed point math could be useful. Does anyone know whether fixed point math actually is faster than floating point math? On modern processors like my dual core amd64 it’s probably completely irrelevant, but what about mobile processors?

#37

fixed point is faster on mobile phones than floating point. IIRC, a few games use fixed point to accelerate 3D rendering on the NGage platform.

DP

#38

I checked out Phys2D yesterday with the idea of intergrating it with JOODE. It looks really nice, but at the moment there are not really enough new 2D primatives to really warrent the work. So just waiting for polgon support… hehe. I would personally like accuracy to be there, with a switch to turn it off, though our tri mesh support also has problems with very pointy thin geometies (ported from Collada I think).
Tom