Is doesn't happen to me
This works for me in reproducing (tested 6 times and always got this):
Start LFS (no matter if full screen or windowed) -> Multiplayer (can't reproduce that in single player) -> Join specific host (only tried with one which was empty at that time) and go to the track, press F12 and the menu is blurry for me.
Just recently started testing Y12, and something is up with the text render quality. Never had problems before, but now the text is in general rather blurry and suffers from pixels of adjacent characters bleeding over (I think).
It seems to have something to do with the texture mip bias, or rather by some driver setting of whether to allow negative mip bias or not (illustrated in the attachment). Personally I cannot live without "clamping" the mip bias in the GFX driver, or else I get absolutely horrible texture shimmering all over LFS. However, back in Y all was fine, no matter which setting.
Anti-aliasing seems to affect it a little, but only in such a way that it blurs the parts where pixel bleeding occurred a bit, making it less noticeable.
It seems to have something to do with the texture mip bias, or rather by some driver setting of whether to allow negative mip bias or not (illustrated in the attachment). Personally I cannot live without "clamping" the mip bias in the GFX driver, or else I get absolutely horrible texture shimmering all over LFS. However, back in Y all was fine, no matter which setting.
Anti-aliasing seems to affect it a little, but only in such a way that it blurs the parts where pixel bleeding occurred a bit, making it less noticeable.
I've had this happen before. With ATITool, it gives a blur (even in Y), but without it, just with normal, it works fine. I know that I could force it, by forcing certain mip bias levels, even on the main menu.
Thanks for that bug reproduction method. I can now reproduce this and I see that it is related to the drawing of the network status bars, for some reason the mip bias for that (0.0) carries on to the in-game text which should be -1.0.
OK, try again in the next text patch because that blurry text should be fixed. However, the text mip bias in LFS is -1.0 (no option) and that gives clean text (when there is no bug). I'm a bit confused though, I don't think it's going to help if you use the clamp option. I'm not sure why you want to use the clamp option in your card driver settings though - doesn't the mip bias slider in LFS graphics options do the job?
No, unfortunately it doesn't. I know, it doesn't really make any sense, as setting the mip bias to 0 and clamping it should theoretically have the same effect, but the difference is very noticeable.
E: Sorry for the non-contributing attachment, but be warned guys, forcing the mip level to +3.0 doesn't help either. But it enables LFS comic mode
(Scawen, ignore this)
E: Sorry for the non-contributing attachment, but be warned guys, forcing the mip level to +3.0 doesn't help either. But it enables LFS comic mode
(Scawen, ignore this)
Team Fortress 2 For Speed? :P
Android, Higher values (or lower) look entirely comical also.
Android, Higher values (or lower) look entirely comical also.
Same here...
How to change font in LFS...I cant see the place anywhere....
You can only select the font in Chinese, Japanese, Korean languages.
Scawen, I think the LFS graphics engine isn't using mip bias right (E: or maybe it is?). For testing, I created a texture with coloured mip levels to see where they start/end. Level 0 I left with the original texture, all other levels have been coloured.
This is the result:
(using 8x Anisotropic filtering, forced trilinear mipmaps)
E: It seems that the anisotropic filtering is causing the mipmaps to change much earlier. When I turn it off, the clamped setting looks much more like the middle picture.
E2: It has definitely something to do with the combination of clamped bias + AF enabled. For some reason mip levels change very early when both are active. If I disable either, the mip levels act pretty much the same (as LFS @ 0.0). Maybe it's actually something of the ForceWare drivers? Maybe you can incorporate a setting in LFS that allows us to generate a similar effect as seen in the third picture without having to rely on clamping the mip bias?
This is the result:
(using 8x Anisotropic filtering, forced trilinear mipmaps)
E: It seems that the anisotropic filtering is causing the mipmaps to change much earlier. When I turn it off, the clamped setting looks much more like the middle picture.
E2: It has definitely something to do with the combination of clamped bias + AF enabled. For some reason mip levels change very early when both are active. If I disable either, the mip levels act pretty much the same (as LFS @ 0.0). Maybe it's actually something of the ForceWare drivers? Maybe you can incorporate a setting in LFS that allows us to generate a similar effect as seen in the third picture without having to rely on clamping the mip bias?
[post written before your edit]
The reason for the difference in the 2nd and 3rd pictures is that LFS has an additional mip bias that can be set per surface type.
The reason for that is because textures that are seen very flat-on (I mean, at an oblique angle to the camera) like road textures, and to a lesser extent walls, need a lower mip bias or they go soft too early [this is certainly true if anisotropic filtering is not enabled].
To say that another way... if you set the mip bias correctly for a texture that is seen flat-on (about 0 or -1) this is too low for road textures. I just had a look in LFS and currently the road textures are set to have an extra -2.0 mip bias.
This issue I've described is (or was) a problem in racing games because the road is drawn so flat as it goes into the distance. But you've got me thinking now because as I expect you know, this is in fact the purpose of anisotropic filtering... to solve this problem "properly" without the "hack" of assigning a lower mip bias to textures that are likely to be seen flat-on.
I'm not sure if this extra mip bias is needed any more now that we have anisotropic filtering... but maybe anisotropic filtering isn't perfect and can still be helped by having additional mip bias?
I think that it should be possible to turn on anisotropic filtering inside LFS, at the moment you can only switch between bilinear and trilinear. Maybe the additional mip bias should only be enabled when the filtering is bilinear / off...
Opinions welcome.
The reason for the difference in the 2nd and 3rd pictures is that LFS has an additional mip bias that can be set per surface type.
The reason for that is because textures that are seen very flat-on (I mean, at an oblique angle to the camera) like road textures, and to a lesser extent walls, need a lower mip bias or they go soft too early [this is certainly true if anisotropic filtering is not enabled].
To say that another way... if you set the mip bias correctly for a texture that is seen flat-on (about 0 or -1) this is too low for road textures. I just had a look in LFS and currently the road textures are set to have an extra -2.0 mip bias.
This issue I've described is (or was) a problem in racing games because the road is drawn so flat as it goes into the distance. But you've got me thinking now because as I expect you know, this is in fact the purpose of anisotropic filtering... to solve this problem "properly" without the "hack" of assigning a lower mip bias to textures that are likely to be seen flat-on.
I'm not sure if this extra mip bias is needed any more now that we have anisotropic filtering... but maybe anisotropic filtering isn't perfect and can still be helped by having additional mip bias?
I think that it should be possible to turn on anisotropic filtering inside LFS, at the moment you can only switch between bilinear and trilinear. Maybe the additional mip bias should only be enabled when the filtering is bilinear / off...
Opinions welcome.
I'd certainly welcome an option to manually change the extra mip bias you apply to the road/flat surface textures, either by a slider or a simple on/off switch. Heck, even a hidden cfg.txt entry would suffice 
The possibility to set the AF level (any maybe AA too, while you're at it
), would also be a good addition, opening up the more eye-pleasing graphic options to people who don't know about them or how to force them via the GFX drivers. It would also (I think) give you the possibility to control which surfaces AF/AA is being used on, enhancing the performance compared to forced AF/AA (though the hit isn't that big for modern cards anyway).
For me the extra mip bias adjustment would be enough - the other options depend on how much time you want to invest on the issue. Personally though I'd either do the former and not waste too much time, or do the full deal with complete AA/AF options and whatnot. Doing it only halfway might bite you in the arse later on
The possibility to set the AF level (any maybe AA too, while you're at it
), would also be a good addition, opening up the more eye-pleasing graphic options to people who don't know about them or how to force them via the GFX drivers. It would also (I think) give you the possibility to control which surfaces AF/AA is being used on, enhancing the performance compared to forced AF/AA (though the hit isn't that big for modern cards anyway).For me the extra mip bias adjustment would be enough - the other options depend on how much time you want to invest on the issue. Personally though I'd either do the former and not waste too much time, or do the full deal with complete AA/AF options and whatnot. Doing it only halfway might bite you in the arse later on
Scawen, I think that the filtering in LFS would be great, especially seeing most modern games allow this access within the application itself. Having this would be a good step forward for LFS I think. I also think that the ability to adjust the road mip bias (for road, maybe make it cfg.txt adjustable?) might be nice too, to give us the ability to finer tune LFS to our visual preferences.
It is nice now to know what LFS is doing with the filtering, and AF (and AA..
) would be an excellent addition.
EDIT : Seems Android and I had the same idea to change the road mip bias, which means it must be brilliant... (COME ON Y13!!!)
It is nice now to know what LFS is doing with the filtering, and AF (and AA..
) would be an excellent addition.EDIT : Seems Android and I had the same idea to change the road mip bias, which means it must be brilliant... (COME ON Y13!!!
)Definately a +1 for changeable AF inside LFS ( while you are at it, why not add AA also ? :o ) . I don't know how others are doing it, but i have to run AtiTrayTools if I want to change AA and AF settings, so that means plus one program has to be running in the background.
edit:beatenby2posts:[
edit:beatenby2posts:[
a bit off topic but what exactly are negative mip values anyway? i thought 0 was the original texture
and almost completely unrelated: andriod you should turn off the trilinear (aka brilinear) optimisation in the driver settings
and almost completely unrelated: andriod you should turn off the trilinear (aka brilinear) optimisation in the driver settings
Just did that, finally I could actually see what effect those settings have, and I promptly turned it off
Negative mip bias just means that level 0 is used for a longer distance, pushing the other levels further back.
Negative mip bias just means that level 0 is used for a longer distance, pushing the other levels further back.
Android, please could you attach that test texture you made, just to save me doing one, that would be quite useful for testing.
that doesnt explain why clamping it to 0 negatively (no pun intended) influences the text rendering which should happen on polys with mip 0 either way
btw which tool allows you to visualize the mip level on only 1 texture or are those photoshopped together from shots with and without the colouring?
Of course, here you are. It's a high-res texture, though, so forgive the size.
@Shotglass: The text is rendered with -1 mip bias at a certain distance away from the user, so when I clamp it to 0, I make LFS use less detailed mipmaps for the text, causing the pixel bleeding. The mipmaps are visualised via the texture I attached, I simply saved and modified pre-generated mip maps into the dds texture. Normally LFS dds textures don't have mipmaps generated so LFS does it on the fly.
The texture looks like this now:
http://members.chello.at/fam-jelinek/christian/miplevels.jpg
@Shotglass: The text is rendered with -1 mip bias at a certain distance away from the user, so when I clamp it to 0, I make LFS use less detailed mipmaps for the text, causing the pixel bleeding. The mipmaps are visualised via the texture I attached, I simply saved and modified pre-generated mip maps into the dds texture. Normally LFS dds textures don't have mipmaps generated so LFS does it on the fly.
The texture looks like this now:
http://members.chello.at/fam-jelinek/christian/miplevels.jpg
why would it be rendered at a distance? its on the frontmost polys (obvious since they overlay everything else) and certainly much much closer than any of the road you see in front of you
i just dont understand why youd ever put text somewhere that isnt on mip0 (or less) in every case
No idea, really. It probably has a reason, but I've never worked on a 3D application myself, only simple sprite based 2D stuff. 
Same here when i press key combination of Ctrl + Shift to see player LFSWorld usernames in connection's list.
The characters on the character textures are made large enough to be seen at an acceptable resolution when they are drawn as large characters in LFS. Smaller characters (i.e. most of them) have less pixels on screen than there are on the character texture. So they are drawn using a smaller mipmap. That's just how mipmaps work, it's nothing to do with distance, it's purely related to the size. A mipmap is chosen by the card that is a close match between the mipmap texels and the screen pixels. Bilinear filtering chooses one single mipmap. Trilinear filtering blends between two mipmaps. Anisotropic deals with this in a better looking but more computationally expensive way.
Anyway of course at some point there is a transition between one mipmap and the next. Mip bias affects these transition points. With LFS text, the best bias is -1.0. Because 0.0 comes out a bit too blurred. This is not provided as a user option. In 3d it is a matter of preference, but for 2d it's very clear what looks best.
Ah OK thanks that clears up the confusion on my part, I thought the Z value was the basis for choosing a MIP level.
BTW when you change the way the MIP bias is adjusted for road textures keep in mind that, as illustrated by the step in the MIP levels in Androids pics, Nvidia cards (6 and 7 series and 8 if you dont disable the optimizations) do a horrible job at aniso filtering at certain angles, like eg. flat right in front of you. The effect is that with clamp on lines on the road that strech out right in front of you (eg on the car park) will blur far too soon even with agressive levels of aniso.
IIRC this is precisely the reason why Android wants a lower MIP bias in the first place, properly functioning aniso should not cause the texture shimering you get with lines across the road even with the current negative MIP bias.
This thread is closed
TEST Patch Y12 - East Asian Support
(53 posts, closed, started )
FGED GREDG RDFGDR GSFDG