• Advertisement
Sign in to follow this  

Have you used havok before?

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

Well I would just like to know if you've used havok and if you have what do you think about it?

Share this post


Link to post
Share on other sites
Advertisement
Yes, I have. It's a good system (assuming you're talking about Havok Physics). It has limitations, but nothing worth mentioning in response to such a vague question.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Yes, I have. It's a good system (assuming you're talking about Havok Physics). It has limitations, but nothing worth mentioning in response to such a vague question.


Yes Havok Physics, what limitations?

In the game I'm making I need to make mesh objects that don't need cooking, does Havok offer this feature?

Share this post


Link to post
Share on other sites
I've not used Havok. But...I imagine most engines that support some variant of collision detection using meshes will do cooking. They might not call it "cooking." They might not reveal explicitly that they are doing it, e.g., it might be done during export from, say, 3ds max, and they just roll it up into "export." At runtime, for procedural or custom data, it might happen automatically in the "setindices/setvertices" method or whatever. But, somewhere or other, cooking, by whatever name, most likely is there.

The reason is...cooking prepares a data structure such as an octree spatial partition or maybe an OBB tree that makes it vastly faster to search through an arbitrary mesh to find candidate collision pairs at the triangle level. Without something equivalent to Ageia's "cooking" you'd be talking about a dumb walk through all the triangles, and that means slowdown.

There is certainly a performance consideration then, when loading or procedurally generating custom meshes at game runtime, when you want to use those meshes for collision detection.

Out of curiosity, is there some reason why you cannot represent your object as one or more primitive shapes, such as sphere/capsule/cube? If you can use a collection of primitive shapes, instead of mesh/triangle-level collision detection, you can avoid full-up "cooking."

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
In the game I'm making I need to make mesh objects that don't need cooking

No, you don't. You just need the ability to process them at runtime. IIRC, Havok does allow this.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by EmptyVoid
In the game I'm making I need to make mesh objects that don't need cooking

No, you don't. You just need the ability to process them at runtime. IIRC, Havok does allow this.


Good!

Share this post


Link to post
Share on other sites
Quote:
Original post by grhodes_at_work
I've not used Havok. But...I imagine most engines that support some variant of collision detection using meshes will do cooking. They might not call it "cooking." They might not reveal explicitly that they are doing it, e.g., it might be done during export from, say, 3ds max, and they just roll it up into "export." At runtime, for procedural or custom data, it might happen automatically in the "setindices/setvertices" method or whatever. But, somewhere or other, cooking, by whatever name, most likely is there.

The reason is...cooking prepares a data structure such as an octree spatial partition or maybe an OBB tree that makes it vastly faster to search through an arbitrary mesh to find candidate collision pairs at the triangle level. Without something equivalent to Ageia's "cooking" you'd be talking about a dumb walk through all the triangles, and that means slowdown.

There is certainly a performance consideration then, when loading or procedurally generating custom meshes at game runtime, when you want to use those meshes for collision detection.

Out of curiosity, is there some reason why you cannot represent your object as one or more primitive shapes, such as sphere/capsule/cube? If you can use a collection of primitive shapes, instead of mesh/triangle-level collision detection, you can avoid full-up "cooking."


1. Can't represent it as a shape because it's terrain.

2. I can't represent it as a height map because it's a cube thats been normalized to the shape of a sphere so the chunks are deformed in such a way that they can no longer be represented by a height map.

Share this post


Link to post
Share on other sites
I know this is a Havok thread but if you don't mind the mention, (if you do mind then just ignore this post please!) it might be worth pointing out that the new(ish) PhysX shape, the "heightfield shape", doesn't require cooking. Plus future plans for it are said to allow streaming of just the Y coord.

Now, if you're still reading, the point is (and I haven't actually tested this as it's off-topic) that I don't see any reason why you couldn't get the shape's descriptor, adjust it, and save it back...like any other physx shape? And should that not be possible then it surely soon should be possible, due to the nature of it being cook-free!

Ah well, back to Havok...always interesting reading about other SDK's than what I use :)


edit: eek, I just hit post and remembered reading your mention that the terrain is in the form of a sphere...guess the above could be good for other cases though. Or saying that, if you really wanted to workaround, 6 heightfields could do it.

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
I just thought of something can havok do any type of height map distortion?


I doubt it. This would be a somewhat nonstandard thing to do, in games.

Is this a fixed mesh, or is it some kind of LOD system? Trying to figure out if there is more complexity to your situation.

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
I just thought of something can havok do any type of height map distortion?


No, but you can..

Havok utilizes a client defined height field object. Internally you could apply any distortion that you'd like and simply return the collision results to havok.

Share this post


Link to post
Share on other sites
Quote:
Original post by bzroom
Quote:
Original post by EmptyVoid
I just thought of something can havok do any type of height map distortion?


No, but you can..

Havok utilizes a client defined height field object. Internally you could apply any distortion that you'd like and simply return the collision results to havok.


Nice! I'm looking forward to seeing the API once it is finally released for noncommercial users.

Share this post


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

  • Advertisement