NormanCao

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

100 Neutral

About NormanCao

  • Rank
    Member
  1. Dynamic circle vs line segment friction

    Two bodies moving across each other is the same thing as one body moving across a stationary object, it just depends on your reference frame. What you're looking for is [url="http://en.wikipedia.org/wiki/Kinetic_friction#Kinetic_friction"]Kinetic Friction[/url], which is proportional to the normal force between the two objects (i.e. how hard one object pushes on the other and vice versa), and always directly opposes the direction of motion.
  2. Collision Resolving issue 2D

    A good knowledge of calculus is absolutely necessary to understand anything but the most basic steps and operations you're doing right now. I would suggest cracking open a textbook on single-variable calculus and get reading. Then you can begin to understand concepts like force, acceleration, and velocity on a mathematical level. As simply as I can put it, calculus introduces two new concepts that work on functions: derivatives and integration. A derivative describes a rate of change, while an integral describes a total accumulated change. The derivative and the integral are then sort-of opposites of one another. Hence, velocity, which is the derivative of position with respect to time, can be used to find the position by integrating velocity with respect to time. All of the integration techniques you have described are numerical techniques for approximating integrals. Once you learn a bit of calculus it will become clearer why there are different methods, and why you would need to use different methods in the first place.
  3. That's because the timestep is differing between the two machines. This is a math problem, not an alternative library problem. You don't limit your framerate, so deltaTime will vary a lot from computer to computer. Euler Integration (which is what you are using when you calculate the new position from the old velocity) has very different errors for different values of deltaTime, so you need to cap your framerate or come up with another way to ensure that deltaTime will vary little between different computers. And secondly, when adding acceleration to velocity, you also need to multiply acceleration by a deltaTime component if your deltaTime isn't constant.
  4. Seemingly random number based on coordinates

    You initialize Perlin Noise with a certain seed. Perlin Noise is a function that will return the same value given the same input values for x and y (it can also be extended to z and t). There's no need to hash anything.
  5. Seemingly random number based on coordinates

    Just use [url="http://en.wikipedia.org/wiki/Perlin_noise"]Perlin Noise[/url], or any number of different noise generators which take an initial seed, then an x and y value to generate the value of the noise at that point.
  6. A variety of inertial problems

    Well, as long as your axes are constructed using the same coordinate system as the tensor, then you should have no issues. The papers probably suggested using the inertia tensor around the principal axis so that the number of calculations is cut down, but that's just a wild guess on my part. If you were to rotate your coordinate system so that your inertia tensor was around the principal axis, you would just have to make sure you also apply this rotation to all of your other axes as well. I've never tried it myself though, so you should try and apply a known rotation to the coordinate system so that the tensor is no longer around the principal axis, then see if axes constructed using the new coordinate system give the same values for moment of inertia as the original unrotated tensor.
  7. A variety of inertial problems

    1) For rigid bodies, the change is instantaneous. Imagine two rigid bodies colliding with each other. Since they do not deform, momentum is transferred between them instantaneously (I think, anyways). Think billiard balls. You could probably cheat your way around this by having some sort of "tractor beam" that will gradually speed up the component that's being added to the ship so the effect looks less jarring. That would probably create the visual effect you're intending. 2) Moment of inertia is in kg*meter^2. It's defined as [img]http://upload.wikimedia.org/math/a/e/c/aecd2b471c5633f50ef87e7182c3358a.png[/img], and the tensor form is defined similarly. I've heard that the terminology can be a little inconsistent though. Also, you may want to look at the formula given for the parallel axis theorem on the original page for moment of inertia, since it gives you the generalized tensor equation for moment of inertia. 3) As long as you're storing rotational position correctly (either roll-pitch-yaw or axis-angle), then the moment of inertia tensor should not affect your rendering in any way.
  8. Haha, I should mention that I've so far only taken single-variable calculus (no real analysis yet) and I won't be taking linear algebra for two years, so it'll be a while before I learn how to calculate the eigenvalues of a matrix. I also wouldn't expect initial conditions to affect stability, but for some odd reason, they do. Using the following implementation, I did a few tests. I increased the number of periods run through to 49298 just to make the difference more apparent. The starting conditions are changed at the declarations of x and v. [source lang="java"]double dt = 0.015; int steps = (int) (Math.PI * 98596 / dt); double t = 0.0; double x = 1.0; double v = Math.sin(-dt/2); double maxVar = 0.0; double maxVarDiff = 0.0; double prevVar = 0.0; double startVar = 0.0; double tick = 0.0; for (int i = 0; i < steps; ++i) { if (t >= tick) { // System.out.println(t + "\t" + Math.cos(t) + "\t" + x + "\t" + maxVar); tick += Math.PI * 2.0; if (prevVar != 0.0 && maxVar - prevVar > maxVarDiff) { maxVarDiff = maxVar - prevVar; } prevVar = maxVar; if (startVar == 0.0) { startVar = maxVar; } } t += dt; double dx1 = dt * v; double dv1 = dt * -x; double dx2 = dt * (v + .5 * dv1); double dv2 = dt * -(x + .5 * dx1); double dx3 = dt * (v + .5 * dv2); double dv3 = dt * -(x + .5 * dx2); double dx4 = dt * (v + dv3); double dv4 = dt * -(x + dx3); x += (dx1 + 2*dx2 + 2*dx3 + dx4) / 6; v += (dv1 + 2*dv2 + 2*dv3 + dv4) / 6; double var = Math.pow(Math.cos(t) - x, 2.0); if (var > maxVar) { maxVar = var; } } System.out.println("Starting Variance: " + startVar); System.out.println("Maximum Variance: " + maxVar); System.out.println("Maximum Variance Diff: " + maxVarDiff);[/source] [code]Starting Variance: 4.146225112688903E-18 Maximum Variance: 8.548421030412684E-8 Maximum Variance Diff: 6.354040387133647E-12[/code] Replacing double x = 1.0; double v = 0.0; with double x = 1.0; double v = Math.sin(-dt/2); gets you this output: [code]Starting Variance: 5.6248594490512076E-5 Maximum Variance: 5.6248857190816965E-5 Maximum Variance Diff: 2.627003048891164E-10[/code] Uncommenting the output line at the top of the loop (and changing it back to 157 periods to run through) and plotting sqrt(maxVar) versus time will show that the original accumulates errors linearly with time, while the latter does not. EDIT: I think I realized the issue. Wow, silly mistake on my part. Changing the starting condition (i.e. increasing velocity) would increase the amplitude of the oscillation. This additional amplitude is slightly off from the original amplitude, so each variance has a big constant factor added to it in addition to any instability resulting from the simulation. That's why I wasn't seeing an order of magnitude growth in inaccuracy in the version with the slightly changed starting conditions. The fact that the resulting function was shifted over slightly due to having a different phase also made the variance seem to be within acceptable bounds. It's just that compared to the other methods of integration I was using (Leapfrog and Verlet), the variance was still so much smaller that I just assumed the larger variance was a consequence of numerical stability.
  9. I was using RK4 for the purposes of the test, but looking at the Leapfrog integrator (which looks like forward Euler but has similar stability characteristics) I assumed that it shouldn't matter what basic integration method you're using. Stability is the rate at which error grows based on the total time that has passed (versus order, which is the error based on the timestep). With an unstable integrator, undamped oscillatory motion will eventually "explode" (i.e. error continues to grow without bound), but with a stable integrator, undamped oscillatory motion (in theory) will not "explode" (i.e. error appears to have a bound). I'm simply measuring stability by plotting the maximum deviation between simulated and predicted values of x(t) against time, and seeing if the general upward trend is "large" enough to not be explained simply through round-off errors (my personal criteria is that the first 4-5 digits have not changed).
  10. This thread isn't so much for help as it is for curiosity. I understand very well that what I'm about to ask is by no means important or relevant to the bigger picture of game development. However, it just [i]bothers[/i] me to no end. I wanted to test the stability and accuracy of a few integrators with oscillatory motion a(t) = -x(t). I ran tests over 157 periods with a timestep of 0.015 using double precision floating point accuracy. With starting conditions x(0) = 1.0 and v(0) = 0.0, x(t) = cos(t) and v(t) = sin(t). Why is it that using x(0) and v(0) as starting conditions is unstable (for higher order integrators, error grows proportionately to total time passed), but using x(0) and v(dt/2) is stable? Just to satisfy my curiosity I tried using other combinations of starting conditions (i.e. x(dt/2) v(0), x(dt/2) v(dt/2), and just because those previous two worked, I tried x(dt), v(dt)). As it turns out, pretty much the only way to make RK4 unstable for oscillatory motion was to use x(0) and v(0) as starting conditions (discounting round-off errors). What the heck is going on here? EDIT: Turns out it was a mistake on my part. But still creepy.