Making sure I'm doing this right.

[snoozbuster]

Okay, I've been hunting for this bug somewhere in my code and can't seem to find it. What happens with it is that most entities with a LocalPosition have their collision data offset from the intended position. I have a class called RotateMachine that takes a center position in the constructor and then calculates the LocalPosition based on that and the entity's position, and it looks like this:

Code: Select all

foreach(BaseModel m in modelList)
                {
                    m.Ent.CollisionInformation.LocalPosition = m.Ent.Position - centerOfRotation;
                    m.Ent.Position -= m.Ent.CollisionInformation.LocalPosition; // keeps the model positioned where it was
                }

This is right, isn't it? Usually, even if it gets close to the correct answer, it's still off by a little bit. Some entities do just fine with this, but others break. Even more oddly, models which I have checked are at the origin in the modeler and checked again aren't drawn in tandem with the collison data drawn from the associated entity's CollisionInformation.BoundingBox, even using CollisionInformation.WorldTransform.Matrix. Are there any cases when drawing with CollisionInformation.WorldTransform.Matrix will produce an incorrect result? I already know that it won't work when the entity being drawn isn't in any Space, but other than that, is there anything?

[Norbo]

This is right, isn't it?

The LocalPosition is the offset from the entity position to the center of the collision shape in local space. If the entity has nonidentity orientation at the time of this calculation, the LocalPosition will not be correct.

Another minor point- the entity's Position is its center of rotation. It may be more intuitive (though equivalent) to simply set the position directly to the centerOfRotation.

Are there any cases when drawing with CollisionInformation.WorldTransform.Matrix will produce an incorrect result? I already know that it won't work when the entity being drawn isn't in any Space, but other than that, is there anything?

Two possibilities come to mind:
-The collision information world transform operates purely on internal data. If some code uses interpolated states and some other code uses the collision information world transform, there will be an inconsistency. The result will likely be a jittering or half-updated (out of sync) appearance.
-The world transform points to the center of the collision shape. If the graphic is not consistently aligned but is positioned using the transform, it will be offset.

As far as any situations where the collidable's world transform itself is 'wrong' with respect to the physics- no, that should not be possible. That world transform is the true physical state used internally to perform collision detection.

[snoozbuster]

This is right, isn't it?

The LocalPosition is the offset from the entity position to the center of the collision shape in local space. If the entity has nonidentity orientation at the time of this calculation, the LocalPosition will not be correct.

Another minor point- the entity's Position is its center of rotation. It may be more intuitive (though equivalent) to simply set the position directly to the centerOfRotation.

The entities do not have rotation when I do this, so it should be right. I also did set the position to centerOfRotation to avoid precision errors.

-The world transform points to the center of the collision shape. If the graphic is not consistently aligned but is positioned using the transform, it will be offset.

This sounds like it might be the problem... What's happening is the models are being drawn in the correct places, but the collision data is offset in some undesirable direction. Which WorldTransform are you talking about? The entity's or CollisionInformation's? Here's a screenshot demonstrating the problem:



As you can see, the yellow bounding boxes of the sets of collision information aren't aligned with the models, even though the models are drawn correctly.

[snoozbuster]

The LocalPosition is the offset from the entity position to the center of the collision shape in local space. If the entity has nonidentity orientation at the time of this calculation, the LocalPosition will not be correct.

Another minor point- the entity's Position is its center of rotation. It may be more intuitive (though equivalent) to simply set the position directly to the centerOfRotation.

The entities do not have rotation when I do this, so it should be right. I also did set the position to centerOfRotation to avoid precision errors.

-The world transform points to the center of the collision shape. If the graphic is not consistently aligned but is positioned using the transform, it will be offset.

This sounds like it might be the problem... What's happening is the models are being drawn in the correct places, but the collision data is offset in some undesirable direction. Which WorldTransform are you talking about? The entity's or CollisionInformation's? Here's a screenshot demonstrating the problem:



As you can see, the yellow bounding boxes of the sets of collision information aren't aligned with the models, even though the models are drawn correctly. In this particular case, the center of rotation is set to be right between the two arms of the bucket.

[Norbo]

Which WorldTransform are you talking about? The entity's or CollisionInformation's?

The entity.CollisionInformation.WorldTransform.

As you can see, the yellow bounding boxes of the sets of collision information aren't aligned with the models, even though the models are drawn correctly. In this particular case, the center of rotation is set to be right between the two arms of the bucket.

It may be useful to bring in the BEPUphysicsDrawer for debugging purposes. Seeing the actual configuration of the shapes could provide more insight than bounding boxes alone.

Other than that, I can't offer much beyond 'something isn't quite right'

[snoozbuster]

It may be useful to bring in the BEPUphysicsDrawer for debugging purposes. Seeing the actual configuration of the shapes could provide more insight than bounding boxes alone.

I can't quite get it to work. I created it, added entities, and call Draw(), but nothing shows up. I stepped through it and it appears it's drawing correctly, but nothing appears onscreen. Am I missing something? It sets the states it needs in Draw(), so that's not the problem...

[Norbo]

I can't quite get it to work. I created it, added entities, and call Draw(), but nothing shows up. I stepped through it and it appears it's drawing correctly, but nothing appears onscreen. Am I missing something? It sets the states it needs in Draw(), so that's not the problem...

Is the update method being called?

[snoozbuster]

I can't quite get it to work. I created it, added entities, and call Draw(), but nothing shows up. I stepped through it and it appears it's drawing correctly, but nothing appears onscreen. Am I missing something? It sets the states it needs in Draw(), so that's not the problem...

Is the update method being called?

Le derp.

[snoozbuster]

Okay, it works now, but this is all it does:



I'm not sure how that helps me other than telling me the models are the same. Does it help you at all?

[Norbo]

I can't quite tell because I'm not familiar with the geometry, but it looks like the bucket has more than a simple offset going on.

In any case, I can't do much more remotely, unfortunately. Something, somewhere, is transforming something wrong.

[snoozbuster]

I can't quite tell because I'm not familiar with the geometry, but it looks like the bucket has more than a simple offset going on.

In any case, I can't do much more remotely, unfortunately. Something, somewhere, is transforming something wrong.

I could have told you that. XD I'd be happy if I could get them to line up, even if they weren't in the right places. It's just strange that the entities are offset, but the models are drawn correctly.

[snoozbuster]

Hey, do you think it could be related to setting LocalPosition before the entity is added to a Space? I used to add all my models to a Space on creation, but then I realized that doesn't work and changed it. However, a number of constructors still reference CollisionInformation (in fact, I just fixed a bug that pulled a Quaternion of (0, 0, 0, 0) and crashed when you attempted to re-set the orientation to it). It wasn't until a day or two ago I even realized CollisionInformation was only relevent when the model is added to a Space.

Also, I played around with the centerOfRotation a little bit, and discovered even if I changed it, the models nor the collision data moved from their spots, they just rotated differently. Perhaps that's useful?

[Norbo]

Hey, do you think it could be related to setting LocalPosition before the entity is added to a Space?

That would be unlikely; setting the LocalPosition is a direct operation that does not do anything but change the value of the backing field. In every space update, the world transform is computed anew based upon the current LocalPosition and the entity's position and orientation.

It wasn't until a day or two ago I even realized CollisionInformation was only relevent when the model is added to a Space.

To clear up any possible confusion, an entity's collision information is available immediately after construction (unless it was manually force-created with no collidable, which is a tricky thing to do and isn't something that can happen by accident). Apart from the obvious parts like the Pairs list or its world transform which require interaction with a simulation to be automatically meaningful, the collidable is still there before being added to the space.

Also, I played around with the centerOfRotation a little bit, and discovered even if I changed it, the models nor the collision data moved from their spots, they just rotated differently. Perhaps that's useful?

In the way that I was interpreting the problem, that sounds like expected behavior. Conceptually, changing the center of rotation should not itself move a shape. Instead, how it moves should change.

[snoozbuster]

Alright. This is so peculiar... Okay, related question. Are there any conditions when TriangleMesh.GetVerticiesAndIndicesFromModel won't work as expected, such as when vertices are offset in the modeler or other similar conditions?

[Norbo]

Are there any conditions when TriangleMesh.GetVerticiesAndIndicesFromModel won't work as expected, such as when vertices are offset in the modeler or other similar conditions?

I wouldn't be surprised if there were, but I haven't encountered nor heard of any. It's a pretty simple convenience method which has alternatives- using another equivalent approach, like a content pipeline processor to extract the vertices, would be a good test.