General Information


Topics within this section include:

For an overview and a list of lookup tables, see Lookup Tables.

A lookup table is a PEX resource that holds collections of related values. When processing output commands, the renderer accesses the data you specify in the lookup tables you define. It may be easier and faster for you to change values in a lookup table, where you group values, rather than editing every single instance of the data you want to change throughout a large structure network. Lookup tables are also used by programs to store information such as light source descriptions, depth-cue parameters, and view definitions.

Lookup tables consist of table entries, described in section Table Types, Availability, and Definitions, with each entry holding potentially different values for the set of parameters particular to the table type. Each entry in a table is addressed by an integer index. Depending on the table type, the first index you can define is either 0 or 1 and the maximum index you can define is either 65534 or 65535. Although the minimum and maximum indices theoretically allow for 65543 entries, implementations may offer less. To determine the maximum number of table entries that an implementation supports for each table, invoke the PEXGetTableInfo function.

You do not have to define sequential indices for entries in a table. Your table could contain entries 5, 7, and 10, for example, without containing entries 1 through 4, 6, 8, or 9. If a table has no entry for a particular index, then that entry is said to be undefined for that table. Initially, all entries not predefined are undefined.

You must explicitly create each table by invoking the PEXCreateLookupTable function. Add or redefine entries by invoking the PEXChangeTableValues function. Delete entries with the PEXDeleteTableEntries function when they are no longer needed.

Fallback Entries and Values

Related topics include:

For an overview and a list of lookup tables, see Lookup Tables.

Each lookup table has a designated fallback entry; a default value if no table entries are defined. If the renderer tries to access an undefined table entry during rendering, then the renderer uses the fallback table entry instead. If the fallback entry is undefined, then the renderer uses the fallback table values defined for each field of the table. The fallback entry and fallback values are listed with the definition of each table type in Table Types, Availability, and Definitions

If the renderer attempts to use a lookup table which has a renderer attribute value of Null, then the results are as defined in Renderers. The renderer uses the fallback values if your application references a valid table resource but the selected and fallback entries are undefined.

Table Values and Table Entries

Related topics include:

For an overview and a list of lookup tables, see Lookup Tables.

Prior to PEXlib 5.2, you were able to edit lookup table entries only by replacing the entire table entry. Beginning with PEXlib 5.2, the table entry manipulation functions (PEXChangeTableValues and PEXGetTableValues) enable you to alter or retrieve portions of a table entry, instead of the entire entry. These table entry portions are called "values" and may consist of one or several members of the table values data structure. To indicate which portions of the table entry you intend to edit or retrieve, use the bitmask argument included with these functions. When using the PEXChangeTableValues and PEXGetTableValues functions, always use the PEX<table name>Values data structures to access the data.

The older table entry manipulation functions (PEXSetTableEntries, PEXGetTableEntry, and PEXGetTableEntries) are still supported for the pre-PEXlib 5.2 table types, but because only the newer functions enable you access to all of the table types, you should avoid using these older table entry manipulation functions in newer applications. Also, some pre-PEXlib 5.2 table types now offer new members, which you can access only with the newer functions. When using these older functions, always use the PEX<table name>Entry data structures.

Predefined Entries

Related topics include:

For an overview and a list of lookup tables, see Lookup Tables.

A PEX implementation may predefine some entries in a lookup table when the application creates the table. These are entries that the implementation fills in automatically. Predefined entries are sequential and include the first legal entry of the table. The number of entries predefined is implementation-dependent, may be zero, and may vary for each table type. The client can redefine predefined entries. To determine the number of predefined entries for a particular table type, invoke the PEXGetTableInfo function. To determine the actual entries that a implementation predefines for a particular table type and the sample drawable, invoke the PEXGetPredefinedEntries function.

As of PEXlib 5.2, it is recommended that implementations not provide predefined entries because of the large variation in the predefined values found in different implementations. Therefore, do not rely on predefined entries when writing PEXlib programs. The concept is explained here and supported to maintain compatibility with PEX versions previous to 5.2.

Set and Realized Values

Related topics include:

For an overview and a list of lookup tables, see Lookup Tables.

If you set a particular value in a table entry, it is possible that the implementation can not represent the exact value you specify. Therefore, your implementation may round the value to a lower precision, or modify the value somewhat to the closest value it can handle. In these cases, the implementation silently maps the value to an approximation. This mapped value is called the "realized" value. To determine the realized value (the value your implementation actually uses when rendering) invoke the PEXGetTableValues function.

Resources in Table Entries

Related topics include:

Some table entry types have members that store references to other resources. If you would like to modify a table entry member to indicates that no resource is to be used, then store the value None in the member.