Sign in to follow this  

Newton Or ODE?

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

OK so I've had some problems finding the right physics engine to use with my game. It uses full sized planets and generates the terrain as you move around. I was using PhysX but I don't have time to cook the meshes every time you walk 20 feet and it has to work on the operating system that my server will be using (Not sure yet...) Seems Newton can be programed for almost any operating system and it does not require me to cook the meshes before I use them but when I use the playground thing and throw a object real fast it gets stuck in walls and stuff. My game is a MMO and if your walking around a city and someones been making things like tables and chairs get stuck on the side of walls it would take away allot of the realism and make the game super crappy. the ODE Physics library seems sound but I've not seem many samples. So I cant really be sure. Has someone used both and can tell me which is better and why?

Share this post


Link to post
Share on other sites
From my own experience, ODE is lacking documentation compared to Newton and it is also much buggier than Newton. I am happy that I switched to Newton soon enough :) Although I must say, Newton is far from finished to be honest. I never managed to complex objects such as a chair working yet.

Share this post


Link to post
Share on other sites
Very true ODE is lacking documentation but I'm not sure Newton can do a game like mine its to buggy. I just dont want people to say "Hmm this game is awsome other then when the phsyics go crazy" =/ what I want to know is does newton always do that? or is it just bad programing on that one sample? alsoI'd like to know more about ODE theres like no info? and are these two the best other then PhysX? this is how I think they rank:

1. PhysX
2. Newton
3. ODE

Now PhysX is already out because I simply can not cook the meshes. So is Newton secound best? and is there anyway to make sure objects dont get stuck togather? Does ODE have any problems with objects getting stuck to each other?

Share this post


Link to post
Share on other sites
Every physics engine has problems with objects getting stuck together. Even Havok. Though havok is brilliant in it's collision resolution. Objects that are penetrating slowly emerge from each other rather than exploding. But to answer your question I personaly would chose ODE, but thats just because I have the most experience with it.

Share this post


Link to post
Share on other sites
Why don't you just use a physics engine wrapper? That way you can just target a specific engine later or use multiple engines....

As for which one is better for your problem, just try them all with the wrapper, and then you will know.

Share this post


Link to post
Share on other sites
You should be able to write custom collision routines for Bullet, ODE, Tokamak and JigLib engines that will work with your (presumably) procedural terrain. It's _probably_ easiest/best to use Bullet for this - so long as the rest of the engine is OK for you.

If you decided to continue with PhysX you could spawn threads/processes to cook the areas (in 2D tiles/3D cells) surrounding the active area as the game runs (caching to either file or memory) - though this depends on how fast the cooking is, and whether you can cope with the situation where the cooked data isn't generated fast enough....

Share this post


Link to post
Share on other sites
PhysX is completely out of question there is no way I have time to cook the meshes. And no not all physics engines have objects that get stuck together. PhysX never had objects that stuck together and trust me I put it though some real rough tests.

Share this post


Link to post
Share on other sites
Quote:
Original post by e64
Why don't you just use a physics engine wrapper? That way you can just target a specific engine later or use multiple engines....

As for which one is better for your problem, just try them all with the wrapper, and then you will know.


Very nice!!!! although I would still have to reprogram it after I find the right one. =/

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
Very nice!!!! although I would still have to reprogram it after I find the right one. =/


no, if you wanted to take advantage of a specific feature of an engine you can just inherit that directly, eg "#include palNovodex.h" and then use the GetScene() to get at the underlying novodex code - that way you don't need to modify any existing code at all.

Share this post


Link to post
Share on other sites
Wait, what?! Objects don't get stuck in walls for NewtonGD

With NewtonGD you can use a user collision to provide the collision data in real-time, since you manage the data yourself (unlike the other collision types, which have you send data to NewtonGD - still no "cooking", though).

Yeah, though, getting stuck in walls? Honestly never encountered that. I've stressed the engine well enough (I even broke the physics laws it follows and allowed stuff to collide with itself through portals), trust me.

As for chairs... Just stick a bunch of convex collisions together via a CompoundCollision.

Share this post


Link to post
Share on other sites
When I smash a object REALLY fast into another they one of 2 things. Get stuck togather or go right though. Thats in the playground sample but if its possable to make a object go the speed of light and it to not go though then Newton is perfect! Do you think it is?

Share this post


Link to post
Share on other sites
Well, PhysX might be able to handle that due to their fully swept collisions, but in general, you can't throw arbitrarily large numbers at a physics simulation. The integrator will fall apart in those conditions.

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
I was using PhysX but I don't have time to cook the meshes every time you walk 20 feet...


Hmmm. I think the way to optimize this is to pre-cook meshes, streaming pre-cooked data from disk as you move around. What you get with cooked meshes is after-cooking speedup. Other engines might not require cooking, but they also might not be as fast at collision detection as the cooked PhysX meshes. But you have to pre-cook to benefit from this.

Share this post


Link to post
Share on other sites
Newton has a 'continuous collision' mode that should remove/reduce tunneling problems. Don't know if the Newton playground uses that mode though...

Share this post


Link to post
Share on other sites
Quote:
Original post by grhodes_at_work
Quote:
Original post by EmptyVoid
I was using PhysX but I don't have time to cook the meshes every time you walk 20 feet...


Hmmm. I think the way to optimize this is to pre-cook meshes, streaming pre-cooked data from disk as you move around. What you get with cooked meshes is after-cooking speedup. Other engines might not require cooking, but they also might not be as fast at collision detection as the cooked PhysX meshes. But you have to pre-cook to benefit from this.


Did you even read the post its going to be a whole galaxy hundreds of tera bites of cooked mesh data PhesX is completely out of question and its not speed that I have a problem with. Did you really think I was acually saying the physics engine has to move as fast as light? that would be impossable! I need it to just add the factor of time to prevent objects from simply pasing another or getting stuck like this:

Image Hosted by ImageShack.us

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
Did you even read the post its going to be a whole galaxy hundreds of tera bites of cooked mesh data PhesX is completely out of question and its not speed that I have a problem with. Did you really think I was acually saying the physics engine has to move as fast as light? that would be impossable! I need it to just add the factor of time to prevent objects from simply pasing another or getting stuck like this:


OK, okay, so PhysX is out of the question, I believe you. I don't care which engine you pick. As for "fast as light," for what its worth (nothing I think) the only purpose of my comment was to clarify how to avoid in-game cooking. You never said "galaxy" before, only "planets," but I did miss the original post comment about procedurally generating terrain on-the-fly, so I now better understanding of why you were worried about in-game cooking.

As for PhysX, just for information in case someone here might still be vaguely thinking about it, the only objects that are cooked are triangle meshes, I think. If terrain is generated as simple uniform heightfield grids, then you can use NxHeightField, which doesn't need to be cooked.

Share this post


Link to post
Share on other sites
Hmm after another week of trying my hardest to get a small pile of objects to come to rest, I've decided to give up on ODE. The amount of parameter tweaking I've had to do makes using it counterproductive.

Share this post


Link to post
Share on other sites
Quote:

I tried bullet, but it continuously crashed with failed assertions. So I tried ODE, which sometimes crashes with failed assertions.

It would be useful to get to know which assertions you hit, so the documentation/feedback of Bullet can be improved.

Can you help with some feedback or reproduction case of those assertions?
Thanks,
Erwin
http://bulletphysics.com

Share this post


Link to post
Share on other sites

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this