Using ComputeMipLevel results in materials that look blurry from the side - the MipLevel computation does not seem to be correct. This happens 100% of the time. Tested on two separate systems (one with a Nvidia and one with an AMD GPU). There is no visible difference between D3D and OpenGL.
The quality improves when carefully reducing the Texture Size input for ComputeMipLevel.
I have been looking into your issue and have come up with a few questions. First let me describe what I am seeing.
I have set up the 2 materials, as you have shown in the photos, and have applied them to 2 separate static meshes. I have also disabled the Texture streaming as as step 2 states. As I view them from an angle, the bottom mesh does appear to be very blurred compared to the top mesh. If you take off the Texture streaming and proceed to change the values of the constant-2 node going into the ComputeMipLevel, the higher the values, the more blurred the material will become. Here is a photo what I am seeing exactly:
In the image shown, I have set my constant values at 500 and 500, not the 1020 and 1020 as recommended in your setup. If I set the values that high, the material is almost one solid color. Even if I PIE and get really close to material that the mesh is on, it barely changes the blurred state.
Is there another step or checkbox that you could of possibly forgotten from the RePro that would enable me to have almost a similar photo as yours because all I am seeing is a normal material and a heavily blurred one if I set the values to 1.02e+003 by 1.02e+003?
the Constant2Vector matches the texture size, so in my case I just used a 1024,1024 Vector for a 1024x1024 texture. Other than that, there’s nothing more to it, so I’m wondering why you get this result. The only time I saw such blurry textures was when texture streaming was broken, which should be fixed in 4.2. On my machine on 4.2.1 it doesn’t matter if texture streaming is enabled for the texture or not.
I should add another repro step: Set the texture quality to high. When set to low, the normal material looks very similar in terms of blurryness. Which makes me wonder if this whole issue is just a result of anisotropic filtering not working for custom mip levels.
Hi Sean,
I think you might be on to something regarding the difference being anisotropic filtering. I was able to repro the issue too but it was fairly subtle in the test I did.
I am going to reach out to the engine programmer who helped me add this material function to the game to make sure that is going on.
For the record, this function was really only intended to be used when you are doing things like MosaicUVs which creates hard-edged jumps in the UV value that cause the GPU to try and render mipmapped textures on the border causing really bad artifacts.
Here is an example of the type of artifacts computemiplevel will help with.
This uses a technique similar to the mosaicUVs material function to break up a single tiling texture into planks. Normally this creates artifacts at the edge of each tile, even though the “mask” was set black there in the specular as a test.
Hi Ryan,
actually, randomly shuffling texture tiles is exactly my use case
It’d be great to know if that’s a fixable problem or just a drawback of the method.
It’s kind of noticeable when you have an entire floor covered with a tiled material like this.
One major difference is anisotropic texturing.
Computeing a single float for the mip already means there can be no anisotropic filtering. That means angle surfaces will not be as sharp. We would have to compute the footprint (2x float2) and pass to a textur2dgrad instructions (quiet slower). We want to avoid that slow path.
Actual mip computation can be done in many ways. e.g. we can make it more sharp but then it shimmers more.
