Getting surface normal from collision

What do you mean by "disabled and re-enabled the sphere collider game object"? $$anonymous$$anually in the inspector? Or via script?

It doesn't seem to change anything for me. Was trying to reproduce your jitter without success. The normals are fine, even when I apply any force to the objects.

Re: disabling/enabling. $$anonymous$$anually in the inspector. If you do the test below and everything comes out fine, try disabling and renabling the sphere object in the inspector while it's playing and try again.

Here's a little test script that should show what I mean. To set up the object, create a game object with a sphere collider and a rigidbody (disable useGravity, enable freeze rotation XYZ), add the script. Create several ramps and different slope angles, and even rotate a couple on the Y so they're not all facing XY perfectly. $$anonymous$$ove the game object with the WASD keys, RF for up/down movement. Enable gizmo display. Play and push the sphere against the ramp at various angles. Try stopping on the ramp. It will show a debug readout showing the current slope angle of the surface as well as draw a red line representing the surface normal of the contact.

 using UnityEngine;
 using System.Collections;
 
 public class CollisionTest : $$anonymous$$onoBehaviour {
 
     public float speed = 5.0f;
     private Vector3 moveDirection = Vector3.zero;
 
     private Rigidbody rb;
 
     void Awake() {
         rb = rigidbody;
     }
 
     void OnCollisionStay(Collision c) {
         // Display slope of all collision contacts
         ContactPoint[] ps = c.contacts;
         for(int i = 0; i < ps.Length; i++) {
             Vector3 normal = ps[i].normal;
             Debug.DrawRay(ps[i].point, normal, Color.red);
             float slopeAngle = Vector3.Angle(normal, Vector3.up);
             Debug.Log("contact.normal slope = " + slopeAngle + " degrees @ " + Time.time); // show the surface normal
             //Debug.Break();
         }
     }
 
     void FixedUpdate() {
         // zero moveDirection
         moveDirection.x = 0.0f;
         moveDirection.y = 0.0f;
         moveDirection.z = 0.0f;
 
         // zero velocity - critical to eli$$anonymous$$ate physics imparted forces (trying to mimic CharacterController's behavior)
         rb.velocity = new Vector3(0.0f, 0.0f, 0.0f);
 
         // add unit movement
         if(Input.Get$$anonymous$$ey($$anonymous$$eyCode.W))
             Add$$anonymous$$ove(Vector3.left);
         if(Input.Get$$anonymous$$ey($$anonymous$$eyCode.A))
             Add$$anonymous$$ove(Vector3.back);
         if(Input.Get$$anonymous$$ey($$anonymous$$eyCode.D))
             Add$$anonymous$$ove(Vector3.forward);
         if(Input.Get$$anonymous$$ey($$anonymous$$eyCode.S))
             Add$$anonymous$$ove(Vector3.right);
         if(Input.Get$$anonymous$$ey($$anonymous$$eyCode.R))
             Add$$anonymous$$ove(Vector3.up);
         if(Input.Get$$anonymous$$ey($$anonymous$$eyCode.F))
             Add$$anonymous$$ove(Vector3.down);
 
         // move the unit
         rb.AddForce(moveDirection, Force$$anonymous$$ode.VelocityChange);
     }
 
     void Add$$anonymous$$ove(Vector3 dir) {
         Vector3 move = dir * speed;
         moveDirection.x += move.x;
         moveDirection.y += move.y;
         moveDirection.z += move.z;
     }
 }
 

Very interesting, now I can reproduce your error - but only when I briefly disable the object. Disabling and enabling seems to somehow break the rigidbody. When you play long enough with the rigidbody settings it does recover again. Really strange. It's definitely not expected behavior. I would file a bug report.

In the meantime your raycast solution seems the best way to go.

sounds mysterious-good to file a bug report! Just take the scene in question and send it to unity as a package if you want or use the in-program bug report option.

you could disable the mesh renderer, the Collider component, and other components individually to achieve the same thing? you could also change the ball position and place it in outer space when you don't need it?

Glad to see it does the same thing for you and I'm not crazy. ;) Actually, in my case, I don't even have to disable/enable the object for the problem to show up. So while there may be some kind of bug with enable/disable, it's possible to get this issue without doing that.

I ran into another situation where the normal returned is incorrect. I placed a flat rectangular step (about 0.15 high) sticking out of the flat plane floor to test walking up a step simply using the default behavior of physics forces. I ran the sphere collider towards the step and placed a Debug.Break and a Debug.DrawLine showing the normal on impact of the most forward collision point. One would expect the normal to return a 90 degree slope if it hit the side plane, or a 0 degree slope if it hit the top plane. However, it returned slopes between 13 and 40 something degrees randomly. The best I could tell is that it may have been returning an average normal since it was essentially hitting the corner of the step, though I don't recall ever seeing exactly 45 degrees. Still, it reenforces my concern that CollisionPoint.normal does not return surface normals but rather some other normal based on impact angles, or the shapes of the colliders, or something I haven't identified.