Lower FFB multiplier a tad and up the FFB smooth a tad. Should make it perfect for someone who want the bumps to be less bumpy.
And here we have one variable that is very underrated in the discussion. The cars physics parametrization has big play in the perception of tracks bumpyness/smoothness. What are the chances that comparison car, that was used to compare data to real dPI car data, is wrong ? I would suppose that chances there are greater than guy who was modeling rF2 Sebring surface misusing the pointcloud data and having two bumps on whole track slightly too harsh. Also... in case if there really are a couple of bumps actually too harsh, then there must be few bumps equally too smooth, but no one is ever going to complain about those though. Another thing I'd like to point out is that such feedback without being specific is borderline useless. Race tracks spans for kilometers and are wide. Every square meter or certainly 25 square meters of race track can be unique. So just driving a track and getting several surprising bumps at specific places and then saying that whole track is too bumpy to what you expect it should be is truly hardly useful at all for anybody. For people who made it, it is just basically suggesting to revisit whole tracks surface. As a gamers perspective who wants easy comfortable stuff thats ok - just smooth out whole thing so no one is sad (except honest simulation purists, like me ), but for being true to reality it is just not a proper feedback and the discussion inevitably is going to be everyone having different part of track in their mind.
The rF2 model I use is a clearbody model of the same car the MoTec data comes from. Probably the only team with a shock dyno as well. The damper values are dead on in the model. I didn't build the model, they paid an outside source for that. The tires feel a bit different from the S397 and RSS models in terms of elasticity, but the driver thinks they are dead on. Most tracks that are modeled pretty well the setups are really close between real world and rF2. Laser scanning is great stuff but just because the word "LASER" is in the name (or even Fiber Optic for that matter) it's seems to be instantly perceived as a perfect solution to whatever its used for. Laser scanning can generate a highly accurate surface model when the scanning head is mounted on an X-Y drive where the source coordinates are controlled by the axis drives with feedback from the encoders and Z-Axis is fixed. Mount those systems on a moving vehicle and the source location has to be extrapolated from a series of accelerometers, generally 3 different 9 axis units. As the carrier vehicle moves it not only follows the track, the suspension moves vertically as well. No two passes of a high end rolling laser scanning unit will generate identical surface maps. But they do generate surface maps without many hours the labor required to do it manually. Now consider the size of the data collected from a 3 dimensional source like Sebring. Lets define the height of the bumps as the Z-Axis, with forward-back as X-Axis, and side-side as Y-Axis. There are multiple lasers running on timed pulses; each laser needs 7 data points to determine its position and direction, to at least 12 bits of resolution in relation to the mounting head, GPS position, with dead reckoning factored in between GPS "True" points and 9-Axis accelerometers. To get the level of resolution required to measure an 1/8" bump thats a lot of data to crunch and a big part of why two sampling runs around a track like Sebring return some significant differences in the surface map. Probably might suggest why NASA uses a ball of balloons to land a vehicle on Mars rather than just setting down on the surface - not to mention they also use imaging radar rather than lasers. OK so we now have data in hand from a scan. It starts as a gargantuan file as X-Y-Z points in the many gigabyte, possibly terabyte range. Might be a bit tedious for user download so the resolution gets reduced. Now that could be through generating a surface map but not all surface maps are the same. Catia has the most efficient algorithms for that (an ideal for airplane design) but its a proprietary algorithm. Same goes for the Parametrics Technology families (Pro-E, Creo, Wildfire), Solidworks, Solidedge and Autodesk products.Those who have ever tried to convert surface models from any of the programs from one platform to another are familiar with the primitives the surfaces are translated to. However for rF2 that gargantuan X-Y-Z "waypoints" are pretty much limited to just reducing the resolution levels to generate a surface map, and in many cases will merely smooth out all the bumps, they end up getting added back in manually and most likely by the contractor who generated the laser scan to begin with.
Exactly, and people have the solution to smooth it out if they want to. Thats what FFB settings are for. There is nothing to complain about here. The track is exceptionally made.
That is probably why I still enjoy BTCC but cannot watch WTCC or DTM. The cars just look dead compared to all the bouncin' and hoppin' the BTCC cars endure on those old Brit circuits.
You wrote a lot of detailed information in your reply. I couldn't possibly do that. But I just picked few little details that are important. What do you mean by 3.175milimeters bump ? Thats perhaps some threshold size to expect good accuracy from proper ground level scan. By the way the height of a bump means nothing, bump can't be described so, there must be area described too, or at least a length. I have to deal slightly with tracks modeling and I have a track bump that is rather annoying and wrong, and in the 3D model surface is virtually perfectly flat, the bump happens to be ~3-5cm undulation change in something like ~25 meters maybe, and it does feel like something from sebring... Also surely there will be errors of accuracy for each point, but there are many points close to one another, and in final result aproximated and averaged data point that will end up being used in the mesh of 3D model will be very accurate. It must be so, because errors of accuracy, will not going to have a bias to one direction, they will cancel out each other to most extent. Also those devices that are being used has their expected margin of error declared rather clearly, and I don't remember those being big for ground level scaning devices. I do have some experience with point cloud data. But I bult a track using LiDAR point cloud. It isn't anything super detailed like ground scan, but it was surely enough, and it was pretty spot on to what detail should be expected for actual road mesh in the simulators that we use. I also did something unusual that is related to using LiDAR data. I just smoothed it out very strongly. Surprisingly just smoothed out track was pretty realistic, there were just a couple concerns about bumpyness from few people, I was discovering undulations and bumps while watching real footage and looking for them in model, and also the other way around - discovering bumps and undulations in game and then discovering them in real footage. I did add two or three bumps manually, but no more. I continued carefully smoothing out the track in some localized areas, because I kept learning about true track. Why do I share all that ? Maybe because to do little bit of boasting, but more importantly just to say that ground level scan couldn't possibly need manually added bumps, like you suggest could have happened, as it was barely even needed by using LiDAR. I would highly doubt that anything like that would be ever needed for a project that is based on ground level scan. And in my mind as a regular rF2 user, Sebring doesn't feel too bumpy for me. And I would still question the DPi mod that was used in comparison, which I am sure has higher chances of having something wrong about bump/rebound travels, or stiffness, or perhaps tires lacks damping... many possible reasons. I would also question some of the developers from other sims, or modders, that approach simulations in safe tactic, making stuff more pleasant and not daring to push closer to real deal, because it becomes harder to please users. However good arguments has to be welcome. But predictably there seems to be disbalance of arguments when something seems not good enough, to when things are likely too good, which is very expected and understandable bias... So thats why I say that correct way to approach simulation development is starting with something that is more likely on the higher difficulty side or less comfortable side. Because making something better and more realistic is double improvement, making something more realistic but worse might not be understood by majority, sadly most chance for direction of changes in consumer simulations is making things better, and not carring if it is more or less realistic, consumer will always simply like straight up improvement that will make him to perform better and feel better, there are too few geeks that looks into details of reality.
