So I was thinking about a texture format...
Author
And wondered if such a thing already exists, or, if not, whether it should. Is there a format that can have different resolutions for different rectangular areas? So you could start with a 64x64 map, and then have one of the "pixels" in the middle split up into another 64x64 texture, or have a 5x5 area in the middle contain 32x32 pixels.
Basically an image with subdivision. Of course, the final texture "size" would have to be expressed in terms of the smallest "pixels". I was just thinking that this could be quite useful for using a relatively coarse texture map, but then adding very fine details in certain areas for added realism.
It sounds a lot like mipmapping to me, only for arbitrary locations and sizes. You could possible write a fragment that does this though, if the feature doesn't already exist. For each level, have two textures, a 1-bit one and a regular one. The 1-bit one tells you for this level whether or not a texel in the regular texture is the final color, or is subdivided. The regular texture map will have valid colors for the non-subdivided pixels. If it's subdivided, then the next level down has the same two textures that do the same thing. Basically it's a tree.
I like the idea if that means anything. I don't know how fast or memory efficient it will be though.
I like the idea if that means anything. I don't know how fast or memory efficient it will be though.
If you are referring to mip mapping, OpenGL (surely D3D can as well) can generate them on the fly from a file with only one dimension, the highest resolution one. A 64x64 image already contains all of the data for a 32x32 image, the only thing that needs to be done is "down sampling."
Now, if your file stores the down sampled results then it can be useful, because you won't have to generate mip maps at run time. However, if all it does is store the structure of the mip map (one version is 64x64, the next is 32x32, etc...) then it is mostly a waste. Unless you want to apply mip maps differently for some files. In which case such a setup could add information for how that should be done. I can't imagine why you would need that. However.
TIFF's may have something like that, but I don't know and from what I recall it's a poorly implemented format.
Now, if your file stores the down sampled results then it can be useful, because you won't have to generate mip maps at run time. However, if all it does is store the structure of the mip map (one version is 64x64, the next is 32x32, etc...) then it is mostly a waste. Unless you want to apply mip maps differently for some files. In which case such a setup could add information for how that should be done. I can't imagine why you would need that. However.
TIFF's may have something like that, but I don't know and from what I recall it's a poorly implemented format.
To my knowledge there's no current support for multi-resolution texture maps as you describe. Mipmapping will work if you're only interested in filtering regions, but it sounds to me like the primary concern here is memory usage (ie. you don't want to store the whole texture in high resolution).
One way to implement what you are describing is by adding a level of indirection to your texture lookup using dependent texture reads in the fragment shader. I won't go into details, but I'm sure you can dig up some information or an example on the 'net without too much difficulty.
One way to implement what you are describing is by adding a level of indirection to your texture lookup using dependent texture reads in the fragment shader. I won't go into details, but I'm sure you can dig up some information or an example on the 'net without too much difficulty.
Author
Quote:Original post by AndyTX
To my knowledge there's no current support for multi-resolution texture maps as you describe. Mipmapping will work if you're only interested in filtering regions, but it sounds to me like the primary concern here is memory usage (ie. you don't want to store the whole texture in high resolution).
One way to implement what you are describing is by adding a level of indirection to your texture lookup using dependent texture reads in the fragment shader. I won't go into details, but I'm sure you can dig up some information or an example on the 'net without too much difficulty.
Yes, that's exactly what I want. Thanks for the information.
That kind of thing is useful for large terrain databases where you want more precision in certain areas. The military simulation business does this kind of thing. You can express this behavior in SEDRIS, and possibly in TerraPage, but those are data interchange formats, not texture formats.
When it comes to rendering, hardware doesn't support such multi-resolution descriptions, so you have to come up with a hardware-friendly solution (such as the one hinted at by AndyTX).
When it comes to rendering, hardware doesn't support such multi-resolution descriptions, so you have to come up with a hardware-friendly solution (such as the one hinted at by AndyTX).
I thought before that something like this could be useful, for storing images. For instance jpeg is generally quite nice-looking but some things look really bad - text being one of the worst things in a jpeg image.
It seems silly to have to have the whole image at 90% quality in your exported because of the small amount of text in the corner, when the rest of the image would look great exported at 40%.
So it would be cool if you could have a jpeg/png variant where different sections of the image could be stored at different loss-settings.
It seems silly to have to have the whole image at 90% quality in your exported because of the small amount of text in the corner, when the rest of the image would look great exported at 40%.
So it would be cool if you could have a jpeg/png variant where different sections of the image could be stored at different loss-settings.
You could probably do this with a normal JPEG and some clever manipulations of the texuture coordinates. Low resolution areas will be stretched more while high resolution areas will be strecthed less and occupy more pixels in the texture. Then you could have two files. One that describes the resolution of each section of the image. Then a second which uses the first file to store the generated texture coordinates. Then you can use the first file for development and the second for the actual 3D engine. Although it would be nice to combine such files with the texture file, I doubt you can beat JPEG compression.
[Edited by - T1Oracle on November 11, 2005 5:07:02 PM]
[Edited by - T1Oracle on November 11, 2005 5:07:02 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
