Jump to content

  • Log In with Google      Sign In   
  • Create Account

bmarci

Member Since 05 Jul 2002
Offline Last Active Jun 24 2016 05:02 AM

Posts I've Made

In Topic: How does Runge-Kutta 4 work in games

06 June 2016 - 02:58 PM

 

Wow. Are you making that game?  :)

I think that Python has doubles bind in for float as default. And doubles are 32-bit rather than 16-bit, right?

Using explicit Euler is simple, but it's indeed unstable. My calculation system is the same as yours. I first calculate the net force summing gravity, normalforce, friction, air resistance, springs(the joints between softbody particles) aswell as any external forces. Than I express acceleration from it(just a = F/m) and integrate it in velocity. And I integrate the position right after.

 

 

Yes, it's my recreational hobby stuff that I make if I don't have anything else to do :D

Doubles are 64bit !!! Racer is using 32bit floats and also 1000Hz update rate, so it should be fine too.

I sent you the integrator docs in PM.


In Topic: How does Runge-Kutta 4 work in games

06 June 2016 - 06:07 AM

http://pasteall.org/blend/42241 - the RK4 is yet unstable. Set the stiffness to be 1000 (N/m = 1 kN/m). You'll see that the cube just goes out of screen. The force is still too huge. Hm... It's getting suspecious.

 

1000N/m is almost nothing, that's suspicious indeed. My stiff suspension has 200000N/m and seems very stable.

Here is an example for an F1-car:

https://www.youtube.com/watch?v=-zhmOuBhNwA

 

I saw a car demo (source) that used RK4, and seemed too much overkill in the source. Some components are yet too complex with euler, I don't even dare to think of how would it look with RK4 :)

 

By the way - do you integrate implicit Euler by repeating calculation in a loop until the error gets as small as possible? Something like that?

 

No, only explicit Euler, no inner-loops.

acc = F / m

vel += acc * dt

pos += vel * dt

that's it.

 

My update looks something like this;

1. For every component: Stuff->CalculateForces(); // This only calculates force values like normal load, traction, air resistance...etc

2. For every component: Stuff->Integrate(); // Advance in time (1ms delta-time in my case) calculating acceleration and position change...etc

3. Apply forces wherever they needed.

 

as a second note: I use double precision, because of the above mentioned small numbers and precision issues


In Topic: Traction Circle vs Seperate Forces

06 June 2016 - 02:57 AM

Hi! I actually forgot about checking this. I was making a coloumb friction based multi-sampled spring/damper system softbody tire model(using generic equations, but the concept and system is fully developed by myself). I will try this method later. However, in case of success, I will have a more physics-based approximated softbody tire for real-time applciation:)

 

 

So, I did, and my results are not realistic at all.

 

The Fx looks ok, but the Fy is totally off, I tried to figure out, and double-checked the formulas, but can't see anything.

 

with these inputs, only slip angle:

Fz = 2500

s = 0

alpha = 10degrees (in radian)

camber = 0 (gamma maybe)

The magic parameters are taken from the 3rd column (P185/70R13)

 

Fy is ~69.9


In Topic: How does Runge-Kutta 4 work in games

06 June 2016 - 01:11 AM

One note:

 

The most critical problem overall is that every resource of integration shows it from the curve-generation single-condition object state. Basicly it's a function of current state and time. However, in game's it's different. We have force that generates first input - acceleration. Here we have velocity and delta velocity. We also have delta time. However, we don't have the time(and we won't have it). This just updates the velocity(of course, explicit Euler method of v += a*dt is definetly off-course and instable). Than we take velocity and update position(where the velocity is actually delta position). Again, explicit Euler in case of springs won't work(p += v * dt). The problem is that most of those integration methods have function f(y, t). Come on - what does that mean? They all have hardcoded inputs. And it just makes no sense to me. I don't know how to convert it to the needed method.

OK! When it says y = dt * f(y, t), than I know that it's the explicit euler. However, there is no point in this. I just can't replace the f(y, t) in other functions by something like (v / dt + a) which is pretty strange. In many cases this just wouldn't work(or would it?).

 

It would! :)

 

A couple of years ago I found an other tutorial from Marco Monster, "Achieving a stable simulator" or something similar it was called. It described the very same thing you are looking for; RK4 vs Euler, and why it becomes unstable, and what to do to achieve RK4's precision with Euler's simplicity.​

I tried to find it on the net but no success, I might dig up my old stuffs, maybe I saved it somewhere. Even if it won't help, you will surely understand why springs are unstable with Euler at high delta-time.

 

I only use explicit Euler everywhere and it works like a dream, the key thing is frequency. Somewhere I read about Grand Prix Legends (1998) they used 330Hz update rate. I use 1000Hz.

With the standard 50-60Hz that physics engines provide, you won't go too far with Euler :(

​You can try RK4, but as someone mentioned earlier, you don't want to, EVER!!! :)

 

 

If you have high-profile super realistic simulator in mind, you may consider switching to C++ or other native languages, you'll be glad later ;)


In Topic: Traction Circle vs Seperate Forces

27 May 2016 - 03:44 AM

http://code.eng.buffalo.edu/dat/sites/tire/tire.html - I found this resource and it seems to be the most promising one so far. It seems to be kind of accurate and stable and at the same time I can understand it very well. I should, however, test it in game.

 

Great, did it work for you? I already found this tire model somewhere else, but that one didn't give any of the magic tire constants. Without those it was just a pile of useless math :)

I'm curious about its combined slip behavior.

 

This paper also forgets to mention about the Ygamma at camber calculations :)

I'll check when I have some time.


PARTNERS