Knowing the terminology (terms) and language of something makes understanding it easier—usually, anyway. I have included references to Criterion's RenderWare API Reference in the definitions, along with my interpretations. If the definitions do not make sense, explore the links within them. I've tried to explain things to a certain degree, but I can only do so much explaining before it gets ridiculous. If you're having trouble, search for more information on the Net. Good sites I've found are:

• nVidia's 3D Glossary
• Wikipedia: 3D graphics (Webopedia's definition)

Another thing you can do is access the Active Worlds worldbuilders newsgroup and ask questions there. Lastly, you can email me and ask to explain something further--but only email me after you've exhausted the contents of this site and its links.

Note: please don't override this page's colors with your web browser's colors, as this page's colors are used to aid in illustration of terms.

Terms/script commands format/syntax:

term/script command: [(alternate name(s)—if any)]

1. definition(s)/description

script command syntax <argument> [(<optional arguments>)]: syntax/argument explanation

The command syntax/argument(s) is/are how the command is actually written (syntax) in the script. Some terms/commands will have subterms/subcommands, some terms are the commands, and some terms are just terms. It may be confusing at first but just keep exploring the links and it should sink in eventually.

Roland has added the complete "RWX Command Reference" (no direct link) to AW3+'s help, so be sure to read it as well in case there are discrepancies (which I've tried to mention on the site but there may be some I missed).

3D Terms & RenderWare Script Commands

model [3D "object"/"script"/RenderWare script (RWX) file]: A collection of clumps.

Note
• AW3+ also supports RW3's DFF binary object format, which some modellers can save/export to.
• Object names can't be more than 22 characters or AW will give an error about not finding the RWX file.

modelbegin: Begins model; used at the beginning of a script file.
modelend: Ends model; used at the end of a script file.

Every script file should have exactly one top-level ModelBegin … ModelEnd block. Within such a block, zero or more ProtoBegin … ProtoEnd blocks followed by one top-level ClumpBegin … ClumpEnd block are expected. The ProtoBegin … ProtoEnd blocks are prototype declarations, and the top-level ClumpBegin … ClumpEnd block is an actual clump being constructed by the script.

Note: Even though it says "every script file should have exactly one top-level ModelBegin ... ModelEnd block", if a script file does not have any heirachial/parent-child/nested clumps or prototypes, the modelbegin/modelend statements are unnecessary (and completely optional in AW3+, but for backward compatibility with AW 2.2 follow the above guidelines).

clump

1. A collection of Polygons and Vertices. Clump objects allow applications to handle large numbers of related polygons and vertices as a single, atomic entity. This greatly simplifies application construction.
2. occupies volume in world space

   clumpbegin: Begins clump; used after a modelbegin statement.
   clumpend: Ends clump; used before a modelend statement.

   Note: Nested clumps can be used to make part of an object non-solid.

# ("pound" sign, "number" symbol):

1. a whole number (1, 2, 3, etc) or with decimals (1.5, 3.145, etc)
2. Used to make comments, label vertices, or other information (creator, date, copyright, etc).
3. RenderWare ignores # and anything after it on that line.

   Note

   1. Using # before a texture command, or any text with "texture" as the first word, will cause Active Worlds to still either download the texture (and mask, if specified) or a texture file with the name of the first word after "texture" (adding a ".jpg" to the end). This is an AW bug.
   2. AW3+ will not ignore "#!" (but AW 2.2- will) so be sure to use it before prelight, collision, and textureaddressmode so objects still work for AW 2.2 users and for older RWX programs. However, if a single "#" appears anywhere before "#!", AW3 will ignore the "#!" so if you want to make a comment on a vert with "#!", put it after the RWX command extension.

coordinate

1. In RenderWare, a coordinate is a location/point in three-dimensional (3D) Cartesian space. These dimensions are represented by three axes (lines) from a single, central, relative location/point (origin):
   x-axis/coordinate: horizontal/width/left-to-right
   y-axis/coordinate: vertical/height/up-and-down
   z-axis/coordinate: depth/front-to-back

2. RenderWare uses a right-handed world coordinate system. This has the same orientation as that given by taking the thumb, first and second fingers of your right hand as the x, y and z axes, respectively. The positive x axis points to the right, the positive y axis points up, whilst the positive z axis points forwards (out of the screen).

vertex ("vert", vertices/"verts"):

1. point/dot/corner
2. defined in any order to form a polygon

   vertex # # # uv # # prelight # # #: where the first # is the x-coordinate, the second # is the y-coordinate, and the third # is the z-coordinate. uv and prelight coordinates are optional.

   
   UV

   1. Grover: "'UV' originates in vector calculus and represents transpositions and vector functions that are almost always taken from the Cartesian system to the u,v,w system".
   2. Used after vertex coordinates; defines texture repetitions across vertices.
   3. Texture coordinates, conventionally called (u, v). These coordinates are each in the range [0.0 - 32.0] and measure how far to the right and below the upper left corner of the image (respectively) to take the texel color. Each vertex in a clump may be assigned a pair of texture coordinates. A textured image is "wrapped" over a polygon by interpolating texture coordinates defined at the vertices over the polygon's projection.
      Note: Even though it says the range of the UV coordinates is from 0 to 32, I have used 180 on a ground object and more than 32 on chainlink fences. Some viewers (RWXMod and RWXLook, specifically) won't render an object if the UV coordinates are more than 32, but once inside Active Worlds, objects render fine. I think the limit is around 360 in Active Worlds, though, but I'm not sure. If anyone finds out, email me. kf: "I have made grounds with UV values up to 600, which work very well. Such high values are needed when, for example, you have a non-repeating formed ground in a large world to prevent the ground ending before the maximum sight (1200m) ends."
   4. see texture mapping and textureaddressmode
   5. To get a random and unpredictable pattern similar to that of AW3-3.1, use randomuvs.

   vertex # # # uv # #: Where the first # after uv is the horizontal distance across the texture and the second # after uv is the vertical distance across the texture.

   
   prelight: Light (currently the world's ambient light color) is calculated starting from this color.

   vertex # # # uv # # # prelight # # #: Where the #s after prelight are from zero (0) to one (1) in the RGB (red-green-blue) color system:
   0 0 0 = black (default): same as world ambient color
   1 0 0 = red
   0 1 0 = green
   0 0 1 = blue
   .5 .5 .5 = grey
   1 1 1 = white
   etc.

   See editors/viewers for programs to make color selection easier.

   Note:

   1. Roland: "Unspecified prelight colors on vertices now default to the previously specified prelight color (if any) in the same clump, instead of to black. This allows multiple vertices to be initialized to the same prelight value without having to individually specify a prelight color for each one."
   2. AW3+ wireframe polygons are always prelit white.
   3. See prelighting for more tips and tricks.

polygon ("poly"/face/facet/side): More than one vertex (usually more than 4 when used in a RenderWare script file) connected together to form a polygon.

polygon # # # # # (tag <tag>)...: where the first # is the total number of vertices this polygon statement will connect, the second # is the first vertex, the third # is the second vertex, the fourth # is the third vertex, the fifth # is the fourth vertex, and so on

quad (quadrilateral): A 4-vertex polygon (i.e. a square or rectangle)

quad # # # # (tag <tag>): Where the first # is the first vertex, the second # is the second vertex, the third # is the third vertex, and the fourth # is the fourth vertex

triangle: A 3-vertex polygon ("tri" would probably be a better name to be consistent with "quad").

triangle # # # (tag <tag>): Where the first # is the first vertex, the second # is the second vertex, and the third # is the third vertex.
• Connecting vertices counterclockwise causes polygons to face forward while clockwise causes polygons to face backwards.
• Any number of vertices can be connected in any order to form a polygon, quad, or triangle, but keeping verts connected in a counterclockwise order will make forming polygons out of them and texture mapping them easier.
• "tag <tag>" is optional.

  Note: If polygon and/or quad commands are used in AW3+, since RW3 no longer supports non-triangle polygons, it (and AW3+) will tessellate polygon and quad commands into, essentially, "triangle" commands. This can cause some polygons to become distorted (not flat/smooth: /) that otherwise look fine outside of AW (older viewers, etc). The solution is to create the triangle polygons manually.

  Stephan Vogt (edited): "Polygons will render perfectly when the surface is a plane aligned to any of the primary axes but if the surface is curved, and most importantly, passes through the origin, distortion will result."

primitives: Simple ("primitive") premade shapes used to make modelling a little easier.

block: A six-sided cube (flat, equal-sided, or elongated) centered on the origin (where the axes meet).


block # # #: width, height, depth

Note: If a negative value is given for any one, two, or all three of (a) block argument(s), polygons forming the block will be reversed.

cone: A pyramid that can be smoothed into a cone, centered on the base.

cone # # #: height, radius (x-z plane), number of sides in whole numbers (3: pyramid to whatever: smoother "pyramid"/cone)

cylinder: A hollow tube centered on the base.

cylinder # # # #: height (0: flat "doughnut" to whatever: tube), base/bottom radius (x-z plane), top radius (x-z plane), number of sides in whole numbers from 0 (triangle) to whatever (smoother circle)

disc: A filled circle centered on the y-axis. These can be used to cap the ends of cylinders and cones, but be sure to use the same number of sides or gaps will appear.

disc # # #: height, radius (x-z plane), number of sides (in whole numbers from 0: triangle to whatever: circle)

hemisphere: A hollow pyramid to a cap/bowl/dome, centered on the base. These can be used to cap the ends of cylinders and cones, but be sure to use the same number of sides or gaps will appear (see note).

hemisphere # #: radius (x-z plane), polygon density (in whole numbers from 0: pyramid to whatever: cap/bowl/dome):
1: pyramid (4 sides/polygons)
2: 8 sides, 16 polygons
higher: cap/bowl/dome (rounder/smoother)

sphere: A cube to a ball, centered on the origin.

sphere # #: radius (x-z plane), polygon density (in whole numbers:
0: cube (6 sides/quad polygons)
1: diamond (8 sides, 32 quad polygons)
higher: ball/sphere (rounder/smoother)

Note:
• If negative radii are given, polygons forming the cones, cylinders, discs, hemispheres, or spheres will be reversed. However, in AW3+, at least cylinders and discs (and probably other primitives) do not require rotation to line up with the normal (unreversed) polygons as in previous AW versions.
• The number of polygons in hemispheres and spheres increases exponentially (a lot) with density, so be weary of complexity.
• Polygon density (hemispheres/spheres) is different in AW 3.2(?)+: a density of "2" (instead of "1") only has 4 sides (triangle/diamond), on top/bottom and 2 sides, instead of 8 (2 sides only). A workaround is to convert (with RWXMod) the hemisphere/sphere primitives into "full", expanded polygons.
• Use Andras' hemisphere program to create hemispheres of any number of sides.
• Vertex lightsampling will look "cleaner"/smoother than on non-primitives. However, light shading can sometimes appear weird (reversed, at odd angles, etc) after converting primitives to vertices and polygons with RWXMod.
• AW3+ will automatically texturemap primitives but most modellers won't (without explicitly telling them to anyway). To convert primitives to vertices and polygons, open and save the RWX in RWXMod (if you know of other programs that can do this, email me), then use a texture mapper (or manually apply the UV coordinates).

material

1. Each polygon has an associated material object, which defines the appearance of the polygon. Each material object may be shared by many polygons. Material objects encapsulate the following surface properties: geometrysampling type, lightsampling type, RGB color; ambient, diffuse and specular coefficients of reflection, opacity, texture, and texturemodes.
2. See geometrysampling, lightsampling, color, surface (which contains ambient, diffuse, and specular), opacity, texture, and texturemodes.

materialmode/addmaterialmode/removematerialmode: Sets overall material characteristics. In AW this is just whether or not polygons are single- or double-sided.
materialmode null: Removes material; default.
materialmode double: Renders polygons double-sided.

Note: materialmode double will only make one side of a polygon solid. "addmaterialmode" and "removematerialmode" can also be used but aren't necessary (and waste bytes) since there are only two materialmode commands: "double" and "null", unlike texturemode's 3 commands.

geometrysampling: How polygons are rendered.

geometrysampling pointcloud: Vertices; unsupported in AW3+.
geometrysampling wireframe: Edges or lined/connected vertices; unfilled.
geometrysampling solid: Filled; default.

Note: Wireframe polygons are always fully prelit (AW3+) and no matter what their surface don't reflect light; they also don't break up, fragment, and remain consistently visibly solid at long (+20m) distances unlike solid polygons.

• solidity/non-solid(ity): see collision detection

geometrysampling wireframe	geometrysampling solid	geometrysampling solid
no lightsampling or lightsampling facet or vertex	lightsampling facet	lightsampling vertex

lightsampling: how light is displayed across polygons

lightsampling facet
1. flat-shaded
2. no variation in shading or gradience
3. a single lighting sample per polygon at the polygon's center
4. makes polygons more noticeable
5. default

lightsampling vertex

1. Depending on direction of light source(s), light will shade/gradiate/fade smoothly cross polygons, brighter closest to the light source, and darker farthest.
2. Several lighting samples per polygon; one at each polygon vertex.

Note:

• Light will not fade uniformly across multiple objects; lightsampling is only a per-object (and sometimes per-polygon) effect.
• If texturemode lit is disabled, lightsampling won't work since the texture won't be able to reflect light based on the polygon's surface settings.
• RW 2.1's MMX driver displays light darker than the software and Direct3D rendering drivers.

color: specifies colors of polygons

color # # #: where #s are from zero (0) to one (1) in the RGB (red-green-blue) color system:
0 0 0 = black (default)
1 0 0 = red
0 1 0 = green
0 0 1 = blue
.5 .5 .5 = grey
1 1 1 = white
etc.

See editors/viewers for programs to make color selection easier.

surface

1. how polygons reflect light from light source(s)
2. Used to specify ambient, diffuse, and specular commands (coefficients) in a single command.

surface # # #: Where the first # is ambience, the second # is diffusion, and the third # is specularity:

ambient (ambience):
1. overall light intensity
2. Reflected light is non-directional, approaches from all directions, and is reflected to applied polygons with equal intensity.

ambient #: Where # is from 0 (default; no ambience—black) to 1 (full ambience—white)

1. .68 to .69 is about optimum ambience in AW 2.2; .5 in AW3+.
2. Values between 0 and 1 will show the polygon(s) color(s) in varying intensity.

diffuse (diffusion): Shaded (diffused) light from light source(s), causing effects ranging from a flat/matte finish to a smooth gradient (if lightsampling vertex is enabled).

diffuse #: Where # is from 0 (default; no diffusion) to 1 (full diffusion).

• I've found "1" is best in AW3+ for the most realistic light shading but will make objects appear bright white in AW 2.2. I use 0, .05, or .1 for objects in shadows, but I'm still experimenting with it.

specular (specularity): Highlight/glare/glossiness/shininess from light source(s).

specular #: Where # is from 0 (default; no specularity) to 1 (full specularity).

Note:

1. These three commands can also be used separately.
2. If texturemode lit is disabled/null, surface commands won't work since the texture won't be able to reflect light. However, AW3+ makes the texture appear like it has full ambience.
3. If lightsampling vertex is disabled, surface commands will look different because of how vertex lightsampling reflects light.
4. Specularity is not present in RW3 so it will have no effect in AW3+.
5. AW3+ wireframe polygons don't reflect light and act as if they have full ambient.

opacity (visibility/invisibility, transparency/see-throughness):

RW 2.1 uses dithering (faster, lower quality) in software and alpha blending (slower, better quality) in hardware (through MMX or Direct3D drivers) to achieve opacity; RW3+ uses alpha blending only.

opacity #: Where # is from 0 (no opacity) to 1 (default; full opacity); in between, .25 and .75 are the next consistently dithered opacities, followed by .38 and .63, then .14 and .87.

Note:

1. Finer opacity is capable with AW3+ (and AW 2.2 with RW 2.1's MMX driver--see AW performance settings--obsolete in AW3+) and/or Direct3D rendering enabled, but keep the consistently shaded opacities in mind for those who may not have MMX or Direct3D (or OpenGL with AW 3.2+) capability so the meshing of the lower quality dithering isn't as noticeable.
2. AW 2.2 has a problem (obsolete in AW3+) with the RW MMX drivers showing 0-opacity polygons as visible, but there's nothing in the RWX that can be done to fix this. See Princess Tia's MMX Bug page for more info.
3. opacityfix can (supposedly) fix the AW3.1+ problem of fragmenting overlapping transparent (opaque) polygons, but it is only for single-object transparency problems and it makes polygons flat-shaded. Shamus (edited): "I think the flat-shading is a natural side-effect of using opacityfix. It seems like the browser breaks the clump of transparent polys into individual clumps (1 poly per clump) and then sorts them. This explains why it is slower, and why it would be flat-shaded." However, I don't really see an improvement, unfortunately.

texture

1. A texture is an image that covers a polygon to give it a "texture".
2. RenderWare uses Windows bitmap (BMP) or Sun Rasterfile (RAS) format images, but Active Worlds uses JPG format for textures, which the RW 2.1 DLL drivers will reduce (depending on the DLL file) to a size of either 128 pixels wide x 128 pixels high or 256 pixels wide x 256 pixels high (if single frame), or 128 x n or 256 x n (with n being the amount of pixels in either 128- or 256-pixel increments—again, depending on the DLL) for multi-framed/animated textures) resolution automatically. Having the JPG/BMP 128x128, 256x256, 128 x n, or 256 x n textures/masks prevents RW from having to resize them once downloaded, if the texture(s)/mask(s) was/were higher than these resolutions). Note: RW3 and AW3 have different texture resolutions and requirements you should become aware of. Also, from Roland: "It's worth mentioning that the largest possible texture size you can use in AW is actually a function of your video card; not all video cards support textures as large as 512 x 512, while others can do 1024 x 1024 or even larger. However, the 3.0 browser *should* automatically scale any JPEG down to the largest possible supported texture dimension on your card; in other words, you'll still see the texture, just not with as high a resolution."
3. Textures are applied by assigning a texel color to each pixel within a projected polygon from an associated position within that image. This position is specified by a pair of texture coordinates, conventionally called (u, v) (see uv).

texture null default no texture Any texture associated with the current material is removed. From that point on, no texture is applied to the geometry created. texture <texture>: Where <texture> is the name of the texture, with or without the extension (".bmp", ".jpg",".ras"). mask An image used to make parts of a texture invisible/opaque/see-through/transparent. In RW 2.1, a mask is a black-and-white 1-bit resolution depth image the same size as the texture it is masking. The black part will be what is invisible/not shown, while the white part will be what is visible/shown. In RW3 and AW3, masks can either be 1-bit or up to 8-bit greyscale. Note: All masks will now reduce a texture's color bit depth from 16- to 12-bit because AW3 does not support 32-bit color. AW and RW use BMP format images for masks, which will be handled, resolutionwise, as textures are as explained above. more generic definition texture <texture> mask <texture>: Same as texture command above except with mask <texture>, where <texture> is the name of the mask, with or without the extension (".bmp"). Note: The texture doesn't need to have a black area around what is shown in the original image (tree3.jpg for this example). The black and white colors are only for the mask. If a texture and mask are declared for texturemapped polygons before the same texture (minus the mask) is declared for non-texturemapped polygons, the non-texturemapped polygons won't be textured in AW (will be polygon color) and will appear invisible in RWXMod. If the polygons are primitives, they still won't appear untextured in AW, and won't load (and will give errors) in RWXMod and possibly other modellers).

Texture/Mask Example (128x128 resolution tree3m) Because web browsers can't create masked images the same way AW/RW do, and to reduce file size, I use some GIFs for the above example.

---

texture mapping: Applying UV coordinates to vertices in order to place textures on an object.

• Refer to texture mappers and HenrikG's Texture Tutorial for a more detailed look into texture mapping.
• Lightwave (edited): "What I do to UV a side of an object is break the object up in Modeler and convert to (save as separate) pieces, use TexMap or UVMap on each piece, then protoinstance them together in the RWX. It gets harder when you want to cylindrical texture map an object like a can."
• Primitives are automatically texturemapped in AW3+.

---

texturemode/texturemodes/addtexturemode/removetexturemode

1. Sets lit, foreshorten, and filter settings for textures.
2. Permits fine grain control over the rendering of textures.

lit
1. Allows textures to reflect light based on diffuse and specular surface settings.
2. Texture is illuminated by light sources.
3. default

foreshorten

1. corrects distortion/"smearing"
2. Controls the interpolation of texture coordinates; by default, the texture coordinates specified at the vertices are interpolated bilinearly over the screen projection of a polygon. This method of texture coordinate interpolation is analogous to the luminance interpolation of Gouraud shading, and gives high speed performance. For perspective views however, this bilinear interpolation is only mathematically correct if the polygon is at a constant depth from - and therefore lies in a plane parallel to -- the view plane. The bilinear screen space interpolation of texture coordinates over the projection of a polygon which is not parallel to the view plane will "drift" away from their true values when the interpolation is distant from the projected vertices, although the interpolation always synchronizes with exact values at the vertices. Such inaccuracies are often negligible, but can be noticeable if a polygon extends over a significant depth range relative to the screen or projects to a large screen area. A large depth range introduces inaccuracies into the bilinear interpolation, whilst a large projected area allows plenty of screen "real estate" away from vertices over which these may accumulate. Such inaccuracies manifest themselves by the applied texture not being foreshortened as would be expected in a perspective image.

   The FORESHORTEN texture mode will ensure that exact texture coordinates are interpolated over the entire screen projection of a polygon, thereby rendering the expected foreshortening. However, the arithmetic underlying this interpolation can be significantly more involved than that for bilinear interpolation. The indiscriminate application of this texture mode can degrade performance to an unacceptable level. The FORESHORTEN texture mode should only [be] applied when texturing polygons for which bilinear interpolation is significantly inaccurate -- those extending over a significant depth range relative to the screen plane and projecting to a large screen area. The interpolation adopted in the FORESHORTEN texture mode has been optimized for polygons projecting to a large screen area, so that visual and performance integrity may be ensured simultaneously.

3. perspective correction
4. default in AW3+

filter Blurs (dithers) pixels to reduce aliasing. reduces the effect of pixelation due to aliasing; reduces texture aliasing artifacts arising from extreme texellation to make the texture map appear more continuous. By default, when "zooming in" to a textured polygon, the square texel boundaries become clearly visible, emphasizing discrete texel steps in the texture map. The texture map may be made to appear more continuous and hence realistic, since such sharp transitions tend not to occur in real world texture detail, by applying the [filter] texture mode. This mode smoothes the transition between adjacent texels to reduce the sharp edges which would otherwise appear. RW 2.1 uses software dithering and hardware alpha blending (like opacity); RW3 uses alpha blending only. bilinear texture filtering default in AW3+ Note: In AW 2.2 and below, filtering does not work if texturemodes lit and foreshorten, and lightsampling vertex are all enabled. In other words, RenderWare can't smooth textures on smooth-lighted objects. I told Criterion about this a few years ago and it seems they finally got around to fixing it for RW3, so this isn't an issue for AW3+. See how the Direct3D filtering example shows a fine edge around the offwhite areas? That's the background showing through the mask, and it should be blurred around the mask edges as well (like in the non-Direct3D filter example), but it isn't. Hopefully Criterion will fix that problem too... Seems the nVidia RIVA TNT2 Ultra chipset (or at least some card's implementation of it) and Matrox Millenium G200 don't have this problem (see Direct3D Support), which may imply a 3D chip limitation and not a RenderWare bug.

Filter Texturemode Example (Closeup of Tree3m)

---

textureaddressmode wrap, mirror, or clamp

Note:
• See AW3+ texture edgeline problem (local copy) when using this command and for single texture tiling problems in general.
• There is also an annoying seam bug using the "create texture" or "create animate" action commands to apply a texture (with or without a mask) not specified on a textureclamped object that hasn't already been downloaded as clamped. The texture will not be clamped if it is applied via an action command and has not already been used in an RWX with a "textureaddressmode clamp" command.
• Unlike most, if not all other RWX commands, textureaddressmode won't be applied to multiple prototypes (as a command usually is if placed after modelbegin and before the first protobegin). Put the textureaddressmode command inside the prototype.

texturemipmapstate on or off: turn mipmapping on or off

---

prototype

1. A way to minimize clump repetition by separation and modularity.
2. From section 19.3 of Ferraro's book: "Modeling prototypes are very similar to software prototypes. They are organizational constructs that allow objects to be built modularly. Prototypes are defined with the ProtoBegin and ProtoEnd brackets. Prototypes do not necessarily generate clumps. They are simply groups of commands that can be included into a structure using the ProtoInstance comand."
3. See tree shadow and Grover's Renderware Walk-Through: Transforms for more info and examples.

protobegin <name>: Where <name> is whatever name you want to call the prototype; begins prototype

protoend: ends prototype

protoinstance <name>: Where <name> is the prototype name as defined in protobegin <name>; calls prototype; placed after a clumpbegin

protoinstancegeometry <name>: Same as protoinstance except the materials are not used. This is useful for just the verts/polys.

Note:

• Prototypes can be used in other prototypes but only after the initial prototype is declared before the first clumpbegin.
• Most RWX commands (except textureaddressmode) can be applied to prototypes without having to declare each command separately within each prototype (see redundancy).

---

transform (transformation):

1. A shortcut for applying the translate, rotate, and scale commands in a single command; only use this if you understand matrix algebra (finite math).
2. primarily used in avatars
3. Take[s] a 4 x 4 transformation matrix as an argument, e.g., Transform, require[s] the matrix to be specified by a sequence of sixteen real numbers (separated by spaces) representing its elements. The Transform and TransformJoint scripting keywords expect the matrix elements to be specified in row-major order, i.e., the first four elements specify the first row of the matrix, and so on.
4. RenderWare uses 4 x 4 homogeneous matrices to represent 3D transformations. Rotation and scaling are encoded in the top-left 3 x 3 sub-matrix, and translation in the final row.

   transform # # # # # # # # # # # # # # # #:

   
   transform <scale x> <rotate #> <rotate #> 0 <rotate #> <scale y> <rotate #> 0 <rotate #> <rotate #> <scale z> 0 <translate x> <translate y> <translate z> 1

   Note: I am not 100% certain of the placement of transform commands, but I think everything is correct except the specifics of the rotate commands. Andras explains transformation better, and Just In has some images (transform, rotate) that illustrate it. Note how the rotations aren't really rotations at all but skews! So much for doing transform "rotations" using the rotate command. Oh well...

   Table 1: Transform 4x4 Scaling/Rotation Matrix

   scale x rotate rotate 0 rotate scale y rotate 0 rotate rotate scale z 0 translate x translate y translate z 1

   transformbegin: begins transform
   transformend: ends transform

   transformjoint: Allows limb/joint movement, specifically in avatars, but can also be used to pivot polygons or clumps of polygons (doors, handles, knobs, buttons). In Active Worlds, SEQs are used in avatars (although hopefully one day in non-avatars too) to take advantage of limb/joint movement, or transformjoint commands.

   transformjoint # # # # # # # # # # # # # # # #:
   
   transformjoint <scale x> <rotate #> <rotate #> 0 <rotate #> <scale y> <rotate #> 0 <rotate #> <rotate #> <scale z> 0 <translate x> <translate y> <translate z> 1

   Note: So much for non-avatar object pivoting support. Transformjoint is unsupported in AW3+.

   translate (translation): Moves/offsets/shifts polygon(s)/clump(s) linearally along an axis/axes.
   translate # # #: Where the first # is the x-coordinate (horizontal/width/left-to-right) distance to be translated, the second # is the y-coordinate (vertical/height/up-and-down) distance to be translated, and the third # is the z-coordinate (depth/front-to-back) distance to be translated

   rotate (rotation): Moves polygon(s)/clump(s) around (an) axis/axes.

   rotate # # # #: Where the first # is the x-coordinate (horizontal/width/left-to-right), the second # is the y-coordinate (vertical/height/up-and-down), and the third # is the z-coordinate (depth/front-to-back); the last # is the degree of the rotation.

   scale (scaling): Enlarges or shrinks polygon(s)/clump(s).

   scale # # #: Where the first # is the x-coordinate (horizontal/width/left-to-right) amount to be scaled, the second # is the y-coordinate (vertical/height/up-and-down) amount to be scaled, and the third # is the z-coordinate (depth/front-to-back) amount to be scaled
   Note:
   1. From Grover: "The correct position to place a scale [for objects with hierarchial clumping] is directly before the first clumpbegin statement. This will work in all avatars, even those with non-standard hierarchies or with absolute transform statements. If placed after the clumpbegin statement, the first transform statement within the clump will override it. Placing it above the clumpbegin means it modifies the transform matrix, and so even these will be scaled. Also be careful when using prototypes: placing the scale statement in the wrong spot will shrink the protoinstances twice."
   2. To get a mirrored version of an object, use "scale -1 1 1", but the polys will be reversed (use Andras' Backside program to reverse them).
   3. translate and rotate examples
   4. For more information on transforms, check Grover's Renderware Walk-Through: Transforms.

---

tag

1. Mainly useful for identifying parts of a hierarchical model so that they may be located and manipulated in an application program. A RenderWare application can then locate a particular clump within a clump hierarchy.
2. Placed before polygons or after a single quad, triangle, or polygon declaration.

tag <tag>: Where <tag> is a positive whole number
1. 0 (null; no tag; default)
2. AW-specific tags:
   avatar tags
   tag 100: sign
   tag 200: picture

Note:

1. In order for a picture tag to work correctly, the polygon(s) tagged must be texture mapped.
2. From Grover: "Tag 100 generally won't work on more than one [polygon] at a time and will sometimes cause other objects to turn black."
3. From Lightwave: "Tag 100 and tag 200 don't work in multi-clump objects but work fine on [polygons] in single clump objects."

---

axisalignment (sprite/facer/decal):

1. Keeps clump in-line with certain axes relative to camera (your perspective, depending on if in 1st- or 3rd-person view perspective mode).
2. Clumps may have their axes aligned with the "Look At", "Look Right" and "Look Up" vectors of the camera used to render that clump. This is mainly useful for creating sprites or decals (2D bitmaps aligned with the viewplane of the viewing camera). However, a clump's axis alignment type may be used to constrain the motion of any clump.

axisalignment zorientx: The clump's local Z axis is aligned with the Look At vector of the camera, but the orientation of the 2D projection of the clump's local X axis is preserved.

axisalignment zorienty: The clump's local Z axis is aligned with the Look At vector of the camera, but the orientation of the 2D projection of the clump's local Y axis is preserved.

axisalignment xyz: The clump is not axis aligned, it is unconstrained.

axisalignment noaxisalignment: Do not align the clump with the viewing camera.

Note: AW3+ axisalignment is handled differently and is no longer all axes like in RW 2.1. Because Criterion did not provide backward compatibility for sprites, Roland had to add them to AW3 but did not add full axis alignment (which I hope he adds an option for soon).

---

collision: Enables/disables collision detection (solidity).

collision on or off

Note: This command only works inside clumps (and it either collides as a whole or doesn't, unlike before AW3) and can also be used to make only specific polygons non-solid.

---

hints: Enable RenderWare to render a scene containing that clump more efficiently; hint arguments can be linked together.

hint <hint>: one hint
hints <hint> <hint>: multiple hints
addhint <hint>: add one hint to current hints
removehint <hint>: remove one hint from current hints

<hint> is one of the following hints:

container: The clump spatially contains other clumps.
Note: This hint may cause objects (and/or parts of objects) to disappear at different angles in a world.
editable
1. The clump’s geometry is editable (its vertices can be moved and new vertices and polygons added).
2. z-buffering will be enabled
   Note:
   1. From Shamus Young: "[This hint] seems to be required when you have an object where some surfaces [(polygons)] may obscure others. Without it, the surfaces may render in the wrong order."
   2. Seems to fix polygons that render incorrectly in front of other polygons (something which would make more sense by using the "hs" hint instead).

hs: Action should be taken to prevent hidden surfaces from being visible when the clump is rendered

Note:

1. I have yet to notice any improvement in performance in Active Worlds with hints. If you do, please email me with more information.
2. Hints are unsupported in AW3+.

---

includes: Reference (link to) another model into the current model without having to have the other entire model's code in the current model.

include: Inserts copies of the polygons and vertices of clump into the current clump under construction. The source polygons and vertices are transformed by the CTM before being added. The materials of the source polygons are copied to the new polygons.
include <file.rwx>

includegeometry: Inserts copies of the polygons and vertices of the clump into the current clump under construction. The source polygons and vertices are transformed by the CTM before being added to the current clump. The current material is assigned to the new polygons (the materials of the source polygons are ignored).

includegeometry <file.rwx>

Note:

1. Includes are only really mainly useful in testing how multiple models will look together (without having to go to AW to see them). Not all RWX programs support includes (I've only found Modeler to, actually).
2. Include and includegeometry are unsupported in AW3+.

---

z-buffer(ing): See nVidia's, Webopedia's, and Wikipedia's z-buffer(ing) definitions.

Script Command Defaults

default: Automatically assumed without declaring/stating/specifying otherwise; command does not need to be included in script.
null: nothing/void; no value

Command	Value
ambient	0
diffuse	0
specular	0
lightsampling	facet
geometrysampling	solid
color	0 0 0 (black)
opacity	1
tag	0
texture	null
texturemipmapstate	on*
texturemode	lit, filter*, foreshorten*
materialmode	null

* AW3+ only (but include for AW 2.2 backwards compatibility)

---

Introduction | News/Updates | Files | Measurement | Terminology/Script Commands
RenderWare Scripting (RWX) | Avatars | Links | Site Index | Search

---

^ Top