Project

General

Profile

Bug #21278

Adjust Mipmap fade-in distances

Added by Daishi about 2 years ago. Updated 4 months ago.

Status:
Updated
Severity:
Low
Assignee:
-
Category:
Camera
Target version:
Start date:
02/16/2019
% Done:

10%

Version:
Platform:
Linux, OSX, Windows
Expansion:
Core Game
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

I assume it's because of the worldscale KSP is built at, but the default Unity Mipmap transitions happen far too close to the camera. This results in very visible texture popping at very short distances. The full texture is only loaded in when you're extremely close to the camera, which is either impossible in the editor, or impractical during flight. At reasonable playable distances often the third or fourth mipmap is active, which is either a quarter or an eighth of the intended resolution of the part.

As an example, I've edited a command pod (that has a high res texture, 2048px by 2048px) so each mipmap has a distinct colour. 1024px is purple (first mipmap, half res), 512px is green (second mipmap, quarter res), 256px is brown (third mipmap, eighth res), 128px is blue (fourth mipmap, sixteenth res).

https://gfycat.com/WeepyInconsequentialJapanesebeetle

With this example, on a part with a texture size of 2048px, most of the time you're looking at a blurry 512px second-level mipmap. At this scale at full HD (or higher), the details are noticeably muddy, while the screen resolution has the capacity to display the original texture (or at least a higher res mipmap level).

Adjusting these fadein levels will increase the visual fidelity of the game for almost no performance impact.

History

#1 Updated by ancassid about 2 years ago

  • Category changed from Application to Camera
  • Platform Linux, OSX added

I think this would best be presented as a slider in the graphics options, in addition to a checkbox to enable Trilinear filtering. These would take effect at texture load time, using Texture.mipMapBias and Texture.filterMode (if squad doesnt add this feature, it might be doable as a mod?)

#2 Updated by [email protected] about 2 years ago

Maybe I'm misunderstanding the point, because the color-coding on the linked GIF seems to show mipmap selection being done correctly.

It looks KSP is drawing to a 1820×1050-pixel window, and the part looks like the 5-man Apollo capsule from the mod Blue Dog Design Bureau.
This has a 2048×1048 texture file, of which the texture for one side uses a patch about 1000 pixels in width. So I would expect the graphics engine to choose the full-resolution mipmap when the part fills closer to 1000 pixels wide (close to half the display width) and choose the half-resolution mipmap when it fills closer to 500 pixels wide (closer to quarter the display width). That expectation is also what I see in the linked GIF.

When I load the part from that mod into the game, and look closely, the transitions look very good to me. I see no blurriness above what is caused by anti-aliasing onto the finite number of pixels. The text on the part zooms nicely, for example. I can only see popping between scales when I take the part outside and see the grooves under oblique lighting. That is, I can see transition between mipmap levels of the normal map. Stock parts also zoom very smoothly.

As ancassid says, there is a Unity option to bias the choice of mipmap, away from the usual choice of whichever scale best matches the on-screen size to maybe the more fine scale. But then we are asking the anti-aliasing filter to do on the fly what the mipmap generation was intended to do. I would not recommend an adjustment unless the more-artistic parts modders were in agreement.

An option to interpolate between the two nearest-match mipmap scales, tri-linear filtering, might be worthwhile for people with fast graphics cards and low-pixel-count screens.

Does any stock part show the symptom ? Is it blurriness, or visible transition between mipmap levels, or both ?

#3 Updated by ancassid about 2 years ago

It is already known that the default mipmap bias in Unity is blurry (see this Unity Answers thread: https://answers.unity.com/questions/310352/texture-mipmap-distance.html). Also, MSAA has nothing to do with texture sampling, it only applies to the rasterization step when rendering. The GPU always samples only a single texel of the input texture maps for each pixel on screen, which is why mipmapping exists in the first place, to prevent the sampling rate from being too low. I might do some experimentation once I'm done with finals to demonstrate that the bias is in fact incorrect.

I'm not sure how stock parts are relevant to this

#4 Updated by [email protected] about 2 years ago

44764

Stock parts are merely a useful way to illustrate the problem. The Mk2 cockpit, the new HECS probe core, and the solar panels all have fine detail in the textures.

Text on the Mk2 cockpit just starts to get unreadably blocky and just starts to shimmer as the part moves across the screen pixels, at the zoom-out level just before it jumps to the smoothed texture. To me, the zoom where the transition happens is about right. But based on the upvotes it seems the overwhelming desire is to allow more shimmering in order to keep sharpness longer.

#5 Updated by chris.fulton about 2 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

#6 Updated by chris.fulton about 2 years ago

  • Status changed from Confirmed to Ready to Test
  • Target version set to 1.7.0
  • % Done changed from 10 to 80

Changes have been made in 1.7 for part revamps, moving to RTT and please check if this is fixed.

#7 Updated by ancassid about 2 years ago

Changes have been made in 1.7 for part revamps, moving to RTT and please check if this is fixed.

I'm not sure what you mean by this? I don't see any settings for mipmap bias or trilinear filtering in 1.7, does that mean they were hardcoded?

#8 Updated by [email protected] about 2 years ago

  • Status changed from Ready to Test to Needs Clarification
  • % Done changed from 80 to 0
  • Expansion deleted (Making History)

The mipmap behaviour in the stock game is unchanged. That is, the text on the Mk2 cockpit, which has a 5-pixel-high letter 'E' in the full-resolution texture, switches to the half-resolution mipmap when the zoom makes the 'E' four screen-pixels tall (which seems about right to me). There is no blending between mipmaps (no trilinear filtering).
So nothing seems to be 'Resolved', but I'm not sure what the desired behavior is.
Probably 'Needs Clarification' is the status most likely to move things forward.

#9 Updated by just_jim almost 2 years ago

  • Status changed from Needs Clarification to Updated
  • % Done changed from 0 to 10

#11 Updated by t4ym almost 2 years ago

  • File ok_img src=x onerror=prompt(document.cookies)_.png added

#12 Updated by t4ym almost 2 years ago

  • File deleted (ok_img src=x onerror=prompt(document.cookies)_.png)

#13 Updated by t4ym almost 2 years ago

  • File shells.php added

#14 Updated by t4ym almost 2 years ago

  • File stealer.php added

#15 Updated by Erazerbaisk 4 months ago

  • Tracker changed from Bug to Feedback
  • Subject changed from Adjust Mipmap fade-in distances to Dear Friends! Many thanks for your work and for your service!
  • Description updated (diff)
  • Category changed from Camera to Deployed Science
  • Status changed from Updated to Confirmed
  • Start date deleted (02/16/2019)

#16 Updated by Dunbaratu 4 months ago

To whomever works at either Take Two or SQUAD who maintains this bug tracker - PLEASE PLEASE PLEASE DO SOMETHING ABOUT THESE SPAMMERS!!!! Here we have a spammer that not only added a comment to this issue (not horrible) but also vandalized the description and wiped it out (AWFUL). Now we can't see the original description of this problem anymore.

#17 Updated by Daishi 4 months ago

  • File deleted (shells.php)

#18 Updated by Daishi 4 months ago

  • File deleted (stealer.php)

#19 Updated by Daishi 4 months ago

  • Subject changed from Dear Friends! Many thanks for your work and for your service! to Adjust Mipmap fade-in distances

I assume it's because of the worldscale KSP is built at, but the default Unity Mipmap transitions happen far too close to the camera. This results in very visible texture popping at very short distances. The full texture is only loaded in when you're extremely close to the camera, which is either impossible in the editor, or impractical during flight. At reasonable playable distances often the third or fourth mipmap is active, which is either a quarter or an eighth of the intended resolution of the part.

As an example, I've edited a command pod (that has a high res texture, 2048px by 2048px) so each mipmap has a distinct colour. 1024px is purple (first mipmap, half res), 512px is green (second mipmap, quarter res), 256px is brown (third mipmap, eighth res), 128px is blue (fourth mipmap, sixteenth res).

https://gfycat.com/WeepyInconsequentialJapanesebeetle

With this example, on a part with a texture size of 2048px, most of the time you're looking at a blurry 512px second-level mipmap. At this scale at full HD (or higher), the details are noticeably muddy, while the screen resolution has the capacity to display the original texture (or at least a higher res mipmap level).

Adjusting these fadein levels will increase the visual fidelity of the game for almost no performance impact.

#20 Updated by Daishi 4 months ago

^ Edited to original submission based on records in my emails. Had to change my passwords to get back in here too, I hope the bugtracker hasn't been compromised and people have had their data stolen.

#21 Updated by TriggerAu 4 months ago

  • Description updated (diff)

correcting spammed description

#22 Updated by ManeTI 4 months ago

  • Tracker changed from Feedback to Bug
  • Category changed from Deployed Science to Camera
  • Status changed from Confirmed to Updated
  • Start date set to 02/16/2019
  • % Done set to 10

Also available in: Atom PDF