View Full Version : Lots of small textures or fewer large textures?

01-06-2004, 10:39 AM
I'm going to be writing a program that will be zooming in and out on very large images (10000+x10000+).
I've already tiled the image into lots of 1024x1024 tiles at different LODs (essentially doing my on pre-mipmapping).
I'm also writing a texture manager to load the appropriate textures when the image gets panned etc...

I was wondering if rendering smaller textures (256x256 for example) and having more of them is better for performance than rendering fewer larger textures.


01-06-2004, 11:30 AM
Can't you simply leave the texture size as a parameter and compute the neccessary amount of textures from this? So your program would be flexible and you can find out what's fastest (although I guess if it's just about zooming in and out of one image, speed will not be an issue). Also, I would only calculate the highest level textures and would mipmapping automatically take care of the rest.


01-06-2004, 11:43 AM
I don't think I can use mipmapping because then I would have around 100 base textures (assume 1024x1024 base texture with a 10000x10000 image)...that's A LOT of texture memory once you throw in the mipmaps.

And yes I can generate tiles that are of smaller sizes, but I was just wondering if there was an obvious up-front answer...

[This message has been edited by jlamanna (edited 01-06-2004).]

01-06-2004, 11:57 AM
There is some performance impact inherent in binding to a texture, because this is state change. So in general, it is better to use one large texture than many small textures.

However, this impact may be much smaller than the impact of thrashing textures out of AGP space, if your texture caching scheme is constantly maxing out VRAM usage.

As with most OpenGL performance questions, the best thing to do is just try it both ways on your target hardware and see which way works better.

01-06-2004, 12:49 PM
It depends on the granularity of the pan etc.

Consider memory useage and what happens at the borders. When you start panning you have an instantaneous load with a tiled approach and that needs to be managed over time where several tiles need to be loaded simultaneously you must anticipate, how much anticipation and the padding required is a matter for experimentation but also affects the total texture space used since your border pad must accomodate all anticipated tiles. The smaller the tiles the less this load, however too many small tiles and you start to lose paging performance at all levels of your system.

The bottom line is there's no simple answer anyone can give you. It may be best if your system can support several sizes and you can experiment which size works best.

[This message has been edited by dorbie (edited 01-06-2004).]

01-06-2004, 01:01 PM
He already said he has MIP maps, so thrashing the texture cache won't be a problem.

I think fewer, larger, will always be better.

If you're doing filtering, you should set the textures up with border, or at least repeat the edge pixel of one texture at the beginning of the next.

01-06-2004, 01:13 PM
regarding the mip mapping issue.. I do not really see a difference between mip mapping and computing several LODd textures yourself? I just thought that mip mapping would make it more comfortable.

And like dorbie said, leave the size as a variable parameter and find out what's best. I guess it also differs between different chipsets.

However I think a problem with tiling the image is that one might see the seams, which would make large textures more suitable. if your image is 10000 x 10000, you might use 3 x 3 textures each 4096 4096, or something.

Why are you doing this with OpenGL anyway? If it's just for displaying a large image, simply doing everything yourself might be sufficient.


[This message has been edited by JanHH (edited 01-06-2004).]

01-06-2004, 01:50 PM
The problem with conventional hardware based MIP mapping is that the image tile size reduces with resolution. That becomes impractical as you zoom and page. You must apply your own resolution based texture switch as your level of detail changes. There are many ways to implement this. I won't talk about it in detail because I've worked on proprietary solutions to this problem.

[This message has been edited by dorbie (edited 01-06-2004).]

01-06-2004, 05:46 PM
Originally posted by dorbie:
I won't talk about it in detail because I've worked on proprietary solutions to this problem.

Publicly available information:
<a href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,618,053.WKU.&OS=PN/6,618,053&RS=PN/6,618,053" target="_blank">

[edit: I edited the link text because it was causing the whole page to get stretched unreadably. You may have to cut/paste the pieces if the embedded link doesn't work.]

I believe it's licensable. http://www.opengl.org/discussion_boards/ubb/smile.gif


[This message has been edited by Cyranose (edited 01-06-2004).]

[This message has been edited by Cyranose (edited 01-07-2004).]

01-06-2004, 06:33 PM
For the record, that's not the only scheme I'm thinking of Avi. There are alternative approaches and improved solutions.

01-06-2004, 07:19 PM
Originally posted by dorbie:
For the record, that's not the only scheme I'm thinking of Avi. There are alternative approaches and improved solutions.

Agreed. Just trying to give you something you *can* talk about, Angus http://www.opengl.org/discussion_boards/ubb/smile.gif

01-06-2004, 07:38 PM
Why would I need to when there's an expert around? http://www.opengl.org/discussion_boards/ubb/smile.gif

01-06-2004, 08:08 PM
Originally posted by dorbie:
Why would I need to when there's an expert around? http://www.opengl.org/discussion_boards/ubb/smile.gif

Really? There's a Pop'n Fresh on the board somewhere, but somehow I don't think that's Michael... http://www.opengl.org/discussion_boards/ubb/wink.gif

Seriously, I know a bit about it, but Chris and Phil did much much work on the texturing than I did. I'm a scenegraph and spatial algorithms kind of guy...

Anyway, to save Angus the trouble of typing this up, the key idea from the Universal Texturing patent is the idea of toroidal scrolling of a texture (one per LOD layer) rather than using adjacent tiles and MIP mapping.

By shifting the effective origin of the texture, one can subtexload the one or two slivers that are needed to complete a scroll, and therefore keep the texture properly windowed while minimizing texture memory footprint.

Do that for multiple LODs, and you have a fixed-size texture cube (not a true 3D texture, but shaped like one) you can scroll over a virtually unlimited source texture size, where you can go up and down the stack to find the right LODs per triangle.

Computing the proper LODs and doing the right per-pixel blending to make up for not using H/W trilinear is trickier.

Doing that for a whole planet of imagery is a bit trickier still, but if anyone wants to do _that_, I'd suggest talking to the patent holders about licensing or go another route entirely.


01-06-2004, 08:49 PM
Originally posted by Cyranose:
the idea of toroidal scrolling of a texture (one per LOD layer) rather than using adjacent tiles and MIP mapping.

In other words, the 1985 trick.

01-06-2004, 09:58 PM
arekkusu, I'm very interested, what specific prior art do you have in mind?

01-06-2004, 11:48 PM
@cyranose: the images of the link you provided are broken; do they work for someone else?

@dorbie: I think, he means clipmapping specified by SGI as an OpenGL extension.

01-06-2004, 11:52 PM
Limiting the discussion solely to updating edge strips of a 2d bitmap (windowing scroller) and shifting the virtual origin of the unchanged portion, how about this for starters: http://homepage.mac.com/arekkusu/GS/index.html#SMT

I think I still have the Merlin 16+ assembly source, somewhere. http://www.opengl.org/discussion_boards/ubb/smile.gif

In more recent work (this century) I do the same trick with real OpenGL textures, in the Tilescroller pictured here: http://homepage.mac.com/arekkusu/SW/other.html

I'm not trying to detract from your work, I'm sure there are plenty of novel ideas in the caching scheme. Just saying that "toroidal scrolling" is a new name for an old idea.

[This message has been edited by arekkusu (edited 01-07-2004).]

[This message has been edited by arekkusu (edited 01-07-2004).]

01-07-2004, 05:12 AM
This all looks very similar to the clipmapping extension to me (Toroidal loading, around a region of interest...) I wonder if you could get away with saying you learnt it from clipmapping instead of from the crappy patent http://www.opengl.org/discussion_boards/ubb/biggrin.gif
Anyway just wait a year DirectX Next has virtual texture memory coming up http://www.opengl.org/discussion_boards/ubb/tongue.gif


[This message has been edited by Pentagram (edited 01-07-2004).]

01-07-2004, 06:23 AM
A friend of mine turned me on to OpenSceneGraph (http://openscenegraph.sourceforge.net) which does have support for LOD views.

01-07-2004, 07:34 AM
I have quite some extensive experience in this matter. I currently support literally infinite size rasters (capped by the numerical precision), and have tested with rasters over 1M pixels wide. The memory consumption is quite optimial in that I only use about 16Megs video memory or less. I have even tesetd on loading thousands of these large images at the same time (overcoming system os file handle limitations), and the memory consumption has stayed the same (system memory consumption is also low, less than 20megs for over 2000 images). Roaming is also done in realtime with zooming/scaling/panning, no noticeable lag. Oh, its also 3D or 2D, so all pyramid layers can be active at any given time. What it boils down to in my opinion is as follows.

How fast can you load the 1024x1024 blocks of data? Even compressed, thats still a heavy chunk of data to be read in and decompressed on the fly. Threading is a must when dealing with large imagery, so you're going to have to choose a compressor that is thread friendly (if not using a raw format). Some compressors take up too much cpu time, so unles you have a dual cpu, your second thread will drastically slow down your main thread.

How fast can you upload the data to OpenGL? That is quite a bit of data to upload. Even in a convenient GL data format, using sub loads may be too slow on older cards. It might be faster on newer cards these days, but you tend to get noticeable performance hits when using sizes that large. Even .1 seconds to upload the imagery is a very very big performance hit when the rest of your app runs at 500fps and sudenly drops down to 10 fps.

In general, what I have settled on is to use a selecteable block size for imagery (usually 128 or 256) with a selectable compressor for creating your mip map imagery (similar to TIFF). Alternatively, you can use pre-existing imagery (which I also seamlessly support). There are quite a few, and each have their limitations. Tiled TIFF, MRSID and ECW come to mind. Look into GDAL which wraps these libraries (http://remotesensing.org/gdal/formats_list.html) and provides a nice way to make your program import many other formats besides your native one. Develop your streaming architecture so that the actual GL texture block can be selected regardless of your image block size. That way you can experiment for yourself and choose a good block size. 128 is usually faster for me, but 256 gives a better visual appearance (or in general higher block sizes).

This is quite simply a GIS problem. This is actually the easy part, the hard part would be supporting other features on that raster, and making it dynamic. Hope this helps, lata.

01-07-2004, 08:28 AM
Clipmapping uses a hardware per pixel selection of MIP LOD based on the scrolling torroidal region clip (hence CLIP mapping as a substitute for MIP mapping).

Tanner's software clip map is derived directly from the concepts in hardware clipmapping (he was the principal implementor of clipmapping at SGI), but his approach decouples the levels and uses independent vanilla tiled textures as a clip region with texture coordinates determining the scale of the clip region, and software based OpenGL state changes on scene geometry to select the LOD per primitive.

You may have opinions on patents, but Tanner isn't trying to claim anything in hardware clipmapping. He's as experienced and familiar with SGI clipmapping technology as anyone could be.

As for learning it from CLIP mapping, that is patented too although you can read and decide exactly what's claimed by each approach. Tanner is one of the inventors of SGI clipmapping:

U.S. Patent Number 5,760,783
http://patft.uspto.gov/netacgi/nph-Parse...RS=PN/5,760,783 (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,760,783.WKU.&OS=PN/5,760,783&RS=PN/5,760,783)

Strangely Microsoft has the exact same patent under a different filing and number filed almost 3 years later. Dunno why it should be different if SGI just sold it to them:

U.S. Patent Number 6,417,860
http://patft.uspto.gov/netacgi/nph-Parse...RS=PN/6,417,860 (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,417,860.WKU.&OS=PN/6,417,860&RS=PN/6,417,860)

[This message has been edited by dorbie (edited 01-07-2004).]

01-07-2004, 08:39 AM
I'm curious if anyone here has tried OpenSceneGraph's PagedLOD stuff.

There's not much documentation on it, but there are a few examples.

01-07-2004, 12:59 PM
Originally posted by arekkusu:
Limiting the discussion solely to updating edge strips of a 2d bitmap (windowing scroller) and shifting the virtual origin of the unchanged portion, how about this for starters: http://homepage.mac.com/arekkusu/GS/index.html#SMT

Yeah. I figured that was the part you were talking about. I think toroidal scrolling goes back further than 1985, but it's still clever, IMO.

Angus, yeah that's strange with the dup patents. The one I linked was just transferred to the current owners. But it may make it easier to find out just which patents got sold [out]. http://www.opengl.org/discussion_boards/ubb/smile.gif

(btw, I just edited the UBB URL tag (shortened the link text, not the link itself) so that it doesn't force this forum window to be 2 screens wide. You might want to do that too when you get a sec).

As for patents and "where" anyone learns anything, I don't think that makes a difference if the patent holder wants to act. I'm not a big fan of patents (not starting a thread, just clarifying), but the key thing to moving past them is coming up with improvements or alternate approaches. Doing the near-equivalent of clip mapping in plain OGL was a big improvement (e.g., if you don't have an infinite reality) over SGI's work.


[This message has been edited by Cyranose (edited 01-07-2004).]

01-07-2004, 01:14 PM
It must have been a screwup, AFAIK you don't refile when you aqcuire a patent. But then again, IANAL.

01-07-2004, 06:14 PM
I doubt that patent issues are of major interest for the original poster, this sounds more like a hobbyist or learning project than anything he actually wants to distribute (I might be wrong, of course).

And even if he plans to make it publicly available, we don't know where he lives. Several countries do not recognize software patents, which would make the whole point moot. I guess it's better to focus on the (very interesting) technical details instead of legal ones.

01-07-2004, 07:31 PM
Definitely, it's just in this case it's an interesting point curiosity for a few people.

Robert Osfield
01-11-2004, 06:14 AM
Originally posted by jlamanna:
I'm curious if anyone here has tried OpenSceneGraph's PagedLOD stuff.

There's not much documentation on it, but there are a few examples.

Implementation first, then documentation :-)

PagedLOD and the associated DatabasePager are still very much in development, with a number of improvements to both found the in the latest CVS of the OSG. The TerraPage plugin is now based on PagedLOD, and there a couple more examples, so I'd recomending having a look at that.

Relevant to the original question in this thread there is the osbluemarble example which slices up the Nasa blue marble data into a hierarchy of PagedLOD'd files which contain both geometry and texture. I have played with using larger texture and smaller number of LOD levels vs smaller texture but more LOD levels and have found that 256x256 texture results in the most solid framerates. 512x512 textures result in a greater numer of framedrops since its more likely that the download time pushes you over the edge of getting everything downloaded and drawn in each frame. So bigger is definately not better.

The number of texture binds really is not an issue with the smaller size of texture, lets face it doesn't take many 256x256 textures to fill the screen and this is around the number of textures you'll need to be bound for drawing the terrain for any one frame. Reusing texture objects is obviously a must.

The other item which I have found really important to getting solid framerate is use of compressed textures, it reduces bandwidth from disk to main memory, from main memory to graphics card, and then finally memory foot print down on the graphics card.


01-11-2004, 04:07 PM
It's not (just) state changes that are the performance concern with small textures, there are other nasty implications for bandwidth due to the lack of contiguous memory transfer. That includes disk i/o and downloads to graphics. On the other side of the problem larger textures, although they might give better theoretical throughput, tend increase the footprint of the moving window and increase the load and space used. Finding the sweetspot to maximize the rate at which the 'window' can move is the key to optimizing this. It is a moving target which will change as hardware evolves. FWIW - I wouldn't necessarily call 256x256 small, some solutions subload textures in sections down to 8 pixels.

Any successful paging mechanism will attempt to throttle the performance of texture loads. Especially in a MIP mapped scenario. If you consider the paging demands over time across multiple MIP LODS they are very inconsistent with instantaneous load doubling and quadrupling etc as tiles across multiple MIP LODs align. Even a single level has problematic instantaneous load.

So the absolutely key mechanism to implement for decent performance is load management over time.

[This message has been edited by dorbie (edited 01-11-2004).]

01-11-2004, 06:19 PM
About packing small textures into one large texture. Here is a link to a discussion that was about that.

I thought there was some good info there about the issue of having many small textures or packing them all or a lot of them into a larger one.


01-11-2004, 11:20 PM
That seems like a different subject to me.

Robert Osfield
01-12-2004, 02:53 AM
Originally posted by dorbie:
That seems like a different subject to me.

Seems like exact opposite subject to me http://www.opengl.org/discussion_boards/ubb/smile.gif