RenderWare is the rendering engine used for Active Worlds. A rendering engine is a library of subroutines that can be called from a program to show things on the screen. Unless you plan to build a competing product for Active Worlds or another 3-D environment such as a game or VR, buying RenderWare won't help you. This document is about making RWX models, which are 3-D models the RenderWare engine will interpret and display.
Building RWX models can be tough to learn if you have no experience with CAD or the like, since there is no high-end tool for building RWX models. However, once you get the basic concepts under your belt, you'll see that many objects can be created quickly and easily.
If you're serious about learning this, you should have the book "Learning 3D Programming on the PC" by Richard Ferraro, published by Addison-Wesley. This is essentially the User Guide that Criterion didn't include. Reading the whole book would take a good while, and much of the material is only suitable for programmers, but before trying to create RWX scripts you should at least read the highlights of the section on the Scripting Language and understand the basics of 3D rendering such as polygons, textures (and UV mapping), lighting, etc.. Ferraro's book is specific to Renderware 1.4, and Active Worlds uses a more current version, but the differences are minimal for our purposes.
If you can't get the book yet (check your library if you can't find it in the bookstore or are short on cash,) you can still fool around with scripts to see how you like it. All it takes is an RWX viewer and a text editor, for the latter Notepad (which comes with Windows) is fine. A viewer comes with the book but you can also download a more basic viewer from Criterion, the makers of RenderWare. Their web pages are at http://www.csl.com/RenderWare - http://www.csl.com/RenderWare/ and you'll find RWVIEW in their demo section. While you're there be sure to bookmark the RenderWare API documentation, which includes a lot of programming information you won't need but also has a section on the Scripting Language.
Before we go further let's define a few basics:
There are a two basic ways to make RWX scripts. The simplest approach for a basic object is to just type into the RWX file with a text editor. The other way to create objects is to import them from programs such as Caligari's TrueSpace or Autodesk's 3D Studio. We'll see that for simple objects the best approach is to just use a text editor, especially if you have AlphaWorld's base objects to draw on as an example. You should use a text editor to review RWX files even when you import objects, and in fact it is usually necessary to "tweak" imported objects at least slightly.
Making RWX Files Using a Text Editor
Text editors such as Windows' Notepad or programmers' editors are crude tools for making 3D objects, but they have advantages: the biggest advantage to making objects this way is that you have complete control; the big drawback is that it's difficult to make complex objects. But since complex objects don't render easily, the text editor is by-and-large the tool of choice for making models.
Using Visual Design Tools
You can also design AlphaWorld objects using high-end visual design tools such as Autodesks's 3D Studio and Caligari's Truspace. This method is especially suitable for making complex objects such as avatars. You design the object, save it, and then run one of Criterion's converters to create an RWX file from your design. Currently the only converters are from VRML objects, TrueSpace, 3D Studio, and Autocad's DXF format (which will not preserve textures.)
Once you have completed the conversion, you will need to take a look at your new object in a text editor and touch it up while viewing in Active Worlds or in a viewer such as RWVIEW.
Keep in mind that high-end visual tools are not designed to create optimized objects that will render quickly. You should work to make sure your objects are centered, and that they contain as few polygons as possible.
Let's make a simple model so you can "get your feet wet" with the concepts. First we'll use a text editor to create a simple panel, then we'll use Caligari's TrueSpace to create a more complex object and convert it to RWX format.
Before you make your first Renderware object, get a few pieces of paper and a couple of sharp pencils. Then open a text editor (not a word processor, they insert control codes.)
First let's make a very simple object, a four meter panel. The first thing we do is type in the basic commands to the Renderware scripting language to create a "clump":
modelbegin clumpbegin #Here's where all clump information goes. #Note that everything following "#" on a line #is ignored by RenderWare, the "#" is a "comment" #symbol. clumpend modelend
Step 2: Add vertices
Now let's add the vertices for the panel. At this point it is best to make a rudimentary sketch showing the vertices and their order, possibly something like this:
I can't tell you how important it is to draw these things out, especially with more complex objects, whether you can draw well or not! Especially when it comes time to do UV mapping, one sketch is worth a thousand trials! Well, a hundred anyway. :)
Now we'll add the vertices to our skeleton:
# Simple four meter panel..PAN4TEST.RWX modelbegin clumpbegin vertex -.2 .4 0 #top left vertex .2 .4 0 #top right vertex .2 0 0 #bottom right vertex -.2 0 0 #bottom left clumpend modelend
Vertices are declared in the order "X Y Z". All Active Worlds objects should be centered around 0 X 0 Z and the bottom edge of their bounding box should be at 0 Y (flush with the "ground.") This model will conform to those standards. The object has no depth, so all Z coordinates are 0. X coordinates are equidistant from 0 and Y coordinates start at 0.
Now to make our polygons we add two quad commands to actually create polygons. Since we declared our vertices in clockwise order this is simple:
# Simple four meter panel..PAN4TEST.RWX
modelbegin clumpbegin vertex -.2 .4 0 #top left vertex .2 .4 0 #top right vertex .2 0 0 #bottom right vertex -.2 0 0 #bottom left quad 1 2 3 4 #back side (clockwise) quad 4 3 2 1 #front side (counterclockwise) clumpend modelend
Now we're almost there already, but we want to add both color and surface properties and a bitmap texture. Let's say we're using a "grey stone" surface texture. We want the "flat" version of the model, which Active Worlds shows before the texture has been received across the line, to look similar to the textured version. So we use these values:
color .6 .6 .6 #red, green blue surface .5 .3 0 #ambient, diffusion, shininess
To get color and surface values right for Active Worlds' lighting, you really have to play with them and test within Active Worlds. The surface values shown above usually work fairly well.
Now we have to add UV values to our vertices to make sure the texture maps as we want it. UV is covered by Henrik G. in his UV tutorial. If you think of the bitmap as a piece of fabric, UV coordinates tell RenderWare where to place the fabric on the model. So each UV declaration is like a pin sticking the fabric to the model.
We can extend the fabric allegory a bit: think of the texture as a roll of fabric made up of up to 32 repetitions of the bitmap in each direction.
In general, it makes sense to wrap textures twice or more in a four meter square. If we wrap them too tightly they will render more slowly, especially in more complex objects. However, wrapping them too loosely creates objects where you can see pixels from too far away. What we're basically doing is wrapping a 128 pixels of bitmap across 12 feet of space. But before we double the UV values let's look at a one-to-one map:
vertex -.2 .4 0 UV 0 0 #top left vertex .2 .4 0 UV 1 0 #top right vertex .2 0 0 UV 1 1 #bottom right vertex -.2 0 0 UV 0 1 #bottom left
We assume some knowledge of what UV is about already, but basically the Y coordinate goes from 0 at the top to 1 at the bottom of the bitmap, X goes from 0 (left) to 1 (right). This maps the bitmap rightside up on the square polygon. But we want two copies of the bitmap, so we'll double all the UV values. While we're at it, let's add a texturemode so that the bitmap texture looks good from all angles. We'll use foreshorten because even though it slows rendering, it makes textured objects look much much better when you're not facing them head-on. We'll also use lit because we want our objects to use the lighting in AlphaWorld, showing shadow on one side and lighter color on the other. For objects that face upward or downward, the lit parameter isn’t necessary and should be omitted to speed rendering. But for objects with vertical faces, we’ll use lit despite the cost, so that we can make things look more realistic.
Here is our completed RWX file:
# Simple four meter panel..PAN4TEST.RWX modelbegin clumpbegin vertex -.2 .4 0 UV 0 0 #top left vertex .2 .4 0 UV 1 0 #top right vertex .2 0 0 UV 1 1 #bottom right vertex -.2 0 0 UV 0 1 #bottom left color .6 .6 .6 #red, green blue surface .5 .3 0 #ambient, diffuse, specular texturemodes lit foreshorten quad 1 2 3 4 #back side quad 4 3 2 1 #front side clumpend modelend
Most bitmaps used in your RWX models should be "seamless," that is, the right-hand edge should meet with the left-hand edge smoothly, and similarly the bottom and top should meet continuously. Then if we want to make a matching panel that is 8 meters x 8 meters, we just double the UV values (to multiples of 4 in this case.) This way we can make a suite of panels that all meet smoothly and look as if they were carved out of one piece of stone, wood, or whatever. For instance, the picture below shows two panels. The one on the left is twice as tall as the one on the right but they join "seamlessly."
8x8 and 4x4 panels with seamless UV mapping--
PP03L.RWX (left) and PP03.RWX (right)
Besides quad, the main commands for creating polygons to make up objects are triangle and polygon. For special purposes, there are also higher-level commands such as cone, cylinder, cube, hemisphere, and sphere. Keep in mind when you use these higher-level commands that although they may look simpler in the RWX file, they can create large numbers of polygons. Also, when you use a high-level command there is no way to map UV at the same time.
Here are some basic guidelines for developing objects to build a world. To make an environment where people will enjoy the overall speed of rendering. It's a constant trade-off: you must have realism, but not so much that it causes the client software to choke!
I am unfamiliar with high-end visual design programs other than TrueSpace so I can't give you tips about them. Also, tips about modeling in general using TrueSpace are beyond the scope of this document.
If you use TrueSpace to create RWX models you will probably have to "tweak" the output of COBTORWX to make the models work with RenderWare, for instance you'll have to remove the path references from each place that a texture is referenced, for instance texture c:\textures\mybmp.bmp becomes texture mybmp. It may help to save the model with a viewer program.
COBTORWX will scale your model with 1 meter = 1 renderware unit so you'll either need to make the model .10 times as large as it needs to be, or insert a scale .1 .1 .1 command in the RWX file just before the first clumpbegin.
To get a surface of .5 .3 .1 in the RWX file, make Ambience .5, shininess .3 and roughness .7 in the TrueSpace material (use the 1's complement for roughness, IOW 1 - the specularity you want.) It's more precise and quicker to rightclick on the "shader attributes" in TrueSpace and enter the surface values with the keyboard than to use the slider controls with the mouse.
TrueSpace's default values for complexity of primitives are higher than you need or want for real-time models. Use the right mouse button to click on any primitive's icon (for instance, sphere or cylinder) to reduce the number of polygons in the model. If you choose smooth shading for textures, this will translate to lightsampling vertex and make objects appear much smoother even with low polygon counts.
You can right-click on the mouse pointer icon in TrueSpace to get a dialogue of properties for the currently selected clump, polygon, vertex, face, or line. In this dialog you can enter coordinates, sizes and rotations directly, which can be much more efficient than using the mouse. Be sure to use this option to set the model's location to 0,0,0 before conversion. You should also use the axis tool to set the object's axis of rotation to the base of the model.
TrueSpace's coordinate system is different from RenderWare's--Y and Z axes are interchanged. COBTORWX compensates for this with two rotate commands in the RWX script. If you are making an avatar this will adversely affect the rotations of the joints and throw off joint articulations. To compensate for this in avatars, rotate the whole model 90 0 180 before conversion and after conversion remove the rotate commands.
If you have access to a C compiler and the RenderWare engine, you may want to create and/or change objects programmatically. There are commands in the RenderWare library are accessible from programs that do not have equivalents in the scripting language. For instance, you could create a hemispherical object using the HEMISPHERE script command, but you must use a program to create UV values for each vertex that will wrap a texture properly around the hemisphere:
RwSphericalTexturizeClump(sphereclump);
globetexture=RwGetNamedTexture("test.bmp");
RwForAllPolygonsInClumpPointer(sphereclump,
(RwPolygon3dFuncPointer)RwSetPolygonTexture, globetexture);
It is time-consuming to write programs just to generate objects, but occasionally there is a need for a really spectacular object to draw attention. Even with general building objects, if and object is to be rendered many times by many people, any time you can afford to spend with it to get it right is well spent.
One of the factors that causes the greatest slowdown in AlphaWorld rendering performance is Z buffering. Z buffering is used by Renderware to render objects that interesect, or that come close enough to intersecting that the engine can't tell.
One of the most important things to avoid is intersection with the ground plane. You should design your objects to terminate at 0 on the Y axis to avoid this. Since the ground is usually slightly below this point, this will avoid having Renderware render the ground and other objects much more slowly through Z buffering.
Animations are costly to make and costly to render, but they add a lot to the environment. Choose carefully which animations to support, and try to keep them minimal.
Active Worlds supports the standard Renderware animation technique of "stacking" bitmaps in a "filmstrip" texture. This method provides more control in environments where user construction is allowed, since only the named texture is used. It also allows you to control what surfaces of an object are animated. Another animation option is the animate command, which does not allow as tight control over where the animation is used, but allows much greater control over timing and ordering of frames.
Using "Filmstrip" Bitmaps
To use a "filmstrip" bitmap, you create a bitmap that contains all the frames of your animation "stacked" vertically. For instance, a 4-frame animation is 128 pixels wide and 512 pixels high. This texture is applied to a polygon within the RWX file with the texture command, just as if it were a non-animated bitmap texture. The main drawback to this approach is that the frame rate and order cannot be controlled as with the animate command (see below).
Using the Animate Command
You can achieve greatest control over animations using AW-specific commands.
Animations can be running or stopped, and looping or non-looping. Animations default to running and looping as with the filmstrip technique, but can be stopped or made non-looping. You can use triggers to change an animation’s state in various ways. See "Object Behavior in AlphaTech" for more details about triggers before proceeding here if you haven’tt looked at it yet.
Animate has six parameters: object name, animation name, image count, frame count, frame rate, and an optional list of frames which determines the playing sequence:
When an animation is applied to an object, it is applied to all polygons in that object. If you want only one surface of an object to be animated with the animate command, you’ll need to separate the object into two, so that the one surface to be animated can be addressed as a separate object.
Examples:
To assign a simple seven frame animation called "boggle" with a frame rate of 250 ms to an object, click on the object while using the AW client and enter this in the action field:
animate me boggle 7 7 250
To animate a figure jumping up and down, you only need to create images for the jump up, and then you can use them again for the trip down. Say you have 5 frames total from the bottom to the top of the jump. You’d get a jump up and down like this:
animate me jump 5 9 300 1 2 3 4 5 4 3 2 1
This next animation uses the same image sequence, but repeats frames to simulate a pause at the top of the jump:
animate me jump 5 11 300 1 2 3 4 5 5 5 4 3 2 1
Some additional commands have been added to supplement the animate command:
astop [object name] stops an animation. The animation running on any objects with name object name within sight are stopped. If no object name is given the object with the action attached is assumed.
astart [object name] <on/off> starts an animation, again with an optional object name. The optional on/off argument specifies whether the animation should loop. This defaults to off, so if you want to restart a looping animation that has been stopped, you must give an on argument or it will be changed to non-looping.
frame [object name] [+/-]<frame number> sets or increment an animation's frame number. The optional object name argument specifies which objects are affected. If a "+" or "-" is specified before the number, the current frame number is incremented or decremented by that amount. Otherwise, the current frame is set to the given number. If an animation is incremented or decremented past the end or beginning of its frame sequence, it automatically "wraps around."
adone <action> causes action to take place when an object's running, non-looped animation reaches its last frame. This allows you to chain together animated sequences across multiple objects. You can even use animation sequences to act as timing loops before another action such as a warp or teleport.
Examples
This creates a situation where an object’s animation changes frame every time the objects is bumped into (or walked through if the object is nonsolid and the user isn’t holding down SHIFT.)
bump frame +1
This creates an animated object that doesn’t start showing animation until bumped.
create animate me wow 10 10 300, astop; bump astart on
To expand this so that the animation starts when a hidden bump panel is touched, change the command on the animated object to:
create name s, animate me wow 10 10 300, astop
...and for the trigger wall's action use:
create visible off, solid off;bump frame astart screen off
To create three figures in a row that jump up and down, on the first figure use:
create animate me jump 5 9 300 1 2 3 4 5 4 3 2 1, astop; bump astart; adone astart fig2
on the second figure use:
create name fig2, animate me jump 5 9 300 1 2 3 4 5 4 3 2 1, astop; adone astart fig3
...and on the third figure use:
create name fig3, animate me jump 5 9 300 1 2 3 4 5 4 3 2 1, astop
When the first figure is bumped, it jumps up and down. Then the second one jumps up and down, then the third one.