Odd Results from Barycentric Coordinates and Mesh Normals [4.2 dev6]

Scylla-Leeezard Harden the side edges in Blender. Normals on the mesh look smoothed even for 90 deg edges, so 3 vertex normals for each triangle will differ greatly and the interpolation from barycentric weights will cause the hit normal to fluctuate a lot as you traverse each triangle.

@Scylla-Leeezard - Were you able to resolve this issue? May I ask that you share the solution with us?

I'm experiencing the same problem, despite hardening the side edges and smoothing the shading in Blender. The moment my character comes in contact with my track and starts using barycentric coordinates to determine gravity, I get extremely erratic results. None of which seem to correlate to the expected normal vector.

chetbeigemeister Geometry3D.get_triangle_barycentric_coords() is a generalized function that doesn't know anything about transformations. It just returns barycentric interpolation coords for a given point in a triangle. It's responsibility of the caller to put all arguments into the same transformations space. Otherwise the results won't be correct if mesh instance have any non-identity transforms.

The original code made a mistake of taking the triangle coordinates in mesh/object space while keeping the interpolated point position (gotten from raycasting) in global space.

If you need the normal in global space you can either:
1) transform the triangle vertices from mesh space to global space prior to passing them to bary function, using mesh instance's global_transform. And then transform vertex normals from mesh space to global space prior to interpolating them to get the final normal.
Or
2) transform the raycast point from global space to mesh space, get barycentric coordinates in the mesh space and interpolate the normal in the mesh space as well. Then transform the final normal from mesh space to global space, again using mesh instance's global_transform.

xyz Hello! I am so sorry to necropost; however, you are the only person I've been able to find giving good advice on this topic.

I'm getting similar results (mainly post 4) as OP using mostly similar code. I've experimented with your answer and I cannot seem to figure out where exactly you would convert between local and global spaces. I've tried to think about it logically, but I can't seem to get it right.

1. Could one just multiply the vertices in the for loop by global_transform and leave it that? For example: var vertices: Array[Vector3] = other.get_vertex_positions_at_face_index(ray_cast.get_collision_face_index()) * global_transform

2. When you say "transform vertex normals from mesh space to global space prior to interpolating them to get the final normal," are you saying that you could do the same thing as the vertices array (multiply the normals during iteration by global_transform)? I think what I'm not understanding is the "prior to interpolation" part - as in, what step in the process that would be. Wouldn't that be when OP calls and passes the normal align_up_direction?

xyz Yes it does!

To give you an idea of what is working, here is the core code. Adapted from OP's code, but I made the global changes.

You can see I multiply by each vertex by GlobalTransform, and I also multiply it to upNormal when I pass it to SetUpDirection().

Vector3[] vertices = new Vector3[3];
Vector3[] normals = new Vector3[3];

for (int i = 0; i < 3; i++)
{
    vertices[i] = meshData.GetVertex(meshData.GetFaceVertex(normRay.GetCollisionFaceIndex(), i)) * GlobalTransform;
    normals[i] = meshData.GetVertexNormal(meshData.GetFaceVertex(normRay.GetCollisionFaceIndex(), i));
}

Vector3 baryCoords = Geometry3D.GetTriangleBarycentricCoords(normRay.GetCollisionPoint(), vertices[0], vertices[1], vertices[2]);

Vector3 upNormal = (normals[0] * baryCoords.X) + (normals[1] * baryCoords.Y) + (normals[2] * baryCoords.Z);
upNormal = upNormal.Normalized();
SetUpDirection(upNormal * GlobalTransform, delta);

In SetUpDirection(), you can see I'm using GlobalTransform as well.

  private void SetUpDirection(Vector3 upNormal, double delta)
  {
      Transform3D normTransform = GlobalTransform;
      normTransform.Basis.Y = upNormal;
      normTransform.Basis.X = -normTransform.Basis.Z.Cross(normTransform.Basis.Y);
      normTransform = normTransform.Orthonormalized();
      GlobalTransform = GlobalTransform.InterpolateWith(normTransform, .5f);
  }

paftdunk Matrix multiplication is not commutative. The order of operands is important. To transform a vertex by a matrix the order should be matrix * vertex. Your code is doing vertex * matrix. This is equivalent to multiplying with a transposed matrix which would result in inverse transformation (if the matrix is orthonormal).

Also to transform a normal properly you need to nullify the translation part of the matrix or use only 3x3 submatrix aka the basis. So you can do matrix.basis * normal_vector. If there is some proportional scaling in the basis you either need to orthonormalize the basis prior to multiplication or normalize the resulting normal vector. If there is non proportional scaling in the matrix, you need to use transposed inverse of the actual matrix. Since Godot's transform class doesn't implement transpose function, you can do normal_vector * matrix.basis.affine_inverse(), which now reverses the operand order to transpose the matrix.

paftdunk Post a better image and complete code. Hard to see what's happening there. Remove the interpolation in SetUpDirection for now. First make it work instantly. Just assign the final transform you calculated. Interpolation may introduce other problems. You interpolate barycentric coords anyway so it should work smooth (when on smooth surfaces) without that last interpolation. Always try to isolate the issue into minimum of code. Oh, and you need a second cross product there when calculating the final basis to ensure the wanted orthogonality.

paftdunk Could you explain the need for the second cross product?

I explained it. It ensures the orthogonality of the basis vector. orthonormalized() does that as well but it does not guarantee the order in which it does the cross products. So if your basis vectors are not perpendicular when calling orthonormalized() the function will have to change the direction of some of them to make them perpendicular, but you don't know which ones will be changed. It may happen to be y which is your interpolated normal. You don't want that to be changed. So better do it yourself using two cross products so that you end up with the orthogonal vector and use orthonormalized() only to normalize the vector lengths.
So:
y = normal
x = y cross z (or as you've put it -(z cross y)
z = x cross y
orthonormalize

xyz I gotcha now, thank you! I've learned a lot math-wise through you, so I appreciate that and I'm going to continue reading/practicing with it so maybe one day I'll be able to tackle this since I just cannot get it working.

I'm going to go back to the drawing board and figure out a new approach to this problem.

paftdunk Can you post a minimal reproduction project? The whole thing is straightforward, there shouldn't be anything hard or mysterious about it. You likely have a bug somewhere in your transformation calculations.

paftdunk Normals/vertices need to be transformed from collider's space to global space. Not from skate's space which you're currently doing. That doesn't make much sense. So the matrix/basis you're multiplying them with needs to be collider's, not skate's.

You copypasted my pseudocode without thinking. I used GlobalTransform as a generalization, hoping we're understanding that this is GlobalTransform of whichever object triangles belong to.

paftdunk Well you're trying to move the skate only in global horizontal plane. That will seemingly work only when on near horizontal surfaces. The steeper it gets the glitchier it becomes. Since you're changing skate's orientation in 3d space, it needs to move "forward" from its own point of view. This "forward" changes as your rotate the basis. So to go "forward" you need to move it along its z basis vector. Ditto for y when "vertically" constraining to a collider. You need to move along the normal (or y basis), not along global y axis. If done properly the skate should go smoothly around a sphere without glitches.

Hard edges will obviously be a problem that needs some additional care, but that's for another topic.

paftdunk paftdunk Just directly add some offset along the current y basis to the position prior to doing MoveAndSlide(). It's one line of code. You can also do it along the bary-interpolated normal as that'll be the same vector after you align your basis with the normal.

And use GlobalTransform instead of Transform. Ditto for position. Those two may coincide in a simple setup but as the setup grows they could become different. Use global ones to prevent future gotchas.

paftdunk GlobalPosition = GlobalTransfrom.Basis.Y * offset;
It has nothing to do with altering the basis or the velocity. Simply nudge the position. Or just alter the skate's hierarchy by putting an empty 3d node at the root, parent the mesh to it and position that mesh a little bit up. That way you can put the root node at the exact rayhit point.

Bringing gravity to this would require some changes in the whole approach. You first need to decide what exact type of movement this should be; gravity/inertia based simulation or something more stylized. The approach you started with would facilitate the latter.

xyz I am going with the stylized approach which is why I'm so hellbent on figuring this out, haha. I know generally how I'm going to attack it, it's just the fundamentals here.

As far as the offset with the basis, I'm having a little trouble with that.

When I do GlobalPosition = GlobalTransform.Basis.Y * offset, the CharacterBody ends up near the origin of the scene but offset on the y-axis based on my offset value. I've attempted to multiply the entire Basis.Y vector with another vector (I've attempted different values for the X, Y, Z) and a single float.

Thinking through this: I get, for example, the velocity vector - I am multiplying the speed in the forward direction; however, this isn't setting the position directly. But by doing GlobalPosition = GlobalTransform.Basis.Y, I'm NOT taking the current position into account, just the Basis.Y, hence it would end up at the 0, 1, 0 (since Basis.Y would be 0, 1, 0).

What am I missing as far as what the offset SHOULD be structured like? Especially in the case of getting the collision point.

paftdunk I made a typo. It's GlobalPosition += GlobalTransfrom.Basis.Y * offset.
Without += the whole thing wouldn't be an offset from the current position

paftdunk No, because it follows the line where you assign the rayhit point to the position. We're discussing this line in that context. You can do it all in one line. The gist is:

position = rayhit_position + offset_along_y_basis

or:

position = rayhit_position
position += ofset_along_y_basis

xyz Look at this thing go!

I think I can take it from here

Thank you for all your help again!

paftdunk Look at this thing go!

Insanity!

paftdunk I only see jitter when transitioning between objects, not between faces. Ist hat what you mean? This is understandable because you can only bary-interpolate when on the same object. To minimize it, don't set the normal directly but continually interpolate from the current normal towards wanted normal a little bit each frame.