THE PHILOSOPHY OF EGG FILES (vs. bam files)

Egg files are used by Panda3D to describe many properties of a scene:

simple geometry, including special effects and collision surfaces,

characters including skeletons, morphs, and multiple-joint

assignments, and character animation tables.

Egg files are designed to be the lingua franca of model manipulation

for Panda tools. A number of utilities are provided that read and

write egg files, for instance to convert to or from some other

modeling format, or to apply a transform or optimize vertices. The

egg file philosophy is to describe objects in an abstract way that

facilitates easy manipulation; thus, the format doesn't (usually)

include information such as polygon connectivity or triangle meshes.

Egg files are furthermore designed to be human-readable to help a

developer diagnose (and sometimes repair) problems. Also, the egg

syntax is always intended to be backward compatible with previous

versions, so that as the egg syntax is extended, old egg files will

continue to remain valid.

This is a different philosophy than Panda's bam file format, which is

a binary representation of a model and/or animation that is designed

to be loaded quickly and efficiently, and is strictly tied to a

particular version of Panda. The data in a bam file closely mirrors

the actual Panda structures that are used for rendering. Although an

effort is made to keep bam files backward compatible, occasionally

this is not possible and we must introduce a new bam file major

version.

Where egg files are used for model conversion and manipulation of

models, bam files are strictly used for loading models into Panda.

Although you can load an egg file directly, a bam file will be loaded

much more quickly.

Egg files might be generated by outside sources, and thus it makes

sense to document its syntax here. Bam files, on the other hand,

should only be generated by Panda3D, usually by the program egg2bam.

The exact specification of the bam file format, if you should need it,

is documented within the Panda3D code itself.

GENERAL EGG SYNTAX

Egg files consist of a series of sequential and hierarchically-nested

entries. In general, the syntax of each entry is:

<Entry-type> name { contents }

Where the name is optional (and in many cases, ignored anyway) and the

syntax of the contents is determined by the entry-type. The name (and

strings in general) may be either quoted with double quotes or

unquoted. Newlines are treated like any other whitespace, and case is

not significant. The angle brackets are literally a part of the entry

keyword. (Square brackets and ellipses in this document are used to

indicate optional pieces, and are not literally part of the syntax.)

The name field is always syntactically allowed between an entry

keyword and its opening brace, even if it will be ignored. In the

syntax lines given below, the name is not shown if it will be ignored.

Comments may be delimited using either the C++-style // ... or the

C-style /* ... */. C comments do not nest. There is also a <Comment>

entry type, of the form:

<Comment> { text }

<Comment> entries are slightly different, in that tools which read and

write egg files will preserve the text within <Comment> entries, but

they may not preserve comments delimited by // or /* */. Special

characters and keywords within a <Comment> entry should be quoted;

it's safest to quote the entire comment.

LOCAL INFORMATION ENTRIES

These nodes contain information relevant to the current level of

nesting only.

<Scalar> name { value }

<Char*> name { value }

Scalars can appear in various contexts. They are always optional,

and specify some attribute value relevant to the current context.

The scalar name is the name of the attribute; different attribute

names are meaningful in different contexts. The value is either a

numeric or a (quoted or unquoted) string value; the interpretation

as a number or as a string depends on the nature of the named

attribute. Because of a syntactic accident with the way the egg

syntax evolved, <Scalar> and <Char*> are lexically the same and both

can represent either a string or a number. <Char*> is being phased

out; it is suggested that new egg files use only <Scalar>.

GLOBAL INFORMATION ENTRIES

These nodes contain information relevant to the file as a whole. They

can be nested along with geometry nodes, but this nesting is

irrelevant and the only significant placement rule is that they should

appear before they are referenced.

<CoordinateSystem> { string }

This entry indicates the coordinate system used in the egg file; the

egg loader will automatically make a conversion if necessary. The

following strings are valid: Y-up, Z-up, Y-up-right, Z-up-right,

Y-up-left, or Z-up-left. (Y-up is the same as Y-up-right, and Z-up

is the same as Z-up-right.)

By convention, this entry should only appear at the beginning of the

file, although it is technically allowed anywhere. It is an error

to include more than one coordinate system entry in the same file.

If it is omitted, Y-up is assumed.

<Texture> name { filename [scalars] }

This describes a texture file that can be referenced later with

<TRef> { name }. It is not necessary to make a <Texture> entry for

each texture to be used; a texture may also be referenced directly

by the geometry via an abbreviated inline <Texture> entry, but a

separate <Texture> entry is the only way to specify anything other

than the default texture attributes.

If the filename is a relative path, the current egg file's directory

is searched first, and then the texture-path and model-path are

searched.

The following attributes are presently implemented for textures:

<Scalar> alpha-file { alpha-filename }

If this scalar is present, the texture file's alpha channel is

read in from the named image file (which should contain a

grayscale image), and the two images are combined into a single

two- or four-channel image internally. This is useful for loading

alpha channels along with image file formats like JPEG that don't

traditionally support alpha channels.

<Scalar> alpha-file-channel { channel }

This defines the channel that should be extracted from the file

named by alpha-file to determine the alpha channel for the

resulting channel. The default is 0, which means the grayscale

combination of r, g, b. Otherwise, this should be the 1-based

channel number, for instance 1, 2, or 3 for r, g, or b,

respectively, or 4 for the alpha channel of a four-component

image.

<Scalar> format { format-definition }

This defines the load format of the image file. The

format-definition is one of:

RGBA, RGBM, RGBA12, RGBA8, RGBA4,

RGB, RGB12, RGB8, RGB5, RGB332,

LUMINANCE_ALPHA,

RED, GREEN, BLUE, ALPHA, LUMINANCE

The formats whose names end in digits specifically request a

particular texel width. RGB12 and RGBA12 specify 48-bit texels

with or without alpha; RGB8 and RGBA8 specify 32-bit texels, and

RGB5 and RGBA4 specify 16-bit texels. RGB332 specifies 8-bit

texels.

The remaining formats are generic and specify only the semantic

meaning of the channels. The size of the texels is determined by

the width of the components in the image file. RGBA is the most

general; RGB is the same, but without any alpha channel. RGBM is

like RGBA, except that it requests only one bit of alpha, if the

graphics card can provide that, to leave more room for the RGB

components, which is especially important for older 16-bit

graphics cards (the "M" stands for "mask", as in a cutout).

The number of components of the image file should match the format

specified; if it does not, the egg loader will attempt to provide

the closest match that does.

<Scalar> compression { compression-mode }

Defines an explicit control over the real-time compression mode

applied to the texture. The various options are:

DEFAULT OFF ON

FXT1 DXT1 DXT2 DXT3 DXT4 DXT5

This controls the compression of the texture when it is loaded

into graphics memory, and has nothing to do with on-disk

compression such as JPEG. If this option is omitted or "DEFAULT",

then the texture compression is controlled by the

compressed-textures config variable. If it is "OFF", texture

compression is explicitly off for this texture regardless of the

setting of the config variable; if it is "ON", texture compression

is explicitly on, and a default compression algorithm supported by

the driver is selected. If any of the other options, it names the

specific compression algorithm to be used.

<Scalar> wrap { repeat-definition }

<Scalar> wrapu { repeat-definition }

<Scalar> wrapv { repeat-definition }

<Scalar> wrapw { repeat-definition }

This defines the behavior of the texture image outside of the

normal (u,v) range 0.0 - 1.0. It is "REPEAT" to repeat the

texture to infinity, "CLAMP" not to. The wrapping behavior may be

specified independently for each axis via "wrapu" and "wrapv", or

it may be specified for both simultaneously via "wrap".

Although less often used, for 3-d textures wrapw may also be

specified, and it behaves similarly to wrapu and wrapv.

There are other legal values in addtional to REPEAT and CLAMP.

The full list is:

CLAMP

REPEAT

MIRROR

MIRROR_ONCE

BORDER_COLOR

<Scalar> borderr { red-value }

<Scalar> borderg { green-value }

<Scalar> borderb { blue-value }

<Scalar> bordera { alpha-value }

These define the "border color" of the texture, which is

particularly important when one of the wrap modes, above, is

BORDER_COLOR.

<Scalar> type { texture-type }

This may be one of the following attributes:

1D

2D

3D

CUBE_MAP

The default is "2D", which specifies a normal, 2-d texture. If

any of the other types is specified instead, a texture image of

the corresponding type is loaded.

If 3D or CUBE_MAP is specified, then a series of texture images

must be loaded to make up the complete texture; in this case, the

texture filename is expected to include a sequence of one or more

hash mark ("#") characters, which will be filled in with the

sequence number. The first image in the sequence must be numbered

0, and there must be no gaps in the sequence. In this case, a

separate alpha-file designation is ignored; the alpha channel, if

present, must be included in the same image with the color

channel(s).

<Scalar> multiview { flag }

If this flag is nonzero, the texture is loaded as a multiview

texture. In this case, the filename must contain a hash mark

("#") as in the 3D or CUBE_MAP case, above, and the different

images are loaded into the different views of the multiview

textures. If the texture is already a cube map texture, the

same hash sequence is used for both purposes: the first six images

define the first view, the next six images define the second view,

and so on. If the texture is a 3-D texture, you must also specify

num-views, below, to tell the loader how many images are loaded

for views, and how many are loaded for levels.

A multiview texture is most often used to load stereo textures,

where a different image is presented to each eye viewing the

texture, but other uses are possible, such as for texture

animation.

<Scalar> num-views { count }

This is used only when loading a 3-D multiview texture. It

specifies how many different views the texture holds; the z height

of the texture is then implicitly determined as (number of images)

/ (number of views).

<Scalar> read-mipmaps { flag }

If this flag is nonzero, then pre-generated mipmap levels will be

loaded along with the texture. In this case, the filename should

contain a sequence of one or more hash mark ("#") characters,

which will be filled in with the mipmap level number; the texture

filename thus determines a series of images, one for each mipmap

level. The base texture image is mipmap level 0.

If this flag is specified in conjunction with a 3D or cube map

texture (as specified above), then the filename should contain two

hash mark sequences, separated by a character such as an

underscore, hyphen, or dot. The first sequence will be filled in

with the mipmap level index, and the second sequence will be

filled in with the 3D sequence or cube map face.

<Scalar> minfilter { filter-type }

<Scalar> magfilter { filter-type }

<Scalar> magfilteralpha { filter-type }

<Scalar> magfiltercolor { filter-type }

This specifies the type of filter applied when minimizing or

maximizing. Filter-type may be one of:

NEAREST

LINEAR

NEAREST_MIPMAP_NEAREST

LINEAR_MIPMAP_NEAREST

NEAREST_MIPMAP_LINEAR

LINEAR_MIPMAP_LINEAR

There are also some additional filter types that are supported for

historical reasons, but each of those additional types maps to one

of the above. New egg files should use only the above filter

types.

<Scalar> anisotropic-degree { degree }

Enables anisotropic filtering for the texture, and specifies the

degree of filtering. If the degree is 0 or 1, anisotropic

filtering is disabled. The default is disabled.

<Scalar> envtype { environment-type }

This specifies the type of texture environment to create; i.e. it

controls the way in which textures apply to models.

Environment-type may be one of:

MODULATE

DECAL

BLEND

REPLACE

ADD

BLEND_COLOR_SCALE

MODULATE_GLOW

MODULATE_GLOSS

*NORMAL

*NORMAL_HEIGHT

*GLOW

*GLOSS

*HEIGHT

*SELECTOR

The default environment type is MODULATE, which means the texture

color is multiplied with the base polygon (or vertex) color. This

is the most common texture environment by far. Other environment

types are more esoteric and are especially useful in the presence

of multitexture. In particular, the types prefixed by an asterisk

(*) require enabling Panda's automatic ShaderGenerator.

<Scalar> combine-rgb { combine-mode }

<Scalar> combine-alpha { combine-mode }

<Scalar> combine-rgb-source0 { combine-source }

<Scalar> combine-rgb-operand0 { combine-operand }

<Scalar> combine-rgb-source1 { combine-source }

<Scalar> combine-rgb-operand1 { combine-operand }

<Scalar> combine-rgb-source2 { combine-source }

<Scalar> combine-rgb-operand2 { combine-operand }

<Scalar> combine-alpha-source0 { combine-source }

<Scalar> combine-alpha-operand0 { combine-operand }

<Scalar> combine-alpha-source1 { combine-source }

<Scalar> combine-alpha-operand1 { combine-operand }

<Scalar> combine-alpha-source2 { combine-source }

<Scalar> combine-alpha-operand2 { combine-operand }

These options replace the envtype and specify the texture combiner

mode, which is usually used for multitexturing. This specifies

how the texture combines with the base color and/or the other

textures applied previously. You must specify both an rgb and an

alpha combine mode. Some combine-modes use one source/operand

pair, and some use all three; most use just two.

combine-mode may be one of:

REPLACE

MODULATE

ADD

ADD-SIGNED

INTERPOLATE

SUBTRACT

DOT3-RGB

DOT3-RGBA

combine-source may be one of:

TEXTURE

CONSTANT

PRIMARY-COLOR

PREVIOUS

CONSTANT_COLOR_SCALE

LAST_SAVED_RESULT

combine-operand may be one of:

SRC-COLOR

ONE-MINUS-SRC-COLOR

SRC-ALPHA

ONE-MINUS-SRC-ALPHA

The default values if any of these are omitted are:

<Scalar> combine-rgb { modulate }

<Scalar> combine-alpha { modulate }

<Scalar> combine-rgb-source0 { previous }

<Scalar> combine-rgb-operand0 { src-color }

<Scalar> combine-rgb-source1 { texture }

<Scalar> combine-rgb-operand1 { src-color }

<Scalar> combine-rgb-source2 { constant }

<Scalar> combine-rgb-operand2 { src-alpha }

<Scalar> combine-alpha-source0 { previous }

<Scalar> combine-alpha-operand0 { src-alpha }

<Scalar> combine-alpha-source1 { texture }

<Scalar> combine-alpha-operand1 { src-alpha }

<Scalar> combine-alpha-source2 { constant }

<Scalar> combine-alpha-operand2 { src-alpha }

<Scalar> saved-result { flag }

If flag is nonzero, then it indicates that this particular texture

stage will be supplied as the "last_saved_result" source for any

future texture stages.

<Scalar> tex-gen { mode }

This specifies that texture coordinates for the primitives that

reference this texture should be dynamically computed at runtime,

for instance to apply a reflection map or some other effect. The

valid values for mode are:

EYE_SPHERE_MAP (or SPHERE_MAP)

WORLD_CUBE_MAP

EYE_CUBE_MAP (or CUBE_MAP)

WORLD_NORMAL

EYE_NORMAL

WORLD_POSITION

EYE_POSITION

POINT_SPRITE

<Scalar> stage-name { name }

Specifies the name of the TextureStage object that is created to

render this texture. If this is omitted, a custom TextureStage is

created for this texture if it is required (e.g. because some

other multitexturing parameter has been specified), or the system

default TextureStage is used if multitexturing is not required.

<Scalar> priority { priority-value }

Specifies an integer sort value to rank this texture in priority

among other textures that are applied to the same geometry. This

is only used to eliminate low-priority textures in case more

textures are requested for a particular piece of geometry than the

graphics hardware can render.

<Scalar> blendr { red-value }

<Scalar> blendg { green-value }

<Scalar> blendb { blue-value }

<Scalar> blenda { alpha-value }

Specifies a four-component color that is applied with the color in

case the envtype, above, is "blend", or one of the combine-sources

is "constant".

<Scalar> uv-name { name }

Specifies the name of the texture coordinates that are to be

associated with this texture. If this is omitted, the default

texture coordinates are used.

<Scalar> rgb-scale { scale }

<Scalar> alpha-scale { scale }

Specifies an additional scale factor that will scale the r, g, b

(or a) components after the texture has been applied. This is

only used when a combine mode is in effect. The only legal values

are 1, 2, or 4.

<Scalar> alpha { alpha-type }

This specifies whether and what type of transparency will be

performed. Alpha-type may be one of:

OFF

ON

BLEND

BLEND_NO_OCCLUDE

MS

MS_MASK

BINARY

DUAL

If alpha-type is OFF, it means not to enable transparency, even if

the image contains an alpha channel or the format is RGBA. If

alpha-type is ON, it means to enable the default transparency,

even if the image filename does not contain an alpha channel. If

alpha-type is any of the other options, it specifies the type of

transparency to be enabled.

<Scalar> bin { bin-name }

This specifies the bin name order of all polygons with this

texture applied, in the absence of a bin name specified on the

polygon itself. See the description for bin under polygon

attributes.

<Scalar> draw-order { number }

This specifies the fixed drawing order of all polygons with this

texture applied, in the absence of a drawing order specified on

the polygon itself. See the description for draw-order under

polygon attributes.

<Scalar> depth-offset { number }

<Scalar> depth-write { mode }

<Scalar> depth-test { mode }

Specifies special depth buffer properties of all polygons with this

texture applied. See the descriptions for the individual

attributes under polygon attributes.

<Scalar> quality-level { quality }

Sets a hint to the renderer about the desired performance /

quality tradeoff for this particular texture. This is most useful

for the tinydisplay software renderer; for normal,

hardware-accelerated renderers, this may have little or no effect.

This may be one of:

DEFAULT

FASTEST

NORMAL

BEST

"Default" means to use whatever quality level is specified by the

global texture-quality-level config variable.

<Transform> { transform-definition }

This specifies a 2-d or 3-d transformation that is applied to the

UV's of a surface to generate the texture coordinates.

The transform syntax is similar to that for groups, except it may

define either a 2-d 3x3 matrix or a 3-d 4x4 matrix. (You should

use the two-dimensional forms if the UV's are two-dimensional, and

the three-dimensional forms if the UV's are three-dimensional.)

A two-dimensional transform may be any sequence of zero or more of

the following. Transformations are post multiplied in the order

they are encountered to produce a net transformation matrix.

Rotations are counterclockwise about the origin in degrees.

Matrices, when specified explicitly, are row-major.

<Translate> { x y }

<Rotate> { degrees }

<Scale> { x y }

<Scale> { s }

<Matrix3> {

00 01 02

10 11 12

20 21 22

}

A three-dimensional transform may be any sequence of zero or more

of the following. See the description under <Group>, below, for

more information.

<Translate> { x y z }

<RotX> { degrees }

<RotY> { degrees }

<RotZ> { degrees }

<Rotate> { degrees x y z }

<Scale> { x y z }

<Scale> { s }

<Matrix4> {

00 01 02 03

10 11 12 13

20 21 22 23

30 31 32 33

}

<Material> name { [scalars] }

This defines a set of material attributes that may later be

referenced with <MRef> { name }.

The following attributes may appear within the material block:

<Scalar> diffr { number }

<Scalar> diffg { number }

<Scalar> diffb { number }

<Scalar> diffa { number }

<Scalar> ambr { number }

<Scalar> ambg { number }

<Scalar> ambb { number }

<Scalar> amba { number }

<Scalar> emitr { number }

<Scalar> emitg { number }

<Scalar> emitb { number }

<Scalar> emita { number }

<Scalar> specr { number }

<Scalar> specg { number }

<Scalar> specb { number }

<Scalar> speca { number }

<Scalar> shininess { number }

<Scalar> local { flag }

These properties collectively define a "material" that controls the

lighting effects that are applied to a surface; a material is only

in effect in the presence of lighting.

The four color groups, diff*, amb*, emit*, and spec* specify the

diffuse, ambient, emission, and specular components of the lighting

equation, respectively. Any of them may be omitted; the omitted

component(s) take their color from the native color of the

primitive, otherwise the primitive color is replaced with the

material color.

The shininess property controls the size of the specular highlight,

and the value ranges from 0 to 128. A larger value creates a

smaller highlight (creating the appearance of a shinier surface).

<VertexPool> name { vertices }

A vertex pool is a set of vertices. All geometry is created by

referring to vertices by number in a particular vertex pool. There

may be one or several vertex pools in an egg file, but all vertices

that make up a single polygon must come from the same vertex pool.

The body of a <VertexPool> entry is simply a list of one or more

<Vertex> entries, as follows:

<Vertex> number { x [y [z [w]]] [attributes] }

A <Vertex> entry is only valid within a vertex pool definition.

The number is the index by which this vertex will be referenced.

It is optional; if it is omitted, the vertices are implicitly

numbered consecutively beginning at one. If the number is

supplied, the vertices need not be consecutive.

Normally, vertices are three-dimensional (with coordinates x, y,

and z); however, in certain cases vertices may have fewer or more

dimensions, up to four. This is particularly true of vertices

used as control vertices of NURBS curves and surfaces. If more

coordinates are supplied than needed, the extra coordinates are

ignored; if fewer are supplied than needed, the missing

coordinates are assumed to be 0.

The vertex's coordinates are always given in world space,

regardless of any transforms before the vertex pool or before the

referencing geometry. If the vertex is referenced by geometry

under a transform, the egg loader will do an inverse transform to

move the vertex into the proper coordinate space without changing

its position in world space. One exception is geometry under an

<Instance> node; in this case the vertex coordinates are given in

the space of the <Instance> node. (Another exception is a

<DynamicVertexPool>; see below.)

In neither case does it make a difference whether the vertex pool

is itself declared under a transform or an <Instance> node. The

only deciding factor is whether the geometry that *uses* the

vertex pool appears under an <Instance> node. It is possible for

a single vertex to be interpreted in different coordinate spaces

by different polygons.

While each vertex must at least have a position, it may also have

a color, normal, pair of UV coordinates, and/or a set of morph

offsets. Furthermore, the color, normal, and UV coordinates may

themselves have morph offsets. Thus, the [attributes] in the

syntax line above may be replaced with zero or more of the

following entries:

<Dxyz> target { x y z }

This specifies the offset of this vertex for the named morph

target. See the "MORPH DESCRIPTION ENTRIES" header, below.

<Normal> { x y z [morph-list] }

This specifies the surface normal of the vertex. If omitted, the

vertex will have no normal. Normals may also be morphed;

morph-list here is thus an optional list of <DNormal> entries,

similar to the above.

<RGBA> { r g b a [morph-list] }

This specifies the four-valued color of the vertex. Each

component is in the range 0.0 to 1.0. A vertex color, if

specified for all vertices of the polygon, overrides the polygon's

color. If neither color is given, the default is white

(1 1 1 1). The morph-list is an optional list of <DRGBA> entries.

<UV> [name] { u v [w] [tangent] [binormal] [morph-list] }

This gives the texture coordinates of the vertex. This must be

specified if a texture is to be mapped onto this geometry.

The texture coordinates are usually two-dimensional, with two

component values (u v), but they may also be three-dimensional,

with three component values (u v w). (Arguably, it should be

called <UVW> instead of <UV> in the three-dimensional case, but

it's not.)

As before, morph-list is an optional list of <DUV> entries.

Unlike the other kinds of attributes, there may be multiple sets

of UV's on each vertex, each with a unique name; this provides

support for multitexturing. The name may be omitted to specify

the default UV's.

The UV's also support an optional tangent and binormal. These

values are based on the vertex normal and the UV coordinates of

connected vertices, and are used to render normal maps and similar

lighting effects. They are defined within the <UV> entry because

there may be a different set of tangents and binormals for each

different UV coordinate set. If present, they have the expected

syntax:

<UV> [name] { u v [w] <Tangent> { x y z } <Binormal> { x y z } }

<AUX> name { x y z w }

This specifies some named per-vertex auxiliary data which is

imported from the egg file without further interpretation by

Panda. The auxiliary data is copied to the vertex data under a

column with the specified name. Presumably the data will have

meaning to custom code or a custom shader. Like named UV's, there

may be multiple Aux entries for a given vertex, each with a

different name.

<DynamicVertexPool> name { vertices }

A dynamic vertex pool is similar to a vertex pool in most respects,

except that each vertex might be animated by substituting in values

from a <VertexAnim> table. Also, the vertices defined within a

dynamic vertex pool are always given in local coordinates, instead

of world coordinates.

The presence of a dynamic vertex pool makes sense only within a

character model, and a single dynamic vertex pool may not span

multiple characters. Each dynamic vertex pool creates a DynVerts

object within the character by the same name; this name is used

later when matching up the corresponding <VertexAnim>.

At the present time, the DynamicVertexPool is not implemented in

Panda3D.

GEOMETRY ENTRIES

<Polygon> name {

[attributes]

<VertexRef> {

indices

<Ref> { pool-name }

}

}

A polygon consists of a sequence of vertices from a single vertex

pool. Vertices are identified by pool-name and index number within

the pool; indices is a list of vertex numbers within the given

vertex pool. Vertices are listed in counterclockwise order.

Although the vertices must all come from the same vertex pool, they

may have been assigned to arbitrarily many different joints

regardless of joint connectivity (there is no "straddle-polygon"

limitation). See Joints, below.

The polygon syntax is quite verbose, and there isn't any way to

specify a set of attributes that applies to a group of polygons--the

attributes list must be repeated for each polygon. This is why egg

files tend to be very large.

The following attributes may be specified for polygons:

<TRef> { texture-name }

This refers to a named <Texture> entry given earlier. It applies

the given texture to the polygon. This requires that all the

polygon's vertices have been assigned texture coordinates.

This attribute may be repeated multiple times to specify

multitexture. In this case, each named texture is applied to the

polygon, in the order specified.

<Texture> { filename }

This is another way to apply a texture to a polygon. The

<Texture> entry is defined "inline" to the polygon, instead of

referring to a <Texture> entry given earlier. There is no way to

specify texture attributes given this form.

There's no advantage to this syntax for texture mapping. It's

supported only because it's required by some older egg files.

<MRef> { material-name }

This applies the material properties defined in the earlier

<Material> entry to the polygon.

<Normal> { x y z [morph-list] }

This defines a polygon surface normal. The polygon normal will be

used unless all vertices also have a normal. If no normal is

defined, none will be supplied. The polygon normal, like the

vertex normal, may be morphed by specifying a series of <DNormal>

entries.

The polygon normal is used only for lighting and environment

mapping calculations, and is not related to the implicit normal

calculated for CollisionPolygons.

<RGBA> { r g b a [morph-list] }

This defines the polygon's color, which will be used unless all

vertices also have a color. If no color is defined, the default

is white (1 1 1 1). The color may be morphed with a series of

<DRGBA> entries.

<BFace> { boolean-value }

This defines whether the polygon will be rendered double-sided

(i.e. its back face will be visible). By default, this option is

disabled, and polygons are one-sided; specifying a nonzero value

disables backface culling for this particular polygon and allows

it to be viewed from either side.

<Scalar> bin { bin-name }

It is sometimes important to control the order in which objects

are rendered, particularly when transparency is in use. In Panda,

this is achieved via the use of named bins and, within certain

kinds of bins, sometimes an explicit draw-order is also used (see

below).

In the normal (state-sorting) mode, Panda renders its geometry by

first grouping into one or more named bins, and then rendering the

bins in a specified order. The programmer is free to define any

number of bins, named whatever he/she desires.

This scalar specifies which bin this particular polygon is to be

rendered within. If no bin scalar is given, or if the name given

does not match any of the known bins, the polygon will be assigned

to the default bin, which renders all opaque geometry sorted by

state, followed by all transparent geometry sorted back-to-front.

See also draw-order, below.

<Scalar> draw-order { number }

This works in conjunction with bin, above, to further refine the

order in which this polygon is drawn, relative to other geometry

in the same bin. If (and only if) the bin type named in the bin

scalar is a CullBinFixed, this draw-order is used to define the

fixed order that all geometry in the same will be rendered, from

smaller numbers to larger numbers.

If the draw-order scalar is specified but no bin scalar is

specified, the default is a bin named "fixed", which is a

CullBinFixed object that always exists by default.

<Scalar> depth-offset { number }

Specifies a special depth offset to be applied to the polygon.

This must be an integer value between 0 and 16 or so. The default

value is 0; values larger than 0 will cause the polygon to appear

closer to the camera for purposes of evaluating the depth buffer.

This can be a simple way to resolve Z-fighting between coplanar

polygons: with two or more coplanar polygons, the polygon with the

highest depth-offset value will appear to be visible on top. Note

that this effect doesn't necessarily work well when the polygons

are viewed from a steep angle.

<Scalar> depth-write { mode }

Specifies the mode for writing to the depth buffer. This may be

ON or OFF. The default is ON.

<Scalar> depth-test { mode }

Specifies the mode for testing against the depth buffer. This may

be ON or OFF. The default is ON.

<Scalar> visibility { hidden | normal }

If the visibility of a primitive is set to "hidden", the primitive

is not generated as a normally visible primitive. If the

Config.prc variable egg-suppress-hidden is set to true, the

primitive is not converted at all; otherwise, it is converted as a

"stashed" node.

This, like the other rendering flags alpha, draw-order, and bin,

may be specified at the group level, within the primitive level,

or even within a texture.

<Patch> name {

[attributes]

<VertexRef> {

indices

<Ref> { pool-name }

}

}

A patch is similar to a polygon, but it is a special primitive that

can only be rendered with the use of a tessellation shader. Each

patch consists of an arbitrary number of vertices; all patches with

the same number of vertices are collected together into the same

GeomPatches object to be delivered to the shader in a single batch.

It is then up to the shader to create the correct set of triangles

from the patch data.

All of the attributes that are valid for Polygon, above, may also be

specified for Patch.

<PointLight> name {

[attributes]

<VertexRef> {

indices

<Ref> { pool-name }

}

}

A PointLight is a set of single points. One point is drawn for each

vertex listed in the <VertexRef>. Normals, textures, and colors may

be specified for PointLights, as well as draw-order, plus one

additional attribute valid only for PointLights and Lines:

<Scalar> thick { number }

This specifies the size of the PointLight (or the width of a

line), in pixels, when it is rendered. This may be a

floating-point number, but the fractional part is meaningful only

when antialiasing is in effect. The default is 1.0.

<Scalar> perspective { boolean-value }

If this is specified, then the thickness, above, is to interpreted

as a size in 3-d spatial units, rather than a size in pixels, and

the point should be scaled according to its distance from the

viewer normally.

<Line> name {

[attributes]

<VertexRef> {

indices

<Ref> { pool-name }

}

[component attributes]

}

A Line is a connected set of line segments. The listed N vertices

define a series of N-1 line segments, drawn between vertex 0 and

vertex 1, vertex 1 and vertex 2, etc. The line is not implicitly

closed; if you wish to represent a loop, you must repeat vertex 0 at

the end. As with a PointLight, normals, textures, colors,

draw-order, and the "thick" attribute are all valid (but not

"perspective"). Also, since a Line (with more than two vertices) is

made up of multiple line segments, it may contain a number of

<Component> entries, to set a different color and/or normal for each

line segment, as in TriangleStrip, below.

<TriangleStrip> name {

[attributes]

<VertexRef> {

indices

<Ref> { pool-name }

}

[component attributes]

}

A triangle strip is only rarely encountered in an egg file; it is

normally generated automatically only during load time, when

connected triangles are automatically meshed for loading, and even

then it exists only momentarily. Since a triangle strip is a