RK4 is suitable for weak forces like changing gravity in space where extremely small drift in the beginning leads to complete failure in the end. The main idea of RK4 is made useless in cases of strong sudden forces because the movement is not continuous enough. If the gravity is just directed towards the ground on earth, RK4 does nothing at all while in the air and when you do collide, RK4 does more harm than good.
 Home
 » Viewing Profile: Posts: Dawoodoz
Dawoodoz
Member Since 16 Aug 2010Offline Last Active Jun 15 2016 10:47 AM
Community Stats
 Group Members
 Active Posts 497
 Profile Views 7,124
 Submitted Links 0
 Member Title Member
 Age Age Unknown
 Birthday Birthday Unknown

Gender
Not Telling
Posts I've Made
In Topic: How does RungeKutta 4 work in games
12 June 2016  08:10 AM
In Topic: Truncating a fraction when overflow occurs
12 June 2016  03:02 AM
Since vertices starts to truncate after just three cuts into a cube, maybe I get the most precision from falling back on the old 64bit float solution for vertice locations and just keep the persistent data that does not accumulate errors in fraction format.
In Topic: Truncating a fraction when overflow occurs
12 June 2016  02:04 AM
Divide both numbers by two? Which is just a right shift.
You could always right shift if your shifting out zeros (on both numbers).
If not, you get truncation, which may be still good enough approximation. (You should not shift out the last bit though)
It tried that but the precision was not good enough.
In Topic: Truncating a fraction when overflow occurs
12 June 2016  02:02 AM
.NET has the BigInteger structure that could do this for me but I decided to use Visual Basic 6 to get many times better performance while still being able to design the interface quickly so I will probably have to implement something on top of 32bit integers or find some existing library if I want to extend the numbers.
In Topic: How does RungeKutta 4 work in games
11 June 2016  12:26 PM
If there is a formula generating the values, try to solve the critical parts with the strongest forces analytically even if the result is not exact and then treat weak signals as blocks of constant, linear, quadratic or exponential signals. Take advantage of other stored values in direct relation to what you are trying to derive. See the problem as a whole differential equation rather than seeing the world as a black box with discrete output.
I mostly use the midpoint method and it can be iterative too.
Always test with different timesteps since euler forward can afford more steps per second.
Start by getting the locations at 0.5 timesteps ahead in time using a linear interpolation.
Calculate the first force from there and use the first force to create a second guess and get a second force.
Use the second force to calculate the final offset with the whole timestep.
Midpoint with one iteration:
MidPointA = OldPosition + (Velocity * TimePerFrame * 0.5)
ForceA = SampleForce(MidPointA)
NewPosition = OldPosition + (Velocity * TimePerFrame) + (ForceA * TimePerFrame ^ 2)
Midpoint with two iterations:
MidPointA = OldPosition + (Velocity * TimePerFrame * 0.5)
ForceA = SampleForce(MidPointA)
MidPointB = OldPosition + (Velocity * TimePerFrame * 0.5) + (ForceA * (TimePerFrame * 0.5) ^ 2)
ForceB = SampleForce(MidPointB)
NewPosition = OldPosition + (Velocity * TimePerFrame) + (ForceB * TimePerFrame ^ 2)
Whenever there is an exponential resistance, apply it by pretending that you are solving an analytical differential equation getting discrete data at the weak connections.
In this example, each line by themselves are analytical solutions on constant signal blocks but together they form a stable approximation if done in the correct order.
Velocity = Velocity + Force * TimePerFrame
Velocity = Velocity * (0.9 ^ TimePerFrame)
If you have multiple exponential forces like air pressure in a hexagonal vector field, consider breaking up the main loop with a smaller internal loop running finer timesteps on the most critical and inexpensive parts of the equation. Remember that sub iterations cannot derive values running in a larger timestep since it would cause oscillation from the discrete jumps.
If something is moving very fast then use continuous collision detection by seeing time as just a fourth spatial dimension.