Jump to content
  • Advertisement
Sign in to follow this  
EmptyVoid

Why Not Havok?

This topic is 3988 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

I've been looking at many different physics engines for my game such as Ageia PhysX, Newton Game Dynamics, Open Dynamics Engine and Bullet. I loved PhysX but it needs you to cook the meshes and the way my game works its not possible. Newton seems from what I can tell to have bugs not just objects getting stuck together but some of the samples I've seen crash ODE and Bullet have no documentation. And none of them other then PhsyX have even been used in a game that I've ever heard of. Havok has been used in almost every game I've ever played or wanted to play and from what I can tell its has no bugs never seen any of those games have objects get stuck together or any real bugs with the physics. So I must ask why not Havok?

Share this post


Link to post
Share on other sites
Advertisement
Havok really isn't all that. Want to see a Havok 'bug'? Check out Team Fortress 2 - the ragdolls drop right through the floor.

No physics library is 100% perfect, there are always imperfections in the simulation. Working with these imperfections is the art of the physics developer, as it is up to him to make the simulation more robust. The more you learn about physics, the more you learn how to achieve this.

All of the physics libraries you have mentioned are excellent libraries and all of which have been integrated in commercial game simulations (with varying degrees of success ..). Bullet is a particularly attractive library.

Want a good reason to not use Havok? Ok here's 2 for you:-
- No demo (you're in or you're out)
- Money (lots of)

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
Havok really isn't all that. Want to see a Havok 'bug'? Check out Team Fortress 2 - the ragdolls drop right through the floor.


That was a bug on Valve's end, which they recently fixed.

As for the OP, I'd say if you have the cash and the manpower, go for it. Havok wouldn't get so much use and attention if it wasn't good, that's gotta be pretty clear. The main things to take into account imo though are obviously the cost, but then also the complexity.

When you're using things like Newton, they are not necessarily developed with the same budget or with the same input/availability of professional staff that some of the bigger teams are capable of. So whilst you may get a slightly less capable or less tested program from a smaller team, you should really be getting a "simpler" program aswell.

Havok is huge. So whilst it can do anything you want, you have to keep in mind that alot of complexity will come with that functionality. So the question is, is the extra hassle that you'll get worth the extra features, or is Havok in your program just overkill.


I'm not quite sure if I made my point very clear there, but hopefully I did.

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
Havok really isn't all that. Want to see a Havok 'bug'? Check out Team Fortress 2 - the ragdolls drop right through the floor.

No physics library is 100% perfect, there are always imperfections in the simulation. Working with these imperfections is the art of the physics developer, as it is up to him to make the simulation more robust. The more you learn about physics, the more you learn how to achieve this.

All of the physics libraries you have mentioned are excellent libraries and all of which have been integrated in commercial game simulations (with varying degrees of success ..). Bullet is a particularly attractive library.

Want a good reason to not use Havok? Ok here's 2 for you:-
- No demo (you're in or you're out)
- Money (lots of)


Bullet is good, I need to look into it more it seems to do all the stuff I need. But can some one name some games that I may have heard of that use Bullet, ODE or Newton?

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
I've seen crash ODE and Bullet have no documentation.


ODE manual

(Dated, granted, but 99% of it still applies, and it does an excellent job of explaining how the engine works.)

Quote:
Original post by EmptyVoid
But can some one name some games that I may have heard of that use Bullet, ODE or Newton?


Programs using ODE

Call of Juarez and BloodRayne 2 stand out in that list.

As you may have guessed, my preference is for ODE. It's open source, sacrifices accuracy for performance (and performance is much more important than accuracy for games), and if you download the source you can see a whole slew of nice demo programs. This is opposed to say, Newton, that tends to be more accurate but a bit slower, and is closed source. I can't say much about PhysX or Bullet. I should probably try them out at some point.

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
Newton seems from what I can tell to have bugs not just objects getting stuck together but some of the samples I've seen crash ODE and Bullet have no documentation.


And what is this?
http://www.bulletphysics.com/mediawiki-1.5.8/index.php?title=Documentation

Looks like documentation to me...

Share this post


Link to post
Share on other sites
What?! Stuff getting stuck together in NGD?

That's not supposed to happen. And it doesn't for me and the rest of the NewtonGD users. Heck, I even put NewtonGD through with a portal implementation (which is physically more advanced than Portal's portal implementation which uses Havok), and it still works 100% correct (if you don't believe me, look:
">youtube vid). You must be doing something seriously wrong [wink].

As in your other thread ("Newton or ODE"), as one poster suggested, you will need the continuous collision mode on for really fast moving objects (or really small stuff for that matter). First you need to enable it on the material (NewtonMaterialSetContinuousCollisionMode(...) or something, check the docs), and then on each body that will be moving super fast or is super small (NewtonBodySetContinuousCollisionMode(...) or something it was, check the docs).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!