Developer Newsletter: Issue #9

In this issue:

• Cg Compiler Official Release Now Available
• DirectX 9.0 Is Shipping
• Dawn to Dusk Developer Conference
• NVIDIA Supports ILM's OpenEXR Standard
• GDC 2003 Talks
• Cg Plug-in for Maya 4.5 Now Available
• "The Cg Tutorial" Book Available in March
• Cg Toolkit for Linux Now Available
• Coding Tip
• Send Us Your Comments!

Cg Compiler Official Release Now Available

Available now, the first official non-beta release of the NVIDIA Cg Compiler coincides with the release of DirectX 9.0 and the recent ratification of the OpenGL ARB fragment program extension. Fully leveraging the programmability of the GeForce FX GPU in both APIs, the compiler now adds further optimization and cross-platform capability for developers creating advanced visual effects for today's programmable GPUs from NVIDIA and other vendors. The compiler now supports 14 different profiles, allowing developers to target a wide variety of platforms and APIs.

By incorporating feedback from developers, following the beta release last June, and working closely with Microsoft's DirectX HLSL development team, the compiler has made considerable advances to aid the creation of cinematic-caliber shader effects.

Fully compatible with HLSL, and providing a suite of complementary tools, including plug-ins for artists (Maya 4.5, 3ds max 5, XSI 3.0), DirectX and OpenGL runtimes, comprehensive documentation and hundreds of shader examples, the latest NVIDIA Cg Toolkit is designed to be your one-stop solution for shader development. Included in the toolkit:

- Cg Compiler Release 1.0

- Enhanced Cg Runtime Libraries

- Cg Browser 5.0

- Updated documentation for all components

DirectX 9.0 Is Shipping

In December 2002, Microsoft released DirectX 9.0, upgrading the popular graphics API to support the functionality provided by the latest graphics hardware. DirectX 9.0 also includes a high level programming language, called HLSL (for "High-Level Shader Language"), that is syntactically equivalent to Cg. This now gives developers a wide range of tools to work with from Microsoft and NVIDIA when developing high level shaders.

Dawn to Dusk Developer Conference

In London on February 11-12, we'll be holding our Dawn to Dusk event, which will give developers a chance to learn more about taking full advantage of the GeForce FX, Cg, and CgFX. The event features many opportunities for developers, including:

* Main Stage – The latest in 3D real-time graphics technologies, including the GeForce FX architecture, how to incorporate Cg into your engine and tools pipeline, and new DirectX® 9.0 and OpenGL features.

* Second Stage – Our artists show you how to make the best use of our tools and share their experiences in the film industry to enable the next level of effects and model complexity. The second day, guests from the DCC industry will share their latest tools and applications, including the latest real-time effects in Alias|Wavefront's Maya.

* Chillout booths – One-on-one discussions with our tools experts, technical artists, and guest speakers.

* GeForce FX Plugfest – Register for an hour of individual time with our engineers to run your latest code on our latest hardware. Test for compatibility, share your ideas and problems, and get performance tips. Bring your code on a CD to install it on our GeForce FX-based machines.

* Business-to-Business area – Where OEMs and publishers can see the latest games.

* Speakers and specialists from Europe and the US – Leading companies present their tools and applications, and share their experiences with the latest technologies.

* Evening event – Beware the creatures of the night.

* Free GeForce FX board per order - Each order will qualify for an NVIDIA GeForce FX board (note, an Economy Twin counts as only 1 order).

NVIDIA Supports ILM's OpenEXR Standard

A cornerstone of NVIDIA's effort in film production is to work with industry leaders such as Industrial Light & Magic to develop effective standards that will ensure continued innovation in the field. One of our most recent initiatives has been to collaborate with ILM on the OpenEXR specification (which was released today to the open-source community) to ensure that it would be compatible with NVIDIA's Quadro FX and GeForce FX GPUs. OpenEXR is a high-precision, 16-bit, floating-point file format with much greater dynamic range than existing 8- and 10-bit file formats. Its lossless data compression achieves compression ratios of 2:1 for scanned film images. The format is currently used in production on many high-profile films implementing HDR (high dynamic range) visual effects, such as Harry Potter and the Sorcerer's Stone, Men in Black II, Gangs of New York, and Signs.

GDC 2003 Talks

NVIDIA will be participating in a variety of talks at the Game Developer's Conference in March 2003. Presentations include:

- Advanced Visual Effects with Direct3D (Full-Day Tutorial) [10:00 AM - Tuesday, March 4]

- Advanced OpenGL Game Programming (Full-Day Tutorial) [10:00 AM - Wednesday, March 5]

- All You Can Eat Polygons: Without the Fat [9:00 AM - Friday, March 7]

- Programming the GPU using Cg [10:30 AM - Friday, March 7]

- From Gaffer to Game Engine: Cinematic Methods & Real Time [12:00 PM - Friday, March 7]

- Graphics Pipeline Performance [3:00 PM - Friday, March 7]

- Ogres & Fairies: Secrets of the NVIDIA Demo Team [4:30 PM - Friday, March 7]

- Hardware Shaders for the Artist [Time and date to be determined]

- Optimized Stenciled Shadow Volumes [Time and date to be determined]

- Simulation and Animation with Hardware-Accelerated Procedural Textures [Time and date to be determined]

Cg Plug-in for Maya 4.5 Now Available

NVIDIA and Alias|Wavefront recently announced the availability of a Cg plug-in that integrates advanced real-time shaders into Maya 4.5. First shown at SIGGRAPH in July 2002, NVIDIA co-developed the Maya Cg plug-in for Windows with Alias|Wavefront to allow Maya 4.5 users to take shaders created for both OpenGL and DirectX-based platforms, such as PCs or Microsoft Xbox, and view them in Maya's OpenGL viewport. The cross-API capability of the Cg language specification is a breakthrough for development teams targeting content creation for multiple platforms by enabling simultaneous work in a WYSIWYG manner in OpenGL applications, while delivering content for DirectX platforms. The Maya Cg Plug-in supports the CgFX file format (.fx) and automatically provides intuitive interface controls and semantics to users and developers alike for editing shader effects in real-time. Since the CgFX format also supports both DirectX and OpenGL, developers may encapsulate a series of fallback techniques for rendering any effect. CgFX files are text-based and describe the complete render state for a particular effect -- multiple passes, texture states, and any number of individual vertex and pixel shaders may be defined to create a complete appearance or effect.

"The Cg Tutorial" Book Available in March

The Cg Tutorial, published by Addison-Wesley, will be available at GDC 2003. The book takes a tutorial-based approach to learning Cg, explaining how to implement both basic and advanced techniques for today’s programmable GPU architectures. In addition to explaining the Cg code for each technique, the book also covers the underlying theory, making it an excellent way to learn about both 3D graphics and shading with a high-level language.

Major topics covered include:

* 3D transformations

* Per-vertex and per-pixel lighting

* Skinning and key-frame interpolation

* Environment mapping

* Bump-mapping

* Fog

* Performance optimization

* Projective Texturing

* Cartoon Shading

* Compositing

Cg Toolkit for Linux Now Available

Coding Tip

This issue's coding tip is more of an informational tip. Because storing normal maps is an issue that any developer will encounter when implementing per-pixel lighting, we thought it would be useful to briefly survey model-space normal maps and tangent-space normal maps, as well as some of the formats available for storing them.

Per-pixel lighting computes the lighting equation individually for each pixel. Each pixel therefore needs access to its individual inputs for the lighting equation. In particular, per-pixel surface normals are needed, which are stored in textures.

When storing normals in a texture you can choose between several texture formats. For example, you can use the red, green, and blue channels of a R8G8B8A8 format to store the three components of a normal, or you can use the specialized HILO formats. HILO8 requires only 16 bits of storage per normal because it stores only the x and y components of each normal, in 8 bit precision. The GPU computes the z component on the fly--since a normal is of length one, z = sqrt(1 - x^2 - y^2). Similarly, HILO16 requires only 32 bits of storage per normal. It stores the x and y components of each normal with 16 bit precision and computes the z component on the fly. Yet another alternative is to use a format like R5G6B5, which uses 5 bits for red, 6 bits for green, and 5 bits for blue, to conserve storage.

In addition to choosing a storage format for the normal, you also have a choice of which coordinate system to store the normal in. The choice of coordinate system influences how efficiently and how accurately you can compute the lighting equation. Obvious choices are tangent space and model space.

Tangent-space normals use the coordinate system of the model's surface. It implies that the z-component of each normal is always positive (because a surface normal always points away from the model's surface.) Because each normal is in tangent space, it must be transformed into the space of the other vectors used in the lighting equation before use. Alternatively, the other vectors may be transformed to tangent space. Transforming a tangent-space normal into model, world, or light space requires a 3x3 matrix multiplication per pixel. It may be more efficient to compute lighting in tangent space. Because the normal is already in tangent space, only the light vectors need to be transformed to tangent space. Since the light vectors do not change per-pixel and the tangent-space transformation only changes significantly per vertex, it is sufficient to pretransform all light vectors to tangent space in the vertex shader. This transformation is accomplished by a 3x3 matrix multiplication for every light vector.

However, if the vertex shader performs matrix palette skinning, then each bone requires its own pre-transformed version of the light-vector. A four bone vertex shader, for example, requires that a light vector be transformed into four different tangent spaces before it can be averaged into a single tangent space light vector to be passed to the pixel shader.

Model-space normals use the coordinate system of the model. Their z-component therefore is free to range arbitrarily from -1 to 1. It becomes nearly impossible to tile model-space normal maps across a model, because the model surface is unlikely to be constant in model space. Model space, however, has the advantage that it is invariant per-pixel and per-vertex, meaning that model-space light vectors can be precomputed. Therefore, computing the lighting equation per-pixel in model space is efficient because it doesn't require coordinate system conversions for any vectors. This computational saving can be substantial: 3 per-pixel instructions or up to 12 per-vertex instructions if doing 4 bone matrix palette skinning. Model-space normal maps however cannot take advantage of the HILO formats.

In summary, tangent-space normal maps can save storage (because they can be tiled, and because they can be stored in specialized formats), while object-space normal maps may be computationally more efficient. The choice you make for your application should depend on your content creation tools, storage requirements, and performance goals.

Send Us Your Comments!

Mailing List Removal