A long, long time ago, in a virtual world far, far away… building virtual worlds consisted of a hodge-podge of tools and technologies to import content from 3D modeling tools and arrange the content in-world. (Well, ok, it wasn’t that long ago — v0.4 only first appeared 7 months ago).
At the heart of the system to assemble worlds was a collection of XML-formatted text files organized into a directory structure on disk, known as the Wonderland File System (WFS). WFS was a big improvement over what existed just a few months before the v0.3 release (i.e. creating and arranging the content by writing Java code), but it did initially require hand-writing XML files. Soon after (for v0.4) came the Wonderland World Builder (see Figure on right), a drag-and-drop interface to construct worlds from pre-fabricated components. On the back-end it would generate the WFS, and if you positioned your directories on disk properly, a "Reload World" command from the client updated the world with the changes you made in the World Builder.
The World Builder had a number of nice features: it presented a clean and easy-to-use catalog of components that you can easily drag onto a fixed grid. It made easy the layout and arrangement of seats within a room, or sections of wall or floor. But its nice features were also its limitations: it only supported static graphics, not the rich set of Cell types (e.g. telephones, whiteboards, etc) available in Wonderland and its fixed grid placed restrictive requirements on the size of each component in the catalogue. Also, the worlds that were built using the World Builder performed poorly, because potentially hundreds of individual Cells were created for essentially a simple scene.
Version 0.5: A Brave New World (Builder)
Let’s fast forward to the release we are currently working on (v0.5). Some architecture decisions we made for v0.5 made supporting the v0.4 World Builder very difficult (if not impossible). The most important of these decisions was the one to make Wonderland a dynamic virtual world, as described by Jon Kaplan’s recent blog, Persistence in Wonderland 0.5. No longer would the state of the world be entirely dictated by what exists within WFS: the live, dynamic state of the world is now stored by the internal database maintained by our Darkstar server middleware layer. It seems then, that any world building activities would have to act upon this dynamic state, and that these tools would need to be integrated into the Wonderland client.
First off, we decided to change our terminology a bit: the tools which I am going to describe we now call "world assembly" because they involve assembling and arranging existing components in-world, rather than building them from scratch. The Wonderland model is still one of an "open art path": content developers use external 3D modeling tools and export to a standard file format to import (in our case, COLLADA). World assembly consists of three components:
- Import and Create
Let’s take a look at each three in turn.
Import and Create
The first step to assembling a world is importing and creating its contents. Generally, this consists of importing 3D models and creating instances of Cells. As I’m sure you’ve heard by now, in v0.5, we are supporting the COLLADA format for 3D models, and their import becomes far simpler too. (Back in v0.4, you needed to import the models, then grab the binary (.j3s.gz) file it produced, load it into a web server, and then create the WFS file to display the content in the world.)
Drag and Drop. In v0.5, this becomes as simple as dragging-and-dropping your model into the world. Your model file is parsed and automatically uploaded to our Webdav-based content repository hosted by the Wonderland server. Once uploaded, the system automatically creates a Cell that displays your model. (This feature will be available in dev5 in May; I have a prototype now).
Here’s a sled from the Google 3D Warehouse that I imported as a Google Earth (.kmz) file by dragging it from the desktop into the Wonderland client. You can also see the model appear under my directory on the Webdav web server: every users gets his/her own directory where models are automatically uploaded.
You can see that in addition to a user’s own space on the Webdav content repository, there is a "system" directory, and eventually there will be a directory in which you can create "groups" to store content for particular purposes.
In fact, it is more than just 3D models that you will be able to import via drag-and-drop. You will be able to drop any form of content into the world, and if there is a Cell type that supports that content type, it will automatically upload the content and launch a Cell to display it. We already do this today with the SVG Whiteboard module: you can drag-and-drop an SVG document from your desktop into the world and have it display in a Whiteboard. (I must say, pretty cool, huh?)
Cell Palette. This being Wonderland, there is naturally more than just 3D models that you can put into your world–there’s all those cool custom Cell types (that come packaged as modules). Introduced in v0.5 is the Cell Palette, a GUI that lets you create instances of Cell types in the world. One of the first steps in defining a custom Cell type is to define the factory class necessary to display your Cell in the Cell Palette.
The Cell Palette comes in two flavors, and I’m currently deciding which one will survive in the final release of v0.5 (perhaps both). The first one presents a text list of Cell names and a "preview" image of the Cell. You can select the Cell name in the list and click the Create button. The second presents the preview images for each Cell in a scrollable list and you can drag-and-drop the icons into the world to create them, which would appear as a window in the HUD (Heads-up Display).
Once you’ve imported your 3D models and created all of the Cells you want, the next step is to arrange them in-world. For that, we provide three visual "affordances" (also "maniplators" ) that let you (1) move, (2) rotate, and (3) scale your Cell. These affordances work for any Cell. Simply right-click on a Cell, a Context Menu appears, and select "Edit.." The Move affordance appears first and a frame with three toggle buttons and a slider. (This frame will eventually appear in the HUD).
You can display all three affordances at once (as controlled by the three toggle buttons on the HUD panel), as shown on the right here:
- Move. The Move affordances appear as thr
ee double-ended arrows along each axis, colored individually (Red for X-Axis, Green for Y-Axis, Blue for Z-Axis). Simply drag each arrow to Move along each axis.
- Rotate. The Rotate affordances appear as three discs, colored for each axis about which they rotate (Red rotates about the X-Axis, Green rotates about the Y-Axis, and Blue rotates about the Z-Axis).
- Resize. The Resize affordance appears as a semi-transparent black sphere. To resize the Cell uniformly in each axis, click on the sphere and drag either away from the center of the Cell (to make the Cell bigger) or towards the center of the Cell (to make the Cell smaller).
The final step to world assembly is editing the properties of a Cell. A Cell’s "properties" is not a well-defined set, it depends upon what properties the Cell exposes and also the properties of all of the Cell Components attached to the Cell. (We haven’t talked much about Cell Components yet, but they are a powerful part of the 0.5 architecture, and it is on our list to write a blog about). To bring up the Cell Properties dialog, simply right-click on a Cell, a Context Menu appears, and select "Properties…".
The left-hand columns contains a list of categories. There are several standard entries, such as "Basic" and "Position" (see picture below). If you click on any of the entries on the left, you see a property sheet for that category on the right. Here, you can edit the position of the Cell using text fields for more fine-grained control versus the visual affordances above.
See the ‘+’ and ‘-’ signs at the bottom left? These aren’t implemented entirely yet, but this will let you dynamically add "capabilities" to a Cell. (You are really adding Cell Components to a Cell). For example, suppose you want to add security attributes to your Cell, so you’d first add the "security capability" to the Cell and configure its parameters. Other examples of capabilities to add to Cells will be scripting and audio capabilities. There’s an API (which is a work in progress) that will let you register your own Cell Components as capabilities and a visual GUI property sheet to edit its properties.
Great question! We’ve come a very long way since 0.4, but in future releases, I think the world assembly can be made even easier by integrating collision and physics. For example, someone should be able to insert a chair into the world and have it fall to the floor (using gravity in the physics engine) or be able to push a sofa right up against a wall (using collision detection). It would also be great to have guide lines and "snap to grid" for arrangement and the 2D birds-eye view that the 0.4 world builder provided.
Needless to say, there’s plenty of work to be done for world assembly, and I view the tools in 0.5 as just the beginning.