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

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?

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."

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!

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.

I just thought of something can havok do any type of height map distortion?

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.