Physics System - Keep ball from sticking

Im working on a personal physics system, and I have run into a slight dilema.

When a ball bounces, how can I keep the ball above the ground on the next frame (so it doesn't "stick") without adding to the ball's velocity (bumping it above ground)?

My current procedure is:
1) Combine Forces
2) Apply half of the total forces
3) update position
4) Apply other half
5) Check for bounce

If a script is required, I will post it.

In the frame that it bounces, compute the correct moment of bounce or directly the correct trajectory.

Im having troubles finding the point of intersection without using brute force (subtract location vector until z > 0). I have looked all over the internet for ideas but have been unable to locate anything.

on a side note, how do other physics systems deal with this? do they just bump the z up to the surface?

You know what the ball's trajectory is in free space. You know where the ground is. Solve for the moment when the ball's center is the ball's radius away from the ground. Conceptually split the time step at that moment by instanteously giving the ball the bounce impulse and computing the trajectory to the end of the time step.

If you are using curved ground, it is inevitable that objects will wind up slightly below ground at some point. That is impossible to prevent.

You need to use a sphere/plane intersection test (http://en.wikipedia.org/wiki/Plane%E...e_intersection.) Use this to compute the exact moment a sphere will collide with the ground within that frame. You need to check for these potential bounces before you update positions for that frame.

If the sphere/plane test turns up a negative time then the object is currently underground, so you can correct it by shoving the object up in the direction of the normal for whatever required distance, then performing a bounce immediately if the object's velocity is still pointed toward the ground.

After that you can look for potential bounces within the next frame. Say a timestep lasts 0.033 seconds, and you've detected an object will bounce in 0.015 seconds. Before the bounce is executed, update the object's position vector to where it would fall within the next 0.015 seconds (this should theoretically be its exact contact point with the ground), then perform the bounce.

Now when you update that object's position for the frame using its velocity, only move it (0.033 - 0.015 = 0.018) seconds worth of movement. That means you'll need to keep a var within all objects for the amount of time to subtract from its movement for that frame, which would usually be 0 but would be higher in the event of a bounce.

hm for my engine i just didnt care much for how exact it is, since its 0.03 sec periode, the eye wont notice it.
Therefore i just detect if the center is below terrainZ+radius then i move the ball up to TerrainZ+Radius before calculating velocity. This is not exact, but its simple and isnt so noticeable haha :P
Ofc if i were gonna make a good physic engine then it would be important to make exact, but my engine isnt physic engine... just "physic engine"

I was wondering how much bouncing I was planning on doing with mine. My problem is I'm a perfectionist and I need something to be 100% for me to feel good about it.

The sad thing is my original intention for this system was not "ground physics" but flying physics.

I have school tomorrow, so Im going to leave this till tomorrow.

poor u :P since science is not perfect, it is good enough.
But it is good to try to make it perfect, just i'm more like an artist interested in science, so as long as things looks nice, then it is fine :D

Grim & pipedream's method i think is faster in performance tho, since it doesnt call extra native to set unit fly height. But this is only a tiny unoticeable performance difference