Shifting axis

[snoozbuster]

So, I was getting closer to making physics work, and I came across an interesting bit of data when comparing the BoundingBoxes of the Entities to the drawn model data.

When objects fall down, their model falls up.

When something is moved upwards by velocity, the model slides sideways.

I know this is related to my choice of up-axis; Z is up and down instead of front and back, and so Y is side-to-side. As such, I would love to know what things I'm going to need to watch out for that are going to be affected by this irksome behavior. Also, I'm not sure of the code I'll need to transform a Matrix/Vector3/etc from a Y-up based value to a Z-up based value, and the places/code necessary where physics will be wrong if a Z-up value is given where a Y-up value is expected. I've gotten this far by finding and replacing Y with Z and Z with Y on the code samples I've actually needed to use, but that's just not gonna work here.

On an unrelated note, is there another way besided Space.Entities to get everything in the space, including StaticMeshs and such? I need to draw dem BoundingBoxes so I can continue le debugging.

[Norbo]

The math doesn't care what you consider the axes to be, so just pick an interpretation and be consistent. If you want Z to be up, you could just set your gravity to -Z and such; there's no need to use different coordinates for your graphics and physics. If you're not comfortable with coordinate systems, you may just want to stick with the traditional XNA meanings of Right/Up/Forward being (1,0,0)/(0,1,0)/(0,0,-1).

On an unrelated note, is there another way besided Space.Entities to get everything in the space, including StaticMeshs and such? I need to draw dem BoundingBoxes so I can continue le debugging.

There is no single list containing all objects with bounding boxes (the engine never needs such a thing). You can, however, examine objects as you add them to the Space.

If they're a type that has a bounding box or has something that owns a bounding box, you can add the boundingbox-owning object to a list. The easiest approach is to just check if the object being added is a BroadPhaseEntry (in which case add it directly) or if it implements the IBroadPhaseEntryOwner interface (in which case add the BroadPhaseEntry it owns to the list).

[snoozbuster]

The math doesn't care what you consider the axes to be, so just pick an interpretation and be consistent. If you want Z to be up, you could just set your gravity to -Z and such; there's no need to use different coordinates for your graphics and physics. If you're not comfortable with coordinate systems, you may just want to stick with the traditional XNA meanings of Right/Up/Forward being (1,0,0)/(0,1,0)/(0,0,-1).

I had the gravity at -Z already, [s]but what really makes no sense is why my objects that are clearly at (0, 0, 0) in my model and are set with a specific position aren't changing their position[/s] never mind, I fixed it. Pretty dumb mistake, too. And yes, I am aware you don't have strikethrough, but oh well. You should. I'm not sure what fixed the objects falling the wrong direction, though. XD Anyway, now to fix the odd sliding object that slides on +X instead of +Z. I dun get eet... All I'm doing for World is multiplying Entity.WorldTransform by my own WorldTransform (which is Identity anyways, except in the case of StaticMeshes, of which the odd sliding object isn't), and the bone transforms (of which I'm sure there aren't any). Do you have any idea? It seems that the Entity's WorldTransform would somehow be off, since it would be the only thing that isn't Identity, but the collision data I'm drawing from the BoundingBox inside it is clearly saying it's translating in the proper position.

EDIT: Also, I decided I really didn't need the boundingbox of the StaticMeshes in the Space, and everything else is an entity, so that's no longer an issue. =p

[Norbo]

Anyway, now to fix the odd sliding object that slides on +X instead of +Z. I dun get eet... All I'm doing for World is multiplying Entity.WorldTransform by my own WorldTransform (which is Identity anyways, except in the case of StaticMeshes, of which the odd sliding object isn't), and the bone transforms (of which I'm sure there aren't any). Do you have any idea? It seems that the Entity's WorldTransform would somehow be off, since it would be the only thing that isn't Identity, but the collision data I'm drawing from the BoundingBox inside it is clearly saying it's translating in the proper position.

There's quite a few unknowns there, so the best I'll be able to do is "something is not as it seems" One option is to do step-by-step debugging where transforms are involved and do a sanity check on each one.

[snoozbuster]

There's quite a few unknowns there, so the best I'll be able to do is "something is not as it seems" One option is to do step-by-step debugging where transforms are involved and do a sanity check on each one.

That's so hard to do when it's in a Draw() function... I did, though, and all the matrices look normal. I went into my model and changed the mesh to be at (0, 0, 0), and then I did the necessary adjustments to my code to actually put the entity at the new position. However, even though all my matrices seem to be correct, the model is drawn in (what appears to be) a mirror across the Y-axis, and then a mirror across the X-axis, and then a 90-degree rotation (or something similar) so that X is up. Like I said, I don't know much about matrices, but that kinda sounds like an inverted matrix to me... Oh ho! I just commented out the part of the world matrix that multiplies by the parent bone's mesh, as well as doing a sanity check after World is calculated, and in fact, it's all wonky from the parent bone transform. I thought that cause all the numbers in it were tiny (like, E-08 tiny) it wouldn't matter, but even though the translation on that matrix is zero the left/right/up/down is all weird and messes up the model. Somehow. Funky how tiny numbers do that.

I'll have to ask my modeler about this odd behavior; and you were right, something was not as it seemed. =p

[snoozbuster]

So, I played around with the matrix in my .fbx file, and I have almost fixed the oddness. However, the X and Y translation gets switched around by some unseen force (for example, if translation is (2, 1, 0) after multiplication it will be (1, 2, 0)). M41-M43 are the proper translations when they come out of Entity, and M41-M43 are 0 in the other two matrices. M44 is 1 in all of them. Mx4 is 0 in all the other rows. Why would X and Y get switched around? The really odd part is I plugged the three matricies into my fancy shmancy graphing calculator and they gave me the proper matrix.

[Norbo]

If the rest of the matrix is left unchanged except for translation component order, then something is very likely arbitrarily interfering with it (if it's always changing the component order, then it's probably not a regular matrix multiplication at fault either), or the collected data isn't right.

I can't remotely intuit what's going on, unfortunately. There's too little context for me to be of much help. I can tell you that it is almost certainly unrelated to the physics engine (particularly the XNA version)

[snoozbuster]

I fixed it by changing the .fbx's internal matrix to identity and flipping stuff in the properties and such. Thanks anyway. =p