Saturday, May 16, 2009

Make SecondLife Use a Ramdisk Cache

Here's some simple instructions and information on how to make SecondLife store it's cached files on a RAM Disk.

1) What's a RAM Disk?
A RAM Disk is a segment of RAM that is used in a fashion similar to a hard drive. Files and directories can be created in it, and it functions in all respects like the normal file system of a computer, and can be accessed by your applications.

2) Advantages
RAM has historically been much faster than hard drives. For example, DDR2-800 RAM has a maximum data transfer rate of 6.4 gigabytes/s, while a Sata3 hard drive has a maximum data transfer rate of 3 gigabytes/s. However, this is the maximum speed of the Sata3 interface. In reality, the data transfer rate of the hard drive itself is somewhat slower. As well, the faster speed of RAM allows for faster indexing operations and loading, making Second Life run more efficiently in this respect. Also, if you are worried about stressing your hard drive, using a RAM Disk cache helps a lot.

3) Disadvantage
RAM is volatile memory, meaning all of the data stored is lost when the computer is shut down. As a result, shutting down or rebooting your computer causes Second Life's cache to be lost, and it is recreated the next time Second Life is run. If you are using Linux, this is not as much of a problem as rebooting and shutting down frequently is not usually necesary. Also, If you have an ISP such as Comcast or AT&T (especially AT&T) that caps your monthly bandwidth, I would not advise using this method if you shutdown frequently, as it increases your risk of going over your bandwidth limit.


Instructions (Linux)

First, you fire up your favorite text editor as root, and open the /etc/fstab file. Add the following line to the file, replacing all instances of /path/to/ramdisk below with the desired mounting point for the RAM Disk:

none /path/to/ramdisk tmpfs defaults,size=1G 0 0

After you've added the entry to /etc/fstab, you (while still in root) create the directory that the RAM Disk will be mounted to by running the command "mkdir /path/to/ramdisk". After that, check to see if the ramdisk's directory is set with the proper permissions (allow any user or any group to view and modify contents). If it doesn't have the correct permissions, set them or set yourself as the directory's owner. Note that if the directory has the improper permissions, you'll have to set them each time you reboot. Once the above done, you mount the directory with "mount /path/to/ramdisk".

After this, you fire up Second Life and open the Network tab in the Preferences menu. Click the button that says "Set" and set it to /path/to/ramdisk. After that, apply the changes, and close the preferences menu. You'll need to restart Second Life in order to take advantage of the RAM Disk. When Second Life next starts up, it'll clear the old cache and begin using the RAM Disk.


Instructions (Mac OS)

To do this under Mac, you open up a terminal, and run these commands (excluding the "$" and the space following it). The instructions assume the cache size is 500mb. Replace the 524,288,000 with 1,048,576,000 for a 1000mb cache. Be warned, however, that larger caches produce lag.

Also, the hdid command may produce a disk with a different name, such as /dev/disk4. If that happens, you replace all instances of /dev/disk1 below with whatever name it gives the disk.

$ hdid -nomount ram://524288000
$ newfs_hfs /dev/disk1
$ mkdir /tmp/ramdisk1
$ mount -t hfs /dev/disk1 /tmp/ramdisk1

After you've mounted the RAM Disk, follow the steps of the last paragraph for the Linux instructions.


Instructions (Windows)
I don't have a windows machine to test this on, though the instructions are easy to find through Google, though you'll need to install drivers in order to create the RAM Disk. Once the RAM Disk is created, you follow the steps in the last paragraph of the instructions for Linux.

This page seems to be a good resource for learning how to create a RAM Disk:


Procedural Content Generation: The Future of Virtual Worlds?

Late last year, shortly before the openspace shangri-lala started, me and a friend of mine were talking of ways to implement an alternative to SecondLife. We spoke about using a few engines as a base, such as Sauerbraten and Irrlicht. The thoughts were eventually dropped. However, one idea that I came up with during the discussion was the use of procedural content generation.

What is it? It's a system of algorithms designed for dynamically generating content for a game on the fly, either by random number generation or specific algorithms. For example, it could be used to generate random levels. Elder Scrolls II, Diablo I & II, Dark Cloud I & II (and III, but that's vaporware) all use it. Angband, ADOM, Lost Labyrinth, and virtually every roguelike game ever made use procedural generation to create levels.

In addition, procedural synthesis can be used to generate textures, animations, sounds, objects, etc. Games such as Spore and .kkrieger both use it extensively. The game .kkrieger can be considered "overkill" with procedural generation: everything in the game is generated dynamically. Because of this, the game takes up only 96 kilobytes, while a conventional game equivalent to .kkrieger would use upwards of two or three hundred megabytes. On a 2.6ghz dual core, all of the game content is generated in the space of 10-20 seconds. This screenshot from .kkrieger demonstrates the results. As well, the image itself is more than half the size of the game at 58 kilobytes.

As you can see, the use of procedural generation can be invaluable with saving disk space in a game. With the increasing demand for higher-quality textures in modern games, procedural generation is seeing greatly increased usage. As well, there are a number of tools that have been created to allow game developers to take advantage of procedural generation such as SpeedTree, Terragen, Genetica, and GML. As well, the open source 3d modeller Art of Illusion contains a built-in node-based texture generator (yes Wayfinder, it is GPL ;-).

Use In Virtual Worlds
So, what if Virtual Worlds were to take advantage of procedural generation? The most immediate benefits are the obvious ones: massive reduction in bandwidth and far less data to store. There are other benefits too. A user that doesn't have the know-how to use photoshop or gimp could use tools built in to the viewer (or external to it) in order to generate their own procedural textures.

Different tools could be used to generate different kinds of specialty textures, such as skins, clothing, hairs, eyes, etc. Art of Illusion and Genetica both use a node-based system to generate textures. As well, this approach could be used to generate both sounds and animations. As well, sounds and animations could be generated in a similar manner.

As well, sculpties / meshes could be generated by a set of tools, such as a "pottery wheel" system where you create a line that generates a symetrical sculpt/mesh much like a pot or vase, converting linked objects into a sculpt/mesh, or manually editing the vertices of a mesh (perhaps an undesireable method for some).

Another possibility is generating textures from scripts. An example of this would be signs that can change the texture, or perhaps it could be used to dynamically generate an interface for HUDs.

I'll try to simplify this for the non-techie SL users. Procedural generation is a kind of computer program that can produce images, sounds, animations, and objects by following a set of rules, set both by the developer of the program and the program's user. For example, by choosing a brick pattern, colors, and a noise filter, you could create a brick texture.

As for the space savings, the data for generating the texture would be stored on the asset servers as "bytecode", or a script which has been reduced from something human-readable (text file) to something computer-readable. Each one of these files will take up less than 1 kilobyte (1024 bytes), while a typical 512x512 texture will be 20-30 kilobytes. That is, of course, if the image is a jpeg. Other formats such as png, tga, and bmp will use far more memory.

In any case, the use of procedural texture generation would not eliminate the need for storing traditional textures, as in the case of snapshots or textures produced by other means.

I would personally like to see this technology implemented in virtual worlds such as OpenSimulator, LiteSim, or Sirikata. OpenSimulator already has a very basic level of this started with some OSSL functions that can edit textures.
Yes, I have a blog now. I'll put stuff up here when I feel like it :P