CapsuleShapes and ShapeTransforms

CapsuleShapes and ShapeTransforms

Hi there

When i create a capsule-shape, i can specify two points and a radius for this shape. As i see it, this should eliminate any need to use transform-shapes on capsules, since i can pack any rotation/translation into those points, right ?

I tried it, and it seems to work. But since it is not mentioned in the documentation, i want to make sure, i don't rely on it now, and have it break in some more complicated situations.

Since i guess this should improve performance, compared to using a transform-shape, maybe in debug-builds a message could mention, that for capsule-shapes no transform-shapes should ever be necessary, just as it now shows a message, when you use a transform-shape as the root-shape of a rigid-body.

Jan.

9 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Hi Jan,

Is there any reason why you're doing this instead of settings this shape's rigid body's transform directly?

Daniel

Yes, in a compound-shape i can spare transform-shapes for capsules this way.

I intend to align my rigid-bodies and shapes to the same transformation, when a rigid-body only has a single shape, but i am not that far, yet.

Jan.

Hi Jan,

Do you intend to change this transform in runtime or is this just an optimization when creating the compound shape, not to be changed during simulation?

Daniel

So far i only did this as an optimization at creation. Is it possible to change a shape's transformation at run-time, at all? I don't intend to do such things, because i thought one would better do such transformations through joints.

Hi Jan,

You're absolutely right: it's not a very good idea to change a shape during runtime. The way you're doing things now is just fine and a very clever optimization. Definitely worth a mention in the documentation anyway.

By the way, could you clarify what you mean when you say you intend to align the transforms of rigid bodies and shapes?

Thanks,
Daniel

Ah, sorry that wasn't very precise, so here's what i meant:

I have a small editor, where i can create physics-objects (my internal representation) and built them out of shapes (one or several). The node that represents the physics-object can have its own position/rotation and each shape can have it's own position/rotation (local to the physics-object). Now, as long as a physics-object is built from only a single shape there is no benefit from having own orientations for both (the rigid-body AND the shape it uses), so in a preprocessing step (before loading the level into my engine) i could set both orientations to be equal, such that the rigid-body is set to the global position of the shape, and thus the shape can be attached to it (in Havok) without any additional local transformation.

It's just like baking certain transformations into a mesh, or whatever. In my case i "bake" the transformation into my scenegraph-nodes, if possible.

Of course, the moment i have a compound object, it is not possible to bake any transformations into the physics-object-node, since there isn't anymore a one-to-one correspondence between the rigid-body and its shape, so i definitely need to use transform-shapes in Havok to place all shapes where they are supposed to be.

Complicated description, for something pretty simple. I hope you understand what i mean.

Jan.

Hi Jan,

I think I see where I was misunderstanding: when you said "shape", I was thinking of that being a shape in the Havok context (i.e., hkpShape). You were actually referring to the shape that you intend to render, right? As opposed to the Havok rigid body which will be the physical representation of that graphical shape..?

Daniel

No, i was using the word "shape" to refer to something like hkpShape and "rigid-body" in the sense of hkpRigidBody. The problem is, in my own scenegraph i have nodes that mimic similar purposes and are actually called similar, too, so i didn't stick precisely to the Havok terminologie. Let me try again:

Lets just say you have a simple physics-object (like a crate, or something), that you want to "model" within Havok. For this you need a hkpRigidBody and a hkpBoxShape, which you attach to the hkpRigidBody. Let the center of the crate be at position (0, 1, 0). You can now set up Havok in different ways, but achieve the same thing (at least i think there should be no difference):

1) You create a hkpRigidBody and set its position to (0, 1, 0). You attach a hkpBoxShape directly to that rigid-body, thus the center of the hkpRigidBody and the hkpBoxShape will be identical, and you don't need any hkTransform. This would be the desired case.

2) You create a hkpRigidBody and set its position to (e.g.) (0, 0, 0). Now to get the same result, you cannot directly attach a hkpBoxShape to that rigid-body (because then your crate would be located somewhere differently, than you want to), but you need to insert a hkTransform (with a local transformation of (0, 1, 0)), to get your box-shape to end up in the right place.

Ideally you have case 1, but since in my engine both components (a node that is later preplaced with a hkpRigidBody and one that will be replaced by a hkpBoxShape) can be placed manually in an editor, the guy who builds objects might place the rigid-body and the box-shape at different positions, so you end up with case 2.

But when you have case 2, you can simply move the scenegraph-node, that represents the hkpRigidBody, to position (0, 1, 0) in a pre-processing step. Now, when the scenegraph is loaded into the engine and the data is used to set up Havok, you have a case 1, which is nice, because you eliminated the need to use a hkTransform.

Now consider that you have a compound-object, lets just say it is two boxes next to each other. One box at position (-1, 0, 0) and one at position (1, 0, 0). The CENTER of those two boxes will be at (0, 0, 0). To model this within Havok you could do it this way:

A hkpRigidBody at position (0, 0, 0). A hkpListShape. One hkTransform with position (-1, 0, 0) and a hkpBoxShape attached to it. Another hkTransform with position (1, 0, 0) and another hkpBoxShape attached to it.

OR, you could even do a little trick and do it this way:

A hkpRigidBody at position (-1, 0, 0). A hkpListShape. One hkpBoxShape with NO hkTransform in between. ONE hkTransform with position (2, 0, 0) and one hkpBoxShape attached to that.

This eliminated one hkTransform, again.

This elimination of hkTransforms by positioning the hkpRigidBody properly, was what i meant with "aligning my rigid-bodies to the shapes". I don't think it will do very much in terms of performance, but it's better than nothing.

Jan.

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui