im making an air hockey game on wp7, and i need to clamp the velocity between 4 and 10. so i did just that. but it was choppy every couple seconds. then used:
MaximumLinearSpeedConstraint puckSpeed = new MaximumLinearSpeedConstraint(puckP, 10);
however since there is no minimum in bepu i still have to clamp. any suggestions?
(also played with the timings quite a bit)
http://www.youtube.com/watch?v=jPQjhVSNqb0
minimum velocity of entity
Re: minimum velocity of entity
The value of the maximum speed constraint is in that it is robust in the face of collisions and other constraints. In that video, there isn't much interaction going on, so using a non-solved constraint should be fine. Whenever physics is being violated, there will be some oddities in corner cases, but direct velocity clamping should work decently.
If the velocity's magnitude is above Max, then normalize the velocity and multiply by Max. If the velocity's magnitude is below Min, then normalize the velocity and multiply by Min.
In the low velocity case, be sure to protect against near-zero velocity to avoid NaN's. If it's close to zero velocity, you could try using the previous valid direction, using some current or recent collision normal, or picking an arbitrary direction.
The choppiness you saw may have been related to clamping the velocity every game Update, but doing more than one simulation time step per game Update due to internal time stepping. If you're using Space.Update(dt) instead of Space.Update(), it could perform multiple time steps. In this case, you need to do your clamping per time step. One easy option is to hook an event handler on the Space.ForceUpdater.Finishing event.
If the velocity's magnitude is above Max, then normalize the velocity and multiply by Max. If the velocity's magnitude is below Min, then normalize the velocity and multiply by Min.
In the low velocity case, be sure to protect against near-zero velocity to avoid NaN's. If it's close to zero velocity, you could try using the previous valid direction, using some current or recent collision normal, or picking an arbitrary direction.
The choppiness you saw may have been related to clamping the velocity every game Update, but doing more than one simulation time step per game Update due to internal time stepping. If you're using Space.Update(dt) instead of Space.Update(), it could perform multiple time steps. In this case, you need to do your clamping per time step. One easy option is to hook an event handler on the Space.ForceUpdater.Finishing event.
Re: minimum velocity of entity
that is exactly how i did the clamping, never thought about the zero case though, but im not sure its ever going there. how could it if its clamped at 4?If the velocity's magnitude is above Max, then normalize the velocity and multiply by Max. If the velocity's magnitude is below Min, then normalize the velocity and multiply by Min.
ive tried setting:
TargetElapsedTime = TimeSpan.FromTicks(088888);
TimeStepDuration = 1 / 120f
MaximumTimeStepsPerFrame = 4
that should all be the same timing right?
but still no luck. you cant really see it on the video and honestly i didnt notice it until i made the puck location a particle emitter. the particles greatly exaggerated the "shift" of around 20 pixels every few seconds.
EDIT**
i might have figured it out, it might be my math converting the position in 3d space to 2d space for the particles. it might solve itself when i make the particles 3d (which i planned on doing today)
Re: minimum velocity of entity
The clamping is being applied between updates. Imagine an object heading directly toward a wall with no sideways velocity and no bounciness. Upon impacting the wall, all the velocity along the normal of collision will be removed. Since all of the object's velocity was along the normal, the object's velocity is now zero. After the end of the time step, the clamping system attempts to normalize the velocity, gets a NaN vector, and everything explodes. There are many other physical situations in which this can occur even with bounciness. It won't happen very often, but it will be nasty when it does.never thought about the zero case though, but im not sure its ever going there. how could it if its clamped at 4?
Even if the clamping is moved into the time step (using the event handler, for example), the minimum test should still be protected.
It's not exactly the same. It would need to be 83333 to 'match'. If you do plan on setting a custom Game update rate, it can be more convenient to use something like TimeSpan.FromTicks((long)(TimeSpan.TicksPerSecond / 120.0)).ive tried setting:
TargetElapsedTime = TimeSpan.FromTicks(088888);
TimeStepDuration = 1 / 120f
MaximumTimeStepsPerFrame = 4
that should all be the same timing right?
Even after setting the game's target update rate to something that is very, very close to matching, the primary issue would still be unresolved. If the parameter-using Space.Update(dt) is used, then there will still be instances where it performs a number of time steps not equal to 1. In these cases, clamping could be missed for one or more frames.
Attaching the clamping to an event handler which fires within the execution of a time step addresses this issue.
Also, if your game has IsFixedTimeStep set to true, then internal time stepping is redundant. In that case, use the appropriate number of parameterless Space.Update() calls for the simulation time step versus the game's time step. If the timesteps match, then calling the parameterless Space.Update() once is all you have to do.
Whether or not this issue has anything to do with the choppiness is another question
Some external bug like you mention would likely be a better explanation if it's extremely visible.