Michael T. Jones (mtj++at++intrinsic.com)
Sat, 12 Jun 1999 10:09:05 -0700
Yes. Due to texture filtering based on the dynamic relationship
between screen pixels and earth texels, varying information
from neighbor tiles is needed for proper filtering.
>Now, I've read a little about texture borders which may help fix this
>but they seem not to be supported on my platform (Onyx2 iR)...
Impressive! It had seemed as though SGI's clever "texture border"
scheme was forgotten once explicit support for it was dropped
from the hardware. The patent explains the technique very well.
Visit the IBM patent server (http://www.patents.ibm.com) and
search for:
US5230039: Texture range controls for improved texture
mapping. Mark S. Grossman, Kurt B. Akeley, and Robert
A. Drebin. SGI. (Read the whole thing, but study Page 14,
Col 12, Line 63 and the following paragraphs closely. What
is described applies to MIP-maps as well, if you use the logic
for each map level separately. This logic is what is missing
in your current implementation running on recent hardware.
US5815157: Method and apparatus for texture border
address mapping in rectangular coordinates. Andrew D.
Bowen. IBM. An interesting implementation.
>...So,
>
>- Is this true? Can't I use texture borders? If so what is their
>purpose? Will they seriously affect performance and texture memory
>usage?
You can implement "texture borders" on any texture-capable
system with full performance. The only problem is that without
explicit hardware support you will pay a penalty of 4x texture
memory consumption. If you read the first patent, you will
understand easily so I'm not going to explain the "why" here;
what follows is just an implementation outline.
Step 1:
To implement a 2^n by 2^n texture with texture borders on
a machine lacking this feature, you must fill the center of a
2^(n+1) by 2^(n+1) texture with your 2^n by 2^n texture.
Now you're consuming 4x the (scarce) memory but only using
the middle "x" amount of it.
Step 2:
Then you must change all of your texture coordinates from the
0..1 space to a new 0.25 .. 0.75 space: algebra suggests that
for any texture coordinate "t" you want ".5*t + 0.25" which is
something that you can do explicitly in the database or on the
go using the texture matrix.
Question: The original texture coordinates were in the range of
0..1 since geometry had been clipped to match the 2^n squared
texture tiles, so now coordinates range from 0.25 to 0.75, which
is just where our original texels are sitting within the larger map.
At this point, will rendering result in exactly the same picture as
before?
Answer: No, the picture will not be the same when we're at the
"edge" of the now centered texture map because the hardware
will try to access one more pixel beyond our edge as part of the
bi-linear (or tri-linear) filtering process. This is essentially the
problem you're already having and the reason you use texture
clamping. Is it also a problem in our new approach?
Step 3:
No. It's the solution! These pixels are the border (just outside
the edge) of the original 2^n squared map, and now we have
more than enough room to store them. ;-) They should come
from the eight texture tiles which surround this one. Example:
the one pixel high by 2^n row just above our 2^n square
should come from the texture tile "north" of us -- it's that tile's
bottom row of texels. Likewise for south, east, and west. What
about our north-west neighbor? Well we need just one texel
from him, his south-east texel, which we put in our 1x1
north-west border corner. The same applies to the other three
corners. Now we are using the 2^n by 2^n middle, two 2^n
by 1 rows, two 1 by 2^n columns, and four 1x1 corners of the
larger 2^(n+1) by 2^(n+1) texture map. This is exactly the
data that Andrew Bowen is storing efficiently off to the side in
the IBM patent.
Look at that. An important graphics feature previous believed
to be hardware-dependent can be implemented on any type
of texture-capable machine by inserting a little software magic
between the hardware and the application. [Visualize Michael
with hands on hips beaming with pride, like the Pillsbury Dough
Boy without the giggle.] Now, what are the pros and cons of
this approach (more specifically, is this the feature that you
really wanted in the first place), and is any general theme
suggested by this example?
Pro:
We have implemented pixel-exact tile matching that handles
linear (bi-, tri-, ...) texture filtering perfectly. (What would we
do if we used higher-order filtering? See. It extends perfectly
up to arbitrary-sized filters.) It works on any texture system.
It runs at full speed. It's conceptually simple. (Though I may
have explained it poorly. The next few day's email "letter
bombs" from Angus will tell.)
Con:
It uses 4x the space, and "wastes" almost 3x of this scarce
resource. (Makes you wish for the special hardware described
in the SGI and IBM patents that can store the extra few
texels off to the side somewhere.) You have to access the
8-connected neighbor tiles to fetch the border data either
during paging or at database construction time. And worst
of all, you *still* have to chop up the terrain based on the
edges of textures. This last is the problem for me. I hate it.
>- Is there any other way I can improve this problem?
Yes. Use Clip-Mapping, which lets you texture the earth with
a single 2^32 by 2^32 texture map good for centimeter-scale
texels of planetary extent. It runs at full speed. It has perfect
texture filtering. It features incremental paging that can be
tuned continuously (more or less milliseconds per frame) to
implement performance/resolution trade-offs. SGI has cool tools
for generating the tile data format used to store textures. Best
of all, it's built into both IRIS Performer and your Onyx2
InfiniteReality (and paging is very fast on that machine.)
It has a patent at the IBM web site too. Look for
US5760783: Method and system for providing texture
using a selected portion of a texture map. Christopher
Joseph Migdal, James L. Foran, Michael Timothy Jones,
and Christopher Clark Tanner. SGI. (Everything is
clear just by looking at the diagram on page 1.)
My love of clip-mapping has nothing to do with being a co-inventor.
It's just the opposite: I love the concept of a seamless universal texture
so much (and I see *so* many applications for it ;-) that it drove me
to think of a hardware/software implementation so that people could
program that way.
We have a demo on our web-site (http://www.intrinsic.com) for
download so users can run InfiniteReality clip-mapping binaries on
their O2 computers. (Something we did quickly last year) The
implementation is not related to any SGI work, the O2, Performer's
clip-map feature, or the texture-border scheme described above. We
just wanted people to get a taste of using all graphics features on all
graphics platforms from a single development environment.
If you look on SGI's Visual PC demo CD (sales office, trade show,
etc.), you'll see our "Earth View," a recent demo of NT-based 320
and 540 VW's doing 60 Hz universal texture from the same clip-map
databases used on InfiniteReality. This same demo compiles and runs
in our environment on the InfiniteReality as well -- if you go to the
SGI command tour you can see an IR and 320 doing global terrain
visualization running from the same data, at similar resolutions and
frame rates, from the same code -- slaved to fly from either the 320
or the InfiniteReality using intrinsic platform support for distributed
applications. Of course, the InfiniteReality clip-map hardware has
advantages over current NT workstations, PC's, consoles, etc., but
it's exciting to make the best techniques in graphics work across a
spectrum of hardware differing in price by a factor of 10,000.
>Any help wouild be appreciated,
Summary: read Mark, Kurt, and Bob's patent to understand my
"damn-the-torpedoes I want texture borders" scheme and check out
clip-mapping in the IRIS Performer man pages and sample programs
to see if it meets the needs of your situation. If so, you'll be a happier
camper. Chris Tanner, Chris Migdal, and I wrote a paper in last
year's SIGGRAPH proceedings explaining clip-mapping in patient
detail if you want more than the man pages.
Many developers have told me they were put off of clip-mapping by
the fear that their data and applications would not be portable from
the IR to other SGI graphics hardware (as in, "I have to go to the
lab to test my code") or to interesting hardware from other companies.
Our demos should be an assurance that using the best methods of
graphics need not limit application performance, portability, or the
ability to share data between wildly different machines (as in the
"Onyx2 InfiniteReality / IRIX / MIPS / Big-Endian" beside "320VW
/ NT / Intel / Little-Endian" inter-operability demonstration made by
Intrinsic Graphics' 60Hz EarthView universal texture program.)
Hope this helps,
Michael "Texture-the-globe-seamlessly" Jones
----------
Michael T. Jones - <mailto:mtj++at++intrinsic.com>mtj++at++intrinsic.com -
<http://www.intrinsic.com/>Intrinsic Graphics Inc. - (408) 507-8160
A frog in a well says "The sky is as big as the mouth of my well"
At 12:30 PM 6/11/99 +0200, Simon Mills wrote:
Hi,
I'm trying to make a spherical Earth model which is split into
tiles,
each one being textured with a seperate texture. The trouble is I'm
seeing disturbing discontinuities in the texture across tile
boundaries.
This is due to texture filtering missing the texels in the adjacent
tile
for the edge texels.
Yes. Due to texture filtering based on the dynamic relationship
between screen pixels and earth texels, varying information
from neighbor tiles is needed for proper filtering.
Now, I've read a little about texture borders
which may help fix this
but they seem not to be supported on my platform (Onyx2
iR)...
Impressive! It had seemed as though SGI's clever "texture
border"
scheme was forgotten once explicit support for it was dropped
from the hardware. The patent explains the technique very well.
Visit the IBM patent server
(http://www.patents.ibm.com)
and
search for:
...So,
- Is this true? Can't I use texture borders? If so what is their
purpose? Will they seriously affect performance and texture memory
usage?
You can implement "texture borders" on any texture-capable
system with full performance. The only problem is that without
explicit hardware support you will pay a penalty of 4x texture
memory consumption. If you read the first patent, you will
understand easily so I'm not going to explain the "why"
here;
what follows is just an implementation outline.
Step 1:
To implement a 2^n by 2^n texture with texture borders on
a machine lacking this feature, you must fill the center of a
2^(n+1) by 2^(n+1) texture with your 2^n by 2^n texture.
Now you're consuming 4x the (scarce) memory but only using
the middle "x" amount of it.
Step 2:
Then you must change all of your texture coordinates from the
0..1 space to a new 0.25 .. 0.75 space: algebra suggests that
for any texture coordinate "t" you want ".5*t + 0.25"
which is
something that you can do explicitly in the database or on the
go using the texture matrix.
Question: The original texture coordinates were in the range of
0..1 since geometry had been clipped to match the 2^n squared
texture tiles, so now coordinates range from 0.25 to 0.75, which
is just where our original texels are sitting within the larger map.
At this point, will rendering result in exactly the same picture as
before?
Answer: No, the picture will not be the same when we're at the
"edge" of the now centered texture map because the
hardware
will try to access one more pixel beyond our edge as part of the
bi-linear (or tri-linear) filtering process. This is essentially
the
problem you're already having and the reason you use texture
clamping. Is it also a problem in our new approach?
Step 3:
No. It's the solution! These pixels are the border (just outside
the edge) of the original 2^n squared map, and now we have
more than enough room to store them. ;-) They should come
from the eight texture tiles which surround this one. Example:
the one pixel high by 2^n row just above our 2^n square
should come from the texture tile "north" of us -- it's that
tile's
bottom row of texels. Likewise for south, east, and west. What
about our north-west neighbor? Well we need just one texel
from him, his south-east texel, which we put in our 1x1
north-west border corner. The same applies to the other three
corners. Now we are using the 2^n by 2^n middle, two 2^n
by 1 rows, two 1 by 2^n columns, and four 1x1 corners of the
larger 2^(n+1) by 2^(n+1) texture map. This is exactly the
data that Andrew Bowen is storing efficiently off to the side in
the IBM patent.
Look at that. An important graphics feature previous believed
to be hardware-dependent can be implemented on any type
of texture-capable machine by inserting a little software magic
between the hardware and the application. [Visualize Michael
with hands on hips beaming with pride, like the Pillsbury Dough
Boy without the giggle.] Now, what are the pros and cons of
this approach (more specifically, is this the feature that you
really wanted in the first place), and is any general theme
suggested by this example?
Pro:
We have implemented pixel-exact tile matching that handles
linear (bi-, tri-, ...) texture filtering perfectly. (What would we
do if we used higher-order filtering? See. It extends perfectly
up to arbitrary-sized filters.) It works on any texture system.
It runs at full speed. It's conceptually simple. (Though I may
have explained it poorly. The next few day's email "letter
bombs" from Angus will tell.)
Con:
It uses 4x the space, and "wastes" almost 3x of this
scarce
resource. (Makes you wish for the special hardware described
in the SGI and IBM patents that can store the extra few
texels off to the side somewhere.) You have to access the
8-connected neighbor tiles to fetch the border data either
during paging or at database construction time. And worst
of all, you *still* have to chop up the terrain based on the
edges of textures. This last is the problem for me. I hate it.
- Is there any other way I can improve this
problem?
Yes. Use Clip-Mapping, which lets you texture the earth with
a single 2^32 by 2^32 texture map good for centimeter-scale
texels of planetary extent. It runs at full speed. It has perfect
texture filtering. It features incremental paging that can be
tuned continuously (more or less milliseconds per frame) to
implement performance/resolution trade-offs. SGI has cool tools
for generating the tile data format used to store textures. Best
of all, it's built into both IRIS Performer and your Onyx2
InfiniteReality (and paging is very fast on that machine.)
It has a patent at the IBM web site too. Look for
My love of clip-mapping has nothing to do with being a co-inventor.
It's just the opposite: I love the concept of a seamless universal
texture
so much (and I see *so* many applications for it ;-) that it drove
me
to think of a hardware/software implementation so that people could
program that way.
We have a demo on our web-site
(http://www.intrinsic.com)
for
download so users can run InfiniteReality clip-mapping binaries on
their O2 computers. (Something we did quickly last year) The
implementation is not related to any SGI work, the O2, Performer's
clip-map feature, or the texture-border scheme described above. We
just wanted people to get a taste of using all graphics features on all
graphics platforms from a single development environment.
If you look on SGI's Visual PC demo CD (sales office, trade show,
etc.), you'll see our "Earth View," a recent demo of NT-based
320
and 540 VW's doing 60 Hz universal texture from the same clip-map
databases used on InfiniteReality. This same demo compiles and runs
in our environment on the InfiniteReality as well -- if you go to
the
SGI command tour you can see an IR and 320 doing global terrain
visualization running from the same data, at similar resolutions
and
frame rates, from the same code -- slaved to fly from either the 320
or the InfiniteReality using intrinsic platform support for
distributed
applications. Of course, the InfiniteReality clip-map hardware has
advantages over current NT workstations, PC's, consoles, etc., but
it's exciting to make the best techniques in graphics work across a
spectrum of hardware differing in price by a factor of 10,000.
Any help wouild be
appreciated,
Summary: read Mark, Kurt, and Bob's patent to understand my
"damn-the-torpedoes I want texture borders" scheme and check
out
clip-mapping in the IRIS Performer man pages and sample programs
to see if it meets the needs of your situation. If so, you'll be a
happier
camper. Chris Tanner, Chris Migdal, and I wrote a paper in last
year's SIGGRAPH proceedings explaining clip-mapping in patient
detail if you want more than the man pages.
Many developers have told me they were put off of clip-mapping by
the fear that their data and applications would not be portable from
the IR to other SGI graphics hardware (as in, "I have to go to the
lab to test my code") or to interesting hardware from other
companies.
Our demos should be an assurance that using the best methods of
graphics need not limit application performance, portability, or the
ability to share data between wildly different machines (as in the
"Onyx2 InfiniteReality / IRIX / MIPS / Big-Endian" beside
"320VW
/ NT / Intel / Little-Endian" inter-operability demonstration made
by
Intrinsic Graphics' 60Hz EarthView universal texture program.)
Hope this helps,
Michael "Texture-the-globe-seamlessly" Jones
This archive was generated by hypermail 2.0b2 on Sat Jun 12 1999 - 10:06:56 PDT