Project CARS (Community Assisted Racing Sim)

[D.man]

Build 188 (5/4/12, Senior Manager)

- оптимизация DX11

- эффект G-Force по умолчанию установлен на 60

- в диалоги добавлена опция "выйти на рабочий стол"

- для всех машин: текстура отражения на резине обновлена для соответствия измененным шейдерам

- Palmer: изменен альфа-канал в раскрасках с эффектом "металлик"

- Palmer: проверки/исправления

- Formula A: закончена модель LODB

- добавлены данные для трассы Moravia

- Leonus68: пересмотр изменений + изменена анимация пилота

- с помощью TAB теперь можно перебирать все опции

- обновление Formula A, Palmer JPLM и Sakitto

- добавлена трасса Moravia

[KSP]

реалистичность = сложность

С этим категорически не согласен! Реалистичность не должна быть сложнее реальности. Однако очень сложно сделать реалистичность достаточно простой...

[Devil Jester]

жду на ПС3

[D.man]

С этим категорически не согласен!

Есть опыт вождения болида Ф1, Gumpert, Caterham или прототипов ЛеМан на предельных скоростях? Думаешь можно просто так сесть в машину с 700 кобылами и покуривая сигарету одним левым мизинцем ставить рекорды на мировых автодромах? F1 от Codemasters легок в управлении и что? Это эталон реалистичности? Ну серьезно, откуда такая уверенность?

Энди выложил несколько скринов из Брно

Кроме того анонсирована новая серия Formula Rookie, которая займет нишу между картингом и FB, и будет выглядеть примерно так

[Sergey934]

в ценах на дополнительный контент написаны: Слоты для украшений - 50¢, Слоты кастомизации - 50¢, Украшения 10¢,Раскраски - 10¢

вот зачем платить допустим за раскраску ? если можно самому свой скин сделать.

[KSP]

Есть опыт вождения болида Ф1, Gumpert, Caterham или прототипов ЛеМан на предельных скоростях?

На этих не ездил, но ездил на других - из самых мощных и спортивных: BMW M3, Maserati Shamal, Impreza WRX STI, карт 30 л.с., выступал на этапах КР по ралли на ВАЗ 21083-06 подготовки ЛСГА, 150 л.с..

F1 от Codemasters легок в управлении и что? Это эталон реалистичности? Ну серьезно, откуда такая уверенность?

Уверенность из личного опыта и внимательного просмотра онбордов. В конечном счёте ведь всё ездит по асфальту на 4-х резиновых шинах, и если есть опыт езды на пределе и за пределом их сцепления, то даже из онборда можно почувствовать нюансы управляемости той или иной машины. Можно просто погонять на прокатном карте помощнее - основа управляемости там будет той же самой.

Эталон реалистичности формул для меня - Formula Mazda в iRacing. У меня правда совсем древний билд 2008-го года с Рутрекера. По-моему там машина ведёт себя вполне достоверно, отличный ФФ, и управлять ей не особо сложно.

[D.man]

Эталон реалистичности формул для меня - Formula Mazda в iRacing ... управлять ей не особо сложно.

Если для тебя Formula Mazda не сложна в управлении, тогда я не понимаю о чем спор. По поведению Formula B примерно там же, а Formula A это как-никак топовый класс и в управлении он сложнее. Но для рядовых игроков, которые кроме NFS никогда ничего не видели, это запредельно сложно. Именно их я имел ввиду, приравнивая реалистичность к сложности

Сегодня рано. И насколько я понимаю, с учетом мартовских новшеств, юниоры получают практически новую игру

Build 189 (6/4/12, Junior Member+)

- дальнейшая настройка поведения камеры, когда движение мира отключено

- исправление материалов для шин

- в Moravia добавлена трава

- Formula A: добавлены раскраски, победившие в конкурсе

- обновление Asano X4, Monterey, Moravia и Sakitto

[D.man]

На портале открылась ветка с постами от некоего A.J., который, судя по всему, ответственен за физику в игре. Под катом оригинальные посты для тех, кто не зарегистрирован и при этом считает, что физика будет на уровне Shift'а. Переводить не буду, слишком специфичный текст, который я пока даже не дочитал. В целом же смысл сводится к тому, что вскоре будет сделан какой-то громадный шаг в плане реализма физической модели

Часть 1

Ploughing issue

I have isolated this problem, and do have a 'fix', although I am not sure I am happy with the fix as it is more like just inviting other behavioral side effects. So I need to get a better handle on the details of the issue and either get comfortable ground with the current fix or get a better fix.

First off, this issue is /not/ due to damping on the grip point. It is not about the grip point at all, which makes sense since it happens way up in the 15-30 kph range, well above the grip point. In fact, it is the grip point that covers up the problem as you slow down. So it was the reduction of the grip point speed that exposed this issue.

The simple fix is not to simply raise the grip point speed. The simple fix is to raise the slow model range, which is currently 0.5m/s to 1.0m/s. Raising it to 0.5-20.0 fixes the plough/drift. Note that the issue is not really an understeer plough, but is rather a seemingly odd slide/drift.

Seemingly. Technically, with a simple steady state model, such as the brush model, I can actually see how this behavior is inherent. What is happening is that all four tires (not just the rear two) are set into slight sideways slide, all at about the same slip angle, and apparently with exactly balancing moment contribution. So the car as a whole does not self correct....it just slows down until the grip point model takes over. One thing to investigate are to actually apply Mz (although I am not sure this will fix it, since Mz tends to be small in the big picture).

The slow model falls off dramatically in Fy, so blending that in in the problem speed range does solve the issue. But the slow model is itself very crude, so this is not likely to be free of its own artifact.

BTW, the f68 is the easiest car to do it in. The cars do differ. This is also a useful piece of information in isolating more nuance on the matter.

Drift Issue

Well, turns out there is more than one 'drift issue'. The one I was dealing with yesterday is not precisely the one reported by Casey. I was not yanking on the wheel as hard as it turns out is necessary to get Casey's mode, and found another mode as I described (which includes fronts also in slip).

Yanking harder results in what Casey describes more or less exactly...meaning the fronts do not slide and it keeps happening even in neutral. It may very well be just two manifestations of the same underlying issue...although I cannot say Casey's mode ought be 'inherent' at all. His mode is certainly a shortcoming or bug in the high speed model. If nothing else, side slipping like the Casey mode should quickly friction/drag out, not lazily drift around.

The worst case scenario remains the same: extend the reach of the slow speed model to about 20m/s. I put a few more miles on this fallback fix, and practically, it is not bad so far. I don't mind it on track as of yet. On paper I still don't like it.

BTW, Casey's mode is easier to recreate if you just go in a tight circle at 30-35kph (over 0.10 slip all around) then suddenly go straight. Works almost every time.

So far all of my offline tests are showing no gross anomaly in the high speed model though. I have a few more offline tests to try tonight, but I think the next step is probably to plug in the other models for comparison (since this is probably the first step in isolating the wandering-bug as well).

Drift Issue

I found the exact problem causing the Casey mode, and suspect a cause of the other mode, which if correct, is related to the wandering issue.

The Casey mode is simply too large of a number in a singularity safety conditional in the high speed model. By reducing that number, the problem goes away. Further, after isolating this, I was able to adjust the domain of some offline tests to demonstrate the problem.

So the good news is that we do not have to extend the range of the slow speed model.

The snap oversteer is inherent with a steady state tire model. It underestimates grip during dynamic transition in a corner. GPL had it. rF1 had it. iR OTM has it peek through their patch-ups from time to time. Even nKp used to have it. The dynamic tire models tend to not have it, such as LFS, VGP3, and maybe rF2. Based on comments, it is still very unclear what iR NTM is really doing.

So everybody and their mother using a steady state model has to find ways to patch it up. How I did it with rF1, given that all I had was the parameters they expose in their tbc files, was to exaggerate pneumatic trail....dramatically. Like an order of magnitude dramatically.

I do not recommend we do that, since that has side effects (thick feel and some understeer on turn in) that I do not like. However, it is a clue, since now I have access to the code itself, to a path we might try. That is why I keep coming back to Mz (which for your model is basically directly related to pneumatic trail) as A) first something we need to feed back up into the car physics, which we are currently ignoring except for FFB and maybe get clever with Mz to smooth over the grip underestimation on transition.

However, the eventual 'right' answer is to not use a steady state model at all. The model I am working on is fully dynamic, and does not have this inherent underestimation problem. Attached is a quick little example demonstrating why...this is a quick little jolt in alpha.

In the shorter term this indicates that maybe there is a heuristic we can use on the steady state brush to lag and smooth grip buildup and release...which we can use the offline (which is not yet officially plugged into Aries) dynamic model to calibrate some initial parameters for.

I am going to refrain from updating for these changes until after I address the wandering issue (which I am expanding in intent to the 'transient grip' issue since the soft tires were put in for that reason in the first place). This is for several reasons.

A) Stiffening up, as suspected, might fix wandering. But in a moddable sim, we might still want overly-accessible cars to work well (meaning with very soft tires, high optimum slip angles, little drop-off past peak alpha, etc). We also do not want drifting purposed cars to wander down straights.

The steady state liability still exists, even though it may be minimized, and with the soft-tire parameters, it may be easier to judge non-stiffness based fixes. IOW, we have a known dragon lurking, and some high confidence ideas to slay that dragon.

C) Flat or flattening tires. A compromised tire will be soft.

D) As good as possible approximation of a dynamic model. I hope to get the true dynamic model in that I've been working on, eventually, but when that happens we'll still need a steady state approximation for AI, latency hiding, etc (due to CPU budget).

Worked on the dynamic grip-space spring. The most naive approach (static stiffness and damping) is not really going to work well. It turns out there is both speed sensitivity and load sensitivity (both of which makes sense, especially the speed one). This is not a major setback though, so far. The speed sensitivity looks like it can be approximated with a variable grip-space stiffness function, and the load sensitivity looks like it can be approximated with a variable grip-space damping function. The stiffness one is almost just linear with speed. The damping one is weirder, and probably needs a little more attention.

Played with the wandering, which is more or less really just wandering or weak directional stability, but not oscillating. Data does not yet indicate an overt bug, but we do know we are missing Mz application from the tire model to the car physics. Mz usage is the next thing to add and test on this front.

Grip changes with load even without what is called "load sensitivity" (bolt on or not), since overall grip is directly related to Fz (load). "Load sensitivity" is the changing of the proportion of perfect grip (Cf * Fz) actually available, and the shifting of optimum slip angle. I do not have the code in front of me (I'm at my day job), but if the graphs are calling GetForce from the tire model directly, then they are probably missing the bolt-on load sensitivity.

The analytic brush already does load sensitivity a little bit inherently, but past peak, the brush does not do so as much as say Pacejka or my dynamic model, so there may still be cause for a little bit of bolt-on.

Attached is first a graph without the bolt-on, showing normalized (wrt Fz) grip. The second graph is with the bolt-on. Note that the brush without the bolt only does the optimum slip angle shift. We'll still need some bolt-on to get the drop in efficiency with load...but probably not as much as this graph shows we have now. Also, it should probably be more even than that, as the Pacejka one shows. (BTW, don't worry about the overall magnitude difference with the Pacejka graph...that is an artifact of the poor long/lat mixing of that particular version (VD) ).

I am guessing the current bolt-on is from when you had the ISI model, which I am guessing was just those explicit curves you put into the tbc files morphed under load with the bolt-on (IOW, ISI's model without the bolt-on may not have done what the Magic Formula does, so they NEEDED the bolt on). If that is the case, I am guessing that bolt-on may be a little too heavy of a hammer for the brush.

Parameterizing the built-in part of the brush may be tricky. It sort of just falls out from the analytic formula. However, if there is stlll a bolt-on portion, maybe that is enough of a dial.

That sounds like a good place to start (half bolt-on load sensitivity and use speed sensitivity to preserve low speed grip).

Yes, more stiffness will reduce built-in load sensitivity in absolute terms, because it is mostly the alpha shift that is built-in, so with smaller optimum alphas, the corresponding shifts are smaller.

As you already know though, graphs and data are not the bible. The final word is the feel. If it turns out that exaggerated load sensitivity feels better, it could very well be that it is compensating for some other phenomena that the computed tire model is missing. The graphs and data are more intended to be qualitative guides than quantitative dictates.

Hooked up Mz to the car physics. This, when exaggerated, did make a difference in directional stability that one can readily feel. However, at the proper dose, it helps but is a little harder to tell, at least in my not-yet-updated tire parameters cut. I think this is just due to the sets the soft (parameter) tires keep taking back and forth (the driver for the wander). I also examined more closely what the tires are actually doing to wander, and like I just mentioned, they tend to take off-center 'sets' that cannot be perfectly balanced in all cases, due to the different load balances, etc. I think this is actually somewhat correct, at least qualitatively. Take out a real car or kart with very low tire pressures and see what it does....it can do exactly that. So with Mz in there, and the stiffening of the parameters, I think this particular wandering issue may 'solved' in that we understand it.

Of course, fixing the wandering this way, which I think is the right way, opens up the door for the snap loose (transient grip) issue. So the next step is to try the force-space spring hack to address the transient grip issue.

I also hooked up Mz directly to the FFB for developmental purposes so I can feel exactly what is going on with the tires in testing. BTW, for most racing cars, the Mz FFB is a close approximation of "steering column" forces due to tires.

I also put in the force-space spring tire hack. You sure can feel it, at least with the Mz FFB. It needs a bit of work before I can call it a keeper though. There are currently feel side effects, but that might just be not having the load and speed sensitivity matched well to the car I am testing it on (FA). Unfortunately, if that is the case, that means it cannot be automatic under the hood, and therefore also likely means a couple more critical parameters per tire.

продолжение следует...

[ICEman_c81]

Build 189 (6/4/12, Junior Member+)

- дальнейшая настройка поведения камеры, когда движение мира отключено

- исправление материалов для шин

- в Moravia добавлена трава

- Formula A: добавлены раскраски, победившие в конкурсе

- обновление Asano X4, Monterey, Moravia и Sakitto

и как это чудо обновлять? Удалять старое - ставить новое или что? И кидай сразу сюда линки на скачивание

[D.man]

Часть 2

First, wrt an earlier comment, and something I responded via email to Mike...the frequency increase may be the huge new key. To be honest, compared to other sims doing this (rF1 w/ realFeel only, VDrift when I hooked up Mz directly, etc), I was shocked how the rumble strips felt in Aries (using Mz). It is excellent.
You'll probably still need to add-in at least collisions though, and some of the other canned stuff is kinda neat (like the gear shifts) to at least keep as options.
To get the kart hop (if it is like a real-life kart hop, which is the outside-rear binding up like a jack hammer) you'll also probably want to mix in some rear axle effect, thereby emulating a little more pants-feel with hands-FFB. The trick there will probably be to avoid diluting the front FFB with rear FFB when things are nominal (not hopping, etc).

Andrew Weber
Saturday
Sounds awesome. A couple of questions AJ:
For your Mz (aligning moment) and wander testing it sounds you were using the tyres before this recent stiffening up phase?
Also the "transient grip" issue your mentioning, is this the snap loose over the peak issue we've been mentioning that got worse since the tyres got stiffer? IE not allowing much controlled sliding or throttle application


Yes, up until now I have been using the softer tires to exaggerate the issue as much as possible. I'll of course verify with the current tires. In fact, my next work session will start with an update to the stiffer tires.
WRT transient grip: exactly. The reason you went soft in the first place was to deal with the snap loose, so even though it sounds like you have that somewhat under control now on the stiffer tires, that dragon still lurks. So I am trying to address the snap loose artifact of steady state tires (like the brush in there now) head on, in the tire model itself.
If the empiricalish (not really empirical, since the ground-truth case is not real-life data, but an offline dynamic model) hack thing does not work, there is still another middle ground solution to try, before going to the full-on dynamic solution. That is to take the tread portion of my dynamic sim and couple that to the steady state carcass notion of the brush. However, I still have high hopes for the force-space hack.
I do have one little note of warning though. We do not want to overkill snapping loose, which is a danger with workarounds and 'hacks'. Real tires and cars also do have snap loose issues. They may not have the clearly 'wrong' snap loose of the transient grip problem, but they do snap loose, so when dealing with this problem with what amounts to sledge hammers, it could be pretty easy to go too far and make the cars too benign.

DougArnao
Yes of course the real cars can snap on you, but you usually know why
The fact that we could actually go too far (and with the higher current stiffness) would be a revalation - lol. Sounds good though. Looking forward to it working .

I said sledge hammerS. Plural. By that I meant going soft on the tires was one of the hammers too. With that you could also go too far. For example, the FA on the low stiffness tires was probably too far. I do not know if the force-space hack will be able to go too far or not yet, but of course, we are hoping it has enough power to do so -- meaning we have a powerful tool to hit a wide spectrum of effect.

This is the simplest rawest example. I simply disabled everything but the constant steering force, and coopted the constant force.
For the purposes of a brush model, Mz is simply trail * Fy, so that is what you'll see in the constant force.
This is crude and hard coded, and bare, just so you can feel purely what it is. The divisor you'll see in there (50) is for the FA. Something like the 67 needs something much smaller (like 20) for example. I suppose when this is exposed to a config file, it might be better to be a multiplier, but I found it handier to divide when testing.
I think an actual proper solution would have some of those other forces (optionally) back on, and maybe some optional smoothing for this bare Mz force.

Note that this little hack was not intended to be "the solution", but rather a raw taste of the keystone for a direct Mz approach.
I'll address some of the issues. First, the variable force magnitude (more force with speed, especially in FA) is correct. For a linear, non power steering linkage. More downforce means more side force (the reason for the downforce in the first place) which means more torque on the wheel. So the 'correct' thing to do wrt this issue is to maybe model power steering, at least wrt linearity. With most of our wheels (consumer wheels) we have a pretty narrow window between no force and saturated force, so we also have to consider where we saturate for the best tradeoff.
This leads to me think maybe a logarithmic filter might be worth trying, so we have a lot more Mz range in play without saturating, while also getting more feel down in the low force range.
Another issue is the zero torque at zero speed, which is very unlike a real steering wheel we all know pulling out of our driveways. That is of course due to the brush model being out of its range at low speed. (side note: my dynamic model does have resistance at zero speed, naturally just falling out -- just pitching when I can ). We should be able to blend in something at near-zero speed to cover up the low speed issue, very analogous to how we have the grip point model blended in for the behavioral side.
Also, like I said, I think some optional (user configurable) smoothing is in order. In particular, some consumer wheels (really, cheap, worn out, whatever), have a real tough time with high frequency forces. Further, some people just don't like the wheel to buzz so much for any period of time. So smoothing will help. There is actually a realistic justification for this too....
My model integrates forces at the rim/hub, since it simulates the carcass with a full-on discretized simulation. The brush we are using now does not, so no matter where you report the forces from, you are really getting forces integrated at the contact patch. So we currently do not have the forces 'smoothed' through the carcass. So they are maybe a little buzzier than real forces should be.
The understeer falloff to me feels right...not too much of a falloff. I think when the other forces get in there (gyroscopic, linkage drag, etc) it won't feel quite so 'empty' when in high understeer. Technically, for just Mz, it is correct, since the trail really does go to zero (actually it often reverses in real tires, giving anti-corrective forces).

Worked mostly on the transient grip bolt-on. The spring/damper based version is turning out to be either very hard to calibrate, or is not complete enough of a concept. It shows flashes of greatness, such as when the car is continuously turning the same direction when you try to induce a snap, but can have some awful side effects when the car shifts weight from one side to the other. I did get the FA close, but it is a tricky business. Too tricky for practical use at this point.
One cause of this is that to do this with the spring damper approach; we are basically integrating over time a concept of "grip space velocity", which in some cases therefore ventures into places we don't want it. Putting tons of damping on it to prevent that seems to kill the benefit, so you have to dial the parameters "just right", but that window is so small that I think even changing the setup on a car might get back out of the window.
So I tried another approach which is to more directly just cap the grip-space velocity and not have a spring damper at all. So if the tire model attempts to move the grip faster than the cap, we just move it at the cap speed. This also has the benefit of having only one parameter (the cap) and sweet spot for that parameter is much wider than the other approach. The problem with this approach is that it is less powerful. So far I cannot say it is strong enough to overshoot on purpose (make the tires extra benign) if we wanted to. IOW, at this point it just takes some edge off of the snap, but is hard pressed to remove it.
Speaking of the edge, for testing I had to go to tires with slip grip well less than stick grip to really get much snap at all.
I need to try to set up some offline tests to capture more of this on graphs, to maybe get some insight into more aspects of the transient grip issue at the practical empirical level, so maybe we can make this approach more complete (and powerful).

Oh yeah, for complete context of my comments, I have been testing with a Logitech DFGT at the Glen (CH) -- mainly since it is short so I can get more reps in a test with a given window of time.

Mike, You mean like the sim in the attached pic?
No, right now what we have running is a solid state based sim (except the grip point thing). What you describe is a dynamic effect.
BTW, that tire in the picture is about the resolution that I've run real time in Aries, via a plugin hook I hacked in a test version to pull in my library. You can see the carcass structure as well as a representation of the semi-Eulerian contact patch sim. Grey is no contact, green is the root position of what I call a seta (similar in some ways to a bristle in a bristle tire sim), yellow is a sticking seta tip, and blue is a sliding seta tip.
If/when we get something like this, you'll have more forces from the model coming through, such as the dynamic scrub you speak of.
Andy, I'll take a look, but that might be due to either how the camber of the contact makes it way to the model (maybe the high effective camber due to the slope of the curb is not getting through), or due to some lack of camber effect in the model itself. Or maybe something else altogether.

[D.man]

Часть 3

Mike
Yes AJ, that's exactly what I'm talking about to solve:

1. roll over rumble strips
2. roll over static and dynamic surfaces (general objects, curbs, physical marbles, sides of objects, deformation FFB feel over curb edges etc)
3. solve dynamic weather / track grip differences
Current FFB is going down a storm over at WMD apart from over-strong centre and under-detailed curbs.
What's involved with integrating such modelling? We would be class leading... oh and would it run on consoles?

The dynamic track, surface, etc differences are something I think that contact patch approach will be particularly good at. First, I do not even use a simple stick/slip model, but rather a smoothed basis kernel model (similar to SPH fluid sim particles) per seta. This should allow for dirt, water, oil and of course asphalt to blend together seamlessly. Second, since the patch is treated mostly Eulerian, flowing things through it, like water flow, should be more natural. For example, hydroplaning should just fall out.
When we get to that point, there are several options to integrating it, ranging from exposing a plugin point and plugging in from the existing codebase, to reimplementing from scratch within the SMS codebase. There are tradeoffs across the whole spectrum.
I do think it would be class leading. For example, rF2 is I think using a straight stick/slip bristle patch (which is still really good), and builds up a database doing a similar carcass sim offline. In effect, this reduces their carcass to steady state, but they do a much higher element count. Their patch is dynamic though, so they do get a lot of first order dynamic effect, including solving the transient grip problem. We'd get even more.
Consoles is a big question, although at a reduced resolution, but still effective, I think it would work there. The killer will be AI. The CPU cost is too high to expect more than one or two cars, including the player car, on lower end hardware. So we still need something dirt cheap, like the brush in there now, for at least AI, even if not consoles. And we need the models to correlate well, at least for basic steady state curves.
Hence, the first priority is to get the brush spruced up nicely before delving into the dynamic model.

Here is the first email:
I have been experimenting with the FFB, and have a couple possible paths I am exploring. There are three things I am shooting for as core accomplishments, around which we can still have whatever other features. As it turns out, they are all related, and I think I have to deal with them as an integrated task.
* best use of the FFB range available.
* deal with the oscillation, either eliminating it or letting it be opt-in for the upside (very direct Mz) that comes with it.
* best core 'feel dials', meaning parameters, for the end user
For the first item, I have been playing with some mapping functions such as natural log. It certainly works for bringing in more detail earlier and not saturating as early, but the side effect is even more oscillation.
For the oscillation, I tried one of the precedented solutions, which is damping (realfeel, etc), and that seems to work as well as it does elsewhere. The other solution, dealing with the latency via estimation (GPL FFB patch, etc), I have not tried, but at least from GPL experience, this seems like a very finicky delicate way to go, even from an end user point of view.
I also tried something else, which is showing promise so far, and that is to have a Spring force that is also Mz driven. Running a spring with Mz, at least on a DFGT, oscillates much less, but is also softer and loses a lot of the delicate edge of the Constant based version. So a blended combination of these two is an area of exploration I intend to try. The blend level is probably end user taste, so that would be exposed.
Actually, that leads to my last item, which I really started thinking a lot about after Kimi's rack issues at Melbourne. Feel is so important in racing, and in many, if not most, racecars is customizable for the driver, but is also limited by linkage constraints, etc. I am thinking in sim racing, since we are missing so much other feel (G's etc), what if instead of trying to emulate the constraints in real cars, we clean slate think about it and empower the end user to customize the core feel in a powerful clean way. I do not just mean toggles for the extra effects, but I mean designing the core tire driven force pipeline to have a nice set of orthogonal powerful dials.
So the current rack force routine in Aries is exactly what one (including myself in earlier conversations) would first think to do, which is to take Mz and run it through the steering geometry and linkages to the rack. This is cool and all, and maybe the default, but I think there is a lot more sim upside to generalizing this into an accessible 'custom rack' system. Sort of like you are Kimi and have Lotus/Renault there at your bidding to fix your feel.
So what are the dials I am thinking of. Well, first there are the inputs, which is Fy, pneumatic trail (which together form base Mz), residual Mz, Fx, and Fz. Typically, in a bare system, like my last shelf, you really only use Mz. In a linkage system, you might bring in Fx too. I am thinking the end user has these at their disposal to map into torque via a handful of dials -- trick being making it as simple as possible, but no simpler.
The classes of things going on would be transformations (such as the natural log or whatever) and offsets (like geometric steering trail) piping to crisper (Constant) and softer (Spring) 'drivers'.
But the end user cannot really see gunk like that, at least not presented like that.
My analogy I guess is guitar amplification. There is a LOT you can do amp design wise, but the amp consumer only wants a handful of powerful dials for an amp that is good for a particular taste or two. The amp designer makes circuit design decisions and hard bakes them, exposing a small number of dials. This concept would be our CORE torque signal...liek a guitar preamp. Then, again like guitar amplification, there are canned effects (in guitar, like phaser, flangers, EQ, etc), each effect having zero to two dials. Our FFB canned effects would be like this.
So for the CORE "pre amps", we'd have maybe at least three choices that I see, based on the forum feedback, and our own tastes and preferences I already see (Andy likes more steering trail, I like thin&bare, etc):
* Linkage Based. This would be very much like the 'rack' torque that I am guessing Eero put in. The dials would be minimal...mainly overall effect, damping, and how a bias dial between Constant and Spring.
* Abstract Function Based. This would be a more purified notion of something like the natural log filter (sensitivity dial) on each input, along with an abstract 'steering trail' dial, and also the aforementioned damping and bias.
* Slide Based. This would be more or less what Constant was doing before we coopted it for Mz.
There could be others, but those are the three at hand I see.
The canned effects-loop effects would be the usual suspects (gear shifts, engine, braking, spin, etc), and maybe some other SA augmenting things we could experiment with later.

----------------------------
Mike responded pointing out that the Fanatec cannot really do both Constat and Spring. Then my next email was
-----------------------------

Interesting on the Spring approach. I feared as much (that thre was some sort of fundamental difference going on) from the different replies we were already getting from Fanatec testers.
Too bad about the blend though. Something in the way the wheel implements the spring, maybe pretty low in the motor control logic, seems to have a strong counter-oscillation effect. When blended with Constant (so Mz basically driving both a Constant directly, and driving a Spring by setting the offset always to zero and adjusting the spring rate based on the factor of Mz and the inverse of the distance from offset) I was getting no deadzone feel along with much less oscillation. IOW, I think the 'deadzone' in this case may not really be 'dead', but is rather no-first-order-force...but something about the controller logic seems to suppress the Constant's oscillation. This is all premilinary. I really need to get a lot more on track reps ans samples, tweaking permutations, to really isolate the pattern -- maybe if/when Fanatec can do both. I'll defer this aspect of my investigation for now.
OK though. I still think the rest of what I said still makes sense (amp analogy appraoch/way of looking at it). Even with Fanatec like issues in the mix, this might be helped, packaging-wise, with amp-analogy-like options.
For the curb issue, which track has the steepest smoothest curbs? I should switch away from Watkins Glen to deal with curbs. I really need to make sure the current model is getting camber fed to it right, and that it is handling it right, because there should be 'something' coming through Mz due to camber unless the slip angle is dead zero, which it almost never is.
The rolling road feel may be able to come in on the current tire model too, if we go down the pre-amp/effects analog path (ok, even if we don't, but I like to think of it that way anyway ). Bringing in Fz, or Fz', maybe through some filter, but not merely indirectly via Fy changes via load, would be the first thing I'll try for that. But yeah, the new model should have more vibrational modes inherently causing road feel. I still think we have hope for this one on the current model.

-----------------------------
And then:
------------------------------

Would it be crazy to ask that the test track have a special curb and bump test zone added, with all sorts of types?

What I am working on at this moment, today, is the curbs.
It looks like the model itself is returning Fy and Mz just fine due to inclination, as these graphs show.
So next is to see if it is maybe something in the collision detection and collision information being fed to the model. That is why I am hoping to find out the best test curbs (modeled well for this testing: steep, big, smooth, and correct normals if that matters in how you are calculating collision info).
Note that these graphs are even at zero slip, so it is not even a model-thing being too insensitive w/o any slip angle. Mz is pretty small in these particular graphs because there is no much pneumatic trail in the case. Through your current FFB, which includes rackForce, which includes mechanical trail in addition to pneumatic trail, we should be feeling substantial curb torque. But we are not. So I suspect the model is not getting the input it should.

It might increase feel if they are saturated otherwise.
That is one aspect of what I am looking at...getting the most out of the window of unsaturated force.

Sunday
I do think I may have found an issue with the inherent kerb feel, but I only got a half day in yesterday. I am going to get back at it tonight.
The tire model is doing its thing right, and the graphs are correct, but there is another component of kerb effect that I think we have sort of let slip through the cracks. The tire model is reporting forces at the patch, and all of that is going through the physics sim pretty much correctly....but our FFB forces, from the model, as wired now, are originating at the patch as well, not the hub. So for FFB we are missing the component of Fz (load) that acts sideways (thereby applying torque to steering wheel) when there is camber (kerbs).
Another fishy issue looks like the groundNormal being used in the first place. It seems to be calculated as the contact point to center of the wheel (normalized). If the wheel were a sphere, this would be fine, but as it is, this limits the effective camber to the angle from the shoulder of the tire to the center. I think kerbs are often more than that.
There is a big chunk of code there though, processing contact information, etc, so I need to digest that better to be sure I am seeing what I think I am seeing with groundNormal.

Within the range of every kerb I tried, groundNormal, the terrain face normal, and computing the face normal manually on the fly, all were very close.
However, none of the kerbs were really steep enough to get the camber high enough to go outside the range of what the current groundNormal approach can capture -- at least not when I am going slow enough to see the peak camber numbers (the car props up when going slow over large kerbs, reducing effective camber on the kerb wheel). The FA tires are pretty wide too, giving the current approach more range.
Adding the aforementioned missing component helps a little bit, but not as much as hoped. The central problem really seems to be that the kerbs are rather flat almost everywhere. When most kerbs have only a degree or two of camber, there just isn't much there to work with. The few places there are kerbs with some body, I can feel some kick on the wheel. Where they do have geometric sawteeth or whatever, I can feel that. But if we want to feel those flat smooth kerbs more, I think it may have to be canned (and optional). Often there is just not enough geometry delta to get much kick out of the rack/Mz forces.
Still, even the larger kerbs with good geometry seem a little weak to me (like the final chicane at Spa). I am going to do a little bit more research on what a real tire should do, FFB-wise, when it hits the shoulder of the tire first. Also, I'll see what the dynamic tire model does. Maybe there is still something to be done there, model-wise, on the brush. But that won't help most of the kerbs, which are quite flat.
Interestingly, some of the smaller kerbs, but with real geometry delta, like the round kerbs at Spa T11 (the last left before Pouhon) and the inside kerb of T18 (end of Blanchimont), feel pretty good. I noticed that for the smaller kerbs, the car itself does not get propped up, so the camber on the kerb-tire changes without much opposite camber change on the opposing tire. On the larger kerbs like the final chicane at Spa, the whole car tilts, balancing the FFB back out some due to opposing camber change on the non kerb tire.
I almost need to go do a test day at a real track now. I wonder if a lot of the large kerb force we think we are missing is really G's and body jolts. If so, that means we need to feed more than Mz/rack forces to the wheel to capture that.
edit: I watched some in-car of Schumacher and Hamilton at Spa, and was pretty surprised at how little evidence of kerb kick I saw on their wheels, over even the meatier kerbs. Especially Schumi seems to have almost no kick at all anywhere for kerbs at Spa. Hamilton had a little on the final chicane, but not much I could see anywhere else. This is at least tenuous evidence that real kerb forces are more through the seat than the wheel in RL...or that F1 cars run very strong power steering. Either way, that does not mean this is not an issue for us. Expectations are still what they are, and being sim, we need to deliver some information signal through alternate paths anyway, since we don't have G's and seat of pants.

Worked mostly on the oscillation issue.
There are several methods that "work", but they all have side effects. The core cause is pretty much a well known thing ever since GPL's FFB patch, at least to some extent, and no known (at least by me) fix is without side effect. That cause is latency from the time we request a force and the time it shows up in full at the wheel. A secondary cause is that there can be a real physical oscillation mode...but that is not really the barely touch the wheel and it oscillates away thing, but is rather the heavy yank on the wheel to induce oscillation.
One known fix is to just not use Mz/Rack forces directly at all. Cook your own artificial forces, which usually includes lots of canned stuff. I clearly do not think we need to do this.
Another known semi-fix is latency hiding, which needs prediction, and is very brittle anyway (does not really have a single best value even for a given rig). This would be viable with a steady state model, such as the current brush (without the dynamic bolt-on), but with a dynamic model in the future, this may not even be viable on common hardware (yet). I have never liked this method though, even when viable, since it only worked somewhat, and only some of the time. Still, maybe I should visit this in due diligence.
The most common known fix is damping. This sure does work, but it makes the wheel feel thicker. Realfeel/rF1 does this too, and it is an exposed dial to allow users to trade off thickness for oscillation (no damping in realfeel oscillates very much the same way as we do right now). (BTW, my taste is to live with full oscillation vulnerability to have the least thickness, as I use realfeel with no damping...but I totally get how many people cannot tolerate oscillation vulnerability). In any case, this is what I'd say was our fallback position. If we cannot find better, then we can at least do this. The way I have implemented it is completely within the steering constant force, so that Fanatec, etc can use it directly.*
So the first new thing I tried that worked (a bunch of ideas did not work at all) was to reduce force based on rotation rate. This works, without the thickness side effect, but basically translates into artificial signal to the driver's brain side effect...I feel changes in force on fast intended wheel movements that tend to register in my brain as effect looking for a cause that isn't there. One angle to this I want to still try is to only do this force reduction when the rotation rate and force are in the same direction (as in oscillation). IOW, the name of the game is to reduce the window of force manipulation tighter and tighter around just oscillation. I can see for some people that this force reduction method could be quite nice, since you reduce oscillation, without thickness, for an artifact that is not in the common tidy driving regime (you have to make bigger mistakes and corrections...or drive with a heavy hand...to feel the side effect).
My favorite method so far is a twist on the damping. We can choose to damp only around the center position with a Gaussian falloff of damping rate. So the thickness is isolated to the center, which even if not really correct, is at least semi-intuitive since street cars at street speed have thickness around center too. What this does is control the touchy latency induced oscillation, but still mostly keep the wheel crisp especially when doing corrections with some lock away from center...which is the common case, since cornering is where most corrections normally happen. At the moment, if we were to pick only one method, this would probably be my recommendation. However, I am still a proponent of that amp-analog method of dealing with FFB, so this would be one component of that.
I am going to do one more day of experiments, down the road of trying to quantize 'oscillation' as different than 'driver saving the car', so I can target just the oscillation better. This is a bit of a long shot, due to both behaviors being very similar (wheel going back and forth). My theory is that oscillations have the force and rotation rate out of phase with each other in a different (almost opposite) manner than saving the car. If this can be measured/detected reliably somehow, then the force manipulation to reduce oscillation could be even more targeted (and hence less artifacts).
I'll have a shelf for this once I figure out which set of methods are the candidates for keepers.
* the wheel position info is rather noisy (at least on my DFGT), so I had to smooth it. I only did this for FFB. This noise probably does have actual tire physics implications too, so I am thinking maybe alpha going into the tire model should be smoothed too.

[D.man]

и как это чудо обновлять? Удалять старое - ставить новое или что? И кидай сразу сюда линки на скачивание

При установке нового билда будет предложено удалить старый. Профиль так же нужно очистить. Линк кидать не буду, а то скоро *опой к стулу прирастешь

[motofan]

Ночной Connecticut Hill просто великолепен. А какие там отражения от машин. Правда я думал, что стационарное освещение трассы чуть поярче будет, но все равно красиво. А вот на других трассах просто тьма, и даже освещения от луны нет (

[ICEman_c81]

Щота мне билд этой недели совершенно не понравился. Есть явные баги, фидбэк какой-то странный стал

[motofan]

По сравнению с предыдущим изменений немного. Мне фидбэк тоже не понравился. Баг с steering sensitivity так и не поправили. Еще у меня глюки в меню при разрешении 1280х1024, графическое меню и зоны активации не совпадают, и нужно курсор выше наводить. Управление настройками авто тоже раздражает, т.к. его нельзя нормально сохранить или сделать несколько копий с разными названиями. Приходится одну и туже переделывать. Чем там люди ответственные за GUI занимаются не понятно. Все машины и трассы добавляют, которых и так море, только удовольствия от этого из-за недостатков настроек и нтерфейса меньше, чем могло бы быть.

У меня еще такой баг. Слышали наверное про 25й кадр? Вот у меня в игре проскакивает такой, и на нем "вид назад" (т.к. как буд-то на машину спереди сморишь) причем происходит это спонтанно.

[D.man]

От того, что вы тут высказались, никто не полетит исправлять эти баги. Переведите на английский и отпишите в багрепорт

А вот на других трассах просто тьма, и даже освещения от луны нет (

Очевидно потому что новое освещение прикрутили только к CH

[motofan]

По поводу stereeng sensitivity уже давно писал на оффрум, но так и не отреагировали. Про 25й кадр тоже написал. Просто хотел узнать у меня у одного столько глюков?

[D.man]

По поводу stereeng sensitivity уже давно писал на оффрум, но так и не отреагировали. Про 25й кадр тоже написал. Просто хотел узнать у меня у одного столько глюков?

По поводу stereeng sensitivity распиши подробнее. "25 кадр" я замечал в прошлых бидлах, но в этом пока не видел. Тут на первой станице приведен список известных проблем и возможные пути их временного обхода.

Megakimi, подскажи как ты проходишь вторую шикану в классическом Хокке, чтобы срез не засчитывали?

Интересное видео, породившее массу интересных предположений. Например, что SMS делают небольшую F2P игру для Porsche и взамен получат лицензию для pCARS, или SMS сами стали частью Porsche. В общем на видео Хоккенхайм, гле тестируют Porsche, а люди, сидящие в боксах, лицезреют на экранах некий симулятор с до боли знакомыми кнопочками во время паузы.

З.Ы.: а боксы то РБшные

[motofan]

Про 25й кадр нашел на форуме. Как-то там спонтанно все это дело описывается, и в теме Багов есть чуть-чуть, и в теме Графики пишут.

Я перепутал stereeng sensitivity с steering deadzone. При сохранении настроек steering deadzone иногда сохраняет значение на 1 меньше чем выставлено в интерфейсе. Например выставляя в 1 после сохранения получаю 0. Выставляя в 2 после сохранения получаю 1. Выставляя 4 получаю 3, и т.д. Т.е. есть значения которые сохраняются на 1 меньше, чем было указано в интерфейсе.

[ICEman_c81]

или SMS сами стали частью Porsche

всем вложившимся - по Porsche 911 (я согласен даже на Cayman)

[D.man]

всем вложившимся - по Porsche 911 (я согласен даже на Cayman)

Это перк только для Manager и выше

Про 25й кадр нашел на форуме...steering deadzone иногда сохраняет значение на 1 меньше чем выставлено в интерфейсе

Насчет 25го добавил свои 5 копеек. Со steering deadzone тоже сейчас заметил такой глюк

[motofan]

Подскажите, чем лучше запись из игры делать? Fraps или что другое посоветуете?

[motofan]

Только у меня с 25 кадром картинка не вперед съезжает, а как бы камера назад смотрит. Правда я верхнюю камеру (как в трансляциях ф1) использую. Хочу видео снять и кадр выдернуть оттуда.

[D.man]

Только у меня с 25 кадром картинка не вперед съезжает, а как бы камера назад смотрит. Правда я верхнюю камеру (как в трансляциях ф1) использую. Хочу видео снять и кадр выдернуть оттуда.

Только что записывал Fraps'ом и словил этот баг. Так же идет смещение вперед

[motofan]

Пробовал записать Fraps'ом, но не удалось поймать баг. У меня фреймрейт маленький при записи. Может из-за этого? D.man а ты какой вид используешь, из кокпита?

Я на FA катаюсь, использую вид с T камеры на вернем воздухозаборнике. Так вот когда я такой глюк ловлю, то у меня на долю секунды становится видно это T камеру и воздухозаборник.