NCE2 Technology Development

Here we present technical details on some of our latest technologies developed for Notcom Racing within "Notcom Racing Engine 2".
These achievements will be employed in the game and will be fully available to developers at a later date.



-FDRI - Flexible Dynamic Range Imagery

-FDRI - Test 1: White Point 52.0

-FDRI - Test 2: White Point 324.0

-FDRI - Test 3: Cubic Environment Map

-FDRI - Natural Texture Compression (FNTC)

-FXTextures type 1 - Multiple channel texturing

-FXTextures type 2 - High-res material texturing

-FXTextures type 3 - FDRI Material Blending







FDRI - Flexible Dynamic Range Imagery


HDRI - High Dynamic Range Imagery developed by Paul Debevec gave an incredible boost in every field of computer graphics, from high-precision image processing to realtime 3D applications. Now that 3D boards support true floating point textures to be mainly used for gaming applications, a new range of problems and technical issues rises for games especially.
Just to cite a few:

- HDR 96bit/pixel float textures cannot be compressed at present times through hardware while common 24bit/pixel textures can benefit from a 6:1 DXT hardware compression ratio.

- As a consequence, it becomes quite impractical to have a full "HDR textured" game, as the VRAM needed would be very high

- RGBE8 textures require an exponential function and some more calculations in the fragment program in order to recover the original pixel value, generally resulting in poor performances.

See the Nvidia GeForce 6 Brochure: GeForce 6 Brochure

Quote:
"So, developers had to develop creative solutions to deliver these types of graphics—including using expensive conversions (such as RGBE) in the pixel shader; avoiding incompatible techniques that would have been desirable (such as dynamic lighting)"

We've done studies on HDRI since 1999, and we've now found an easy and practical solution to correctly represent HDR textures by using common 24bit/pixel textures and with extremely simple fragment programs. Our system, FDRI, allows to get a white point representation between 52.0 and 104.0 with an average error of 0.85% while saving most of the data required for true HDRI, resulting in a "natural compression" to which any other compression technique can be added (DXTC for instance).

While we can't discuss technical details at the moment, nor having a paper ready - on which we're working though, we can present our first results as we've recently implemented FDRI in "Notcom Engine v.2".

Here's a direct comparison between HDRShop, by Paul Debevec, and Notcom Engine v.2 on the same HDR source image.

Some data:

- HDR source image Float - 1024x1024x96 = 12.582 Mbytes
- FDRI - DXT1 compressed - 1024x1024x24 = 3.32 Mbytes

Original HDR high-resolution picture from SACHFORM TECHNOLOGY.
http://www.sachform.de/download.html

NCE2 - FDRI test:

- Textures have been mapped onto a sphere, to get a panoramic view
- OpenGL framework
- Nvidia CG vertex/fragment programs used (ps_2_0 - FP30)
- Trilinear filtering used
- Float calculations
- No AA
- No blur, glow, or "faking" shaders

Measured average accuracy of reconstructed FDRI:

R = 99.25% (error 0.75%)
G = 99.14% (error 0.86%)
B = 99.06% (error 0.94%)

Note: the declared error for the native RGBE8 file format is 1%

Click on the following thumbnails to get the full-res version:

HDRShop +1 Fstop
FDRI +1 Fstop
HDRShop 0 Fstop
FDRI 0 Fstop
HDRShop -1 Fstop
FDRI -1 Fstop
HDRShop -2 Fstop
FDRI -2 Fstop
HDRShop -3 Fstop
FDRI -3 Fstop
HDRShop -4 Fstop
FDRI -4 Fstop


NOTE: Brightness for FDRI images may not exactly match the HDRShop Exposure, as we don't have a "stepped-Fstop" control, but a floating point smooth control.


FDRI 0 Fstop - Wireframe



FDRI are flexible also because developers can easily decide the average error introduced on the image while increasing the maximum representable white point.
By taking, for instance, the average error to 1.58%, an FDRI texture can represent a white point of 324.0, which is more than 3 times the magnitude obtained with a 0.85% average error. While the error introduced by compression algorithms such as Jpeg or DXTC is generally visible - banding artifacts and "blockyness" - the error introduced with FDRI doesn't follow a specific pattern, but it's just the result of a smooth difference in pixel values compared to the original HDR image, thus being generally not visually recognizable. (in fact we can only measure it mathematically by comparing pixel values from the HDR source with the reconstructed FDRI texture)

Here's an example of FDRI with a maximum magnitude of 324.0, and no visible artifacts due to the increased error:

 

FDRI - WPoint 324.0
FDRI - WPoint 324.0
FDRI - WPoint 324.0
FDRI - WPoint 324.0
FDRI - WPoint 324.0
FDRI - WPoint 324.0

 

 

As a third test we've implemented an FDRI Cubic Environment Map, based on Paul Debevec's St.Peter's Basilica, featuring an extremely high white point (around 800.000). The following screenshots will demonstrate simple cubic env-mapping, env-mapping exposure change and FDRI linear interpolation with the env-map.


Reflection = 100%

 

FDRI Cubic Env-map
FDRI Cubic Env-map
FDRI Cubic Env-map
FDRI Cubic Env-map

 

Reflection = 100%

 

FDRI Cubic Env-map - FStop 0
FDRI Cubic Env-map - FStop -2

FDRI Cubic Env-map - FStop -3

 

Diffuse = 100% (Lightmap*Decal)
Reflection = 5%

 

FDRI Cubic Env-map
FDRI Cubic Env-map
FDRI Cubic Env-map
FDRI Cubic Env-map

 

>> More Screenshots

 




FDRI - Natural Texture Compression (FNTC)


Here we demonstrate how FDRI and FXTextures can simply be used to achieve natural texture compression on common 24bit textures. Our first tests involve high quality results, nearly lossless, while achieving a compression ratio of 2.5:1 - similar to high-quality jpeg compression but absolutely with no blocky effect or noticeable artifacts. In further tests we'll demonstrate higher compression ratios (between 5:1 and 6:1) and the resulting quality/error generated.

FNTC 2.5:1 Ratio ( Actual 3.36:1 )**

The following realtime test is based on 3 512x512 24bit textures with no DXTC compression.

- Uncompressed: 2.360 Mbytes
- FNTC: 0.934 Mbytes
- Ratio: 2.52:1
- 6 pixel shader instructions to decode all three textures
- No realtime codec algorithms

 

The first image on the left is a pretty desaturated type of texture, while in the middle we've got a real photograph.
The third texture is a smooth sky, where blockyness would be the main reason not to use DXTC on such a texture.

 

No Compression

Click here for BMP version (2.5 Mbytes)
FNTC - 2.5:1

Click here for BMP version (2.5 Mbytes)

 

The following picture shows how the error is distributed using FNTC.
It is also possible to see how the first texture performs extremely well showing almost no sign of error. The average RGB error for this test is 0.15%, which is the average error for high-quality FDRI textures.

Please note that pixel values have been increased 8 times in order to be visible in a 0-255 range.

 

Image Error

Click here for BMP version (2.5 Mbytes)

 

The following picture instead shows a magnified comparison between uncompressed texture, FNTC 2.5:1 and DXT1 format.
Despite the high compression ratio of 6:1, DXTC might be in some cases unusable due to poor and not-scalable texture quality, thus in a way bringing no compression at all, simply because in real life one might go for uncompressed textures rather than having poor quality. FNTC offers half the ratio, in this first configuration, but tens times better quality than DXT1.

 

FNTC - DXT1 Comparison

Click here for BMP version (2.5 Mbytes)

 

FNTC 4.4:1 Ratio ( Actual 5.81:1 )**

The following realtime test is based on 4 512x512 24bit textures with no DXTC compression.

- Uncompressed: 3.146 Mbytes
- FNTC: 0.720 Mbytes
- Ratio: 4.4:1
- 6 pixel shader instructions to decode all four textures
- No realtime codec algorithms

 

With higher compression ratios we use an hybrid bit-depth system. A custom palettizing method is also applied to get the best out of lower bit-depths.

 

No Compression

FNTC - 4.4:1

 

The following picture shows how the error is distributed using FNTC at higher compression ratios.
The first texture still performs better than the others. The average RGB error for this test goes from 0.19% to 0.73%. Practically, depending on the type of texture, higher ratios can perform as good as the 2.5:1 ratio or as bad as 5 times worse. Obviously, as it happens with other compression systems, low-saturation, low-frequency textures performs much better in terms of quality.

Please note that pixel values have been increased 4 times in order to be visible in a 0-255 range.

 

Image Error





** Important note:

To the best of our knowledge, since Nvidia's NV20 and Ati's Radeon DDR if not even before, the support for R8G8B8 textures have been discontinued. The only available format for full integer precision textures is A8R8G8B8 (or equivalent, such as X8L8V8U8) - 32bit.
Our ratio tests considered 24-bit uncompressed textures for the sake of "direct comparison", but the practical, real-life ratios and comparisons should be run on 32bit textures instead.

Re-calculated ratios (32bit comparison).

2,5:1 Ratio:

Uncompressed (3x512x512 32bit) -> 3.145 Mbytes
FNTC (3 FXTextures) -> 0.934 Mbytes

Actual Ratio: 3.36 : 1

4,4:1 Ratio:

Uncompressed (4x512x512 32bit) -> 4.194 Mbytes
FNTC (4 FXTextures) -> 0.720 Mbytes

Actual Ratio: 5.81 : 1

 

 

For any enquiry on technical research and NCE2, please contact: info@forwardgames.com

 


 



FXTextures Type 1 - Multiple channel texturing


As a direct consequence of the basic techniques involved in FDRI, a simple yet new approach to texturing pre-processing and usage comes into play: FXTexturing.
FXTextures (standard 24bit/pixel) make possible to physically save the number of textures used in modern engines, especially if many "material channels" are used, such as specularity, transparency, self-illumination, reflectivity etc.
FXTextures Type 1, where the type describes their application field, are applicable to materials with 5 to 8 textured channels - when basic FDRI is used (white point 2.0).
The natural advantages of using FXTextures are:

- Save up to 2/3 of the required textures for each material

- Save the number of texture lookups in the fragment program by the same amount

- Practically no overhead in fragment programs compared to standard textures usage.

- Basic FDRI 2.0 white point for free.

FXTextures do not necessarily require pixel shaders, and thus can also be used with fixed rendering pipelines.
Typical scenarios where FXTextures Type 1 in modern engines are:

5 Textured Channels:

- Color (aka Diffuse)
- Lightmaps
- Specularity (aka Gloss map)
- Self Illumination (aka Luminosity)
- Normal Map (normally not involved in FXTexturing)

8 Textured Channels
Previous 5 Channels, plus:

- Transparency (aka Alpha map)
- Reflectivity
- Height Map (for parallax bump mapping)

Five and eight textured channels are achievable respectively using three and four FXTextures Type 1.
It is possible to pick'n'mix channels in any fashion for each material.

Here we present our first pre-production results within NCE2 on a 5 Channels Material:


 

FXTextures 5 Channels Result
600x600 - 75 Kbytes


 

FXTextures 5 Channels Composition
1200x800 - 160 Kbytes



More infos and screenshots soon to be released.

For any enquiry on technical research and NCE2, please contact: info@forwardgames.com


 


 



FXTextures type 2 - High-res material texturing


FXTextures type 2 are the second application field for the generic FXTextures basic concept.
In this case FXTextures are mainly used for normally expensive high-res texturing applications, such as SkyBoxes or SkyHemispheres for instance.
If a SkyBox is to be textured with a 1024x1024 texture for each face, normally and obviously it requires 6x1024x1024 textures, which uncompressed for quality issues as usually happens with skyes in games, it makes 18.87 Mbytes of textures.
Using FXTextures type 2, we're able to get exactly the same resolution using just 3 FXTextures (with a partial DXT1 compression) for the entire SkyBox with no percievable quality loss, and totally allocating just 6.46 Mbytes - 12.41 Mbytes saved.

This of course doesn't apply just to SkyBoxes, but to all those materials that require high-resolution texturing and it's applicable to an entire scene with consequently high memory savings.
Since FXTextures can be treated as common 24bit textures, they allow for DXT3 compression and explicit alpha, just in case you need clouds to be separated from a gradient background using alpha channel, for instance.

The following screenshots illustrate the SkyBox example we just discussed above.
More infos and screenshots soon to be released.


NCE2 - FXTextures type 2 test:

- SkyBox generated in Lightwave3D using volumetric clouds
- Original textures: (6x)1024x1024 96bit/pixel - HDRI
- Using common textures: (6x)1024x1024 24bit/pixel - 18.87 Mbytes
- FXTextures: same nominal resolution (6x)1024x1024 - 6.46 Mbytes
- Basic FDRI: white point 2.0


Click on thumbnails to get the full-res version:


FXTextured SkyBox 0 Fstop
1024x748 - 163 Kbytes
FXTextured SkyBox -1 Fstop
1024x748 - 163 Kbytes
FXTextured SkyBox 0 Fstop
1024x748 - 163 Kbytes
FXTextured SkyBox 0 Fstop
1024x748 - 163 Kbytes


NOTE: You can take global brightness further up or down than FStop 0 or -1, but having a much more limited white point than pure FDRI, you can't expect similar results. You can still appreciate visual benefits compared to common textures though, as show in the first two screenshots.

 

For any enquiry on technical research and NCE2, please contact: info@forwardgames.com


 

-FDRI - Flexible Dynamic Range Imagery

-FXTextures type 1 - Multiple channel texturing

-FXTextures type 2 - High-res material texturing