Hello! Your VT library seems to be the only one publically available solution for virtual texturing with OpenGL!
I have a reasonable question: is it possible to use bigger virtual texture then 128k*128k pixels? For example, 256k*256k, or even 1m*1m pixels?
Maybe I just don't get the idea of using virtual textures, but if I want to texturize the whole Earth with good resolution map, 128k*128k would be not enough!
Are there any tools for creating such textures faster then with imagemagick (for big textures it's very very slow) ? Or do I have I to write my own one? I guess the texture tile pool structure is well-documented, so it shouldn't be a big problem, right? I think that python scripts for building texture tile pool provided with libvt don't give the maximum speed of image processing, am I right? :-)
Also, what if I have textures for some areas with high resolution, and with low resolution for others, what should I do to store such data into a single virtual texture? I could up-scale the low resolution parts before placing them into texture atlas, but that would make atlas's size much much bigger :-(
If it may help, I could try to give more details on my task. Thanks!
> is it possible to use bigger virtual texture then 128k*128k pixels?
theoretically yes, and with a bit of work you can also do this with LibVT.
for a background please read section 4.1.2 Maximum Virtual Texture Size in my thesis ( http://www.cg.tuwien.ac.at/research/publications/2010/Mayer-2010-VT/Mayer-2010-VT-Thesis.pdf )
basically to use a mipmap chain length above 11 (our limit, which limits to 128k^2 textures with a 256 pixel base tile size) you have to modify the shaders to store the higher precision coordinates.
another issue when increasing mip chain length is the that with every step increase the necessary size for the pagetable texture gets 4 times larger. the current limit of a 1k^1 pagetable texture gets fine performance. if you go higher it might be necessary to invest more time into optimizing the updates to the pagetable.
one easy way to get 256^256 textures is to increase the tile size to 512^2, but that significantly lowers performance and increases the necessary size for the backing texture.
another very easy way which you can of course combine with optimizations to allow a higher virtual textue size is to just use multiple virtual textures. 4 128k v-textures give you the resolution of a 256k^2 texture.
> but if I want to texturize the whole Earth with good resolution map, 128k*128k would be not enough!
i don't think anyone ever claimed that virtual texturing can give you that level of detail. for the simple case of rending planets just with heightfields other technologies like simple clipmaps might be more suited.
in fact a 128k^2 virtual texture would only provide data for about 512 by 512 meters of terrain if you want a "perfect resolution" of one (texture) texel per (screen) pixel. so only a 1m^2 texture would only be enough for a few square kilometers.
the game rage which uses virtual texturing still has to divide its game world into several (admittedly large) areas instead one giant map.
>Are there any tools for creating such textures faster then with imagemagick
since image manipulation software still doesn't use virtual texturing most of them can't really handle anything above 32k^2.
one solution is not to create the whole texture at once but just have many many objects with semi-large textures (up to 8k^2) in your scene. each of the textures remains handle-able and you can then use LibVTs scripts like generateTextureAtlas.py to combine them. of course thats assuming a "normal" scenario and not something like wanting to texture a planet.
>Or do I have I to write my own one?
writing a virtual texturing capable world editor (like ID software has) would of course be a cool thing ;)
>I guess the texture tile pool structure is well-documented, so it shouldn't be a big problem, right?
its really very simple, yes. combining all the files into a big binary file would be preferable from a performance standpoint but as it is now its easier to tinker with.
>I think that python scripts for building texture tile pool provided with libvt don't give the maximum speed of image processing, am I right? :-)
true but i guess significant speedups would not come from changing the language (since the actual image processing is done either with imagemagick or the python image library which are all implemented in C) but from making sure the it performs well with the given memory, i.e. some out-of-core solution is needed.
>If it may help, I could try to give more details on my task.
that sounds great! ;) see TODO.txt for a list of open tasks. i'd say just work on whats interesting to you personally, and i'll make sure to get it merged. supporting larger maximum virtual textures is a worthy goal you already mentioned, but it may not be the easiest thing to start with.
Hey! Thanks for your quick answer (in contrast to my very slow one)
The image data is an ierarchy of 1024x1024 px textures, each representing an area of Earth surface. They are divided into N (ranging from 5 to 11) detail levels. Detail levels are organized in the way that each texture may have up to four sub-textures (something like quad-tree of textures).
The 1st level texture represents the whole Earth surface in 1024x1024 px, 2nd level is four 1024x1024 px textures with more detailed 1st level's left-top, right-top, left-bottom and right-bottom parts (lets call them sub-textures) and so on.
It's possible that one texture has only 1, 2 or 3 sub-textures.
My goal is to pass to the current shader correct texture data/coordinates for rendering the visible Earth surface.
We should be able to render sphere textured with coarse quality image data, or plane representing a few kilometers of surface with high quality details (11th detail level is something like 2 pixels/meter)
Do you have any thoughts on this?
if you are projecting everything on a flat plane or sphere, why not go with traditional clip-mapping? afaik all high-res planetary-rendering solutions are clip-map based.
alternatively you could just try to shove that data into libvt. as previously discussed the 11 detail levels should fit into libvt as-is, but thats the maximum. nevertheless i wouldn't recommend using the 1024x1024 textures. i already significantly worse experience using 512 tiles than with 128 tiles.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.