Anyone know a good managed physics library?

AndroidAdam

13-08-2010 22:56:35

Jeez, it's been a long time since I've been here :oops: However, I've been actively using Mogre and have come to a problem.
I need a very minimalistic physics library. I tried out MMOC, but when there were 40 different entities raycasting at the same time, it made the framerate unplayable. The problem is I need a completely managed physics library (no p/invokes or c++/cli). Any suggestions?
At the same time if anyone knows a workaround to using MMOC, that would be really great.

mstoyke

14-08-2010 00:21:08

The problem is I need a completely managed physics library (no p/invokes or c++/cli). Any suggestions?

As far as I remember there was a C# port of bullet physics some time ago. They used it with XNA. I never used it, but it might be worth looking at it.I don't have any bookmarks anymore so Google might be your best friend here...

AndroidAdam

14-08-2010 02:28:02

Thanks for the reply. Yeah, BulletX continues to show up in my searches, but I've had a bad experience with...
That was a while though, so I'll check it out again.

Beauty

16-08-2010 02:15:26

Nice to see you again :D

User boyamer works on a whole game engine.
Alimer Game Engine (Beta Stage)

It's available in similar 2 types. First with wrapped libraries and a second type managed only.
He wrote he uses PhysX for 3D and Farseer for 2D.
If PhysX is a wrapped library - ask him which one he uses for the managed only version.
Ask him in public, not by pm - I want to see the answer :wink:

Also you could look to the Axiom page. Axiom is a C# only port of Ogre. Maybe they also use or use/know a managed physics engine.

When you search in Google, try XNA as additional key. Maybe you get better results, because with XNA works no wrapped code.

By the way - isn't MMOC only a collision library?
Is there a support for rays? Or did you try to use Ogre ray queries instead of a physics/collision library?
To use rays for collision detection is no good idea in the most cases.

AndroidAdam

16-08-2010 21:43:16

Thanks for the reply. The problem is I really don't need a full blown physics engine. I just need to see if one one box is touching the other. Using MOC, or even just the standard ray scene query was to slow when 40 entities were casting rays. Thanks for the tip on using XNA as a keyword, I'll try it out.

Beauty

17-08-2010 01:38:46

If the boxes aren't rotated (always aligned to the axes of coordinate system), then you could wrote a simple check by using AABB (axis aligned bounding box), which is inside of Ogre/Mogre.
Don't be afraid to use a whole physics engine when it's small and support your needs. (Newton you can't need, but for comparism: Including Mogre wrapper the DLL file is just 800 KB). Also it could be that a whole physics engine offers better debugging options (e.g. display of collision bodies).

Maybe there is a port of OPCODE? (OPtimized COllision DEtection)
I don't think so, but just ask in their forum.
As I know it's a tiny library for collision only.

Additionally you can look to an XNA forum.
They should also have a need for collision detection - and the need is managed only.


The problem is I really don't need a full blown physics engine.
Look at your thread title - it's asking for a "good physics library" :lol:

By the way - did you ask boyamer?
He has a very comprehensive knowledge!

AndroidAdam

17-08-2010 23:44:31

Yeah, I was looking into the bounding box method, that's really all I need. The problem is I have to loop through each element in my scene against each entity that needs to be checked. So it ends up looking like this.

foreach (Entity ent in Game.Scene.GetMovableObjectIterator("Entity"))
{
foreach (Entity character in monsters)
{
if (ent.BoundingBox.Intersects(character.BoundingBox))
{
//collision code here
}
}
}

Even with optimizations to make sure that it's only checking against collidable objects, that brings me to 300 entities to check, multiplied by the 40 characters that are colliding bringing me to 1200 iterations, not good.

I wish I could use that method, because that's all I need, but I'm working on something that I think will do the trick and I'll share it with you guys when I'm done.

Beauty

18-08-2010 01:13:13

AABB checks are very simple to calculate and shouldn't need much CPU load.
But right, 1200 iterations for each frame seems to be much.
You could do a performance test and look to the frame rate. Maybe it's good for semi-parallel calculation inside the CPU. Maybe for many iterations the CPU cache helps to increase the speed. I don't know, but it would be interesting so see the test results.

Do you use Mogre for your application? In this case you even use a wrapped C++ library (OgreMain). So you could do the same for the physics wrapper. Or do you use an other graphics engine?
For Newton I gave an idea to the developer and he applied. Now it's possible to check for collision detection without callbacks. Just ast "what's colliding with body X" and you get the related ones.

I suppose there are different optimizations available for AABB checks. For example distance values, flags for objects that didn't move since the last frame, ignored objects etc. But ok, this needs experiences. But in physics engines there should be also many iterations when you have many objects. The question is the needed effort for each iteration. If it's only a flag, there is a good chance to keep it in the CPU cache (will be done automatically) what improves the performance.

AndroidAdam

21-08-2010 05:07:45

Beauty, your help has been greatly appreciated. I tried giving the AABB approach another go, and found what was slowing it down so badly. If a character was intersecting a colliding body, I did Console.WriteLine("Colliding"); well, I guess trying to write that line 1200 times every frame didn't make it very happy, because simply removing it and adding actual the collision code increased the speed significantly.

As to the questions you posed. I'm currently using Mogre, but need to leave the back door open for an Axiom port. If all goes well my game will be hitting the 360.

In regards to boyamers physics enginge, it uses p/invokes. which mono supports, but the xbox doesn't. (I found this information scrounging the Axiom forum for a physics library.

I actually did get a physics library (JigLibX) and added the hooks for Mogre. It was kind of like using .net to wrap something for .net, so it remained completely managed, the down side? The user would have to have XNA installed on their system. A complete port of the library would be possible, if not easy, but I'm afraid I've wasted enough time on collision and need to move on. If there's interest I'll upload the "wrapper", but most people here I'm sure are comfortable using their c++/cli wrappers.

Thanks for the help

Beauty

04-09-2010 16:45:24

Beauty, your help has been greatly appreciated. [...] I did Console.WriteLine("Colliding") [...] 1200 times every frame
Hehe, yes this causes much CPU load. :lol:
But in an other application I did the same mistake - Much output to the console or to a GUI textbox.

When you have a text as String and attach more text very often (myString += "more text") then it could be better to use the class StringBuilder instead. When you update a String, there will be created a new String object for every update. The StringBuilder class is good for heavy write access. (But you only need it if you change the content very very often. In most cases just use common Strings.)
Look here:
http://msdn.microsoft.com/en-us/library ... 71%29.aspx
http://msdn.microsoft.com/en-us/library ... 71%29.aspx


For advanced logging or heavy use (e.g. 1200 log entries per frame) there is a nice logging library called log4net.
http://logging.apache.org/log4net/index.html
log4net is a tool to help the programmer output log statements to a variety of output targets. log4net is a port of the excellent log4j framework to the .NET runtime. We have kept the framework similar in spirit to the original log4j while taking advantage of new features in the .NET runtime.
When the configuration is done (by code or by an XML file), you just need to call log.Info("neu log entry"), log.Warn("neu log entry") or log.Error("neu log entry") and the library will put it to the logfile (using an other thread). By a configuration you can attach time stamps, class names, etc. to your logfiles.
At first the usage is looking complex, but when you understand the concept, then it's fine.
Here is an easy example how to configure by code:
http://www.l4ndash.com/Log4NetMailArchi ... aspx#14858


In regards to boyamers physics enginge, it uses p/invokes.
Boyamer develops a whole game engine, not only a physics engine.
He has a p/invoke version and also a pure C# version of his engine for XNA/Xbox target. I'm shure that boyamer did or will embedd a pure .NET physics engine. If there is realy no fitting library, maybe he write a port for C#. He's a crazy boy and did similar things in the past, although it's much work :wink:



I actually did get a physics library (JigLibX) and added the hooks for Mogre. It was kind of like using .net to wrap something for .net, so it remained completely managed, the down side? The user would have to have XNA installed on their system. A complete port of the library would be possible, if not easy, but I'm afraid I've wasted enough time on collision and need to move on. If there's interest I'll upload the "wrapper", but most people here I'm sure are comfortable using their c++/cli wrappers.
Be welcome to publish your wrapper. Maybe somebody will need it.
I prefere to upload it to a public hoster like sourceforge, google code or bitbucket.
It's a pain, when people upload useful stuff to private websites or file hosters and after some months or years the links are dead.
If it's just a tiny code snippet, maybe you could add it to the Ogre wiki. (If you need help with the wiki, I can help you.)