Huge textures

OpenGL Development JOGL Development
#1

I would like to provide a texture map for a terrain. This map would be a texture containing the layout of hundreds of roads. I’m going to be using a shader to mix my road map with some other textures to make the final terrain look natural.

To create my road map, I’m going to need a huge texture, probably bigger than my graphics card can handle to get any decent amount of resolution. Is there a way to do this? Do I need some fancy paging algorithm to get the texture to and from memory?

Also, is this the best way to handle this problem?

#2

OpenGL has a maximum texture size that is guaranteed to be supported (which I think is 512x512, but can’t actually remember). Some implementations may support bigger textures, but you can’t rely on it.

You’ll have to use multiple textures tiled over your terrain, I expect.

#3

Or figure out how Carmack does what he calls “Mega Texturing”: http://www.gamerwithin.com/?view=article&article=1319&cat=2

(don’t expect any help from me, I have no idea how to do what he is talking about :wink: )

#4

[quote]John Carmach: Level of detail wise, the terrain does not render with any sophisticated geometry morphing situation. That’s one of those things that for years I think most of the research that’s gone into has been wasted. Geometry level of detail on terrain…there have been thousands of papers written about it, and I honestly don’t think it’s all that important. The way the hardware works, you’re so much better off setting down a static mesh that’s all in vertex and index buffers, and just letting the hardware plow through it, rather than going through and having the CPU attempt to do some really clever cross blended interpolation of vertices.
[/quote]
Lesson 1: use a static mesh for your terrain geometry.

[quote]John Carmach:And one of my early suggestions to them was that they consider looking at an approach where you just use one monumentally large texture, and that turned out to be 32,000 by 32,000.
[/quote]
Is it 32k*32k pixels image size?

#5

Nah, that would be 4GB of texture-data.

He’s talking about virtual textures, and how great they are, and what’s so
great about them and how great it is that he doesn’t give any clues about
how to implement it :smiley: unless ‘complex fragment shader’ is enough for ya.

#6

MegaTexture always sounded like a fancy name for a clipmapping style system to me. That approach is well documented, but unfortunately it’s a patent minefield…

#7

Well 2G if you’d use only 16bits for each pixel for example and using some kind of clever compression you could get that down a lot more I guess.

All of that easily fits on a DVD and if you realize that most games nowadays are multi-GB monsters 1 big texture occupying 2GB is nothing special, especially if it would really improve gfx quality by having no ugly repetitive terrain feautres.

And where do you get the idea that it would be a “virtual” texture, as far as I can see he really talks about artists being able to treat the thing as one big canvas to draw upon. Or do you mean by virtual that it won’t all be in system/gfx-card memory at once, because that’s abvious of course.

And that he doesn’t want to tell (yet) how it works seems logical, he first wants to earn money with the idea :wink:

#8

Probably you are right about a clipmapping, or JC has implemented a variation of clipmapping technique.
http://www.vterrain.org/LargeTextures/index.html
http://www.sgi.com/products/software/performer/presentations/clipmap_intro.pdf
http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_Developer/books/Perf_PG/sgi_html/ch12.html
“patented algorithm to allow textures that are much bigger than will fit in texture memory, and even in system memory”
“SGI demonstrated a 32k32k cliptexture (25m data, 800800km) = 3 GB of memory”

#9

Still I would be interested to know how he solved the problem of large terrain height displacements resulting in blurry textures. (At least he claims to have solved it)

#10

Well my current work with JOGL is using shaders to do scientific visualization, while my work isn’t terrain rendering, I am rendering 2GB+ data sets and I simply use a MappedByteBuffer, and glTexSubImage2D() and get very good performance. You might also want to look at the grand canyon demo as well, http://java.sun.com/products/jfc/tsc/articles/jcanyon/