This document is an attempt to explain why ogoglio is architected the way that it is and why that matters to you, the technical reader. This document, originally, was started by Ian; quite the opposite for ogoglio itself which Trevor F. Smith labored on alone for more than a year. A great many of these design decisions—perhaps most—were made by Trevor. In the process of taking on a new employee, Ian Smith, a great many of these decisions have been articulated and re-formulated to make them more clean and hopefully more useful. Further, new design aspects have been created, hacked on, thrown away and tried again. These latter decisions are more related to the way that ogoglio is built, deployed, served, and generally transitioned towards product-land. When Ian came on board, Trevor already had a working demo so it should not be surprising that the later, joint decisions concern a later stage in the system’s development.
Ogoglio is, at the core, a platform for web applications that include 3-D spaces.
There are two critical things in the heading above. First, ogoglio is a web “participant,” the web is not tacked onto a 3-D world. Ogoglio speaks GET/POST for almost all the features it supports. If you want to sign up for an account, cause an animation to occur in the 3D world, make a virtual billboard display today’s news, or play a video in the user’s browser based on actions in the 3D world, you simply use the web. Really, it’s that easy. From a client perspective, you can use the tools you already know (since they already have great support for Web programming) to bend ogoglio to your will. We provide clients in Java but this is not required. It would be straightforward to write a browser-oriented ogoglio client in Actionscript that interacted with ogoglio’s server via HTTP (really, REST) and used Paper3D to display the 3D scenes in the user’s browser. Ogoglio speaks web, we just happen to write our code in Java. Your call.
From the perspective of ogoglio’s server and the 3D world inside it, you script all objects with Javascript (which you already know from Web programming) and this leads, of course, to pulling in RSS feeds via URLs, POSTing to delicious and flickr, or changing the user’s web-based blog to have a photo of their current view of the virtual world. To be concrete, you can write a Javascript “onClick()” handler for an object in the 3D world that uses standard libraries to query Google news, parse out the top stories, and display the headlines on a virtual display. If there are multiple visitors to the 3-D space, they get their own, but up to date, view of the headlines. The display, like all the ogoglio 3-D objects, have a Javascript API that your scripts can address when things happen in the space.
Slightly more surprising to some readers might be that you can POST to objects in ogoglio’s 3-D spaces. Although there are some obvious security constraints, 3-D objects in ogoglio are like micro web services. The respond to a REST API and can perform actions (assuming correct authentication) based on input from other programs on the internet. Perhaps you would like to have your 3D space change in some way to trackbacks to your blog?
The second part of the heading above is that 3-D spaces are part of the ogoglio platform. There really is not much point in building (ugh) yet another framework for 2D web applications—so we didn’t bother. Ogoglio’s current server implementation uses completely static 2-D web pages for the HTML parts of its UI. This UI is largely just there to allow users to interact with the 3-D parts of the system in a convenient way—with their web browser and web forms. (Remember, it’s just the web.) Although aesthetically the authors favor not generating HTML at run-time, this is certainly not a requirement for an ogoglio application. You can use your favorite web development infrastructure . To make this concrete, you can spawn a simulator for a virtual restaurant, create and place 3-D tables and chairs, and control some robotic waiters via POST to (properly formed) ogoglio URIs. This space can be embedded in your customer’s web page (with your surrounding UI, not ours) via an APPLET tag. Would you like to have a fancy AJAX UI for interacting with the chat stream for your restaurant space? Go for it. Ogoglio doesn’t care; it will just quietly keep track of the status of the 3-D objects, including the space’s interactive users and respond to GET if your application need to know something.
We can’t help with the good idea
To build a compelling application in 3-D, using ogoglio or not, is not easy. You need a good idea. The web (via web apps) is now a bit of a catch-all for all of 2-D computing, like it or not. There has not been a lot of work done to provide 3-D, especially multi-user, applications for end users with the exception of gaming. We have excluded gaming because if you want to build a game, you should use a game engine such as Delta 3D, OGRE 3D, Steam, or the DOOM engine running on an iPod, if you roll old school. Although a sufficiently determined person could probably build a first person shooter using ogoglio, we wouldn’t encourage it. We might even laugh. To use ogoglio effectively, you need an idea for an application that interacts with multiple users via the web and needs a 3-D space for these users. You can see some of our application ideas at our company’s web site, www.transmutable.com. Yes, we’ll tell you what our next ogoglio app is, for only three fat Hefty bags full of cash. US dollars only.
Now, once you have your idea, what does ogoglio buy you? Ogoglio is a bit like apache in the context of a traditional web application: it provides a lot of the stuff you need to get your application running and make it interact properly with the web world yet it isn’t actually the mcguffin that makes your web application special. Check the previous heading. Again using the apache analogy, it’s a lot easier to configure Apache a little and connect it to your application than trying to speak all the web protocols yourself. Yet, you still have to do something the user cares about with those protocol streams. Primarily, ogoglio can provide you with a simulator for a 3-D space, a web interface to the space and it’s contents, a basic set of scripting capabilities for objects in the space, and the ability to keep many clients up to date with their correct “view” of the space.
Using ogoglio for an application
Let’s think about the application suggested above of a virtual restaurant. To build this application, you will need to run at least one instance of the ogoglio server. This server, most likely, won’t actually be visible to your application’s users; it’s just a web service that you need to accomplish your job. At the time your application boots up, your application is likely to communicate with the ogoglio server (simple XML over HTTP, nothing fancy) to configure one or more ogoglio spaces. Each space represents a chunk of the virtual world that users can interact with. In this example, perhaps you will have one space that is the dining room, one that is the stockroom, and one that is the kitchen. (This assumes you want people to walk around your restaurant’s kitchen and stockroom!) With ogoglio ready, your web application takes over and starts responding to requests as normal, you know, port 80 and all that.
When you want the user to interact with one of the 3-D spaces, your web application sends them a page containing an applet tag. In the applet tag is information needed to communicate with the ogoglio simulator managing the space. We provide a default “viewer” applet that is pretty small (about 500k) and uses java3D to do the rendering of the scene for the user. This applet is embedded in your web page and (thanks to LiveConnect) thus the web page can communicate with the ogoglio “world” and vice versa. For example, you could have a section of your page that you use to display the health warnings associated with foods such as steak tartare or fungo (posionous blowfish). This section of the page’s DOM, that we usually call the “info panel”, can be addressed by objects in the 3-D space, perhaps in response to a user click or even a user getting near them. The “path” of this HTML warning is this: the object in the 3-D space on the server runs a bit of javascript code and hands a URL to the supplied javascript function “showInfoPanel(url)”, the applet in the user’s browser gets the data from the server, and calls a javascript function, which we also supply, to actually display that URL’s contents in a region of the page. Presto, “Eating uncooked meat, fish, or eggs can be hazardous to your health. The ogoglio restaurant staff takes every precaution to prevent illnesses, but you can still get sick from steak tartare. Really sick. Enjoy!”
The viewer applet we supply is open source and even more open to hacking. A simple capability provided “out of the box” by the viewer applet is the ability for the user to move around the viewed space with the arrow keys. From the user’s point-of-view she uses the arrow keys to navigate around the space. The client applet sends information about the user’s movement to the ogoglio server controlling the space. This is enough to cause the ogoglio simulator to update it’s own model and inform other clients about the user’s motion. To rephrase, the moving client flings a bit of XML to the server indicating its path and the server flings some XML to other clients in the space about the motion so they can update their respective views. Flinging is fun to say.
You can extend the viewer to provide extra capabilities on the client side if you would like the applet to behave differently. (If you want to change the web page the applet is embedded in, you’d be better off using the path described above. We have plenty of examples of both strategies.) For example, when a user is connected to the “dining room” space with default applet viewer and she “right” or “context” clicks on some spaghetti, ogoglio will by default do a few things. First, it determines which object was clicked on—that’s the nasty 3-D part you didn’t want to do, since the user really clicked in a 2-D coordinate system, blah blah blah. Then, the ogoglio server calls the “onContextClick()” method of the aforementioned, tasty pasta dish if it has one. You can put your own javascript code in this and return an array of objects that determine the spaghetti’s context menu. Once you return this list, the server will send this information in a bundle to the viewer application. “Double presto” the user gets a sensible context menu. For example, the context menu might include “throw against wall,” “consume but slurp loudly”, and “eat with fork.” This menu is correctly placed over the object clicked on by the applet. (Again, this a tricky transform from 3d to 2d…oh, whatever, you don’t care, it’ll look right.) When the user makes a choice from the popped-up menu, naturally, the conspiracy works in reverse with the applet telling the server what the user selected and that selection being passed back to the plate of spaghetti’s “itemChosen()” routine. The spaghetti may want to use some supplied javascript routines to change it’s appearance or perhaps to send back a URL to the user’s browser who content says to not eat so much starch.
If you were paying attention and put the proverbial 2-and-2 together you should realize how to cause changes to the spaghetti from some other application, maybe your real-time monitor of the restaurant’s actual kitchen? For the rest, we will explain. Your external application can post to a URL that addresses the plate of spaghetti, and send a small XML document indicating the action you were performed, or whatever. You and the author of the spaghetti’s web service have to work out which version of the spaghetti-modification-editing-and-consumption-protocol™ you should use.
Some work yet to do (by you, not us)
Ogoglio, on both the client and server side, has contributed quite a bit to our eatery in these examples so far, but it is worth noting what technical areas are likely to be work for you as a restaurateur. First and foremost you will need to construct 3-D models of objects that users can see and interact with. Ogoglio supports a standard, simple and text-based format for the 3-D models, ”.obj” format. Almost any 3-D design tool can emit this format and it’s sister format (.mtl) for materials used in the model. When you upload this model to ogoglio, a template is created. You can associate javascript code with this template to handle user input, do special tasks at set-up or tear-down time, etc. Creating 3-D models is well beyond the scope of this document, but if you are reading this document, the chances are decent that you shouldn’t bother trying to make 3-D models at all and should just pay somebody who actually has the talent to do it for you. Once they give you the .obj files, you can write the javascript. Naturally, we supply cube and a cylinder that those untalented among you can use as a placeholder! Actually, there are many great Creative Commons’ licensed objects in the ogoglio distribution.
If you play with the ogoglio distribution on a running ogoglio server, it will give you a (very basic) web form to upload .obj files and edit the javascript associated with a template. Were you paying not paying attention, again? Didn’t you see it coming? The form simply calls POST on a URL to create templates, add textures, change associated javascript, or whatever. You could make your own, almost certainly better, form with your own web development tools. This can also done programmatically to do such things as bulk upload a bunch of .obj files and javascript code to create a set templates to use for testing a space. We do this all the time. See, it’s really just the web.
A second area that you, the developer, will probably need to spend time on is creating javascript libraries to encode the semantics of your application. These libraries, most likely, will end up being the backbone of the 3-D parts of your application. For example, as a restaurateur you are likely to want to have a convenient javascript interface to your real restaurant’s web-based online ordering system allowing a virtual customer to place actual orders via the web. (Surely, by now, you saw that one coming.) At the time of this writing, ogoglio does not provide as big of a library of javascript code as we would like. We do supply the ability to do things like animate a user’s avatar, change the appearance or motion of objects in the space, interact with the DOM of the user’s web browser, and create surfaces that can be modified programmatically. At the time of this writing, this library, like all code libraries, is not big enough.
A Brief Confession
We’ve been harping all along about how “ogoglio is just the web.” Well, there is, like many a political campaign manager has found out to her chagrin, a tawdry secret buried in the past. You may have noticed how when we talk about viewer to server communication we say things like “the client tells the server” about changes in the user’s location in the space. Truth be told, there is a non-webbish protocol that connects the ogoglio server and the applet. Packet sniff on port 8932 if you want to see the dirt for yourself. “Why, oh why, have you terrible people let us web supporters down so badly? How could you do this to us? We trusted you to ‘be’ our web heroes in 3-D…,” you may be wailing. Well, we built this channel because HTTP isn’t so good for fast, asynchronous communication. The server and applet both want to be able to send messages to each other without prompting and want that message to be received pretty quickly—when users move around in spaces, we don’t want the overhead of approximately a jillion HTTP requests; we want the applet to “feel responsive.” We have a side-channel that we send short, fast messages back and forth on; we’re not proud of it but it’s all there in the public record (the source).
In the very near future, we plan to move to the comet protocol, as that is the webbish solution to the problem and would allow us to say, with a deeply soulful expression, that “we were young and impressionable and one small, custom protocol mistake a long time ago shouldn’t be taken as a mark on our character or suitability for high office for all-time.”
Who's building this thing, and why are the lights still on?
Right now the core developers are people at a startup called Transmutable. We give away ogoglio and it’s open source with an Apache 2 license, which means it's out there, you can use it for fun and commerce, and we can't take it back. You can certainly run it yourself and not pay us a dime. Not even a Zibabwean dollar. However, to bring back the apache analogy from before, web hosting companies are in business for a reason, despite the fact that you could run and maintain apache yourself, most people don’t. Running and maintaining an ogoglio server is similar to running apache in terms of your headaches—it’s probably a whole lot easier to pay someone else to worry about scalability, backups, uptime, bandwidth and the like. If you buy that story, you should talk to us about hosting your ogoglio server. If you didn’t buy that story, well, we wish you the best and the next time you're in town let us buy you a beer and swap stories about 3AM pages when the colo caught on fire.
Comments