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:
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.
Written by Frank Kane
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:
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.
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
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:
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:
· 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.
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.
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.
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.
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.
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.
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.
by Petr Kyn
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.
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.
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.
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.)
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.
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.
The process is pretty simple and straightforward.
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/"
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.
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.
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.
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.
To increase Render speed following certain techniques is helpful.
There are things to whatchout for in order not to get z-buffering problems.
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
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:
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.
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".
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.
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".
_D red orange
_E pale pink
_F bright green
_H dark blue
_I blue purple
_J light blue
_K dark pink
_L light green
_M pale orange
_N dark grey
_U light grey
_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.
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:
You should then refer to these textures by their alphabetic abbreviation.
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:
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.
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:
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:
# walk2=common_walk2 mocap
# walk3=common_walk3 bounce
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
- 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:
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:
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.
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.
Use the same technique as with the leg.
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.
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.
Updated 02/17/01 GDK 1848 All Content © Worlds.com, 2004