Project Wonderland WPI MQP

Well, after doing a presentation at WPI Josh and I decided that a presentation should be more scripted. We worked on our presentation for Sun Labs and the initial draft was not what the Labs team had expected. So, with a little finesse, we were able to satisfy the requirements. We did the presentation in-world using the PDF Viewer to display our slides. This proved to be a good and bad thing. The good part was the immersing of ourselves into Wonderland. We were able to demo our components while talking about them. Unfortunately, the PDF Viewer wasn’t intended to give presentations to people in the real-world, so it proved to be a little sluggish (We had to remove the HUD on every slide so the audience could see the entire slide).

In addition, we were able to watch the other WPI MQP teams present at Sun and that proved to be a fun, learning experience.

So, we gave our good-byes to Jordan and Nicole. We want to thank them–and the rest of the Wonderland team–for their time and patience. Now, we move on to the paper portion of our Major Qualifying Project.

Today we gave a demo of our MQP. WPI was holding an open house and the Computer Science Department was giving presentations on why being in the department is so great. They wanted to make sure that five topics were covered. These topics are: Programs, Projects, People, Breadth, Careers. Towards the end of the presentation a couple of MQP projects were spoken about. We demoed the HTML Viewer and WonderBlocks in the demo world. It turned out to be a good practice run for our future presentations and we are glad that we were able to do it.

In other presentation news, we also finished up our slides for our presentation on Wednesday. This will be at Sun Microsystems and in front of the Sun Project Center advisors from WPI and Sun.

We’re pleased to say that WonderBlocks is now feature complete!

Attempting to implement the ability to drag WonderBlocks ended up being far more complex than we were envisioning, so we decided to stop pursuing that ability, in the interest of time. In our current implementation, Blocks can still be moved by going into Edit Mode and changing their position coordinates.

We spent the first part of today writing an abstract for our presentation at Sun next Wednesday. We then did some last bits of cleanup and testing on the WonderBlocks code. Finally, Gerard started building a demo world to show off WonderBlocks and the HTML viewer–a mockup software engineering team room–while Josh attempted to get Wonderland to deploy as a shared web application on Gary’s reserach server. Josh didn’t have good luck with that today, and so far, Jon and Jordan are stumped, too. We’ll have to figure out what the issues are tomorrow.

Lined up for tomorrow: Gerard is being interviewed by ATG all day tomorrow, so Josh will work from home. Josh will continue investigating deploying Wonderland to Gary’s research server, and also start writing the presentation.

We were finally back at the office today! A good amount of progress was made:

1. Implemented editing existing WonderBlocks.
2. Implemented editing existing connections.
3. Refactored WonderBlocks client <-> server messaging system. Instead of utilizing one large, all-encompassing message class that contained lots of fields that are used for various different types of messages, the messaging system now utilizes three message classes. This should actually reduce network overhead/usage, since one of three specialized classes are selected to transfer a given message, leaving out information unnecessary for that particular type of message. This change also made all of the messaging system code much easier to read, understand, and maintain.
4. Unified the logging/’usage hooks’ system. All log entries now follow consistent formats throughout the WonderBlocks application, making them easy to parse using an external application/regular expressions, etc.
5. Changed the HUD so that it must be closed manually by the user. This way, leaving the WonderBlocks bounding box to get a wider view of the WonderBlocks application does not make the HUD disappear, and the user can continue maniuplating WonderBlocks as long as they wish.

On tap for tomorrow: Block dragging/moving, and final code cleanup!

Today, we implemented two new features: Block creation and a dynamically-resizing bounding sphere.

Block Creation

This feature is pretty much self-explanatory. You can now click a HUD button to enter Block Creation mode, in which a dialog pops up that asks you to enter information concerning a WonderBlock (such as its size, color, etc.) Upon confirmation, the Block is then created in-world. Right now, Block coordinates are specified manually by entering separate values for X, Y, and Z coordinates, but we may explore 3D dragging abilities tomorrow.

Dynamic Bounding Sphere

This is a simple but useful feature. The bounding sphere is an invisible sphere surrounding each instance of the WonderBlocks application. When an avatar walks inside this sphere, the WonderBlocks HUD displays, while an avatar leaving the sphere makes the HUD vanish. The size of the bounding sphere now changes dynamically with the amount of space the group of WonderBlocks take up. The position of the WonderBlock that is farthest away from the WonderBlocks cell origin at 3D coordinate (0, 0, 0) is used to calculate the radius of the bounding sphere. Thus, an avatar walking near the ‘edge’ of the WonderBlocks application will always trigger the HUD, no matter how much space the WonderBlocks visually occupy.

On tap for tomorrow: Exploring 3D dragging and minor bugfixing/code cleanup.

The end of our time at Sun is near! We’re presenting our work on the HTML Viewer and WonderBlocks to Sun Labs on October 15th. More details will follow in a future blog post.

A lot has happened in two days.

Day 26

The day’s accomplishments:

1. Minor refactoring/code cleanup.
2. Expanded server <-> client messaging abilities…server can send a message to one client OR all clients. (If a client tries to create an invalid connection, etc, the server will only notify that client, not every client.)
3. With Jordan’s help, discovered a deeply insidious bug in the WonderBlocks backend where == was used instead of .equals() to compare two objects. This worked fine when the backend was running in isolation, because the things being compared could actually refer to the same object in memory, as everything was running in one shared memory space. This caused problems when the backend was actually used inside Wonderland, however, because those conditions don’t apply there.
4. Removed unnecessary HUD elements.
5. Added the ability to create connections between Blocks via a pop-up dialog box.

Day 27

We worked from home today because Gerard had an interview in the morning. Wish him luck in that endeavor! Because we were at WPI, we had a meeting with Gary to discuss our progress.

Today’s other accomplishments:

1. Fixed show-stopping synchronization errors in two places in the backend code. We noticed during our functional testing that some operations would randomly not be performed, manager states would go out of sync, and a ConcurrentModificationException would be thrown by both the Wonderland client and server. This was again due to the differences between running the backend in its own memory space and running the backend inside Wonderland. This same problem appeared in two places in the backend code: a single HashSet in memory was being iterated through in one class, while another class simultaneously removed elements from it. Operations like that are not threadsafe, which is why we were seeing those problems. Solving the issue turned out to be simple: now, we create a copy of the HashSet to be altered, and then iterate through the copy while altering the original. A more elegant solution would have been to switch from using foreach loops to using Iterators with Iterator.remove(), etc, but doing so would have required extensive backend refactoring. Although creating copies of the HashSets in question is less memory-efficient than using Iterators, it was a quick and acceptable solution to the problem. Interestingly, the functional tests that revealed these problems involved deleting a Block that was a parent in more than one conncection, as well as deleting a Block that was a child in more than one connection.
2. Added a ‘Name’ field to the connection creation dialog.
3. More general refactoring/cleanup.

The last two major features that we still have to add to WonderBlocks is the ability to create Blocks in-world, and the ability to edit Blocks. After that, all WonderBlocks core functionality will have been implemented! There are still plenty of minor things to do after that, however.

We’re very excited about today’s progress.

The first thing we did this morning was to explore how to identify WonderBlocks and WonderBlock Connections via mouse click in-world. This turned out to be simpler than we anticipated. The solution involved adding Blocks and Connections to their own Java3D branch groups, rather than adding every component to one large branch group like we’d been doing previously. The mouse listeners available in the Wonderland API are able to identify a branch group when an object inside it is clicked on in-world. Thus, we now use a HashMap that maps BranchGroups to BlockIDs/BlockConnectionIDs in order to identify an object when it is clicked on.

With the newfound ability to identify in-world objects on click, we then fully implemented in-world deletion of Blocks and their associated connections. Objects can be deleted simply by choosing the ‘delete’ button from the WonderBlocks HUD, which will put the client in Delete Mode. Clicking on any Block then deletes that Block and any connections associated with it, while clicking on a connection simply deletes that connection. These changes are triggered on any given client, which then notifies the server that a deletion should take place. After updating its own internal model of the WonderBlocks state, the server instructs all connected clients to locally perform the delete operation.

An architectural change we made is to have each client contain seperate copies of the two manager classes, BlockManager and BlockConnectionManager. This makes it very easy to perform deletions graphically; the same algorithms that are used to manage the server’s state can also be used to remove objects from the screen on the client (such as deleting a Block’s associated connections when the Block itself is deleted.)

Tomorrow, we’ll most likely explore how to implement creating new WonderBlocks or connections in-world.

We were able to get a few things off of our check list today and we are making progress towards our working deliverable.

We’ve added generic interfaces to the WonderBlocks back-end for saving and loading data. Now, instead of only being able to [de]serialize data from a flat XML file, a developer can write drop-in code to [de]serialize data from any source they wish, such as from other file types or a database. In addition, we implemented saving the state of the WonderBlocks as they appear in-world.

Additionally, the head-up-display is in it’s first stage. It is displayed when an avatar walks into the WonderBlocks Cell. Basically, whenever the avatar is in close proximity of the WonderBlocks, a display with several commands shows up, as well as an indication that you are in the area. There is also a display that let’s the user know when they are no longer in range of the WonderBlocks. The only functional command as of now is the Save Button, which makes use of the aformentioned new state-saving functionality. When a save completes successfully, the user is notified in their HUD.