Yeah if bumps are big and affecting the road edges, then it is not going to be easy to alter them, as you will have to also alter mesh positions which is interacting with the road edges. Small local areas might not be super difficult to fix, you can also try some artistic solutions like mask little gaps with some transitional objects or so..... But back to the main point, I don't think that S397 should, or would bother doing that. It is not worth it. It is still laserscaned, and differences will be negligible. Also IMO in real life bumps aren't so great because they are breaking and bending stuff, also unsetting the cars and "helping" some accidents to happen. In simracing there are no such problems. Laserscaning after all is just big label, so far S397 proved it with Sebring that they go a bit more honest with that. Just taking Nordschleife as pure example, other titles has it "repaved" already. They really aren't actually using full resolution of point cloud mesh (it would be way too crazy), they probably aren't even using actual point cloud mesh for road (or are they ?), most likely they just lay new mesh on top of it edit and subdivide it and then applies it function to follow shapes of the actual pointcloud mesh. Anyway, thats the most logical way to do it. At this point it is important what is the resolution of road mesh, it could possibly be totally skipping some important features picked up by laser, many other things may happen such as testers or devs themselves might not like the feel, and smooth it out artificially. One more big thing about Nordschleife is the amount of different tarmac types through whole circuit and the grip is not the same, in the OP video they says that they will not lay very grippy tarmac, to avoid even larger grip differences. Oh some more interesting stuff. In rF2 you would like to have road mesh in neat geometry, rather than random noisy mesh, because of real road technology you want to have rubbering or drying to appear natural. It would not be an issue with much higher resolution of the road, there is also such discussion in these forums. Also with higher resolution it would be possible to get a drying/rubbering tracks for individual wheels rather than whole car path. By the way, by looking at nords and sebring previews you can see that road mesh resolution is crazy, I wonder if they actually are making it so crazy, or they just somehow has pointcloud that smart that it would rectangulate (and separate as in the image bellow) the mesh of the road ? It looks like ~5cm resolution, thats pretty huge. I don't really think that such resolution comes to simulator, but also why would you rectangulate the point cloud ? Also interesting stuff about physics refresh rates is that rF2 refreshes tire calculations at 2400Hz, thats insane and unbelievable. To illustrate that - it is something about each 5cm of travel at 360km/h that would be each vertex of the mesh from above image, maybe slightly an over kill ? FFB is at 400Hz iiric. Recently I watched really nice video, which shows so nicely how actually bumpy the track is, and no sim yet has done justice for that: Beautiful video, I think it is best to observe bumps from exterior videos, onboard videos ar not showing them so well.
@mantasisg What I've read regarding refresh rates is that 'parts of' the tyres update at 2400Hz. So that's open to interpretation, and may not be the rate at which the track geometry is applied to the tyre. But yeah, you do wonder about diminishing returns, and that's why some shots of another game with super high resolution track mesh is probably a little misleading. Most games couldn't possibly use all that data in their vehicle physics, or with the sort of process rF2 uses to make that interaction somewhat realistic, and even if they did would it really make a significant difference to what the player experiences?
Looks like it's gona take ages to load, if Sebring takes a lot more time than the other tracks i don't even want to imagine Nordschleife
The different loading times on rF2 (all, not just the circuits) are incredibly long : Sebring is really the worst ! The arrival of the Nords will force them to improve the load times of the circuits, I think. So it's a good thing.
Unless the stuff close to the track is high quality and it gets progressively 'worse' the further away you get.
There is a question of track quality that determines the loading times. But there is I think things very poorly optimized, it is only to see what is done on other sim to understand it (loading times)
Other sims take shortcuts. AC, for instance, simplifies the visual mesh so not as many textures are being loaded into VRAM. AC also has jitter on long tracks by not using as precise calculations (32-bit math vs 64-bit math? Can't recall the exact reason) and Nords is on the edge of what's reasonable in AC and jitter is evident in Targa Florio. Basically, there are very good reasons why load time is long. A new algorithm might improve that, but it takes time to find a better one and you're looking for 10x improvement where only 10% might be possible, so is it worth the gamble for a developer to take time to find that when there are bugs to be fixed or other features to develop? The other choice is to reduce the details, so would you, as the customer, want reduced details?
Yeah, in that aspect i prefer a track full loaded than one where you see the landscape and trees showing as you get closer...
You seem to have this idea that the entire game is a collection of cobbled-together code which is poorly written, and if they just concentrate on an area they can make a marked improvement. 'Optimization' seems a buzzword these days, if one game does something slower than another game it 'just needs optimization'. It's really not that simple.
I am not a developer at S397, I could be wrong. But I really think that an improvement is necessary, and that it can be at least equal to 15%. I would just like S397 to look at the problem, and see if it is possible to make a significant improvement with a reasonable investment, because yes that's not the top priority. Pointed finger an obvious flaw of rF2 does not mean that I don't support S397 ... on the contrary I believe.
If you want super realistic physics and über realistic laser scanned tracks, you can't really complain when they give you that and the loading times suffer.
There is an obvious problem of loading the tracks (and other types of loadings), actually a much bigger problem concerning Sebring. So you suggest + you find it desirable and normal, that S397 does not investigate to see if the situation can be improved without spending too much time, under the pretext that rF2 has exceptional physics (and that Sebring is particularly detailed, probably also the Nords) ? Well, I do not see things like that. There is no fire without wood.
Loading times in rF2 are affected by encryption and compression, every time a track loads it has to be decrypted and decompressed by the CPU. Assetto Corsa doesn't use either, so the loading times will be shorter. The downside with no compression is that distribution size will grow and some tracks are already pretty big. rF2 MAS2.exe allows compression levels 1-9 to be used, which may have some impact on loading time.
I’m tired and not good at maths but if a track takes 1minute to load, a 15% reduction means it will load in 51 seconds Much wow
I'm forgetting sometimes that English isn't your first language, and maybe you don't realise how it sounds. When you say "force them to improve the load times" it implies you think they haven't done anywhere near enough in this area. With the right tone it even suggests they're deliberately not working in this area. Maybe you don't understand that it sounds that way, so fair enough. But the 15%? Where did that come from? You can't possibly have anything to base that on, except other games which do different things. In that other thread you were asking for AI performance to be optimized (that magic word again) because having Nords means we should be able to run 80-100 on track. You don't know if optimization is possible, let alone how feasible it might be. They can definitely improve loading times. They could defer the loading of some objects until you get close to them, giving some fairly extreme shudder/stutter and putting the game momentarily out of realtime. But the loading time would improve. Code is never written to be slow. Speed is always a consideration. There's also a well known idiom that says you spend 90% of the time in 10% of your code - and it's attacking that 10% that gives you real performance gains - but you can bet that any commercial product has that 10% screwed down pretty well already. Maybe as goals and design philosophy change you can potentially change the way things are structured (which could be a fairly straightforward rewrite, or it could be starting from the bottom and reworking everything) but for the most part there is only minor room for improvement in raw performance. The developer tools these days are just too well honed for a smart programmer to come along and make a 20% difference with some nimble coding (generally). There are probably tricks they could use to make things seem faster, and maybe other games are doing that. Any time you have a user selecting things and then clicking a Race button, you could start processing the content as soon as its selected. By the time the user clicks Race you're already 3 seconds into processing (cbash and shaders would probably benefit from that on a first load). In a game like this where you start on one part of the map you could potentially load the content near where you'll start, but with rFactor's realtime nature you'd have to be very careful with it. Depending how fast the user switches to different cars at the monitor it could also lead to artifacts as you hurry to load the content they've just moved to - and that processing in itself then takes away from your raw performance. Of course they should investigate it, but that's part of software maintenance. @stonec Just to pick up on that point, generally decompression speed isn't affected much by the level of compression. It's the compression that takes longer. (in the ooooold days higher compression could be faster to decompress because of reduced disk reads, but probably less so these days)
If S397 reasoned each time like this, rF2 would almost never be improved. Let's hope that the UI will not suffer from this weak reasoning.
That's just I want, nothing more. Some people do not realize how hard it is to choose the right words in English to really express themselves as I would like. I do not tell that S397 does a bad job !!, I just want them to investigate to see if they can improve something, because I'm wasting too much time in the loading times (not on other sims).
Let’s just be greatful S397 are pulling figures out their ass like that 15% figure, you’d still moan if they did improve it by 15%. It would go something like this S397 - we have optimised the load times by 15%, it took a lon while to find out how to do thank you for your patience Dabadoomba - pffff I can hardly tell any difference, your time would have been better spent working on ai instead, I want 100. I don’t know if I’m not impatient, but load time have never been a problem for me, nords loads in under 1minute for me, I’ll put all settings to high and try again and also with Sebring. Now if tracks were taking 5mins to load an “ optimisation” of 15 % may be worth it. But key the word that has already been said a few times, is diminishing returns This is a business after all and time has to be prioritised and well spent. I’m all for optimisations, and if it took the work of but a moment to get that 15% then yeah fine, but working with code is never a quick task but S397 have bigger problems to fix first, which thankfully they are and have been doing, personally I see optimisations as a polishing of the product, after you have a fully working cohesive experience
Just to add some people do not know how hard it is to work with code, and don’t even know if the process is already running as fast as it can It’s easy to just say it shouldn’t take this long or it should be faster, when you don’t really know
To clarify, every aspect of the tyre model is updated at 2400 Hz. This also means that we will calculate the tyre contact patch (shape) at this rate based on the track geometry underneath the tyre. And I don't know a single consumer simulation that drives "on the point cloud" directly. That is the domain of professional, very expensive simulators like the ones developed at Cruden or rFpro.
