Lots of small textures or fewer large textures?

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

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

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

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.

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].

(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.

Avi

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

It must have been a screwup, AFAIK you don’t refile when you aqcuire a patent. But then again, IANAL.

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.

Definitely, it’s just in this case it’s an interesting point curiosity for a few people.

Originally posted by jlamanna:
[b]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.[/b]

Implementation first, then documentation :slight_smile:

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.

Robert.

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).]

About packing small textures into one large texture. Here is a link to a discussion that was about that.
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/010037.html

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.

-SirKnight

That seems like a different subject to me.

Originally posted by dorbie:
That seems like a different subject to me.

Seems like exact opposite subject to me