Suggestions for (2D) simulation package

Newbie & Debugging Questions
#1

Hi,

I’m looking for an open-source Java simulation package for simulation of 2D (for now) worlds, very preferably with things like collision detection and simple kinematics already included. I have done some Googling but haven’t really found any satisfactory results yet. Does anyone have any suggestions?

Some additional info (not sure if it’s relevant, but better too much than too little I guess): I’m trying to write a toolkit for doing reinforcement learning. Some common (and the most applicable to my own work) scenarios include agents moving about in continuous- or grid worlds, avoiding / collecting / moving around objects, etc. So I was about to start coding that myself when in one of my brighter moments I realised it would probably be better to take an existing package for that and focus my own efforts on the learning algorithms.

So…if anyone knows of a package that suits my purposes, I would be very grateful :slight_smile:

Thanks
Han

#2

Hi,

You should check out Phys2D and JBox2d if you want physics.

It sounds like you don’t necessarily need that though, maybe just some simple A* pathfinding in a tile based map would be ok.

What kind of stuff are you trying to teach?

Good luck,
Keith

#3

Thanks for your reply. I had a look at Phys2D and it’s getting close to what I’m looking for, at least for continuous worlds. Maybe with a bit more functionality than I need, but I guess that might come in handy for when things need to get more realistic. Only thing is that I’m looking to simulate a world from bird’s-eye view, i.e. looking down on top of it, so I guess this would mean turning gravity off otherwise the objects in the world would start falling to the bottom of the screen? Actually what I’m looking for is quite like your SydneyEngine (in which I managed to get myself killed in record time, btw). Did you use Phys2D for that as well? Would you mind if I had a look at your source code?

I’m not trying to teach anything :slight_smile: I’m developing a toolkit for doing reinforcement learning, a field of AI in which agents learn from their actions by receiving rewards and punishments. So basically, a user of the toolkit should be able to easily program / config whatever world they want (“give me a continuous world with x objects and y agents, placed on these locations. When a collision happens, it should be handled like such”, etc). Then they plugin some standard learning algorithm for the agents that comes with the toolkit, or some algorithm of their own. For example, in your SydneyEngine I could place a learning agent inside the “main character”, and after a number of iterations it would hopefully learn to avoid obstacles and enemies (without path finding) and shoot at enemies.

Thanks again for the help!

#4

Sounds cool, AI is a great subject!

Sure you can get the source, but it’s probably a lot more complicated than it needs to be for your purposes since it’s main feature is that it’s multiplayer, but sounds like you only need a single player setup.

Here it is:

http://keithphw.freehostia.com/SydneyEngine/src.zip
And the library jars that you’ll need to unzip and have in the class path:
http://keithphw.freehostia.com/SydneyEngine/lib.zip

The collision detection used is pretty simple - if the player’s circle intersects an obstacle’s line, move the player back to where it was. Otherwise, the player can move to where it tried to go.

It’s not very good since there’s no physics and it can be quite frustrating when you are trying to move near a wall and then you get stuck. So you might be better off using one of the physics engines.

I’m interested to know how your project goes. Sounds like fun

Keith

#5

Thanks, I’ll check the code out.

So I’ve been browsing around some more and I’m getting bit dizzied by all the packages / engines that are out there.

For example, Slick was made by the same guy that made Phys2D. What’s the difference between the two? Is Phys2D purely collision and physics while Slick has more to do with graphics rendering? Does Slick incorporate physics as well?

I think I’ll go with one of those two, but I’d like to know what the difference is exactly and which one is supposed to be best (if they can be compared at all).

With regards to the progress of my project, I can post the location of the code when I have something working. It’s not really game oriented though, more an app to try different learning algorithms (although I’m trying to design it in such a way that learning agents can easily be plugged into other apps, like games).

Cheers
Han

#6

You’re right on: Slick does graphics (and a whole lot more game related stuff, but no physics), Phys2d does physics and physics alone. Very little overlap, but they should be fairly easy to use together.

#7

And ewjordan together with quixote_arg ported Box2d to java to make JBox2d but he’s too modest to say so :slight_smile:

See the cool examples here: http://www.jbox2d.org/

#8

Cool, thanks guys! I’ll check those three things out.

#9

Shh, it’s a secret - if nobody uses it, I don’t have to fix bugs that don’t affect me, and I retain the competitive advantage! :slight_smile:

Seriously, though, it’s more that I don’t really know Slick, and I’m pretty sure Phys2D is made with Slick integration in mind, or at least there are good examples of how to do it; I usually use PulpCore or Processing, so I don’t have much advice to offer as far as integration with the accelerated game libraries (doing up some examples using some OpenGL binding is up there on my todo list, but “up there” doesn’t mean as much as it used to, given the current state of my todo list…).

The main feature JBox2d has over Phys2d (both are Box2d based, btw, Phys2d is based off of Box2d Lite, as it’s now called) is continuous collision detection, but it’s also somewhat more complex to use, so which one is right for the job really depends on what you need to do.

#10

I’m learning so many new things here :slight_smile:

[quote]I’m pretty sure Phys2D is made with Slick integration in mind, or at least there are good examples of how to do it
[/quote]
Could you point me to some of these examples?

[quote]The main feature JBox2d has over Phys2d is continuous collision detection
[/quote]
I might need that, depending on what you mean…what is the difference between continuous collision detection and the type of collision detection Phys2D does?

#11

Hmm, I actually don’t know off the top of my head, but I would look around the Slick forums and Google a bit, I’m almost positive there’s stuff out there. Quite a few people have used Phys2d in projects, and I’m fairly sure a lot of those have used Slick, so I’d imagine there’s got to be some simple source examples around. I originally thought Phys2d used Slick for its examples, but it doesn’t look like that’s the case.

It mainly matters for fast moving objects. Most physics engines check for collisions frame by frame, so if an object is moving very fast towards a thin wall, fast enough so that there is no frame where it’s actually touching the wall, it will “tunnel” right through.

Continuous collision detection attempts to avoid this, in Box2d’s case by using the conservative advancement algorithm, which basically steps a fast moving object through several sub-steps, trying to put it within range so that the normal overlap check will trigger and resolve the collision (or, alternatively, decide that no collision is necessary). It almost always prevents tunneling problems, but at the cost of some speed.

So basically, if you need small, fast moving objects (anything that moves a distance greater than its own size in a single frame), CCD is a very good thing to have; otherwise, it’s not hugely important.

#12

Ok I see, thanks for the explanation. I might need it then since I’ve been encountering exactly these problems (tunneling through walls) in a commercial simulation package for robotics (Webots). Is there a way to choose between the two types of collision detection in JBox2D (for performance reasons)?

#13

Yes, and you can compare it in JBox2D demos here (enableTOI in options).

#14

As jezek2 noted, you can indeed switch TOI collisions (i.e. CCD) on and off in the demos, and you can do it within code on a per-body basis (BodyDef objects have an ‘isBullet’ boolean that you can toggle to true to always use CCD for a particular body).

However, CCD is on by default for dynamic objects vs. static objects, so for instance if all you need to do is make sure that objects don’t tunnel through level walls or other fixed scenery, you don’t need to do anything. Erin Catto (the guy that wrote Box2d in C++) decided that this was generally what people wanted and that the performance penalty wasn’t too extreme, so he left it enabled in that case by default. You only need to do something special if you need dynamic-dynamic collisions to use CCD, or if you want to turn off static-dynamic CCD.

FWIW, the toggle box in those demos that jezek2 linked turns the static/dynamic CCD on and off, but most of the examples don’t have dynamic/dynamic CCD turned on (the one that does is the first one, with the ragdoll bullet box). Also, almost every one of those demos is bottlenecked in graphics, as they use Processing in software mode to render. So if you used something like Slick, you’d probably see better performance.

The speed hit is probably somewhere between 2:1 and 4:1 for each body’s individual simulation time if it’s in a CCD scenario (i.e. its swept bounding box overlaps another swept bounding box), depending on the situation (since the TOI solver stops automatically when it has done a good enough job). I usually keep isBullet disabled for most normal objects, and turn it on for things like…uh, bullets, since if it’s enabled for one dynamic object it will be used for every collision that object participates in.

#15

Awesome, thanks much for the useful info.

Another question (maybe I should start a new topic because it’s no longer really on suggestions, is it): is there a particular reason why JBox2D (and Phys2D as well) implements the “shape hierarchy” from scratch? In other words, why doesn’t it use the interfaces/classes provided as part of Java2D? This would make the shapes much easier to draw by simply using Java’s drawing mechanism, or at least providing the option of doing so, while still being able to create your own drawing mechanism if desired.

If additional functionality on top of the Java Shapes is required (which I guess it is), you could have a Box2DShape or PhysicsShape or whatever interface that extends the java.awt.Shape interface. A CircleShape would either extend Ellipse2D or have an Ellipse2D, etc. Or was it maybe done for performance reasons?

#16

That is a very good question.

Unfortunately java2d shapes are final which is really annoying so you can’t extend them, and every time you try to get a copy of the points in, say, a GeneralPath you create a new list object which is very inefficient. And the points are copies so modifying them doesn’t change the actual GeneralPath.

You can create your own polygon class which implements java.awt.geom.Shape so you can draw and fill it using Graphics2D.fill(polygon) etc. I tried that, and the source for it is in this file, in the class astarpathfinder.geom.KPolygon: http://keithphw.freehostia.com/PathFinder/src.zip Maybe you can graft the Shape methods onto the code in JBox2D/Phys2D if you want to use it with java2D.

#17

Uhm…but the Java2D shape classes aren’t final. The GeneralPath class is final, but in 1.6 you can use Path2D which does the same as GeneralPath, and isn’t final. You can then access the coordinates of the path directly and don’t have to make a copy.

#18

That’s cool, didn’t realise that.

In the past every shape was final which was a head-ache.

Oh well, at least the class I made has a list of point objects which is easier to work with than extending Path2D.Float and having to work on its array of floats which must be x and y coordinates stored one after the other.

Anyway, making a polygon implement Shape isn’t too hard so you can do it yourself if you want the physics engine shapes to be drawable using java2d.

#19

I think the main reason for not using Java’s Shape class is that it would imply that any shape you can create with Java’s Shape class is supported in JBox2d, which is not the case. For every shape type there’s a lot of code in a lot of different places that must be written, so it’s hard to be very general.

Plus, it would bring us a lot further from a pure port of the C++ code. Now I’m starting to consider such divergences, as the C++ code has settled quite a bit and there are a lot of things that Java could do in a cleaner fashion, but it’s not quite as simple as writing a few lines to make JBox2d’s Shape implement Java’s, because in Box2d a lot of stuff needs to be done to get from a Shape object to the actual coordinates where the Shape should show up, since Shapes live on Bodys and need to be transformed before drawing.

I’m not saying something like this is entirely off the table, because all that stuff is doable and it would be pretty useful, but I’d have to consider the ramifications of it, and see whether the gains would be worth the time it takes (there are 10 methods to implement for each shape type, so it’s not trivial). We’ll see…if I find a bit of time, I may just bang it out and see how it goes.

#20

I don’t think that it’s good idea, physics should be independent of graphics. In games often (maybe nearly always?) graphical representation is different from physical one. You usually want to draw some sprite or so, or you have approximated the shape of sprite with more than one smaller physics shapes.

Some things can be pretty easy to do but still wrong in bigger picture, also it’s not nice to make dependance on Java2D when user uses completely different library such as Slick or PulpCore.