When specifying say a LOD-bias of 2.5, out of tex2Dlod and tex2Dbias which one blurs between MIP levels 2 and 3 with a lerper of 0.5 and which one rounds up or down to the nearest “hard integer” MIP level? The Cg specs say that tex2Dbias blurs and doesn’t specify anything for tex2Dlod, but visual tests in Unity (GLES 3 with -force-opengl) seem to indicate the exact opposite, but maybe my eyes are tired… 
1 Like
Um, nope? As I said the spec for bias reads “Level-of-detail bias can be used to artificially blur or sharpen the result of texture sampling” BUT the spec for lod says nothing on the topic one way or the other. Which, OK, probably means as per spec there’s no blurring. So what happens with a bias of 0.5? Sure I can try everything and their dog experimentally but some cold hard super-detailed specs ala Khronos wouldn’t hurt I guess. OK gonna check the glsl/hlsl specs for the equivalent funcs.
Ohh, you’re wondering if it applies texture filtering.
Yeah, that appears to be broken in Deferred Lighting.
Nope, didn’t mention filtering. Basically wondering, if bias with a 2.5 bias blurs between MIP 2 and 3, what does lod do with a 2.5 bias
And how could texture filtering in any way possibly “appear broken in Deferred Lighting”? I’m not using Unity’s Deferred but still that would seriously surprise me. Filtering is just “the basics”.
Neither of these.
Lod with 2.5 means “sample between mip levels 2 and 3”. Whether it blurs or not depends on whether filter mode on the texture is set to bilinear or trilinear (by default textures have bilinear filter mode).
Bias with 2.5 means “hey whatever mip level you would be normally using… add 2.5 to that”. A bias of 2.5 would translate to something like “pretend the object is 6 times smaller on screen than it really is”.
9 Likes
As far as I’m aware, that’s the main difference between bilinear and trilinear filtering. That’s why I saw both pages as similar when they both indicated they could sample a different detail levels.
Hold on, I’ll try to do a quick test. I just remember losing filtering (it used point sampling) when sampling cubemaps at higher MIP levels, in Deferred Lighting. [Edit] Ah, nope, just for cubemaps, works fine for regular textures.
[Edit] Ah, ninja’d by the ninja
zOMG thanks dude, you’re the hero the Cg documentation team needed, but apparently didn’t deserve Crazy how I could misunderstand tex2Dbias so badly. But both doc articles sounding “basically-identical” did contribute to that. Thanks for enlightenment, much appreciated. This explains why my bicubic and bspline heightmap interpolation experiments “flattened” everything inexplicably. Calculating a LOD level and then giving it to tex2Dbias (thinking one gets a nice extra blur) would do that.
Again, I’m pretty confident cubemap sampling should happen the same in Forward and Deferred. It’s always done in a shader, and the GPU-side shading level has no concept of Unity’s different render-paths. Especially if you explicitly specify a MIP level. Maybe it works as you expect to and maybe it doesn’t, but it should be the same behavior in Forward and Deferred theoretically.
It knows when you tell it:#define UNITY_PASS_FORWARDBASEwhich surface shaders do.
But it turns out to be a problem with SampleLevel and the automatically generated SamplerStates, not tex2Dlod or tex2Dbias. Sorry for the confusion.
They should write this sentence(s) into the function documentation…!