Worlds.com

     |  Development Kit Table of Contents  |

Gamma Procedures - Advanced

 

Packaging Worlds

Note: World package names (such as "MyPack", which is used as an example throughout this checklists) should NEVER end in a digit, as this will cause confusion when a version number is appended.

Packaging a world (internal):

1. The following checklist assumes that the world is in a subdirectory of the GDK directory named "MyPack". Throughout this checklist, replace "MyPack" by the name of your subdirectory.

2. Open all your .world files in the shaper, and confirm that each world's "Multiuser" property is set to TRUE. If it isn't already, change it to TRUE and save the world.

3. If you want your world to have different worldsmarks than it used to, or if this is the first time you're packaging this world, do these four steps:

3.1 Delete your gamma.worldsmarks file from the GDK directory (feel free to back it up or rename it first, if you don't want to lose it).

3.2 Run gamma, and create any bookmarks you want your world to be installed with. They will be saved in gamma.worldsmarks. For instance, I'd Change Location to "home:MyPack\MyPack.world" and make a worldsmark for it.

3.3 Edit each worldsmark, and make sure it starts with "home:MyPack/someFile.world"

3.4 Exit gamma, and move the new gamma.worldsmarks file into the "MyPack" subdirectory. If you backed up your old gamma.worldsmarks file, you can put it back in the GDK directory now.

4. To make your world package smaller in size, it is a good idea to condense your texture files before packaging your world (but you don't have to). To do this, open your world in Gamma, go to the Options menu and choose Condense World Files. In the pop-up window, click on Condense. This will create a Content.zip within your world directory. All .cmp files will be condensed into this .zip file (.rwx, .rwg, and .bmp files will not be condensed). If you ever need to unzip the Content.zip, simply open your world file in Gamma, go to the Options menu, and choose Expand World Files.

5. If this isn't the first version of this world to be packaged, make sure you have either the zip file created last time you packaged this world, named "MyPack-123.zip" (where 123 would be replaced by the previous version number of this world) or a previous subdirectory named MyPack.old.

6. Make sure that you use the same upper and lowercase letters in MyPack this time that you used the last time you packaged this world. If you used "MyPack" last time, and you use "myPack" this time, it'll mess things up.

7. Make sure you have the following files in the "MyPack" subdirectory: your world files (MyPack.world, MyPack-Map.gif, MyPack-map.inf) your textures (preferably in a subdirectory) gamma.worldsmarks - see step #6 below.

8. Remove any old "MyPack000.exe" and "MyPack000-001.exe" files from the "MyPack" and GDK directories (where 000 and 001 are any old version numbers) if they exist. Either delete them or save them somewhere else.

9. Make sure you have plenty of disk space on the drive where your GDK is installed. You may need 4 or 5 times as much space as the total of the files in the "MyPack" directory. You can find out this total by selecting the "MyPack" folder in Windows Explorer, and using the "Properties" command (on the "File" menu). It will show how much space is used by the "MyPack" directory, and how much space is available on the drive.

10. In a DOS box, go to the GDK directory. If you have packaged this world before, run the following command:

package MyPack MyPack-123.zip
or
package MyPack MyPack.old
(as needed)

If you have never packaged this world before, run the following command instead:

package MyPack -

Remember to replace "MyPack" by the name of your package, and "123" by the previous version number.

11. The package command will generate a file named "MyPack456.exe" in the GDK directory. If this isn't the first version of this world, the package command will also generate a file named "MyPack123-456.exe", where 123 will be replaced by the old version number, and 456 will be replaced by the new version number.

12. The package command will also generate files named "MyPack-456.zip" and (if this is an upgrade from an older version) "MyPack-123.zip".

13. Find someone to test the new full install on their machine (not the machine on which you did the packaging). This person will be referred to as the "Tester" below.

14. Have the Tester install MyPack456.exe into an internal GDK on their machine.

15. Have the Tester check that you can get to the world via the worldsmarks menu. Have the Tester check that the world still works.

16. Find someone to test the upgrade on their machine (not the machine on which you did the packaging). It might be a good idea to do this test a machine different from the machine which was used for the test in steps 10a-12 above. This person will be referred to as the "Tester" below.

17. Using your web browser, get the file "http://dev.worlds.net/newup/MyPack/upgrades.lst" if it exists, and save it locally.

18. If you got upgrades.lst in the last step, open it with a text editor. If there was no upgrades.lst in the last step (because MyPack hasn't been uploaded before) create a new upgrades.lst in a text editor. In either case, add a line of the form "123 999900456#778899:1214" to the end of the file, where 123 is the last version of MyPack as in step 9, 456 is the new version of MyPack that you're going to upload, 778899 is the size of MyPack123-456.exe in bytes, and 1214 is the last "everyone" version of Gamma prior to the one that you used to create it. Note that before the pound sign, you should have 9 digits: four '9's, a string of '0's, and your version number. To find the last "everyone" version, look in http://dev.worlds.net/newup/index.html for your gdk's version, say it's 1216. Look at whether the version number for 1216 is normal or light-colored, and scan down until you find the first normal-colored entry. In this case, 1216 is light colored, so you scan down and find 1214 is the next normal-colored entry, so you use 1214 in the upgrades.lst line above.

19. If you are going to make the full version MyPack456.exe available, insert a new first line into upgrades.lst, of the form "-1 999900456#789789:1214". Values are as in step 17 above, and 789789 is the size of MyPack456.exe in bytes.

20. Save upgrades.lst.

21. Ftp "MyPack123-456.exe" and "MyPack456.exe" to the "newup/MyPack" directory in the www account on dev.worlds.net. If this is the first time an upgrade of this world has been uploaded, you'll have to create the "MyPack" directory in the "newup" directory before you can upload to it.

22. Ftp the new "upgrades.lst" to the "newup/MyPack" directory in the www account on dev.worlds.net. Don't start ftping it until "MyPack123-456.exe" and MyPack456.exe have finished transferring.

23. Ftp an empty file named "timestamp.upgrades" to the newup directory in the www account on dev.worlds.net. This must be done after step 18 above, to get the file time on the server set correctly.

24. Ftp an empty file named "timestamp.dir" to the newup/MyPack directory in the www account on dev.worlds.net. This must be done after step 18a above, to get the file time on the server set correctly.

25. Verify that "MyPack123-456.exe", "MyPack456.exe" and "upgrades.lst" all exist in the "newup/MyPack" directory on dev.worlds.net, and have the correct sizes.

26. Have the Tester Edit the "worlds.ini" file in the GDK on their machine. In the [Gamma] section, add a line that says "TESTWORLDAUTOUPGRADE=10".

27. Have the Tester run Gamma. The Tester should choose "Upgrade now" from the "Options" menu. Have the Tester confirm that your upgrade gets downloaded and installed correctly.

28. Have the Tester delete the world's subdir from their Gamma directory, and then run Gamma. Have the Tester confirm that the full world download works correctly.

29. Edit "upgrades.lst". Change the lines you added to the form "123 456#778899:1214" (that is, get rid of the four '9's and the '0's), and "-1 456#789789:1214" (ditto). If there is another old line in upgrades.lst that starts with "-1 ", besides the one you just added, delete the old line.

30. Ftp the new "upgrades.lst" to the same place (the "newup/MyPack" directory in the www account on dev.worlds.net).

31. Ftp the empty file named "timestamp.upgrades", again, to the newup directory in the www account on dev.worlds.net. This must be done after step 22 above, to get the file time on the server set correctly.

32. Have the Tester remove the "TESTWORLDAUTOUPGRADE=10" line from their "worlds.ini" file.

33. Using your web browser, get the file "http://dev.worlds.net/newup/MyPack/index.html" if it exists, and save it locally. If it doesn't exist, you'll have to create one. The best way to create one is to copy one for an existing world package and change it to refer to your world.

34. Edit the index.html file you got in the last step, adding an entry to the top of the table describing your new version of your world. Save index.html.

35. Upload index.html to the "newup/MyPack" directory in the www account on dev.worlds.net.

36. Verify that "index.html" exists in the "newup/MyPack" directory on dev.worlds.net, and has the correct size.

37. Delete any old "MyPack012.exe" (except for the very first version, and of course the one you just uploaded) from the "newup/MyPack" directory on dev.worlds.net, to save disk space.

Top of Page

Updating Worlds

Written by Frank Kane
11/27/00

This document presumes that you have created a world updater and want to distribute it to the world. As an example, it will presume that you are uploading the world update to the ENewMedia servers at server01.worldsinasia.com and server02.worldsinasia.com. For other situations, substitute the appropriate upgrade servers wherever you see these names.

Follow these steps:

1. FTP to server01.worldsinasia.com using the www account, and navigate to the subdirectory of the 3DCDup for the world you wish to update.

2. Upload the updater .exe file to this directory (ie GroundZero21-22.exe). Be sure to use “binary” mode for all FTP transactions!

3. Download the upgrades.lst file from this directory to your computer, and open it up in a text editor.

4. Add a line to upgrades.lst describing the new updater. This line is of the format:

<previous version> <newversion>#<filesize>:<required client version>

So for example, to create an updater for version 21 to 22 where the updater .exe file is 41233 bytes and the updater was created using version 1804 of the WorldsPlayer, the line would be:

21 22#41233:1804

5. Upload your new, edited upgrades.lst file to the upgrade server, replacing the old one.

6. Repeat steps 1-5 for server02.worldsinasia.com, or any other upgrade servers that you need to post your world upgrade to.

7. Delete your file cache by deleting the contents of the “cachedir” directory in the Worldsplayer installation directory on your computer.

8. If you have uploaded your upgrade to a server that is mirrored to multiple actual servers, wait for your upload to propagate.

9. Test the update by launching your WorldsPlayer.

Top of Page

Universe Map

Within your Internal Worldsplayer directory, there's a directory called Universe. Within this Universe directory are two files, Universe.dat and Universe.jpg. Universe.jpg is the background image (stars and planets) for the Universe Map. Universe.dat is a text file that tells the program where on the Universe.jpg image to position the text for all the worlds available for download.

Below is a section of the Universe Map as it appears to the user:

In the Universe.dat file, each world is listed with a set of coordinates and text that designate where and how the world is displayed on the map. For example, Ground Zero is listed in the .dat file like this:

296 274 302 269 GroundZero 0 Ground Zero

Each of the items listed in the .dat file are explained at the top of the file.

·  The first two numbers are the location of the small circle that will be to the left of the world name. This circle appears as a red "open" circle if the user does not have the world and a red solid circle if the user has the world. A solid green circle indicates the world the user is currently in.

·  The next two numbers are the "button" coordinates, or the upper left corner of where the text (name of the world) will be located. Generally the x coordinate is the circle's x coordinate plus 6 (in the example above, 296+6=302). The y coordinate of the button is the circle's y coordinate minus 5 (in the example above, 274-5=269).

·  Next is listed the "package" name, or what the world's directory and .exe file are named on the server. In the example above, GroundZero.

·  The number after the package name designates whether a world is public, private, proscribed or special order. Generally the worlds are public, but below is a brief description of what each of these terms means:

  • 0 - Public worlds are shown to everyone.
  • 1 - Restricted worlds are shown only if this user is noncloistered (designated by a file in the users home directory), or the user already has that world loaded.
  • 2 - Proscribed worlds are shown only if the user is noncloistered (designated by a file in the users home directory), not even if the user already has that world loaded.
  • 3 - Special Order worlds are shown only if the user already has that world loaded.

·  Lastly you need to designate the "text" for the world as it will be listed on the Universe Map. In the above example it's "Ground Zero" - this is the text that will be listed next to the circle on the map.

Top of Page

Utilizing 3D Studio Max files

Creating a World in 3D Studio Max

  1. Create your world in 3D Studio Max, with all the rooms in one big space. You'll be exporting it to Gamma in room-sized pieces, but by building it all in one space you won't have to deal with coordinate conversion issues. In Max, use units of 1 per meter, and be sure to turn off automatic unit conversion and then build the world from scratch, or your scaling will be messed up. You can make ramps and walking areas of different height in MAX, but after importing the MAX file into Gamma, you'll need to create floor patches over any floor not set at 0 in height.
  2. Follow the general rules in this document to make a world design that Gamma can draw quickly.
  3. Make rectangles for portals. The portal must be a straight upright rectangle -- that is, it must have a horizontal bottom edge and a vertical right edge. Use a wireframe material for the rectangle in Max so that it'll become invisible (and replaced by a portal) when it is imported into Gamma.

Each portal rectangle belongs to one room, and connects to another. Suppose these are respectively called room1 and room2. When saving the rooms, the portal is saved as part of room1, and not saved as part of room2. The name of the portal must contain the phrase "portal room2" within it: that is, the word "portal" followed by the name of the room that the portal connects to. For instance, "room1 portal room2" would be a valid name. Room names must be 5 or fewer characters long.

The border between two rooms has to be flat, and all the pivot points for all the objects in both rooms have to be in the same spot in the portal area.

Do not make the rectangle double-sided; it's important that you can see the rectangle only from room1, not from room2.

  1. Make rectangles for bumpers. These must be upright rectangles in the same way they were for portals, above. But a single object may contain many such rectangles. Include the word "bumper" in the object name, such as "bumper5", and use wireframe material for the object, and Gamma will convert it into invisible bumper surfaces upon import. You may also include the word "bumper" in the name of non-wireframe objects, like regular walls, and bumper surfaces will be generated for them, too.
  2. Make an animated polygon if desired. There may be only one per room shape, but the animated polygon may be any shape desired, as one and only one texture is applied to the entire polygon. Include the word "animated" in the object name in 3ds max (some might think of this as the face name in 3ds max), and Gamma will flag this polygon for texture replacement by any attached AnimateAction.
  3. Save each room separately, to a file called roomname.rwx. For instance, the two rooms involved in the portal in the previous paragraph would be called room1.rwx and room2.rwx. Save with "Scale by 1" and don't check the "center object" checkbox. Usually models look best with the "Lit" checkbox in the export dialog box checked, and with "preserve hierarchy". Do not choose the "flat (single clump)" option; that'll produce a file that crashes Gamma.
  4. Run "max2rwx whatever.rwx" to prepare the exported file from Max for import into Gamma (works only with 3D Studio MAX 2.5 - see the 3D Studio Max to Gamma section for other conversion options). If you fail to do this, portals and bumpers won't be recognizable to Gamma. See section about about setting up to use world-builder commands.
  5. (Optional) Run "rwx2rwg roomwhatever.rwx" to convert the room to an rwg file. This is necessary for the final product, since rwg files load into Gamma more quickly than do rwx files. But during development it will be convenient to skip this step and load the rwx files directly into Gamma. Be sure to come back and reload rwg files in place of the rwx files before you ship the world!

rwx2rwg will print out lines stating the names of the cmp files that will be required to load the rwg into Gamma. Run "compit name.bmp" on each bmp file to convert it to a cmp.

  1. If you are starting from scratch, start with an empty world in Gamma. The easiest way is to use File/New, then to create your first room as described in the next step, then to WorldsMarks/Change Location to the new room, then to delete the initial room that came in as part of the New World. Don't delete the initial room until you've changed location away from it, as that will crash Gamma.
  2. The next few steps should be repeated for each room you add. Add a room by dragging from the library's Objects tab either ShapedRoom or SlowShapedRoom to the main window. This creates a new room in the world. Select its name in the property window and rename it to match the room you are loading. A ShapedRoom has the underlying RoomShape in its Environment, while a SlowShapedRoom has the RoomShape in its Contents.

A variation that isn't supplied as a prebuilt room is to have a RoomShape in the Infinite Background of the room. You can cut or copy and paste the RoomShape, and can even have multiple RoomShapes at once, although only one RoomShape in a room may have portals or bumpers. For a room destined to become on infinite background, save the room from Max with the "center object" checkbox set.

  1. Use WorldsMarks/Change Location to move the camera into the new room, by replacing everything after the # in the text box that comes up, with the new room name. All you'll see at this point is a small cube, which represents the non-yet-loaded Shape for this room.

At this point, if you are creating the first room in a new world, set that room's name into the Default Room Name property of the world. Then save your world so that the .world file is in the appropriate directory, and restart Gamma and load the .world file. This will cause Gamma to look in the right place for loading rwx files in the next step.

  1. Right-click on the cube and choose Properties. Then enter your roomwhatever.rwg into the file property of the RoomShape. This loads the rwx model in, and by turning around you should be able to see it. The cube you were originally looking at was at the 0,0,0 of the space, and the loaded room will be at whatever coordinates it was created at, so it might be off in the distance a bit.

If the cube remains, there was an error loading your model. The most common problem is for one of the textures to be missing that the model calls upon. If you're loading a .rwg, make sure that every needed .cmp is in the same directory as the .rwg. If you're loading a .rwx, make sure that the corresponding .bmp files are all present. You can look at the .rwx file with a text editor if you like to see what .bmp files it is expecting, and to check to make sure it has the right Max objects in it.

Make sure there are no cameras, lights, grouped objects or any other type of maps other than bitmaps in the 3D Studio MAX file.

  1. Set the RoomShape's PrepareRoom property to true. This causes Gamma to activate any portals and bumpers in this room. If you haven't yet loaded the target room that a portal points to, that portal won't activate yet; and after you do load that target room you'll need to come back to this room and set its RoomShape's PrepareRoom property to true again, to activate it.
  2. (Optional) If you want, move the camera until it's inside the new room, and look at WorldsMarks/Change Location to see your location. Then transfer the x,y,z and perhaps orientation to the Room's default position properties. These are the first four numbers after the room name and @. Doing this will cause you to start up at the new location upon loading the room, rather than off in the distance when you go to this room during further development.

It is also possible to add one or more RoomShapes to a room that contains other objects. Just drag Shape from the library's Objects tab to the desired position, reset its Transform property's position to 0,0,0, and change its file as desired. Or, copy and paste a RoomShape from an existing room, which will already have the Transform set properly. Move the Shape into the room's environment or infinite background with cut and paste if that would be more appropriate.

Room Model rwx file format

Special values for the tags in the clumps in a rwx file are used to tell Gamma that it should handle those clumps specially, when the PrepareRoom property is set true as described in the section above.

A tag value with bit 30 set means that this clump is a portal. The lower bits are five 6-bit values. Add 32 to each of these to convert to ascii, and convert to lowercase. The result is the room name that the portal will autoconnect to.

A tag value with bit 29 set means that this clump is a bumper. Lower bits are ignored, except that bit 28 can also be set according to the paragraph below. The clump is scanned for upright rectangles, and an invisible Rect is built for each. Each rectangle must be represented in the clump as two triangles, joined at the rectangle's diagonal. It's an error to have any other sort of polygons in the clump, and will produce warning messages to the Gamma logfile upon import.

A tag value with bit 28 set means that this clump is animated. Lower bits are ignored. All triangles in the clump are assumed to have the same texture applied to them, and this texture is replaced on all these triangles when the AnimateAction is attached to the Shape.

A tag value with bit 27 set means that this clump is a placeholder for a child clump to be connected to a placeholder. The child has the same tag value but without bit 27 set; this tag must be < 31. The transform of the placeholder is copied into the child. This feature is activated only for xParts, the special parts used for composed-of-parts avatars.

A clump with the wireframe geometrysampling mode will be turned off upon being loaded into Gamma, becoming invisible. Usually portals and bumpers are built as wireframes so that they'll get out of the way of their replacements that are built by the PrepareRoom procedure. But one is permitted to have non-wireframe portals and bumpers, which won't go away.

3D Studio MAX To Gamma

by Petr Kyn

Overview

Gamma uses Criterion’s Renderware realtime 3D Engine to display realtime 3D environments. Gamma allows the user to create 3D scenes with texture maps, lighting effects, animations, and triggered actions, although it allows the user a fair amount of modeling control, it is not a a full 3D Modeling tool. So it is quite beneficial to use a 3rd party application like Discreets 3DS Max.

This document was written to aid a 3D Artist in how to model in 3DS Max and export it into Gamma. It will cover modeling procedures, tecniques and the steps to import it into Gamma.

Exporters

This document will cover three exporters that convert into the Renderware "RWX" format, the Criterion Renderware stand alone converter (Rw3dconv.exe), the Criterion Renderware converter plugin (rwexp.dlr) and Okino’s PolyTrans.

    • Criterion Renderware converter plugin (rwexp.dlr) is available for download at http://developer.renderware.com/updates/rw2.1update.htm at no charge, but it has many limitations and certain modeling procedures need to be followed in order to get the expected results.
    • Criterion Renderware stand alone converter (Rw3dconv.exe) is not available for download and has fewer limitations but is somewhat more time consuming to use.
    • The Okino PolyTrans converter is the preferred converter with a cost of about $380.00 with minimal export limitations. It also allows the user to convert using a plugin or a stand alone applications. It is the only one that supports MAX 3.0.

RWX

The RWX format is a proprietary format created by Criterion for the Renderware 3d Engine. A rwx file is an Ascii file with a description of the exported Max scene. It includes all the mesh information with its mapping (even hidden meshes), materials assigned to the meshes and it exports it as one object. It does not store any animation, camera or light information. During export it will convert all objects to strickly mesh information creating a list of vertices and triangles (faces) that connect the vertices.

Materials

The Material data stored in a RWX containes, Shading type (constant or vertex), light sampling (wire or 2-sided) it also contains a texture map and mask. The texture map information comes from Material/Maps/Diffuse in the Material description of a Standard Max material. The Mask information comes from Material/Maps/Oppacity in the Material description of a Standard Max material. The mask uses the color 0,0,0 to determine which pixels should be invisble. When using cmps with transparencies it is not necessary and in most cases inefficient to use a mask Opacity is stored and is displayed as dithered pixels or true opacity.

It does not use Shininess, Shininess strength, Self-illumination, filter or opacity falloff. When using lit it also uses Ambient, Diffuse and Specular, but the Specular shows up with different intensities on different computers, so it should be used with this in consideration (this problem yet to be resolved as of 11-18-99.)

Lighting

Renderware does not allow for lights to be imported so the only light to consider is the the light used in Gamma. There is one directional light in each room that can be turned to any direction and changed to any RGB color. When a model is exported with "Lit" on, it will recieve the lighting from the given room that it is in.

Animating RWXs

In order to translate or animate objects in Gamma they need to be exported separtely from the rest of the scene, and since it exports meshes that are hidden it becomes necessary to either save them as separate files or delete the unwanted meshes in each export.

Animated Materials on RWXs

In Gamma a "Shape" can have an Animate Action which allows for a list of frames that will animate as a texture on the object using its predefined mapping coordinates. It allows for only one object and not a loft or compound object per file.

Exporting Procedure

The process is pretty simple and straightforward.

    • Using a plug-in exporter.

5.      Model a scene in Max.

6.      Using Export save the file as an RWX or PolyTrans RWX and save it in the "tex" directory.

7.      I In Gamma drag the Object "Shape" onto the screen.

8.      Set the filename of the RWX under "file" using the path "tex/"

    • Using a stand alone exporter.
    1. Model a scene in Max.
    2. Using Export save the file as an 3ds file.
    3. In PolyTrans or Rw3dconv.exe open or import the file.
    4. Then Save as or Export the file as an RWX.
    5. In Gamma drag the Object "Shape" onto the screen.
    6. Set the filename of the RWX under "file" using the path "tex/"

 

Export Parameters

Certain parameters should be set for the best result.

For rwexp.dlr and Rw3dconv.exe:

If "Center object" is not checked it will uses the origin defined in Max Scene, otherwise it will center the origin on the object.

If "Scale by" is set to one, it will match the units to the Max units. It is important to note that the default Max scale is much bigger than the default Gamma scale, so if you can not see the object in Gamma, try scaling it down. It is good to start modeling after zooming in.

"Hierarchy" should be set to "Preserve Heirarchy"

"Forshorten" should be checked on.

If there are texture maps in the scene "Show Textures" should be ckecked.

If using CMPs, "Override Extension" should be set to CMPs. This will allow the scene to use the compressed form of the BMPs. With this enabled the Cmps need to have the same name as the Bmps and if one is missing the rwx will not show up in Gamma.

For PolyTrans:

The default options works very well and there are also some options which seem to be very beneficial which need to be further explored.

Converter Bugs and Anomalies

Here is an accumulated list of problems and limitations base on each converter. This list although thorough, is a work in progress so there may be more problems that surface other fixes around current problems. In each case the problem is specific to the converter and generally another converter should not have the same problem. All of these limitations and problems are very important because it will alter the modeling process dependant on the converter.

  

 Problem

Details

Fix

Converter

1.

Concave Objects

Any object with a concave surfaces that also has backfaces will run into z-buffering problems.

Detach groups of faces into sperate objects so that each single object has no concave surfaces. This can be done with a Loft objects by splitting up the shape as well.

rwexp.dlr

2.

Smoothing Anomolies

Some primitives like spheres have apparent seems because how smoothing is calculated.

Lathe shapes to create cylinders or spheres and then using Edit(able) Mesh weld the vertices.

rwexp.dlr

3.

Smoothing Types

Smoothing is calculated by mapping type, using either cylindrical, spherical, shrink or planar. You can not change smoothing without changing map types.

Either break apart selected faces to control the smoothing groups or using Mesh Select and UV map Gizmo apply mapping to groups of selected faces on the object as many times necessary to create different smoothing groups.

rwexp.dlr

4.

Map-Tile Limitations

Tiling an object more than 26 times creates abnormal tiling on certain faces.

Detach the problem faces as separate objects and apply unique mapping.

rwexp.dlr

5.

Map-Tile Multi-subobject Material

At about 4 sub-materials the current mapping is disrupted. NOTE: You can use more, and it will work, however in Gamma you will see a 1-2 pixel line between the materials. It is an rwx problem.

Detach any faces and apply unique mapping

PolyTrans

6.

Animated Material

Apparently Objects can not use the Gamma Animate action.

Use another exporter.

PolyTrans

7.

Animated Material is Unlit

When using the Animate Action the Object becomes unlit.

None Available

rwexp.dlr

Rw3dconv.exe

8.

Mirroring

Mirroring an object flips the normals.

Flip the normals back.

rwexp.dlr

Rw3dconv.exe

 

RWG

The RWG format is a binary form of the RWX file. The executable Rwg2rwx.exe will convert the RWX file to RWG. On the process please see the "Fast Worlds" document.

Data Size

One must consider the size of the file not only the polygon count due to the fact that its intent is for download. There are a number of factors to take in to consideration when creating scenes.

    • The more faces the larger the file.
    • The more objects (not necessarily the any more faces) the larger the file.
    • Saving the file with comments creates a larger file.

 Renderspeed

To increase Render speed following certain techniques is helpful.

    • Modeling with a low polygon count.
    • The fewer overlapping objects the better.
    • Use double sided material sparingly.
    • Dividing rwx into separate rooms that are separated by portals with doors.
    • Delete the faces you not going to see

 

 Z-buffering problems

There are things to whatchout for in order not to get z-buffering problems.

    • When close overlapping objects are pretty far away they tend to have z-buffering problems.
    • Avoid creating T-joints they create cracks. Always connect all vertices to other vertices and to to edges.
    • Use 3D snap to connect vertices and faces, so there are no cracks.

Production Methodology

It is possbile to model entire Worlds just using Gamma and almost possilble just using Max. There are certain things which will not be possbile, like Actions and Behaviors (which are a critical elements to Worlds creation.) But for the modeling of the environment, Max will do a pretty complete job.

There are two steps which complete the building process of a World. Bumpable Walls and portals, both of these can be created by exporting Max and converting them in Gamma. Please reference "Building Gamma Worlds" on how to export Max objects that become bumpers and Portals. NOTE: Works only with 3D Studio MAX 2.5, but not with 3.1

Using higher-res textures in 3D Studio (RWX)

By Eni Oken

One can use Gamma's high-res feature (see comp2h2v above) only with Rects, not with more complex models. However, inside 3D Studio it is possible to split an object made of polygons into 2 or more separate objects in order to assign more than one 128 image. For example, to split an object into 4 separate objects:

    1. Create an object with normal tools. If creating a spline, convert it into Editable Mesh (clicking on the stack modifiers or using the Edit Mesh command).
    2. In a viewport facing the frontal part of the object, apply a modifier UVW mapping, choosing Planar, then View Align and Fit to make the UVW gizmo align perfectly fit to the object. Assign 2 for the U tile and 2 for the V tile.
    3. In the modifier stack, click on the stack and ask to collapse all. This will convert the object into Editable mesh again, but will maintain the mapping coordinates embedded in the object.
    4. Choose the Sub-object Edge and click on Slice Plane. A yellow icon will appear. On the top view, looking down on to the object laterally to the slicing plane, rotate the slicing plane at 90 degrees, using the Angle snap on for precision. Click on Slice to finalize the slicing of the object.
    5. On a viewport facing frontal to the object, rotate the slicing plane again, 90 degrees and click on Slice again. This command splits the polygons of the object, without creating separate objects.
    6. Choose Sub-Object Face and select the upper quadrant faces and ask to detach (assign a new name for the object, such as object 01). Repeat with each quadrant.
    7. Create a texture in Photoshop or other program with 256x256 resolution. Using the rectangular select tool, click on options and choose Style Fixed Size, and determine it to be 128x128.
    8. Select portions of the 256x256 texture (upper left, upper right, lower left and lower right) and save them as 4 separated 128x128 images.
    9. In 3D Studio, create 4 separated materials, numbered respectively according to the textures, and apply them to the correct quadrants.
    10. Export normally as rwx.

Note: if you use another approach that results in inexact splitting of the texture across the subobjects, the max2rwx converter might not be able to fix up the file properly, resulting in visible joins between the subparts once they're imported into Gamma. This happens when UV texture coordinates in the resulting rwx range from 1 to 2 rather than the usual 0 to 1 range. max2rwx will fail to adjust this if some of the UVs fall outside of the 1-to-2 range due to inexact conversion.

Top of Page

 

Articulated Avatars

To be an articulated avatar, a model must be in .bod format, and be stored in the avatars subdirectory; they aren't currently loadable over the network. The .bod file is made from a .rwx using rwxtobod, for instance "rwxtobod amy" makes amy.bod from amy.rwx.

The .rwx file must use y as its height dimension, and use units of 1 unit = 10 meters. This is the ActiveWorlds avatar format.

The avatar must have the following hierarchical structure of clumps, each of which is identified by a comment line in the rwx, in the standard form put out by the 3DS Max converter to rwx. For instance, the pelvis clump must be preceded by the line "# pelvis".

 

      

 
P   pelvis
B     back                 <-- front and back of abdomen
N       neck
H         head
L       lfshoulder         <-- left upper arm
M         lfelbow          <-- left forearm
O           lfwrist        <-- left hand
R       rtshoulder         <-- right upper arm
U         rtelbow          <-- right forearm
V           rtwrist        <-- right hand
I     lfhip                <-- left thigh
J       lfknee             <-- left calf
K         lfankle          <-- left foot
W     rthip                <-- right thigh
X       rtknee             <-- right calf
Y         rtankle          <-- right foot
Z     tail

Any of the above clumps (except the pelvis) may be left out, in which case the system assumes that part is missing. But an in-between clump can't be left out -- e.g. if you have a head clump, you must also have the neck clump.

The letters at the start of each line in the above table are used in the custom av language described in the next section.

All joint matrices should be identity matrices, since the system overwrites them internally when doing animations. The Container clump should have an identity transform matrix, since the system overwrites this when setting the figure's position and orientation in a space. The transform matrix for each clump may be defined. If the overall figure needs to be scaled, set the scale in the diagonal values of the pelvis transform matrix.

When the figure is loaded, its bounding box will be used to position it so that its lowest point touches the ground. If you want the figure to float above the ground, make a dummy triangle below the figure to force the rest of the figure to be higher up. See BIRDE.RWX for an example of this.

Top of Page

Custom Avatar Language

The name of the avatar is a special "language" that allows Gamma to substitute different body parts in making a custom av. You can change your avatar by modifying the Avatar property of the Console in the Shaper. A custom avatar name must always use the form "basetype.0code.rwg". basetype is one of the existing base avatars, and controls which set of actions your avatar will have. code is a sequence of letters, made up of one subsequence for each limb one wishes to modify from its default for that basetype avatar. Each limb subsequence starts with one of the letters from the table in the above section, for instance P for pelvis.

Each limb subsequence consists of the following options: 

    C: color, followed by either _ and a capital letter for a mnemonic color
        code as listed in following table, or by three letters giving the
        RGB value in base 64 from the alphabet -0-9a-zA-Z+.  For instance,
        C_R is red, and C--Z is a blue.  C__ is a special code that means to
        use the original material for the object; it doesn't work in
        animation sequences since it just means "don't replace".
        
            _A black        
            _B blue         
            _C brown        
            _D red orange   
            _E pale pink    
            _F bright green 
            _G green        
            _H dark blue    
            _I blue purple
            _J light blue
            _K dark pink
            _L light green
            _M pale orange
            _N dark grey
            _O orange
            _P pink
            _Q purple
            _R red
            _S burgundy
            _T teal
            _U light grey
            _V violet
            _W white
            _X golden yellow
            _Y medium yellow
            _Z light yellow
            
    T: texture, followed by a lowercase texture file name, for instance
       Ttexa loads the file avatar:texa.cmp.  If the T is followed by a
       number, it represents a frame of an mov file, and the number is the
       frame number, 1 for the first frame.  Otherwise the texture is a cmp
       file.  Next comes the texture file name, which must consist entirely
       of lowercase letters.  The texture name may be left out, in which
       case the last texture name given previously in the avatar string is
       used, or the basetype if there is no previous texture name.  So in
       the avatar amy.0PT1HTZT5sam.rwg, the pelvis uses the first frame of the
       file amy.mov, the head uses the file amy.cmp, and the tail uses the
       fifth frame from the file sam.mov.
       
    S: scale, followed by three letters from the alphabet z-a0A-Z, that give
       the scale in x, y, and z.  y is the height/length dimension, x is the
       width.  Lowercase letters shrink, uppercase letters grow.  If you
       scale a limb, any hierarchically-derived limbs are scaled accordingly.
       To restore such a child limb to normal use, use the corresponding
       other-case letter: for instance, S0b0 is counteracted by S0B0.
       
    G: followed by body type name consisting entirely of lowercase letters,
       for instance Ghabib.  This example loads this
       limb and hierarchically dependent ones from the habib.bod body file.
       A number may follow the G to identify a non-standard body type by
       tag number: for instance, RG15amy means to use Amy's leg part as
       a right shoulder.  The tag numbers used here are:
       
            pelvis => 1
            back => 2
            neck => 3
            head => 4
            rtsternum => 5
            rtshoulder => 6
            rtelbow => 7
            rtwrist => 8
            rtfingers => 9
            lfsternum => 10
            lfshoulder => 11
            lfelbow => 12
            lfwrist => 13
            lffingers => 14
            rthip => 15
            rtknee => 16
            rtankle => 17
            rttoes => 18
            lfhip => 19
            lfknee => 20
            lfankle => 21
            lftoes => 22
            back2 => 23
            tail => 24
            mouth => 25
            nose => 26
            lfear => 27
            rtear => 28
            back3 => 29
            tail2 => 30
            tail3 => 31
            tail4 => 32
       
    0-9: A sequence of digits identifies a subclump within the limb, and all
       further commands affect that subclump rather than the main limb clump.
       These subclump control strings must occur in increasing order; that
       is, H2C_R3C_G is ok, but H3C_G2C_R is not.
       
       The subclump ordering is determined by rwxtobod when it creates the
       limbs in the bod file.  A subclump is made for each separate color
       used in the original clump in the rwx file.  The clumps are sorted
       so that any with textures come first, in alphabetical order, then
       so that those with brighter colors come first, then so that those
       with more polygons come first.
    
    Q: quote.  A no-op character, useful to separate variable length commands
       like Tname from lower-case letter material references a-z, or to do
       similar separation before numerically-specified subclumps.
       
    D: followed by a single character that gives a delay amount.  Used in
       conjunction with multiple color or texture (collectively known as
       material) definitions to specify an animation sequence for a limb.
       Normally the last material specified is shown; then the animation
       starts, interpreting the sequence of D and material commands.  For
       instance, the sequence DeT2D3T3T2T1 shows texture frame 1 to start
       with, then waits "e" time units, then shows frame 2, then waits "3"
       time units, then shows frame 3, then waits the default number of time
       units between showing frame 2 and then frame 1, and starting over.
       
       The time units are on an exponential scale from the default of
       1/20 sec, through the base64 alphabet -0-9a-zA-Z+ using the
       equation 1.0932**val - 0.9.  Using this system, 0-9 are approximately
       in tenths of second increments, a-z are approximately seconds, and
       A-Z are longer delays, up to about five minutes for +.  Multiple
       successive D commands before a material are additive.
       
    a-z: Lowercase letters are a compression technique: they refer to the
       corresponding material defined earlier in the string.
       "a" means the first C/T color/texture definition in the
       overall string, "b" the second, etc.  Forward references are allowed.
Examples: aura.NC_R.rwg <-- aura with a red neck.
          aura.NS0G0.rwg  <-- aura with a tall thin neck and head.
          aura.HGhabibOC_RVa.rwg <-- aura with habib's head and red hands.

Top of Page

Creating Customizable Avatars

In order to make avatars that are customizable via the Gallery of Metamorphics (WearWalls) and the Customize Avatar dialog box, the name you create must follow even stricter guidelines than those presented above.

First, you need to indicate which textures are modified by the various buttons on the Gallery of Metamorphics.  You do this by including a prefix on the name that associates textures with each of the body parts that may be modified in this way.  This “prefix” must immediately follow the period after the avatar name, and begin with the identifier “0E”.

After 0E, specify materials (textures or colors) for the following body parts, in this order:

  1. skin
  2. shirt
  3. coat
  4. dress
  5. pants
  6. hair

You should then refer to these textures by their alphabetic abbreviation.

For example,

0ET7fdaT3fdaT2fdaT6fdaT3fdbT1fdb

Specifies that by default, frame 7 of fda.mov is the skin texture, frame 3 of fda.mov is the shirt texture, etc.  When a user changes the skin texture, any reference to material “a” will then be replaced by whatever they selected.

In order for the WorldsPlayer to allow customization of head sizes, the neck and head must be the last parts specified in a name. The neck must start with “NS000” to specify a neck of default scale; the user may then modify this scale value. Immediately after the neck’s scale and material, specify the head with a section that starts with “HDg” followed by the face texture(s).

Here’s a complete example for Aura’s customizable avatar name:

aura.0EC__C__C__C__C__C__LcMcOaRcUcVaWdXdYIdJdKBbPeNS000QaHDgT2auraT3T2T1Q0f.rwg

This string specifies that the six customizable materials initially use the flat-shaded color stored in the model.  These materials are then referenced by individual body parts, to allow customization.  Note the “NS000” and “HDg” tags that are used to identify the neck and head.

Top of Page

Integrating New Avatars into WorldsPlayer

I have this beautiful new articulated avatar that I want in Worlds. How do I get it up and running? It’s possible to distribute new avatars to end users without distributing a new WorldsPlayer; just follow these steps:

Preparing texture maps

First, you need to organize your texture maps and convert them to our compressed .mov format.   .mov files may contain up to ten textures apiece, so if your avatar requires more than ten texture maps, you’ll have to create multiple mov files.

In order to make it easier to implement changes and tweaks to your textures, it makes sense to set up a batch file to automate the conversion of your source texture map images to .mov format.  Create a batch file, “movit.bat” for example, that contains:

Compimg –ace –c255 –pt –r0 –l5,3 –Xd1128 –Yd128 –emov –M%1.mov +%2

Now, for each set of ten textures, create a text file that simply lists their file names… for example, you could create “av.lst” that contains:

Lnface1.bmp

Lnface2.bmp

Lnface3.bmp

Lnarms.bmp

Lnback.bmp

To convert these textures into a .mov, you would just type “movit textures av.lst” to create a file named “textures.mov” that contains the textures listed in the file “av.lst”.  Make sure that the name of the texture file you select is unique within all of the textures used by Worlds’ avatars.

Preparing the geometry

Using the 3DS->RWX standalone file converter or 3D Studio conversion plugin, create an RWX file for your avatar according to the strict specifications listed above.   It is important that the hierarchy and labels of this model are exactly right; review the actual RWX file in a text editor before proceeding to ensure that the subclumps are all in the proper hierarchy and labeled correctly.

Next, as described above, run rwx2bod to create a .BOD file for your avatar.  Play close attention to any error messages that appear that need to be corrected.

Preparing new motions

If you have created new actions for your avatar using the LifeForms software package, you will need to export the lifeforms motion files to our internal “seq” or “csq” format.  Be sure to rename your finished files with an “seq” extension.

Creating the texture mapping string

Next, you need to worry about applying your textures to the avatar.  Follow the instructions above in “Custom Avatar Language” to create a string that describes what textures are applied to which limbs and subclumps of the model.  Save this string for later.

Creating an avatars.dat file

Now, you must create a text file named “avatars.dat” that describes what motions your avatar is capable of.  The file must specify the file name of the .bod file, along with a list of “implicit” and “explicit” actions that the user may select from. “Implicit” actions are actions that happen automatically, such as walking or sleeping.  “Explicit” actions must be selected by the user, and will appear in the avatar’s “actions” dialog box in the WorldsPlayer.  Each action must specify an seq file that contains the motion data for the avatar.

Here is an example avatars.dat file that just uses some of the generic, default motions:

avatar

  name=Lian

  geometry=lian.rwx

  beginimp

    walk=common_walk

#   walk2=common_walk2 mocap

#   walk3=common_walk3 bounce 

    wait=common_a_wait

    endwait=common_a_endwait

  endimp

  beginexp

    wave=common_a_wave

    dance=common_a_dance2

    yes=common_a_yes

    rocknroll=common_a_funky2

    no=common_a_no3

    macarena=common_a_macarena3

    happy=common_happy

    pirouette=common_y_ballet2

    upset=common_y_angry

    twirl=common_a_spin2

    getLost=common_getLost

    achoo=common_a_sneeze2

    look=common_a_look

    bow=common_a_bow

    flip=common_a_flip2

  endexp

endavatar

It is possible to do some fancy things in the avatars.dat file, such as specify explicit actions that modify the implicit actions.  Contact a developer if you need more information on this feature, or see the avatars.dat for any of the EnewMedia adult avatars for an example.

Create an update package for the avatar

Now, you must create a ZIP archive that contains all of the files needed to represent your avatar.  The WorldsPlayer will download this file when it needs to display your new avatar for the first time.  Collect all of the following files into a ZIP file with the same base name as the BOD file:

- The .BOD file

- All .MOV files for the avatar

- Avatars.dat

- Any SEQ files specified in avatars.dat, other than ones that begin with “common_”

Upload the ZIP file to the upgrade server(s) you wish to serve the avatar from, in the AvatarUpgrades subdirectory.  After you have uploaded the ZIP file, upload a zero-length “timestamp.dir” file to AvatarUpgrades to notify clients that a new file is available.

Update the avatar tables

The upgrade servers also provide information to the clients about what avatars are available, what default texture mapping strings to use for them, and what names for the avatars are displayed to the end users.

Within the upgrade server(s), download the file “tables/tables.txt”.  Open this file in a text editor, and make the following additions for your new avatar:

  1. Under the section “permittedList”, add the base name of the avatar’s bod file and the avatar’s default texture mapping string. Use the other entries as a guideline to the required format. The name and string must be enclosed in quotes and separated by commas.
  2. If your new avatar’s face texture is not the first frame of a .mov file that has the same base name as the .bod file, add an entry to the “faceList” section that lists the base name of the avatar’s .bod file, and, as a second entry, the frame number and base name of the mov file that contains the face texture. The gallery of metamorphics uses this information.
  3. If your avatar is human, add an entry to the “humanList” section that lists the base name of the bod file and if it is “m” or “f” (male or female.) The humanList is used to determine if an avatar is allowed in human-only worlds, such as the Yankees Stadium.
  4. If your avatar should not be displayed within the “Choose Avatar” menus of all users, add it to the “secretList” section. Avatars listed here will not appear to end-users unless they are specifically enabled for that user’s serial number (which we’ll talk about in the next section.)
  5. If you would like the name of your avatar to appear to end users as something other than the base name of the .bod file, you can add an entry to the “avatarAliases” section to do so.

When you have made the necessary changes to tables.txt, upload it back to the upgrade server in its “tables” directory. Since this file contains information we might not want end users to know about, the file must be encrypted before the WorldsPlayer will recognize it. To encrypt your tables.txt file into a tables.dat file, follow these steps:

  1. Copy your unencrypted tables.txt file to the directory above the directory you have the latest WorldsPlayer installed. If you installed WorldsPlayer to C:\worlds, you would copy tables.txt into c:\tables.txt.
  2. Edit the worlds.ini file in the directory you installed WorldsPlayer to include the following line under the “Gamma” section:
    encryptTables=1
  3. Run the WorldsPlayer. It will then create an encrypted file named “tables.dat” in a tables subdirectory under your WorldsPlayer installation directory. Quit the WorldsPlayer as soon as it comes up (or later if you feel like chatting.)
  4. Upload the resulting tables.dat file to the upgrade server(s), in the “tables” subdirectory.
  5. Upload a zero-length “timestamp.dir” file to the “tables” subdirectory on the upgrade server, to inform the clients that new tables are available.
  6. Remove the encryptTables=1 line from your ini file.

Release the avatar to the public

Whenever WorldsPlayer logs in a user, it looks up that user’s serial number and obtains a list of “allowed” avatars for that user based on his or her serial number. This allows us to release avatars only to specific accounts or clients, or to everybody… whatever is appropriate. Furthermore, we can restrict avatars to certain rooms or worlds if we wish.

The files that determine who sees what avatars are stored on the upgrade servers in the AvatarUpgrades directory. Any file that has a .txt extension is a list of avatars for a specific account.

Defavs.txt specifies the default avatar list that a user receives if his serial number is not dealt with explicitly by another list. As appropriate, add a line to these txt files (download, modify, and re-upload) to distribute your new avatar to the appropriate users. For example, the line

aggie   f       all

specifies that the client may access the avatar packaged in “aggie.zip”, that this is a female, human avatar, and it is available in all rooms. Each field is separated by a TAB character.

After you have uploaded your new files, upload a zero-length timestamp.dir file to AvatarUpgrades to inform clients that new files are available.

Test it out

Run your WorldsPlayer and exit it, to allow it to obtain the new tables you uploaded. The next time you run WorldsPlayer, your new avatar should be available. Try it out to confirm that there are no problems.

If it’s not working and there doesn’t seem to be any good reason why, you may be running into replication issues. Some upgrade servers actually consist of several servers that synchronize their contents automatically every few hours. It may take a few hours for the server you’re using to receive your new files. If, after a few hours, it still doesn’t work, then you’ve got an error to figure out.

Top of Page

Avatar Modeling

Modeling a human body using box modeling technique with mesh smooth

1. Making profiles

First make two reference pictures (front and side view of the figure), scan them and place them in Max as a background picture.

Alternative way to draw profiles is to draw them directly in Max using line tool.

 Set your units in the preference menu to 1unit =1meter. Average height of the human figure should be 1.73 meters

2. Modeling leg

Start by making a box. Apply Edit Mesh and select a top face. You don’t have to enter in the “amount”; just press up arrow and you’ll see the extrusion.

Always add more segments at the joint areas, like knees, elbows…

You also should watch your side view.

To edit the leg move vertices so they match with the reference pictures you made.

3. Torso

Use the same technique as with the leg.

4. Arm

Start by selecting the face where to start arm extrusion and use extrusion again…

Use the same techniques to model other parts of the body.

An avatar has to be segmented, so use Slice tool under Edit Mesh Edge sub object level to separate the figure into the following parts: pelvis, back, neck, upper arm, forearm, hand, thigh, and calf, foot. Follow proper body part naming structure as explained in the document “Articulated Avatars”

To make your figure more rounded you can apply mesh smooth or select individual faces and tessellate them depending where you need more detail. By using tessellate tool you will have more control over your face count.

You have to watch face count of your model very carefully. Average model should not exceed mode then 1200- 1500 faces. 1000 faces is an ideal size for the model.

5. Textures

Texture the model using bitmaps, size 128x128 pix. If you have more than one texture on one object (like head) use MultiSubobject as your map type in the Material Editor.

Top of Page

Wear Walls

Coming soon.

Top of Page

Integrating Web-Based Content within WorldsPlayer

By Frank Kane, 6/19/00
Updated by Julie Renfro, 2/15/01

What is web-based content?

Beginning with revision 1651, the Worlds.com client has the capability to display web-based content in both 2D and 3D contexts. Specifically, a two-dimensional web page, or any portion of it, may be overlaid on top of the 3D window of the WorldsPlayer. Furthermore, a web page, or any portion of it, may be used as a dynamic texture map on a “Gamma Rect” three-dimensional object.

There are many applications of such technology:

         - Traditional ad-banner placement within the UI of the WorldsPlayer

         - Embedded HTML-based bulletin boards, whiteboards, or help systems

         - 3D advertising via virtual billboards in the worlds

         - Integration of third-party web-based technology without implementing client changes

         - Integration of games using Java or Shockwave in either 2D or 3D contexts.

In technical terms, the web-based content is implemented by making the WorldsPlayer into a container for the Internet Explorer ActiveX object. It therefore requires that Internet Explorer 4 or higher be installed on the user’s machine, and is capable of displaying any HTML content that Internet Explorer can represent.

Furthermore, clicks on both 2D and 3D web-based content are passed on to the underlying Internet Explorer object, allowing interactive web pages in three dimensions.

To fully exploit the advertising capabilities offered by this technology, the client is also capable of sending user information along with its web requests, including username, serial number, the current room, and the current world. To support server scalability, the client is also capable of directing web requests to “hard-coded” servers, to the current “script server,” or to the current “upgrade server”, both defined by the WorldServer or ini file override.

URL Macros

To send this user information to a web server, you will include special “macros” within the URL’s you assign to web objects within the Shaper. Any URL that a web object is set to will replace the following words with the following pieces of information:

$USERNAME

The user name, or chat name, of the person currently logged in.

$SERIALNUM

The serial number of the user currently logged in.

$SCRIPTSERVER

The “script server” specified by the WorldsServer upon login.  Generally, this script server is responsible for handling user registration CGI scripts, but may also be used for handling ad banner tracking and serving.

$UPGRADESERVER

The “upgrade server” specified by the WorldsServer upon login, or overriden by an ini file. This server is generally used to serve world and client upgrades, but may also be used for ad banner or other web page serving.

$WORLD

The name of the world the user is presently in when the web object is created.

$ROOM

The name of the room the user is in when the web object is created.

A “web object” may refer to either 2D or 3D embedded web-based content.  So for example, if you were to set up a 2D ad banner that points to:

$SCRIPTSERVERgetad.pl?u=$USERNAME&s=$SERIALNUM

This would get translated into something like:

http://3dcd.worlds.com/cgi-bin/getad.pl?u=fkane&s=XLR4452345

before being sent out through Internet Explorer.

Most of these macros are meaningless until the client has logged in or communicated with the server in some way. If you use these macros within your URLs, the web-based content will not display while the user is logged out. It will appear as soon as they log in.

Creating Two-Dimensional Ad Banners

Traditional, two-dimensional ad banners are implemented in two ways. The first as a property of a World that gets displayed within the WorldsPlayer UI, and the second as an Ad Banner object within the 3D world. To add a banner that will display in the UI, open up the World Properties in the Shaper. Set the properties as appropriate (see properties below), save and distribute the world, and your ad banners are up.

The WorldsPlayer will reset the ad banner as appropriate whenever the user changes worlds. Also, note that any links in a 2D ad banner will open up in a new window, regardless of whether a target of “new” is specified in the html.

The World properties related to Ad Banners are:

“Has Ad Banner”

If set to YES, the ad banner will be displayed in the lower-right corner of the 3D window according to the other ad banner properties set.  If NO, all ad banner properties are ignored and no banner will appear for this world.

“Banner Width”

The width, in pixels, of the embedded web page displaying the ad banner.  Make sure that the banner is displayed flush against the top-left corner of the web page to be fully displayed.

“Banner Height”

The height, in pixels, of the embedded web page to display the banner.

“Ad Banner URL”

The URL of the ad content to be displayed in this world. You may use the macros discussed above to pass user information to a cgi script, or just point directly to a static ad banner image.

The second way to create an ad banner is to use the Ad Banner object. This will place an ad banner within a 3D world, wherever you want it to be. Simply drag and drop an Ad Banner object into the object hierarchy of your world and position the banner as needed. See the Ad Banner object listed in the Objects Catalog for more details. The instructions below for creating WebPageWalls or "Billboards" also apply to Ad Banner objects, since the properties for Ad Banner and Web Page objects are the same.

Creating 3D “Billboards”

3D web content is created by assigning a Web Page object to a world. So, to create something like a wall with a Shockwave game on it, or a billboard with web-based advertising on it, you would simply drag and drop a Web Page object (WebPageWall) into the heirarchy of your world.

At this point, you should see either a pattern of the default ad cube image or the default Worlds.com web page, depending on whether or not you are logged in at the time.

Now, you may proceed to set the properties of the WebPageWall you just created.

First, you need to understand the two modes of operation for Web Page objects. In one, a click on the web page will cause a 2D web page to appear over the 3D window, displaying a specified URL. In the other mode, clicks on the web page are passed through to Internet Explorer, allowing interactive web pages in three dimensions. The mode used is determined by the “Pass Clicks” property of the Web Page object.

Both modes have their own special applications. For example, an interactive Java-based game mapped to a wall would pass clicks through to Internet Explorer. However, a billboard that represents a web-based community bulletin board might intercept clicks and display the bulletin board in high-resolution in two dimensions over the 3D window when clicked. A billboard for handling moderated chat may intercept clicks and display a 2D web page that takes up only a portion of the 3D window, allowing the user to continue navigating through the Worlds while using some 2D web-based chat moderation system simultaneously within the UI of the WorldsPlayer Ad banners would probably pass clicks through and allow the underlying HTML of the ad banner page to handle displaying the correct content in a new browser window upon a click.

A description of each WebPageWall property follows:

“Wall's URL”

This is the URL that will be displayed as a texture map on the WebPageWall. Important Note! Make sure this web page does NOT USE FRAMES. There is a bug beyond our control in the Internet Explorer 5 control that will not draw frames properly on pages higher than 150 pixels.

“Wall Page Width”

This controls the width of the web page used as a 3D texture.  Internet Explorer will attempt for format the web page specified by “Wall URL” into an off-screen window with the width and height specified; the contents of this window will then be mapped onto the Rect this attribute affects.

“Wall Page Height”

This controls the height of the web page used as a 3D texture.  Note that WorldsPlayer will create as many 128x128 textures needed automatically to represent the width and height of the web page you specify.  Bigger web pages mean more textures, which mean more memory and slower performance.

“Wall Refresh Rate”

This controls how often the web-based texture is updated from Internet Explorer. A value of –1 would mean that the texture would be updated only when the page is initially loaded.  A value of 1 would update the texture every frame of animation, and a value of 5 updates the texture every five frames.  In general, a page that features a lot of animation should use low numbers and pages that do not animate much or animate infrequently should use high numbers or –1.  Updating a web-based texture frequently can noticably affect performance, so you will need to find a good compromise between performance and fluid animations.

“Use Scrollbars"

If set to true, scrollbars will appear on top of the 2D WebPageWall.

“Pass Clicks”

If set to Yes, the Web Page will pass any clicks on it through to Internet Explorer, where they may do such things as activate hyperlinks or interact with games.  If set to No, a click on the Web Page will launch the 2D web page specified by Target URL within the UI of WorldsPlayer.

“Target URL for click”

If you have specified that clicks are not passed through this Web Page, a click on the Web Page is intercepted by the WorldsPlayer and will cause a 2D web page to appear over the 3D window, set to the URL specified in this property.  This is NOT the URL displayed on the WebPageWall itself.  If the WebPageWall is set to pass clicks through to Internet Explorer, this property will be ignored.

“Target Page Size Units”

This controls whether the x and y dimensions of the target page are interpreted as a percentage or as pixels.

“X Overlay % or Width”

If “Pass Clicks” is set to No, and a click on the Web Page will launch a 2D web page specified  by “Target URL”, this property specifies how wide the 2D web page will appear on-screen.  The 2D web page appears as an overlay on top of the 3D window, so you may choose to obscure only a portion of the 3D window with the web page if you wish. 

“Y Overlay % or Height”

This property represents the percentage of the height of the 3D window you wish to overlay with this web page. If “Pass Clicks” is set to “No”, this property is ignored.

“Target Page Has Toolbar”

This field also applies to the 2D web page displayed if “Pass Clicks” is set to No, specified by “Target URL.” If this property is set to “yes”, a simple navigation toolbar will appear on top of the 2D web page.  This toolbar will allow the user to go home, back, forward, and to close the 2D web page, thereby unobscuring the 3D window.  Without a toolbar, the user will have no means of dismissing the 2D web page (desirable for advertising, perhaps.)

Note that when a web page is mapped onto a Rect, the WorldsPlayer will automatically create as many textures as it needs to represent the page in high resolution on the Rect. There is no need to break a Rect up into sub-Rects and map different parts of the web page to each one by hand.

In Sum

These new systems offer the ability to integrate the wide range of off-the-shelf multimedia applications developed for the World Wide Web within WorldsPlayer. While created primarily for community cork-boards and advertising purposes, I hope creative minds will find other exciting applications for it.

Top of Page

The Recorder Feature

Recorder Shaper Actions

New actions have been added to the Shaper as of revision 1830 to control the new Recorder feature. With these actions, you could record "3D cutscenes" and play them back in response to some trigger in the world... for example, a cheat button in a puzzle could play back a recording of a user solving the puzzle.

The new actions are:
PlaybackRecording - The only property is the "FileName", which should be a URL to the recording file you wish to play back.
StopRecording - This action, which has no properties, will stop any currently playing recording.

Auto-play and Soundtrack Synchronization of Recorder Files

For the purpose of sales and marketing demos, you may record a sequence of events in Worlds to be played back automatically upon launching WorldsPlayer. Using this feature, a CD could be created that could simply be inserted into a prospect's CD player, automatically install WorldsPlayer, and start up WorldsPlayer in a guided, noninteractive tour with a synchronized sound track explaining what the user is seeing. At the end of the demo, the user is left in an interactive mode to explore on her own.

To set up such a scenario, the following entries must be inserted into the INSTALL.INI, SETUP.INI, and/or AUTOPLAY.INI file prior to bundling the demo:

AutoPlaybackFile= The file name of the recording to play back upon startup.

AutoPlaybackSound= The file name of a WAV file to play back at the same time that the recording starts playing. This entry may be omitted.

Offline=1 This entry will cause the demo to start up quickly, even if the user does not have an Internet connection available to our servers.

The recording file and/or WAV file should be placed in the MMEDIA directory prior to bundling in order to ensure they are installed to the proper location on the user's hard drive. See the instructions on creating installers for more information (downloadable.txt)

Recorder INI File Entries

disableRecorder - If set to 1, all recorder features will be disabled.

recorderEnabled - Controls whether the "Recorder" menu appears in the Options menu. Set to 1 for true, 0 for false. If set to 0, recordings will still work via the auto-play features and Shaper actions.

AutoPlaybackFile - Set to the file name of a recording file to be played back upon startup of WorldsPlayer. The file should be installed into the top installation directory of WorldsPlayer by the installer.

AutoPlaybackSound - Set to the file name of a WAV file to be played back synchronized with the recording file specified in AutoPlaybackFile. This file should also be in the installation directory of WorldsPlayer.

Top of Page

Dynamic Textures

Coming Soon

Top of Page

Games and Fun Things

Creating Mirrors and Magnifying Mirrors

Mirrors are very easy to create, they are simply Portals that have been connected to themselves rather than to another Portal. To create a mirror, follow these steps:

  1. Add a Portal at the location where you want the mirror.
  2. Resize it to the size you want the mirror.
  3. Under the Portal Properties, change Destination Room Name to the name of the room the mirror is in.
  4. Under the Portal Properties, change Destination Portal Name to the name of the portal itself. The portal turns into a mirror.
  5. You'll notice, however, that the room and objects are not truly "mirrored". Under Portal Properties, double-click Mirrored and select the "mirrored" option to designate this property as true.
  6. VERY IMPORTANT - if you leave the mirror as is, you can walk through the mirror with some very strange results - you'll end up walking on the ceiling of the next room, the right arrow key will make you turn left, the left arrow key will make you turn right, and you won't be able to walk out of this upsidedown room! Assuming you don't want this effect, you'll need to do the following steps:
    1. Make the portal unbumpable (make the Bumpable property = false).
    2. Place a rect of the same size directly over the portal.
    3. Either make the rect's Visible property = false, or add a "frame" by adding a texture to the rect that has transparency in the center.

Magnifying Mirrors

In the Gallery of Metamorphics, the smaller mirrors on the left side of the Gallery are magnifying mirrors. To make a magnifying mirror, follow these steps:

  1. Create a mirror using the steps above.
  2. Add a second portal on top of the first portal.
  3. Give the second portal a Name that is different than the first portal.
  4. Move the second portal out into the room 300 units.
  5. Move the second portal 30 units down into the floor.
  6. Make the second portal invisible and unbumpable.
  7. Connect the first portal to the second portal. You now have a magnifying mirror.
  8. You'll notice that if you walk up too close to the mirror, the avatar's reflection disappears. You will need to add invisible bump walls in front of the first mirror so that users can't get too close to it - experiment with different distances.

Top of Page

Trading Game

The Trading Game is currently under development, but the following explains how it would work.

The Trade action is used to make "merchants" in worlds. When triggered, this action pops up a dialog that allows a user to trade with the system. There are only four properties the world builder should adjust: the User Item Type, Merchant Item Type, and the number of each. When triggered, the action will pop up appropriate dialogs asking the user if s/he wants to make the trade, or telling the user s/he hasn't enough of the User Item Type to be trading here.

The world builder must be careful to use valid trade amounts. The system only permits trades that follow the rate schedule below. This is done to prevent hacking the system -- even a world builder cannot force the system to create new items for less than they are worth.

Item names always start with a capital letter, and are followed by lowercase letters. No digits or symbols are permitted. Currently the items the system understands are:

    • A - Coin.
    • H - High jump.
    • Vvbowie - special Bowie avatar.

The first letter of the item name specifies the item's intrinsic worth, in coins, according to the following table:

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

2

3

5

7

10

15

22

30

40

55

75

100

150

225

350

500

750

1000

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

For instance, any item whose name starts with H (such as a high jump), is worth 22 coins. Any item whose name starts with a letter from T to Z is "invaluable", and can't be traded with the system. Such items (for instance, the Vvbowie item mentioned above) can be traded only with other users. In other words, there is no way to create such T-Z items from other types of items.

When setting up a TradeAction, you must arrange the trade so that the system makes at least 10% on the deal, or it won't be permitted. For instance, a TradeAction that trades the user's 3 D-value objects for the system's 1 G-value object will be ignored by the system, since it's a trade of 3x5=15 for 1x15=15. The system requires its cut. A trade of 11 A-value items for 1 F-value item would work, as that's a trade of 11x1=11 for 1x10=10, and 11 >= 10 + 10%.

The system will also allow any trade where it makes more than 10% on the deal. So a TradeAction is permitted that trades 10 I-value objects from the user for 1 M-object from the system: 10x30=300 for 1x100=100, the system is making a nice profit.

You should consider setting up your virtual merchants to allow at least two trades each: one selling an item type for coins, the other buying back the item type for fewer coins. By making your trades involve coins, it's easy for users to exchange one type of item for another by doing deals with the various types of merchants through the intermediate of coins. For instance, I could take my High jump (H) to the High jump merchant and sell it for, say, 15 coins. Maybe if I hunted around I could find a better deal, maybe there's a merchant in some corner of Hanson that buys back High jumps for 20, the maximum allowed. But say I sell it for 15. Then I could take my 15 coins to the Forp merchant (no such thing) and buy a Forp for 15 coins. That way I can change my High jump into a Forp, without needing to find a special High jump-to-Forp merchant.

Note that it can make things more interesting if the merchants that do better deals are located in out-of-the-way places, encouraging people to search the universe for the best deals, and for ways to buy unusual items. Perhaps the most rare items will be available only through merchants that don't take coins. Maybe you'll set up your merchants so that the only way to buy a Sarg (value 1000) is to trade three Quds (value 1500). There are no such things, this is just an example.

Here's an extra fact about item names that you don't need to know for trading purposes, but might find useful as background knowledge. Just as the first letter of item names specifies the intrinsic value of the item, the second letter specifies the type of the object. Currently the only type that means anything is "v", which means that the object is an avatar that will be listed in the user's VIP/Choose Avatars/Special Avatars menu when the user has any of them.

Top of Page

Dartboard

Instructions Coming Soon

Top of Page

Pin the Tail on the Donkey

The Pin the Tail game that is in the Birthday Room in Worlds Center is not hard to make, but it is tedious. There are several rects and MANY Move Actions and click sensors. The game consists of 16 rects: 1 background (with Donkey), 9 tails, and 6 start buttons. It appears that there is only one "start" button, but in reality there are 6 start buttons rotating (in a sense) about every 2 seconds. There are 6 start buttons because there are 6 "games", each game having the tails in different start positions so that each time the user plays the game it's different (6 was an arbitrary number).

Here's how to set up the game:

  1. Create a grid of 9 rects (tails) next to your Donkey background, naming each one with a number (Tail1, Tail2, etc.)
    Tails

 

  1. Write down the positions of each tail (you'll need these coordinates later). Each set of coordinates is a starting position:
    Starting Positions
    So in the instance of the game in the Birthday Room, Starting Position A, or "SA"=(244.78003,1363.12,215). These initial positions are what we'll call "Game 1". For Games 2-6 the tails will be moved around. In "Game 2" Tail1 might be in Position E, Tail 2 in Position C, etc.

 

  1. Now, we need to assign a Move Action to each Tail for these Game 1 positions. Eventually when we make the start buttons, "Start Button 1" will trigger these Move Actions so that the Tails end up in these spots for Game 1. Confused yet? Hang in there. So, for Tail1 for example, add a Move Action and name it something like "MoveAction_T1_SA" for Tail1, starting position A. Double-click the Copy Start/End property of the Move Action and enter 3 and hit OK. Double-click the Copy Start/End property of the Move Action and enter 4 and hit OK. Now whenever this Move Action is triggered, Tail1 will go to position A. Do the same thing for each tail, but remember that Tail2 is in position B, Tail3 is in position C, etc., and name the Move Actions accordingly.
  2. Move all 9 rects to wherever you want their ending positions to be on the Donkey background (make sure one of them is where the tail goes!)
  3. Now you'll need to assign a Move Action for each rect at this position. For example, right-click on one of the tails (say it's Tail1) and assign another Move Action to it. Name the Move Action something like "MoveAction_T1_P" for Tail1 Game Position. Double-click the Copy Start/End property of the Move Action and enter 3 and hit OK. Double-click the Copy Start/End property of the Move Action and enter 4 and hit OK. Now whenever this Move Action is triggered, Tail1 will go to its position on the Donkey background. Do the same thing for each tail.
  4. Add Click Sensors to each tail. The target for these Click Sensors is the Game Position for each tail. For example, add a Click Sensor to Tail 1. In the target list, add "MoveAction_T1_P" (the Move Action you just created for the "Game Position" of the tail). Do this for each tail.
  5. Make the trigger to start Game 1. Make a small rect to the right of the game. Name it something like "PinStart1". Under the rect's Material Texture properties, double-click Texture type and select "Texture created from a text string". Double-click Text and type in "Start". Change the Font, Size, Foreground Color and Background Color as desired.
  6. Add a Click Sensor to PinStart1. This click sensor's target list will look like this:
    MoveAction_T1_SA
    MoveAction_T2_SB
    MoveAction_T3_SC
    MoveAction_T4_SD
    MoveAction_T5_SE
    MoveAction_T6_SF
    MoveAction_T7_SG
    MoveAction_T8_SH
    MoveAction_T9_SI

    Click on PinStart1 and hopefully all the tails move to their starting positions for Game 1!
  7. Here comes the really tedious part. Each tail now has two Move Actions, one for its Game 1 start position, the other for its ending position on the board. Now you have to add up to 5 more Move Actions for each tail, one action for each Game starting position. Below is a diagram that shows you the starting positions for each of the "games" in the Birthday Room:

    You'll notice in the diagram above that Tail1 is in start positions A,B,C,D,E, and H. You'll need to add 5 more Move Actions to Tail1 (you already made one for starting position A). Click on each tail to have them go to their position on the Donkey Background. Using the coordinates you wrote down earlier, move all the tails to their Game 2 positions (Tail1 to position E, Tail2 to position C, etc.). Then add another Move Action to each tail. For example, Tail1 is in position E. Add another Move Action to Tail1 and Name the Move Action something like "MoveAction_T1_SE" for Tail1 Starting Position E. Double-click the Copy Start/End property of the Move Action and enter 3 and hit OK. Double-click the Copy Start/End property of the Move Action and enter 4 and hit OK. Now whenever this Move Action is triggered, Tail1 will go to position E. Add Move Actions to the other tails for the Game 2 starting positions.
  8. Copy and paste PinStart1 (the "start" button for Game 1) and rename it PinStart2. Move PinStart2 so that it's right above PinStart1 (so you can see it). Repeat step 8 adding a click sensor to PinStart2, but the target list will reflect the MoveActions of each tail for Game 2 start positions. Click on all the tails so that they are on the board. Then click on PinStart2 - the tails should go to their starting positions for Game 2.
  9. Repeat steps 9 and 10 for Games 3-6. You should end up with 6 "start" buttons, one on top of the other, each triggering a new "game".
  10. Now we have to make the 6 start buttons look like one. First you need to add two SetVisBump actions to each start button. One will trigger it visible and bumpable, the other invisible and unbumpable. For example, add two SetVisBump triggers to PinStart1. Name one SetVisible_PinStart1_On and set Target Visible to "true" and Target Bumpable to "true". Name the other one SetVisible_PinStart1_Off and set Target Visible to "false" and Target Bumpable to "false". Do this for each start button.
  11. You'll need to add a Sequence Action and a Wait Action to something in the room. In the case of the Birthday Room, they have been added to the floor. Set the Wait Action's Duration to 2. The Sequence action's components will look like this:
    SetVisible_PinGame2_On
    SetVisible_PinGame1_Off
    WaitAction_PinGame
    SetVisible_PinGame3_On
    SetVisible_PinGame2_Off
    WaitAction_PinGame
    SetVisible_PinGame4_On
    SetVisible_PinGame3_Off
    WaitAction_PinGame
    SetVisible_PinGame5_On
    SetVisible_PinGame4_Off
    WaitAction_PinGame
    SetVisible_PinGame6_On
    SetVisible_PinGame5_Off
    WaitAction_PinGame
    SetVisible_PinGame1_On
    SetVisible_PinGame6_Off
    WaitAction_PinGame
    If you do "Trigger Now" for the Sequence Action, you should see your Start buttons appear and disappear, one at a time. Move all the PinStart rects to the same spot over the original PinStart1.
  12. To set the whole thing running add a SameRoom Sensor to the floor, and make its target the Sequence Action you just made. Voila! You've made a Pin the Tail on the Donkey game!

Top of Page

Gravity Fly Through

Instructions Coming Soon

Top of Page

Mirror Ball

Instructions Coming Soon

Top of Page

Flickering Candle

In the Birthday Room in Worlds Center, the candle on the birthday cake is not really animated. It's actually a Hologram that contains an .mov file with 4 frames. The hologram has been given a Spin Behavior so that each of the frames are displayed continuously without the user having to change positions relative to the candle.

Here's how to make the candle:

  1. Create a four frame animation (or however many frames you want) for a burning candle. The area around the candle will be transparent.
  2. Make an .mov using the four frames or make four .cmps out of the frames (if you're making .cmps, they need to be numbered, like candle1.cmp, candle2.cmp, etc.). You'll be adding the files to a Hologram object, so either method will do.
  3. Add a Hologram object to your world (most likely in the Room Contents). The size of the candle Hologram in the Birthday Room is 64x64 gamma units. Place the Hologram where you want the candle to be, remembering that the Hologram's location is where its center is (not its lower left corner like normal Rects).
  4. Under Hologram Properties add your .mov or .cmps to the File property. For .cmps, the file would be something like tex/candle4s*.cmp, the "4s*" being how many frames (files) there are. You should now see one frame of your candle on the Hologram.
  5. To make the candle "animate", you need to add a Spin behavior to the Hologram. From the Behaviors Library, add a Spin behavior to the Event Handlers of your Hologram (Spin and Post-Spin are old Behaviors that are really more like Actions. They do not need a trigger - they immediately start effecting the object you assign them to). The candle should immediately begin to animate at a slow frame rate. Under the SpinBehavior Properties, change the Cycle Time to .5

Blowing Out the Candle

coming soon

Top of Page

Elevators

Instructions Coming Soon

Top of Page

Updated 02/17/01  GDK 1848        All Content © Worlds.com, 2004