Img Tech Patent

[pmac]

Some snippets from the patent:

We have appreciated that it is possible to implement, in hardware, an additional set of functions that provides an efficient means for the direct transformation of a height map into filtered perturbed surface normals that have C1 continuity. These normals can subsequently be used for various rendering purposes such as per-pixel lighting. In particular, we have devised a method which, by re-using colour texture filtering hardware that is ubiquitous in today's graphics systems in a new way with the addition of some small processing units, achieves the functions needed to compute the normal from a smooth surface controlled by a set of heights. Thus the data can substantially be generated in real time.
The filtered surface normals are created 'on demand' and are not stored. This provides the joint benefits of reducing the amount of texture data and bandwidth needed for bump mapping, as well as overcoming some of the issues with the filtering of normal maps. This feature is also important when using dynamic height maps in real-time rendering since a pre-processing stage may be prohibitive.
Embodiments of the invention keep the advantages of computing bump map-based shading in local tangent space as described by Peercy et al,(although it is not restricted to do so), with the convenience of using Blinn's height map but with the option of using a function with higher continuity.

In another embodiment, colour textures are also filtered using bi-quadratic B-splines, either through the addition of bilinear filtering units, or by iterations through the colour channels, whereby the individual weights to the bilinear units are adjusted according to the previously described embodiments.

[/url]http://l2.espacenet.com/espacenet/viewer?PN=GB2400778&CY=gb&LG=en&DB=EPD

 

[Simon F]

Haven't you got anything better to do than trawl the patent database?

 

[KimB]

It basically sounds like a way to use a heightmap instead of a normal map for bump mapping. I don't think it's that great, though, as you can anti-alias normal maps to some reasonable approximation without much extra calculation (filtered heighmaps would lose some of the normal data).

 

[3dcgi]

It basically sounds like a way to use a heightmap instead of a normal map for bump mapping.

To me it sounds like it's creating a normal map from a heightmap and using the normal map. Basically a form of compression. It seems to be for smooth surfaces though so it might not be a general compression mechanism.

 

[Simon F]

To me it sounds like it's creating a normal map from a heightmap and using the normal map.

Yes, except that the normal map never actually exists - the normals are computed on-the-fly.

Basically a form of compression.

That is an intention of the patent.

It seems to be for smooth surfaces though so it might not be a general compression mechanism.

It's meant as a general purpose bump mapping technique - not just for smooth surfaces.

 

[Ailuros]

Haven't you got anything better to do than trawl the patent database?

Pfffff old news by now

 

[Ailuros]

***edit: double post

 

[KimB]

It's meant as a general purpose bump mapping technique - not just for smooth surfaces.

Sure, but I don't think it'd work as well as normal mapping for more irregular surfaces. That is to say, as I stated, I don't think it'd be as easy to antialias.

 

[3dcgi]

I don't have time, but someone could test this if they wished. While it might not work exactly the same Nvidia has a photoshop plugin that creates a normal map from a height map.
http://developer.nvidia.com/object/nv_texture_tools.html

Also, does anyone know the purpose of the .dds format? Is it for compressed textures?

 

[AndrewM]

Also, does anyone know the purpose of the .dds format? Is it for compressed textures?

It's a direct draw surface format. Used for storing DXTn textures. Most games using pre-compressed textures use it.

 

[Simon F]

Sure, but I don't think it'd work as well as normal mapping for more irregular surfaces. That is to say, as I stated, I don't think it'd be as easy to antialias.

OK I'll bite (though I'll probably regret it). Why do you think the antialiasing will be harder?

Are you talking of supersampling AA or of the issues of texture filtering? If it's the former, then there is no technical difference to make the patent method harder.

If you are referring to texture filtering then I don't understand your view at all. When you use normal maps, then the normals are (typically) (bi|tri)linearly filtered and then the lighting is applied. This means that on a grid aligned with texel centres, there are discontinuities in the first derivative. I can't see how that could be considered better.

 

[KimB]

OK I'll bite (though I'll probably regret it). Why do you think the antialiasing will be harder?

Well, it's simply because as you filter a height map, you lose all information about any underlying irregularity. There is a technique to use normal texture filtering on normal maps, then using the length of the final vector to extract information about irregularity.

Specifically, if the filtered normal map has a length close to one, that means there wasn't much change in the direction of the normal over the surface. If the filtered normal map is very short, it means that the normal changed significantly, allowing a reasonable approximation to proper MIP mapping for bump mapped surfaces.

Here's a paper on the technique:
http://developer.nvidia.com/object/mipmapping_normal_maps.html

 

[Simon F]

OK I'll bite (though I'll probably regret it). Why do you think the antialiasing will be harder?

Well, it's simply because as you filter a height map, you lose all information about any underlying irregularity. There is a technique to use normal texture filtering on normal maps, then using the length of the final vector to extract information about irregularity.

So you were talking about the overall MIP mapping issue and thus are concerned about having a "roughness/glossiness" parameter? I personally feel that should be encoded with another channel anyway because the whole thing is highly non-linear.

 

[KimB]

So you were talking about the overall MIP mapping issue and thus are concerned about having a "roughness/glossiness" parameter? I personally feel that should be encoded with another channel anyway because the whole thing is highly non-linear.

The way of doing it I posted, though, varies appropriately with the texel size/pixel size ratio. How would you do that by encoding it in another channel?

 

[Simon F]

The way of doing it I posted, though, varies appropriately with the texel size/pixel size ratio.

No, it doesn't. I'll leave you to think about it.

 

[KimB]

No, it doesn't. I'll leave you to think about it.

I'm not a mind reader and have no idea what situation you're talking about where it doesn't.