Latest Roadmap Update -April 2019

[Lazza]

@DrivingFast for someone so into rF2 and realism, you seem to have missed a lot of stuff.

Quick catch up: rubber groove gives more grip in the dry, and probably more in the wet (I haven't specifically tested). Certainly not less.

In terms of reality the bigger issue is worn aggregate, which is the main reason for the 'wet line' drivers take, especially on sharper corners. The game now has the ability to have varying roughness for different materials and this should allow a more realistic dry/wet grip transition, at least on a damp track (on a wet track, >50% wetness, a tyre-defined grip loss occurs in lieu of actual aquaplaning). In practice I don't know if anyone knows good figures to use to achieve this.

I suggested a wet groove effects parameter back in maybe 2013 as a workaround. We got material roughness replacing a wet grip parameter in 2015 or 2016, and that's where we are.

When people come along and say why is everyone happy with how rF2 is, why aren't they complaining, are they all fanboys? No, we've just given up for the moment on asking for things. We can only hope that with the new lease on life S397 is giving rF2 some of these ongoing issues are finally looked at.

 

[UsedMomo]

Sorry to insist but it seems important.

Is it true ???

Because if it's true, it's a big problem.

Indeed realism is the DNA of rF2, so if for something so important the realroad does not correspond to reality on wet track, I consider it a major problem.

If this statement from UsedMomo is false, can S397 deny it ?

Thank you !

Indeed it is true. In reality, the rubber on the racing line becomes very slippery when it gets wet. In rF2 it still has more grip than off the line.

IRL one can drive over wet marbles with slicks and get more traction. The bits sticking to the tire help channel the water. This is a feature that ACC has or will have.

 

[Gonzo]

The UI has required the sim to be totally deconstructed and reconstructed due to how ISI coded it. S397 has bought a very tricky product. Yes, I know, iTs bEeN tWO yeArS, bu I think there’s more important things to worry about than how menus look. Safety car, AI fixes etc.

that is not true. the old gui is still there. the new one requires a rest api and a local webserver. such an ui has a lot of functions and things to show, so it takes a lot of time, but the new gui will offer so much more flexibility, community, etc.

 

[UsedMomo]

One more thing -- and I don't know if any sim models it -- but I heard an IMSA driver say that they turn the traction control down in the rain, because the extra wheel spin also helps channel water.

 

[DrivingFast]

In reality, the rubber on the racing line becomes very slippery when it gets wet. In rF2 it still has more grip than off the line.

I knew that for IRL of course, but I had not really tested on rF2.

In fact, I have the very bad habit not "professional" to take wet road trajectories not enough different from the dry.

This is not good!

Thanks to Lazza also for explanations.

 

[AMillward]

One more thing -- and I don't know if any sim models it -- but I heard an IMSA driver say that they turn the traction control down in the rain, because the extra wheel spin also helps channel water.

That's actually really interesting.

 

[mantasisg]

I thought some drivers would use more extreme TC and driving style in the wet to maintain higher temperatures in tires. So it would make sense that in the wet being fast can unlock you even more speed. That explains why some drivers are so superior to other in the rain.

More wheel spin makes sense for more water removal, but I suppose it would be very subtle wheelspin. I love watching some oldschool F1 footage where Alessi or Schumacher put the cars to the very perceivable edge in the rain, if cars in simracing immediately spins out in the wet with slight slip ratio and slip angle increase even being very careful and anticipating slide, then it makes little sense.

Few of us have been discussing surface roughness parameter for a while, I don't know if it doesn't work as a substitute to the old "wet" grip parameter, or we don't know how to use it, but most likely it is the first thing. However logic of roughness is very nice, and definitely in the right way, definitely better than just "wet".... there is a lot to talk about it.

As Lazza said the bigger influence is worn smooth agregate, or smooth texture of the surface. Rubber itself probably has nothing to do with tarmac being slippery. It is the texture becoming smoother due to rubber buildup, also embedded rubber will make tarmac surface drainage worse. Theoretically if surface would become perfectly smooth, it should become as slippery as the ice.


Edit: Back to topic. Nice to see the progress. I don't expect much from first release of UI, but hopefully new stuff and polishing will not be difficult for devs. Most important thing to me would be to know exactly what the server is about before entering it. Super excited about Nordschleife and Nurburgring GP, not that much about FE Monaco layout, but still nice. Still have to buy FE, but I have completely no time recently, it is very interesting car, hope to jump in soon.

 

[Will Mazeo]

It's funny how rF2 is the most realistic sim ever till someone mention something is wrong or missing lol
It's like the Oreca, nobody cared, everyone was happy. Then someone mentioned "wrong" aero stuff based on God knows what and boom! The most arcade car ever appeared in the opinion of those that were 100% happy with it 1 minute before reading the post

 

[AMillward]

It's funny how rF2 is the most realistic sim ever till someone mention something is wrong or missing lol
It's like the Oreca, nobody cared, everyone was happy. Then someone mentioned "wrong" aero stuff based on God knows what and boom! The most arcade car ever appeared in the opinion of those that were 100% happy with it 1 minute before reading the post

Like the AC players that loved Zandvoort until they found out it wasn't laser scanned.

 

[Rui Santos]

Well, it's a fact that there are things in rFactor2 that need a deeper look at, like rain physics, tire pressures, cambers, influence of track surface temp on pressure and wear, etçª...

That don't deny the fact that it's the most complex and complete simulation, but it has flaws, i really hope that after this storm of DLC's, UI's, Competition system, 64bit ONLY conversion, etçª they give a good revamp to the overall details of the simulation experience. Once this is done, no other simulation software will even come close...

 

[mantasisg]

Once we will have involving, stable and consistent online racing, all the existing goodness will double, simply will get more valuable. Once it is set I hope that everything we are talking will be revised, well at least the things that are true, because we do share some nonsense as we lack some understanding sometimes and truth is not always obvious.

 

[Emery]

You do realize that no longer having to maintain two code bases frees up dev time?
You do realize that having a homogeneous environment in terms of clients may allow specific optimisations to be sought (since the headache of porting them is no longer there).

I was mainly counting on less distraction due to the 32bit builds, but probably with the new UI we’ll see more optimisations. Believe Marcel spoke or this long ago (ie ISIS code lacked multithreading and such).

In the PC world, the homogenous client is kind of a misnomer when you consider how dissimilar any two PCs are out there. The combinations of graphics cards, audio cards, steering wheels, shifters, display device, etc. is mind-boggling! Sure, the number of compiler switches is reduced when you go from supporting two clients to only one client, but it still ain't gonna be a cakewalk to find optimizations when other development might be a higher priority.

So let's talk about these theoretical optimizations...

What areas are code optimizations likely to be evident?

Graphics fps? S397 is using a 3rd party graphics library, the same one that AC uses, so they're at the mercy of somebody else's code. The bigger fps jumps have been due to feature omission rather than inclusion. AC's choice was to limit physical lighting effects (no day/night cycle, static weather, etc.) and limit polygons (visual road surface different from physical). An rF2 example is how the reflections refresh rate has been slowed one level. Maybe there is a way to present data to the graphics library that is faster, but I seriously doubt much improvement can be found without dropping into assembler and thus increasing dev time.

Nonplayer physics fps? Again, the large fps jumps have come from omission rather than inclusion. AC, for instance, limits terrain collision detection by putting invisible barriers between the track and most of the terrain whereas rF2 has allowed free roam; technically this isn't even a code improvement as content creators are in control of this and it could be implemented today without any coding time. Nonplayers are already using simplified tire physics and slower suspension rates ala rF1; I don't know if the ultrachassis is used by nonplayers, but if it is, that maybe could be omitted (which would be a simple move even with dual-build environments).

Code development cycle time? Yes, by all means code development cycle should speed up because there will be 50% less testing required. Will we see changes 50% sooner or 10% sooner? I don't know.

 

[jayarrbee36]

Do you know what? I'm starting to think the perfect sim just hasn't been made yet.

 

[LokiD]

...and never will be.

 

[gabrielof]

In the PC world, the homogenous client is kind of a misnomer when you consider how dissimilar any two PCs are out there. The combinations of graphics cards, audio cards, steering wheels, shifters, display device, etc. is mind-boggling! Sure, the number of compiler switches is reduced when you go from supporting two clients to only one client, but it still ain't gonna be a cakewalk to find optimizations when other development might be a higher priority.

So let's talk about these theoretical optimizations...

What areas are code optimizations likely to be evident?

Graphics fps? S397 is using a 3rd party graphics library, the same one that AC uses, so they're at the mercy of somebody else's code. The bigger fps jumps have been due to feature omission rather than inclusion. AC's choice was to limit physical lighting effects (no day/night cycle, static weather, etc.) and limit polygons (visual road surface different from physical). An rF2 example is how the reflections refresh rate has been slowed one level. Maybe there is a way to present data to the graphics library that is faster, but I seriously doubt much improvement can be found without dropping into assembler and thus increasing dev time.

Nonplayer physics fps? Again, the large fps jumps have come from omission rather than inclusion. AC, for instance, limits terrain collision detection by putting invisible barriers between the track and most of the terrain whereas rF2 has allowed free roam; technically this isn't even a code improvement as content creators are in control of this and it could be implemented today without any coding time. Nonplayers are already using simplified tire physics and slower suspension rates ala rF1; I don't know if the ultrachassis is used by nonplayers, but if it is, that maybe could be omitted (which would be a simple move even with dual-build environments).

Code development cycle time? Yes, by all means code development cycle should speed up because there will be 50% less testing required. Will we see changes 50% sooner or 10% sooner? I don't know.

My two cents about graphics, I believe you refer to post-processing library, cause the graphics library is DX11 (well, still same as AC and third-party to be fair) and there are lots of optimisations that could be made on rF2. I believe that multithreading would improve performance by a big margin, AFAIK basically everything in rF2 is single thread.

 

[stonec]

My two cents about graphics, I believe you refer to post-processing library, cause the graphics library is DX11 (well, still same as AC and third-party to be fair) and there are lots of optimisations that could be made on rF2. I believe that multithreading would improve performance by a big margin, AFAIK basically everything in rF2 is single thread.

To be more specific, rF2 is running two main threads, one for graphics and one for physics. This is how it was ever since DX9 days. You can enable a third thread for FFB by changing the parameter "Use thread" to true. And a way to use a fourth thread for AI cars is to run a dedicated server instance with AI's loaded there and then locally join that session.

There is a lack of information regarding graphics multithreading, but it's definitely there in some form. Though there is ambiguity on what "true" multithreading means, because DX11 Nvidia/AMD drivers can by themselves optimize the load over different CPU cores. By simply looking at CPU load during gameplay through e.g. MSI Afterburner you can see that the load is distributed over multiple cores in some way.

 

[DrivingFast]

And a way to use a fourth thread for AI cars is to run a dedicated server instance with AI's loaded there and then locally join that session.

What I really want, especially with the realization of the Nurburgring, is a strong optimization of rF2 when using a lot of AI.

I do not have any special technical knowledge, but that seems really possible given what @stonec explained, see above, using a 4th thread for AI.

By experience, the performance gain on the CPU side is very important.

There may be other things to do to optimize the AI, especially for FPS performance, but I leave that to the S397 experts !

I created about a month ago a thread about it in the "Wish List" part.

 

[AMillward]

What I really want, especially with the realization of the Nurburgring, is a strong optimization of rF2 when using a lot of AI.

I do not have any special technical knowledge, but that seems really possible given what @stonec explained, see above, using a 4th thread for AI.

By experience, the performance gain on the CPU side is very important.

There may be other things to do to optimize the AI, especially for FPS performance, but I leave that to the S397 experts !

I created about a month ago a thread about it in the "Wish List" part.

But aren’t you running something like 100 AI on the Nurburgring? That’s going to put a strain on even the most powerful computers.

 

[DrivingFast]

But aren’t you running something like 100 AI on the Nurburgring? That’s going to put a strain on even the most powerful computers.

Exactly with my i7 4770k not OC, I can put 100 AI without problem now WHEN I use the method of creating a LAN part.

But it's so restrictive that I never do it.

In this case, if I remember correctly, CPU usage does not exceed 90% (no "out of real time").

And my CPU is not considered today as very powerful.

Imagine the best i7, OC: 160 AI? (a bit excessive !)

 

[burgesjl]

Pretty disappointing roadmap once again, like several of the most recent ones. If it weren't for that fact that it is almost entirely about content, I'd call it almost content-free.

The only non-content section was on the UI, which showed us a matchmaker UI that is almost identical to what we have in the current UI. That's progress? It doesn't show any sort of innovative thinking about "how to tackle the problem in a different way" - in this case, how to find people to race against or the specific event you want to join if it's an organized competition. This is pretty much true of the rest of the screenshots of the UI. Thing like the settings screens, they work in exactly the same way for selecting values instead of giving us a new paradigm, like displaying a picture/icon of each tire compound and allowing us to select it rather than a selection box, or a moving diagram of stiffer/softer shock settings. It's just the same UI, written in different technology.

I'm also frustrated at the lack of any info in developments of the core simulation. For example, several months ago we got given a new set of graphics to represent raindrops and wipers, road reflections etc. and puddles, with the promise that this was going to be followed up on the physics side. So far, nothing. We've had some threads in here recently talking about a model of 'surface roughness' and I'd go so far as to say other impacts on surface, like temperature from sun heating and running on it, rather than what we currently have with RealRoad and the tire model as-is. Is there any research going on around this?

The above conversation on 'multi-threading' is also interesting on two different fronts. First, most interesting, is the idea of moving AI to a separate thread, but doing so by effectively creating a dedicated server and having the AI run in that, and not on the client instance/thread. Is that dedi server running on the same PC, or does it have to run on another one? Because that sounds like the answer to lots of problems whereby we get better control of events/rules etc. and usage of PC power even when running "offline". This is an architectural design of the app itself - other words, if running offline you'd always have two instances of the app running, one in dedi server and one for the client/user. It opens up no end of options - for instance, you could stream/publish to Twitch or whatever off that dedi server as well. And if you did do it with the dedi server across a LAN (two machines in your own home), again that's a good approach. I just finally upgraded my machine to an i5 9600K with 6 cores/no HT, and I'd like to see more utilized. The discussion on the multi-threading of graphics, interestingly EA said this week they are going with Vulkan. Reading the tech stuff, it says although they have implemented DX12 in their latest titles, they are still having problems with microstuttering in those and it seems like they are potentially saying this might get solved using Vulkan. My understanding is that there is some limited multithreading in DX11 but still one primary thread, where DX12 allows more of the graphics calls to be multithreaded. But that'll need work both in the core program and also the middleware/graphics library S397 are using (the same one used by pCARS2 and AC, but maybe in a different way).