Physics The Physics discussion thread

[Avo77]

http://www.racedepartment.com/downloads/acti-assetto-corsa-telemetry-interface.3948/

 

[RC45]

acti.exe spends more time crashing than logging

 

[Avo77]

Never had a single issue with it.

 

[RC45]

No issues with 1.8.1, but with 1.9.1 it appears to crash - I will just work with 1.8.1.

 

[garyjpaterson]

I have ... another actual physics question for discussion!
(copy/paste from my question on AC forums...)

Its regarding the Electronic Brake Bias Controller we have available; The fact is I really just want to play around and experiment with it, but the way its implemented by Kunos is really confusing me and seems illogical, and would be glad of any assistance which helps explain what the logic is.

Here is an example of the controller for those who haven't seen it:

[CONTROLLER_0]
INPUT=LOAD_SPREAD_LF
COMBINATOR=ADD
LUT=(|0.4=0.70|0.5=0.65|0.6=0.70|)
FILTER=0.99
UP_LIMIT=1
DOWN_LIMIT=0.0

My first thought was to implement some sort of system that matches the braking bias to the front/rear load proportionally (disregarding any other factors for the time being, tyre grip, lateral loads, brake temps etc.), then tune it from there.

As a starting point I went with a LUT a bit like this below, thinking the values on the left is the front axle load spread (% of the load on the front axle), and the value on the right the Front Brake Bias:

0.0=0.00
0.5=0.50
1.0=1.00

This in theory would mean the braking bias always matches the load, so say in a typical braking zone, the front load would be 70%, so brake bias would also be at 70% - but in practice this was heavily locking the rears, and I'm not entirely sure why.

The best results I could achieve were by upping the brake bias by 20%, so even a 50% load spread resulted in a 70% brake bias and so on. This gave pretty even braking over both axles throughout the braking zone. So the LUT looked like this:

0.0=0.20
0.5=0.70
0.80=1.00

But the way Kunos is implementing it is more like this (not actual values, same format though):

0.4=0.70
0.5=0.65
0.6=0.70

And I just don't understand the logic - at 0.5 load (that being equal load between front and rear), the brake bias is 65%, thats fine. At 0.6 load (so the front is loaded up more than the rear, ie more grip), the brake bias is 70% front, again that makes sense.
What confuses me is when the load is 0.4 (so the rear is more loaded), the brake bias is again 70%, which makes no sense to me?!

Also, when using EBB, does this completely disregard whatever brake bias is set either in the cockpit or setup? From my testing it seems so.

I'm guessing I'm missing some crucial bit of information or understanding. If anyone can shed some light on the proper way to utilise this function, I'd appreciate the help!

 

[Stereo]

This in theory would mean the braking bias always matches the load, so say in a typical braking zone, the front load would be 70%, so brake bias would also be at 70% - but in practice this was heavily locking the rears, and I'm not entirely sure why.

On this point in particular, engine braking should affect the driven axle more strongly so that's one thing to take into account.

 

[garyjpaterson]

On this point in particular, engine braking should affect the driven axle more strongly so that's one thing to take into account.

Thats a good point, I'll test it in neutral and see what happens.

 

[RC45]

Here's another couple actual physics questions:

1.)
In aero.ini in the [WING_n] sections there are the following LUT multiplier values:

CL_GAIN=0 ; Coefficient of Lift multiplier (for easy fine tuning)
CD_GAIN=1 ; Coefficient of drag multiplier (for easy fine tuning)

I take for easy tuning to mean just that - but it wouldn't be the first time KS document one thing and mean another
1.1) Does this coefficient of lift/drag multiplier apply the current setup selected line in the appropriate lookup table LUT file?
1.2) Does this multiplier work as follows: 1.0 applies the value as it appears,1.5 applies 1 and half times the value and 0 applies no lift or drag value?
1.3) Can a negative value be used to change down force to positive lift?

2.)
In the AERO section (or any other section that references lookup table selections) of the setup.ini do these line items:

MIN=0 ; Minimum permitted value
MAX=4 ; Maximum permitted value
STEP=1 ; Step

2.1) Do these steps apply to the lookup table in the LUT file?
2.2) In the event there are more lines than steps is there a proportional break down of which line items a particular step applies to?

 

[Stereo]

2.1 The lut line used is based on the current AOA (angle of attack) or GH (ground height, ie. distance from the middle of the wing to the ground) of the wing within the world. So it's just based on how the wing's oriented and which direction it's moving.

The setup is the angle relative to the car's coordinate system.

So for example if the setup is 0 degrees and the car's diving a degree under braking, it'll use +1 in the lut. Then if the car goes to -0.25 degrees under acceleration it'll use -0.25 in the lut.
2.2 it uses linear interpolation between lines in the lut. So if you have 0|0 1|1, and your wing is at 0.5 degrees, it would return 0.5. The first number on each line is the angle it applies to.


1.1/1.2. You're correct, CL_GAIN just multiplies whatever the results of the luts are. If you want an upward end result you can use a negative number here or in the lut.
To get the overall CL, you multiply CL_GAIN, every involved lut (aoa + gh if present), and then the chord + span of the wing. The last 2 are more for visualization and sanity checks than anything else; if you set them reasonably then your aoa_cl should look something like the efficiency of the wing. Always use the aero app ingame to confirm that overall forces are what you want.
1.3. yes.

 

[StefanoCasillo]

that's the first post that made me laugh in this thread. And you can't be possibly serious to even think that the in game physics model can replicate something that's useful out of the post 02 pacejka models.

still that's what most uberprofessional multi million simulators use.
Let that sink in for a moment.

 

[Borbor]

still that's what most uberprofessional multi million simulators use.
Let that sink in for a moment.

when you say "that", which "that" are you referring to, pacejka model? There are more than one of those, which you already know i'm sure considering the rave reviews your product is getting. The one we chose at one of my programs of involvement isn't necessarily the same one (or it could be, who knows) used by someone else. No one in their right mind would build a sim in that environment w/o either a) getting tire data from the manufacturer, or b) going to calspan (for us over here on the east coast) to obtain it should option a) doesn't happen.

Just like how one technically shouldn't design the kinematics of a car w/o tire data, nor should one start building a sim before it either.

 

[Brownninja97]

I thought id read the rest of this thread to learn a thing or two but all ive learnt is people seem to love to make their words bold when they are triggered. I'll remember this for future reference. Hmm dont think ive got the hang of it yet.

acti.exe spends more time crashing than logging

Why dont you use their support page then.

 

[RC45]

I thought id read the rest of this thread to learn a thing or two but all ive learnt is people seem to love to make their words bold when they are triggered. I'll remember this for future reference. Hmm dont think ive got the hang of it yet.

Why dont you use their support page then.

Why don't I use their support page? It doesn't offer a solution to the problem that acti.exe doesn't shut down correctly with 1.9.2, so I have stayed with with 1.8.1.

I find bold text also useful to highlight punctuation errors

 

[Brownninja97]

Why don't I use their support page? It doesn't offer a solution to the problem that acti.exe doesn't shut down correctly with 1.9.2, so I have stayed with with 1.8.1.

I find bold text also useful to highlight punctuation errors

Why dont you tell them that there is a problem so they can fix it, isnt that the whole point of this thread. If you have identified a problem and want it fixed then you need to notify the creators, how else will they find out.

 

[StefanoCasillo]

when you say "that", which "that" are you referring to, pacejka model?

Yes, it is the de facto industry standard when it comes to high end realtime simulators and yet, in this community it is frowned upon as some sort of primitive disease, which i find hilarious.

 

[Andreas Knöpke]

@kunos

Don't confuse "community" which a bunch a vocal whiners.

 

[Borbor]

Yes, it is the de facto industry standard when it comes to high end realtime simulators and yet, in this community it is frowned upon as some sort of primitive disease, which i find hilarious.

the message you first quoted me, was from me replying to someone suggesting the use of pacejka.

problem is, that person didn't specify WHICH pacejka model

I haven't been following all the talks about tire models, so I'll have to take your word at face value. But that'd be surprising.

 

[RC45]

Why dont you tell them that there is a problem so they can fix it, isnt that the whole point of this thread. If you have identified a problem and want it fixed then you need to notify the creators, how else will they find out.

I have no obligation to report any bugs found - I have a work around and use that - I have not upgraded to 1.9.x yet. That is my resolution.

 

[RC45]

Fudged tyres not withstanding over all the private use stock C5 Z06 is coming along well.

Been able to get lift/downforce close to reported wind tunnel number front & rear. C5 generates about 60lbs+ of lift at high speed so I will give KS credit for the in-game wing applet - very useful to fine tune aero values at speed.

It is very evident that developing any car in AC is not possible without judicious and regular use of the aero and suspension applets.

Assetto Corsa 2001 C5 Z06

Real life 2001 C5Z

 

[mclarenf1papa]

It is very evident that developing any car in AC is not possible without judicious and regular use of the aero and suspension applets.

I mean that's not strictly true....It's better to make an excel (or similar) spreadsheet to calculate it all so you don't have to go ingame to check all the time...plus it allows for more accuracy; the only real possible way to match aeromap data closely is by doing so.