It is not very hard to make a virtual world. It is somewhat harder to make a world with flair and impact. But it is a real balancing act to make a world that works well over a net connection on today's machines. What can be done to make a world move smoothly yet still be interesting to explore? Can you make a very large or even infinite world that doesn't slow your machine to a pitiful crawl? What kinds of textures can you use that won't bog your machine and net connection down? Sounds are often enormous... are there any tricks to reducing downloads and yet still having acceptable sounds in your world?
There are 2 parts to this talk:
Another, lesser limit is number of polygons, but polygons are fairly easy to manage using a VRML node called "LOD" (Level Of Detail). You would use LOD this way: there is a complex building which has lots of textures and ornamentation. This detailed model is in the first LOD node. When you are further away and the details are difficult to see, you replace the building with a simpler version. That simpler, untextured building is in the second LOD node. Even further away and the building looks like not much more than a box, so put a simple box in the next LOD node. For the last LOD node you can either have the building disappear, by putting an empty Group node inside the final LOD node, or perhaps just represent it with a point. There is no limit to the number of levels you can use in a LOD node but it is sensible to keep it to just a few. You can either specify the distances you want these different levels of detail to kick in, or leave it up to the display program to decide. The "Inline" node can also be used to delay loading the fully detailed model until the object is approached.
One of the nice things about VRML is that it can use most file formats, though you are best off to stick to a few special ones that confer special advantages.
One of the most important file formats is PNG (Portable Network Graphics). It is a lossless format that compresses very well to make a small file, but its best aspect is its ability to make transparent and graded transparency images -- the alpha channel. PNG images can be 1 bit up to 48 bits per pixel. Only use the number of bits per pixel that you absolutely need -- don't use a 24-bit image for a diagram that only has black and white. One bit per pixel will suffice there. Remember that they eye can't distinguish between more than 256 shades of grey (or of any single color). This means that 8 bit images will suit grey-shaded pictures (2^8=256). 24 bit colors cover all the colors and shades the eye can see (8 bits for red + 8 bits for green + 8 bits for blue). If you add another 8 bits for transparency then you get 32 bits. PNG will compress to smaller file sizes than GIF and if the picture has a lot of the same color (as diagrams generally do) then PNG will even compress better than JPEG.
JPEG is the other important image file format. It doesn't have transparency but its compression capabilities deliver smaller files for photographic images than other formats. (Although you will find that PNG makes smaller files of images that have a lot of flat color.) While PNG is a really cool format and usually compresses better most other formats, even JPEG if the picture is a diagram, nevertheless JPEG files are almost always smaller, especially for photographic pictures, and if you can live with throwing away some of the information in the picture. One place you would use a PNG even for a photographic image though, is when the picture requires transparency -- particularly graded transparency. When saving in jpeg format there is a compression setting that it is best to set at around 70% or 80% I find. Bear in mind that jpeg is a lossy compression format (unlike png). It thows away some of the information in the image related to how we see things. Usually it is almost impossible to see any image degradation, but this depends to some degree upon the image. Also, how much an image will compress is highly dependent upon the look of the image -- a grainy picture with lots of fine detail and dithered colors will compress less well than a blurry one with soft grades.
A lot of people still use GIF for images, but it doesn't compress as efficiently as PNG and offers only up to 8-bit images. GIF images can include transparency but unfortunately it is just a single totally clear "color".
Textures can be mapped onto any shape object, but the more complex the object the more involved it can be. You can usually make do with the default mapping of a texture, otherwise (particularly with irregularly shaped objects) you'll need to match points on that object to coordinates on the texture. Obviously mapping onto a rectangle is straightforward, but mapping onto certain object primitives (e.g. a sphere, a cone, a box, a cylinder) is also simple, though might not give you the result you were hoping for. In that case, you will need to explicitly match object points and texture points. While it can be done by hand, it is often more easily done using modeling software.
VRML .wrl files are straight text, so are actually quite small. You can gzip them which reduces their sizes still further. All web browsers can transparently ungzip .wrl files on-the-fly. (Note that gzip is different to winzip. Gzip is one of the free tools distributed as part of the GNU project. If you have any difficulties obtaining it I can email it to you.)
PROTOs are a great way of making your own custom nodes in VRML. This lets you re-use your code. DEF and USE let you recycle code too and should be taken advantage of wherever possible.
PROTO libraries (as EXTERNPROTOs) are a cool idea for organising information, but it must be borne in mind that with several external protos in one library file, if you only use one proto, you still have to download the whole file just to get that one. If you end up using most of the protos it can actually pay off, but this is highly dependant on the viewer program. Some viewers will cache the PROTO library so that it only needs to be downloaded once, but some will go through the hassle of fetching the whole thing from across the net every time one of the PROTOs in the library is used. Even programs that cache the PROTO library may still need to send out a request over the net to ensure that the file in the cache is the latest version... it depends on how smart the software is. The time taken to fetch things over the net can introduce considerable delays into loading your world. If it is a problem then probably DEF or PROTO might be a better way to re-use some objects. Some of this problem can be lessened by making all EXTERNPROTOs one per file. That is, don't make libraries of many EXTERNPROTOs in a file. However they still have to be fetched over the net. The resultant extra delay may or may not be a hassle depending on how important they are to the scene. If they are not immediately visible anyway then leaving them as EXTERNPROTOs will speed the download of the main world file. However if they are crucial to the main scene it is probably better to make them ordinary PROTOs in the main file as this doesn't have the delays of extra fetches out over the net.
If your world will be chiefly delivered over the internet small, efficient files are of paramount importance. Sound can be delivered to VRML worlds in 3 main formats: wave, midi, and mpeg. Stereo is unnecessary (and inefficient) because the sounds appear to come from single points from within the world anyway.
• Wave files tend to be enormous but can be gzipped to reduce their size roughly by half, and will be transparently decompressed by the VRML viewer. Also, because they increase linearly with play length it is important to use 8 bit sampling where you can, and to use the lowest sample rate that is acceptable. You may have to go for higher sample rates if the sound has dominant high frequencies (like small bird chirps), but generally the lower the sample rate the better. Use 11kHz as much as you can and if you can get away with 8kHz then do that. This is a rather special artform which requires careful balancing of file-size against sound quality. Quite often you will find it comes down to providing an illusion of the sound being higher quality than it really is. This is more difficult than it seems, and way harder than just using nice, CD-quality, high sample rates for professional recordings.
• Midi is the most efficient file format but depends on the quality of the sound card in the user's machine. Music can sound like it is being played on a little handheld GameBoy computer if played on a machine with a low-end sound card, but the same midi file played on a high quality sound card can sound very impressive. One interesting use of midi is to create sound effects instead of music. I have a tiny (just 400 bytes!!) file of surf at a beach which is a midi file. It plays for about 30 seconds. A 30 second sound file in any other format would be likely to run to hundreds of kbytes. I can imagine the wind whistling, birds chirping, pigeons cooing, coucal pheasants making their delightful wook-wook-wook sounds all would be quite feasible in midi. Unfortunately due to hardware limitations only one midi file can play at a time. But this can be got around through smart scripting.
• Mpeg files come in various flavors but as far as I know all are usable from within VRML. Mpeg files are much smaller than wave files but have the drawback that they require much more computer power. Wave files are basically offloaded to the sound card to do most of the work, whereas mpeg sound (and video if included) is recreated from what what I understand to be basically a description of what frequencies are used. So mpeg should be used sparingly, and preferably mp2 rather than mp3 (though less of a problem these days) -- mp2 is less processor intensive, but has slightly larger file sizes, than mp3.
You will probably want most sounds to loop, though there will be some, like opening doors, that just play once. There are some tricks that can make looping sounds seem less repetitive, like making more than one sound play at the same place in the world, but instead of making them the same length, you make the ratio of play lengths an irrational number -- that is something which never quite divides out properly -- so that they never quite match up at the same timing as they loop. (And you thought your high school maths would never come in handy! :)
In a VRML world sounds can be placed anywhere so that as you approach, pass, and move away from the sound it varies in volume and auditory position in the world. If the sound is on your right it will come out of your right speaker more strongly; if it is on your left it will sound like it is on your left. You don't need to do anything about this, it is a normal feature of VRML worlds.
Sounds can also have directionality -- they can be set to "carry" further in one direction than any other, as they would if you were standing some distance from an open doorway to a room where music was playing. If you moved off to either side the volume would drop off rapidly even though you were still the same distance from the source.
Another interesting effect is to set different sounds to be used at various distances from an object, for instance if you are some distance from a waterfall it sounds muffled, but as you approach, it becomes crisper with more high frequencies in the hiss. Or if you are outside a nightclub you hear the thud of the bass with some dulled music. Upon entering the club all the sharpness of the music is heard.
You can generally rely upon about 6 sounds (but only one of them midi) being able to be generated at any one time (I think most VRML viewers make 6 the standard number). They can have more than that, but it generally requires the user to know how to open up their preferences and alter that setting, so you can't assume that it will be available.
But we don't go to VR without preconceptions -- we still do live in the real world.
I put a lot of plants in my world designs. They would seem useless, but my reason is that people relax when they can see plants -- even artificial ones. There has even been research that shows people recover from illness faster if they can see plants -- even if it is just a tree outside their window.
A lot of people place chairs, tables, and beds in their buildings. These give a familiar homey air but render a lot of the space unusable, and our avatars can't sit or lie down, or get tired of standing. Walls and ceilings are of no structural use in VR and they don't protect you from the weather. Their only real use is psychological -- to partition space for privacy, separating one visual experience from another, or for aesthetic reasons.
Objects are free to float in the air without requiring supporting pedestals, though sometimes a stand can tie the object to a certain spot on the ground, aiding depth perception.
Stairs are easier for humans to walk on than ramps, but avatars have no such difficulty with ramps, and they use much less data than stairs, letting you put more in a world.
Most objects in a world are solid, but there is no reason why they must
my original plan for AWABA included an art gallery where you would walk _through_ picture after picture. This came from my annoyance with the way most VR galleries are arranged
they have a wall that you walk sideways in front of to look at the pictures. But it is hard to line up properly with the wall, and because moving sideways means pressing the shift key you can become embedded in any higher ground. (The holding down the shift key while moving turns off collision in ActiveWorlds worlds.)
If you think carefully about it you can come up with ways to use VR innovatively and usefully, but remember my point about plants in VR -- don't discard things just because you can. There can be very good reasons to keep some points of realism.
This is the first generation to really start to colonise cyberspace.
When settlers first came to Australia they built houses like they did in England and they painted English landscapes of Australia. It took them a long time to wake up to how cool Australia is. The same thing is happening in VR. People make virtual things like they are in the real world. We are only just starting to wake up to the really cool possibilities of VR.
Finally, I should mention one thing about navigation that I feel strongly about.
Try to build asymmetrical worlds. People always start by building with symmetry, and it is a terrible mistake. Who here has been to Canberra? Who here has been lost in Canberra? (For those who have never been to Canberra, it is a very symmetrical city, which makes it way too easy for people to lose their place.)
Asymmetry gives you constant visual cues as to where you are now. Unfortunately the job I am doing currently violates that important rule -- it was designed before I came on board -- but will be adding other forms of asymmetry to make up for the radial symmetry of the world.
Ways to give a world asymmetry: