My english is very bad. All I can say. "My name is Dmitry, I love my wife, I love racing, I work with 3D modeler motor racing track. I am a designer." the end.
Dmitry, have a little patience and let's see if they work on those areas once they get closer to releasing the title to the general public. I expect to see quite a bit of improvement between now and then, though I am not on the dev team so there is always a possibility that I might be wrong, but I hope not.
agree. The last example. Video long. A dry track. The wet track. An example of work. a layer of rubber and drying, enlarged 80 times.
Dmitry - that road in KRP is most likely updated by GPU. It means that every client in multiplayer will draw it's own and they will not be identical. Very similar, but not identical. Just different graphics settings in driver could affect it slightly. rF2 takes this matter seriously - it updates real road by CPU. It means if will have less precision, but will be exactly the same on two different computers. In the end - KRP offers better visual results, but cannot offer 100% fair play. It will seem the same, but there may be 0.2-0.3s of advantage for some players. And another thing - if you accelerated drying line 80 times, then you only need to do 1 lap to see changes on road. With normal rate, you would have to do 80 laps to see the same. But you wouldn't be able to drive 80 laps exactly the same line. So with normal rate you wouldn't see these trails so clearily - they would seem blurred - more like they look like now in rF2. I don't think that in actual multiplayer racing we would want to use such high rubber / drying line acceleration rates, that a single car makes noticeable difference, so I don't mind game's design isn't capable of that.
I realized that just me, alone, are not satisfied in the generalized system RealRoad rF2. I see that the support of my opinion is almost there. The race is not predictable, a lot of narrow tracks, all one after the other drive, one narrow path. Rally and Rally Cross.
K Szczech are an inexhaustible source of wisdom. Thank you for tell these little details in a manner so simple and that otherwise we would know or that are not there, or how important they are.
I feel like a fool, all the smart, I'm a dork. I do not know English, and trying to prove something wheel broke. star cracked due to the strong FFB I'll go drink vodka.
I am sure it is tough relying on a translator to try and get your point across. Hopefully you will be able to make your point to everyone's satisfaction in the end. Keep trying
argue, meaning I do not see ... Much has been said, all I have probably already realized, but the big question, ISI will be able to carry it all? Will? And they want it? ... Technically this is possible or not? ... (I had already drank 100 grams, and the world has become more fun)
I may be wrong on many things, so don't take my word for everything To me, it's a matter of simple math. Let's take a car, travelling 100 m/s. In some racing series cars can go faster, but let's assume this is as fast as car will ever go. So, the fragment of road affected by passing car can be 100 meters long every second and simulation must keep up with that requirement. Now how wide will that area be? An obvious answer would be "around 2 meters", because that's the width of a car, but it's not the right answer. Apart from area under the car, it will also have effect on area near the car (marble buildup for example). So let's add 2 meters on either side and now we have 100x6 meters area affected by each car every second. If we assume that our real road will have a sample distribution of 1 per square meters, then this gives us 600 samples per second, that can be affected by single car. Each of these samples will describe a number of road parameters - temperature, rubber, wetness, marbles. Just these 4 parameters require 4 floating point numbers. Each one is 4 bytes long. So, 16 bytes per sample multiplied by 600 samples per second. This means a single car can update 9600 bytes of data per second. To send that data to a client, you need 76800 bits per second. If there are 20 cars on the track, then total data affected by them can be 1536000 bits. That's 1,5Mb/s connection required, just to send that data.... to one player. Of course you can encode this data to make it 2-4 times smaller. So let's look at server requirements in rF2 now: It says, that for our 20 player case, you need 256Kb/s - it's 1/6 of what I estimated. That's because real road in current rF2 tracks doesn't have 1 sample per square meter - It's slightly less. Add some encoding and optimizations an you may end up with 6 times less data than I estimated, which is what we see in the above list of requirements. But of course you need to send that data not to one, but to 20 players Now imagine you want your samples to be more dense - let's say each one should cover 10x10 cm area. That gives 100 samples per sqare meter so our connection speed would have to be 100 times higher. Of course ISI may do this in a completely different way than I described here, but the point is - there are no magic tricks that will allow you to use dense layout of real road samples with low connection requirements. Unless you give up fair play and only send some vague description of changes in real road and let player machines apply changes themselves. I fully understand his point. He wants higher accuracy - high enough so he can have visible patterns without using additional racegroove texture. But it's always a matter of compromise. In this case, increasing quality of real road will require giving up the guarantee of fair play. This is a step ISI is not willing to take, even if other simulator developers do. So yes, it is a technical limitation, because the purpose of real road in rF2 is to affect physics, not produce eye-candy. This design choice implies technical limitations and that's it. We're not arguing with Dmitry's point of view. We're simply explaining why real road in rF2 works this way and what are the differences to other simulators that seem to have better solutions.
I can live with actual accuracy of real road technology but I would like to see in the future beter visual representation. Is that matter of better shader quality?
No, but it's possible to have two implementations running simultaneously. One with actual physics data and the other with just visual effects. Of course what you would see wouldn't be exactly on par with what you drive, but if done right, could be "close enough". For example - you would see that you had wheels still almost 1 meter away from wet area of the road, but you would have grip dropping allready and could spin. So visuals could be misleading, but if someone is ok with that then he could enable that option at his machine. He would enjoy visuals but would be forced to keep in mind that he can't rely on them too much - he would have to imagine underlying physical layer of real road himself while driving. I'm guessing it would increase network connection requirements by further 30-40% to send that "vague description" I mentioned in my previous post.
@K Szczech If physics will be accurate (and distributed over network), then graphics can be recalculated locally, based on physics data and final visual result can also be very accurate without negative effects on network bandwidth.
No, they cannot. Not just from real road data. Simply because real road data doesn't hold sufficient information. For example - one cell of real road data doesn't hold information about direction of skidmarks there. And there can be many directions at one cell. You can only assume the direction of skidmarks.... and that's what racegroove.dds texture is actually doing And direction of skidmarks is just an example of one information that isn't there. There are more that are needed to get it right. It's like having a 40x30 photo and trying to turn it into 800x600 photo.
OK, but I think we are going back and forth with in our assumption... we got to the point, where having high quality visuals won't work because it would create a huge chunk of information required to be updated frequently via network. I agree. Second thing - physics have to be accurate. So, use physics data and based on it, recalculate visuals locally. Why do you need direction? To have marks from every brick of your grooved tread visible on the road? Why do you need that? And what other things are missing, in order to get better visuals? Of course, right now from technical point of view it's impossible to get good visuals, but not because of network packet size, but because having main track/road built from 10x10mm quads is impossible - we are talking about hundreds of milions of quads for the whole strip of road. To get that precision, some other techniques must be used.
No, I do not sleep. Vodka Kuznetsk. Very high quality. I wish the quality of the ISI, brilliant ideas, the embodiment of them in life! Being the best of our simulator! Pew, cheerio!
No that's not the problem. You can just map texture onto track and it's pretty easy. If you assume that track is 10m wide and want 10x10 cm pixels, then you need 100 pixels across and 10k pixels per every kilometer of track. So 1024x1024 texture would be enough for 1km of track. That part is easy and obviously you could get more accuracy if you spend a few more MB of texture memory per kilometer of track. But what do you paint into that texture? You can't do it based on plain low-res real road data because there's not enough information there. Displaying more accurate marks / drying line on road is no problem at all. Painting anything there is not a problem aswell. Getting information that will tell us what to paint is the problem. If I give you one single number saying that given square meter of road is covered in rubber in 20% - is that enough information for you to paint nice skidmarks there? You don't even know which direction they should be painted. Franky, you don't even know if there should be any skidmarks there at all That 20% rubber build up could be smooth at that place.
The idea ... RACEGROOVE texture monochrome, gray. And still many many traces of braking, sliding, are long, and long long is not lost. This value is in *. TDF file for each coverage. survey: Reaction = skid Tex = skidhard.tga Max = 2500 Pixel = NoReduceDetail Max value change = ~ 9000000 Pixel but the problem is, if you put a value of 15000, the traces are not updated.
