Any guides or samples for applying the physics to a .x mesh?

Any guides or samples for applying the physics to a .x mesh?


I've been working with integrating Havok into my game, and so far it has been going pretty well. It can read .hkx files fine and I can fool around with them in the visual debugger, but I've hit a big problem. The physics part is fine and I understand it, but the rendering part has me in a snag. The game uses DirectX 9, and the only .x file mesh right now is a simple cube 1x1x1 meters (and its .hkx counterpart is performing fine in the visual debugger). Now I'm unsure how to proceed to get the rendered in-game mesh to move as its counterpart is. I assumed it would have to do with setting the mesh's position and rotation to the hkpRigidBody's with something like getPosition and getRotation, but I don't think I'm on the right track. Is there a guide or some sort of basic sample code I can see that performs this? Any bit would be extremely helpful.

Thank you in advance.

9 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

What I do is I get the position, then get the rotation quaternion from the rigid body. You do this by hkpRigidBody::getPosition() and hkpRigidBody::getRotation() I believe it is. If you want to get the x,y,z, and w components of the quaternion, you would use hkpQuaternion::getImag().getSimdAt(0) for the x value, then 1 and 2 for the y and z values. Same goes for position, you would do hkVector4::getSimdAt(0) 1 and 2 for the x, y, z values, where the hkVector4 would be the value returned from the hkpRigidBody::getPosition(). I'm assuming since you are using Direct3D you are able to use quaternions, so converting it into euler angles isn't necessary right now. Hope this helps.

I've done the exact same thing, and took basically the same approach as Benny suggested and it worked fine.

I used hkpRigidBody::GetTransform() though, which returns a hkTransform matrix and just copied that directly over to my mesh's world matrix for rendering, which seemed alot simpler to do at first.

Yeah, it may be worth mentioning the engine I'm using for some odd reason doesn't support setting an objects transformation via matrices, which is why exactly I don't use the GetTransform() method, which I can see being much more simple and more straight forward.

Thank you both very much! I've managed to give the in-game mesh the rotation and translation of the hkpRigidBody, and for the most part it's perfect, but there's one more problem.

The cube's position in-game is quite different than the visual debugger. The cube is set to start at 200 meters on the y-axis (and naturally falling due to gravity). However, in-game it appears much closer to the ground and falls slower, although it does impact the ground at the exact same time as its counterpart in the visual debugger. I think it has to do with the units of measurement. The rotation is perfect the whole way through, most likely because both Havok and DirectX use radians. When the cube hits the ground in the debugger, it bounces up about 9 meters, rotating the whole way through. In-game, it looks like it bounces up a meter at most and just rotates around like it's in a zero gravity environment, and slowly falls back down and settles on the ground just as in the debugger. So this leads me to believe that 9 units in Havok, is very different from what 9 units is in DirectX. Does DirectX use some common form of measurement or is it some arbitrary unit? Once again, any help is greatly appreciated.

Well, its more so depending on what units of measurement it was modeled according to I believe. 3ds max never really exported things correctly for me, so it got a little weird every now and then when using it. Havok works in meters, so one unit is for instance one meter. This is always helpful for me to think about when using Havok personally.

Hi Oliver,

Sorry for the delay in responding to your post. I believe DirectX just uses an arbitrary "unit" with no real-world relation. Since it's only a graphical system, it doesn't actually need to use any concept such as "meters" or "inches".

Havok, however, needs to have such a concept as it deals with forces which are measured in real-world units involving measuring real-world distance.

I'm pretty sure that if 1 DirectX unit = 1 Havok unit you'll be fine. Can you double-check that your construction of the graphical and physical boxes use the same measurements?


Thank you very much Daniel, you reminded me of something!

I use Maya 8 for modeling, and I use the meter as its unit. As a test I made a simple 1x1x1 cube and exported it to hkx (using no transform scene filter since it's already in meters). I loaded it into my program and checked it in the visual debugger. The cube was utterly gigantic, far larger than the 1x1x1 cube I made in the program for comparison (its rendered mesh looked equally large as well) . I exported the Maya file to an FBX and opened it in Deep Exploration, which listed its size as "100". Thus, the cube in Havok was 100 meters cubed instead of just 1. I used the transform scene filter to scale it from centimeters to meters (although the unit in that scene was still meters), and tried the hkx file in the program. It looked about half the size of the 1x1x1 Havok cube, so I adjusted the matrix a bit in the transform scene filter. I changed the .010 for centimeter scaling to .020 and exported it, perfect. Looked the exact same size as the 1x1x1 Havok cube.

I honestly don't know why, but I never thought about that when I had those size problems with .x mesh of the cube. I did try scaling it, but I never got the values right. That's when you reminded me by saying to check the measurements. I set a scaling matrix in my program to .020, rendered it, and it looked perfect. No crazy zero-gravity effect or clipping caused by mismatched sizes. Looks just like it does in the visual debugger.

Although that does lead to the question of why I have to scale it in the first place since it is modeled using meters as its unit. I don't mind it really, it's not that much of a problem now that I know how to fix it, assuming it does not lead to any future problems. Thank you once more Daniel, for sparking my memory!

No problem, Oliver. If you use the View XML filter when exporting you can see the numerical values of the dimensions of your geometry (e.g., the half extents of cubes, etc). This is pretty useful to help debug problems like this and can help you get your scaling in order.

Glad you figured out your problem!

Accedere per lasciare un commento.