What value does the LOD parameter take for texturelod? The spec I found doesn't mention it at all. Is it a percentage or an index value with a percent. If the later is the case, is there a way to get the number of mipmaps the texture has so that I would be able to use a percentage?
The LOD parameter specifies the mipmap level, rounded to the nearest whole number. Remember that OpenGL specifies mipmap levels, such that 0 is the largest, with increasing numbers going smaller.
However, the LOD specified here will always be relative to the current GL_TEXTURE_BASE_LEVEL of the texture. So if you use textureLod(..., 0), and the base level is set to mipmap 2, then you will select from mipmap level 2. You also cannot select mipmaps outside of the GL_TEXTURE_MAX_LEVEL range; the system will automatically clamp the specified parameter appropriately.
Related
Suppose I'm making a VkSampler, or possibly a set of VkSamplers, that I'm planning on using with several textures. Each texture has multiple mip levels, and the number of mip levels varies from texture to texture. I want all sampler options to be the same for all the textures, with the possible exception of maxLod.
I don't actually want maxLod to block any particular mip levels from being used; I only want all of each texture's levels to be used in an ordinary, non-erroneous way. So can I just throw in an absurdly high upper bound and use the same sampler for all the textures:
VkSamplerCreateInfo samplerCreateInfo;
...
samplerCreateInfo.minLod = 0;
samplerCreateInfo.maxLod = 1048576;
...or do I need to create a different sampler for each texture and set maxLod for the sampler to that texture's unique maximal mip index?
I think the answer is probably that I can count on reasonable clamping to happen even if my sampler's maxLod is very high - even if I then explicitly pass a uselessly high value to textureLod in a shader - but I'm not totally sure I've correctly interpreted the relevant sections in the Vulkan and GLSL specifications.
No, you can make maxLod as large as you want. If there were cases where it would be "too high", they would be listed as Valid Usage requirements. According to the spec, the only requirements are that it be greater than or equal to minLod, and if unnormalizedCoordinates is true then it must be zero. Beyond that, it is only used to clamp the computed lod. The actual mipmap level accessed is the computed lod (clamped to maxLod), further clamped to the number of mipmaps levels actually available in the texture.
In spec language, maxLod is used to limit the value of λ (Level of Detail Operation). Then the mipmap level accessed, is d' = levelbase + clamp(λ, 0, levelCount - 1) (Image Level(s) Selection). So if maxLod is larger than levelCount - 1, it won't affect the outcome.
I have a 3D texture. Each texel contains a transparency value on the alpha channel.
I need to generate my mipmaps in such a way that it always takes the values of the texel with he maximum alpha value.
In other words if there are 4 texels 3 with a transparency value of 0 and one with a transparency value of 1 the resulting mipmap texel should be 1.
How can I achieve this?
If I need to write my own shaders, what is the optimal way to do it?
EDIT:
My question, to put it more clearly is:
Do I need to manually create a shader that does this or is there a way to use built in functions of opengl to save me the trouble?
In order to do that, you'll need to render to each layer of each mipmap with a custom shader that computes max of 8 samples from the upper level.
This can be done by attaching each layer of the rendered mipmap to a framebuffer (using glFramebufferTexture3D), and, in the shader, sampling from the same texture by using texelFetch (lod parameter specifies the mipmap to sample from).
What value does the LOD parameter take for texturelod? The spec I found doesn't mention it at all. Is it a percentage or an index value with a percent. If the later is the case, is there a way to get the number of mipmaps the texture has so that I would be able to use a percentage?
The LOD parameter specifies the mipmap level, rounded to the nearest whole number. Remember that OpenGL specifies mipmap levels, such that 0 is the largest, with increasing numbers going smaller.
However, the LOD specified here will always be relative to the current GL_TEXTURE_BASE_LEVEL of the texture. So if you use textureLod(..., 0), and the base level is set to mipmap 2, then you will select from mipmap level 2. You also cannot select mipmaps outside of the GL_TEXTURE_MAX_LEVEL range; the system will automatically clamp the specified parameter appropriately.
How do GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD and LOD_BIAS work?
To check it visually, i have created 6*6 texture with mipmapping and for values > 0.5 for MIN_LOD I get a 3*3 texture irrespective of values for MAX_LOD. If I change LOD_BIAS it does not affect my o/p. I am not able to figure out how it works exactly.
Can anyone explain it by stating an example?
Edit:
I am creating mipmap levels manually so that I can observe which level it is picking up. Here is my code:
glTexImage2D(target, 0, GL_RGBA,9 ,9, 0, GL_RGBA, GL_BYTE,subpix);
glTexImage2D(target, 1, GL_RGBA,4 ,4, 0, GL_RGBA, GL_BYTE,&subpix[4]);
glTexImage2D(target, 2, GL_RGBA,2 ,2, 0, GL_RGBA, GL_BYTE,&subpix[10]);
glTexImage2D(target, 3, GL_RGBA,1 ,1, 0, GL_RGBA, GL_BYTE,&subpix[18]);
glSamplerParameterf(sampler,GL_TEXTURE_MIN_LOD,0.862);
glSamplerParameterf(sampler,GL_TEXTURE_MAX_LOD,0.99);
glSamplerParameterf(sampler,GL_TEXTURE_LOD_BIAS,0.0);
In this case I am expecting it would take 2nd mipmap level which is of 2*2 but It chooses 1st mipmap level of 4*4. When I set min lod < 0.5, It takes 0th level of 9*9. And it this happens irrespective of the value set to max lod.
First some references:
TEXTURE_MIN_LOD Sets the minimum level-of-detail parameter. This floating-point value limits the selection of highest resolution mipmap (lowest mipmap level). The initial value is -1000.
TEXTURE_LOD_BIAS specifies a fixed bias value that is to be added to the level-of-detail parameter for the texture before texture sampling. The specified value is added to the shader-supplied bias value (if any) and subsequently clamped into the implementation-defined range - bias max bias max , where bias max is the value of the implementation defined constant GL_MAX_TEXTURE_LOD_BIAS. The initial value is 0.0
So if you are surprised by the mipmap selection, I suggest following steps (not necessarily in order):
Create mipmaps by hand so that they are visually distinctive from each other
Verify your mipmaps are supplied correctly.
Verify that your LOD_BIAS setting doesn't just put all of the values outside the range, making the sampler effectively always use the maximum or minimum LOD.
Searching around this, I've found textureQueryLod . It might also be of some interest to you to aid debugging.
Hey, I have a texture loaded with glTextImage2D.
I want to get the texture's size after it was loaded to the VRAM, what do I need to do?
My internal format is RGBA and the texture's format varies.
This might be helpful to you and you can probably infer the actual memory usage from it. However, I believe this still is rather an approximation:
http://www.geeks3d.com/20100531/programming-tips-how-to-know-the-graphics-memory-size-and-usage-in-opengl/
(query the total memory usage of OpenGL using NVIDIA or ATI specific extensions)
Also note that from my experience, approximating the memory usage by rough calculation was usually sufficient. Textures "should" be stored either 1,2 or 4 components without any significant overhead. Therefore for a WxH RGBA texture, calculate W*H*4. If you store float textures (i.e. GL_RGBA32F), calculate W*H*4*4. For Mip-Maps, add (1/3) additional memory consumption. Be aware however, that - at least to my knowledge - texture memory can also fragment, possibly leaving you with less available memory as estimated.
Use GetTexLevelParameter, which can give you (for each level):
Width and height *
Depth
Internal format *
Compressed format and relative size
(*) Uses these parameters for computing the texture size (for the specified level).
The single texture memory usage is dependent on the generated mipmaps. Indeed to compute correctly the memory used by a single texture you have to determine the mipmaps related to the textures, and then sum the memory usage for each level.
The mipmap count is determined by the OpenGL specification depending on the texture target: texture arrays elements has their own mipmaps set, each cube face texture has its own mipmap set.
The dimension of the mipmaps are halfed for each level, untill they goes to 1. In the case the dimension are not power of two, they are rounded to the lower integer.