As I mentioned in the other thread these jaggies are not an issue with the graphics engine, they are an issue with the way people have been building content for years. It's perfectly feasible for any track creator to re-export the GMTs with all materials set to a bias of 0.0. This will produce _exactly_ the same results as Alt-M.
Being able to force a mip map lod bias globally would be nice, though having an offset that applied on top of the modeller set bias wouldn't really work. Let's say a track has it's white lines at -3.0 and it's track surface at 0.0. If you added a +3.0 offset the lines would go to 0.0 (great!) but the track surface would go to +3.0 (not great!).
For now, I didn't see a track not smoothed and fixed with the ALT-Magic combination, ISI and third-party ones. As it depends the way the track was made, do you guys see a track where the ALT-M is not as Magic as it could be? I use a lot of different track but didn't go through all tracks for sure...
I'm not sure you'll find one out in the wild, most track creators have been using lots of negative bias for a long time. It seems to have become the accepted way to do things, even though it really shouldn't be.
It can do, but again that's partially in the hands of the modeller/texture artist. Also, if you're running nVidia try 16xS or 32xS, if you have the GPU grunt. Those do some custom bias tweaking, or so I've read. I've not yet had time to check that it works properly in rF2. Edit: Just checked your specs, AMD... ignore the 16xS/32xS comment
If ISI insert a parameter for the default value in the UI or plr with default value of =1 we have the possibility to set it how we want it. Without changing the default value nothing change to how we have it now. It's a small change I think and will made many of is happy. For a discussion about the background of this feature and how track artist should use this, a new other thread should be created. Personally I'm very interested in this topic
negative bias was used because it had to be used for rF1 tracks when it first came out, as such it became the standard way to do things and until now there was no reason to change, obviously now the downside of using negative bias has been pointed out I'm sure track makers will take this into account. Obviously I'm in a minority of people who can remember the white lines on tracks blurring into a fuzzy mess just metres in front of the car.
Guess I need to update my specs. - just replaced my AMD with a Nvidia GTX780 ti - feeding tripples, finally in "MultView" (but also still have to mind the FPS)
Are you sure 16xAF didn't cure the blur in rF1 too, like it does in rF2? Edit: I've still got an rF1 spec machine knocking around, I'll give it a try tomorrow. Sent from my GT-I9300 using Tapatalk
I am talking about the very first tracks released back in 2006 and at that time the negative bias fixed the issue, also the only guide anyone had to making tracks for rFactor at the time was to reverse engineer the supplied ISI tracks which all used negative bias, I'm not saying it's right, just explaining how and why it became common practice.
Understood I think the aliasing problem really started when people started putting track paint on it's own geometry, rather than simply painted on the track textures. Sent from my GT-I9300 using Tapatalk
What's interesting and matches my own experiences, the "Clamp" setting in Nvidia's control panel / nvidia inspector for negative LOD bias texture filtering seems to be broken (at least in some older titles) for newer Nvidia GPU architectures. There's a very short disussion about it HERE. Like I said, from my own experience the last time Clamp actually worked (in rF1 as well as rF2) was with a GPU of the GT200 series (GTX260/265/275/280/285/295...). Using "Clamp" in the driver for this setting should prevent the graphics card to use negative LOD biases at all, using 0.0 instead whenever it is passed a material with a negative bias. This feature is broken for newer GPU architectures though, therefore we can't help ourselves by using this setting in our driver. Using the manual Mip LOD bias in the inspector (which can be set from -3.0 to +3.0) does NOT work either on newer architectures. There is a variable in rF2's (as well in rF1!) PLR to set a custom Mip LOD Bias (with a default value of 0.0), however it doesn't do anything as well for me when trying to change it (in both games, I would love to make rF1 look good again as well, but it doesn't have the Alt+M feature like rF2).
True, I keep forgetting that clamp used to work just fine. I wonder if the AMD bias override tools still work, such as Radeon Pro? Something else for my 'to do one day' list. Sent from my GT-I9300 using Tapatalk
I just made a post over in the GeForce forums. If you got the time and use a Nvidia GPU, you can join the thread, bump it and keep it alive so that Nvidia maybe provides a fix or restores the functionality of the clamp setting in their driver (important for rFactor 1!) and custom Mip LOD bias via the inspector. Here's the post. Support it if you want to.
Here are two shots from an AMD HD6870 of a friend. Apparently this GPU has aliasing issues too, but what stands out is that using Alt+M on this card blurs the textures up close a lot more than on my GTX770. Notice the textures on the car, especially on the front and the tires. Alt+M reduces the sharpness a little bit too much in this case in my opinion. HD6870, 4xMSAA, 16xAF: HD6870, 4xMSAA, 16xAF, Alt+M: Here's a comparison to the GTX770, where Alt+M seems to improve the visual quality a little bit more, the textures up close don't lose their sharpness that much: GTX770, 4xMSAA, 16xAF: GTX770, 4xMSAA, 16xAF, Alt+M:
