Project Wonderland WPI MQP

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.

Now that we’ve implemented the capability to display WonderBlocks in-world, we’ve moved on to making them manipulable by the user. Today, we started exploring several ways that an in-world heads-up display for WonderBlocks can be triggered and used.

We’ve also retooled the WonderBlocks back-end to no longer make use of singleton classes. Singletons were necessary when the back-end was running as a standalone application, but they are unnecessary and in fact cause problems when attempting to use them in conjunction with Wonderland/DarkStar’s own object and data management facilities.

Finally, we’ve finally put a messaging system in place for WonderBlocks, and have written code that allows for WonderBlocks client <-> server communication. The first message we’ve implemented is one that the client can send to the server, instructing the server to save the state of the shared WonderBlocks application instance. The sending of this message will eventually be triggered by a ‘save’ button that will appear in the WonderBlocks client HUD.

WonderBlocks with Working Labels and Directional Connections

We’ve made a lot of progress today.

Where do we begin?

In an attempt to implement drawing/correctly orienting connections between WonderBlocks using thin cylinders, we spent a very long time playing with trigonometric functions, rotation matrices, 3D vectors, euler angles, and the like. After over two full days of experimentation and frustration, we got absolutely nowhere with this, so we decided to use Java 3D’s built-in (but less pretty) line drawing functionality to render connections.

We mentioned yesterday that we were able to improve the shading used on all WonderBlocks, and this is evident in the screenshot above.

We also implemented labels for WonderBlocks, which are visible in the screenshot above. Although it’s not evident from the screenshot, the labels also automatically rotate in the 3D space to always face the in-world camera/avatar. Regardless of where you go in-world (even straight up,) the labels always face you and are perfectly readable. In our current implementation, a label’s color is automatically set to the color of the WonderBlock associated with it.

In addition, we implemented connectional direction indicators. As you can see in the screenshot above, Huey is connected to Dewey bidirectionally, while Dewey is Louie’s parent. We chose to use tiny spheres to indicate direction. Tiny cones may have been a better choice, because they could be made to look more like arrows and clearly show directional relationships, but the aforementioned issues we had with 3D rotation prevented this. Rather than worrying about 3D rotation, using spheres for direction indicators required simple vector math.

We also added a feature that allows the full path to the WonderBlocks Data XML file to be specified in the WonderBlocks WFS WLC XML file. (Whew, that’s a lot of acronyms.)

Next, we are going to investigate creating an in-world HUD that allows WonderBlocks and connections to be added, changed, or removed in-world, as well as the ability to move already existing WonderBlocks (which would also redraw their associated connections.)

We made a significant amount of progress today.

Our first attempts to integrate the front-end and back-end of the WonderBlocks component are showing great promise. The WonderBlocks server-side component is able to read in a collection of WonderBlocks from an XML file and communicate that data to a client, which then draws the WonderBlocks on screen with the correct size, position, color, etc. We’re having problems getting connections between Blocks to render properly, but you can expect to see a screenshot here once we fix that issue.

A few other things got done today. Paul helped us figure out how to enable simple shading on the WonderBlocks so that they look more three-dimensional and have more specularity. We also took a significant amount of time to rework and restructure our repository layout, to make the overall structure of the WonderBlocks component simpler and clearer.

Tomorrow we plan to address the issues we’re having with rendering connections. We’ll also implement rendering directional connections, because currently, a connection’s direction is completely ignored at the rendering stage.

Day 19

We worked for the entire day to find a way to connect two WonderBlocks graphically. After several hours of poring through the Java3D API, sketching, and doing trigonometry, we’ve come up with a method for this that works well.

To draw a connection between two blocks in-world:

1. The origins of the blocks to be connected are averaged together to find their 3D midpoint, which becomes the connection’s origin.
2. The distance between the origins of the blocks to be connected is calculated using the Pythagorean theorem, and this distance becomes the connection’s length.
3. A thin cylinder with the calculated length is drawn at the calculated origin. Angles of rotation for the cylinder in all three 3D axes are calculated using basic trigonometric functions, and the cylinder is then rotated into the appropriate position to appear as though it is connecting the two blocks.

The part of the problem we easily spent the longest time on was the third (rotational) part. The Java3D API includes quite a few different ways to specify rotations, so a lot of math and experimentation was necessary. In any case, after a long day of work, we can finally visually represent WonderBlocks connections in Wonderland.

Day 20

We’ve finally started work on linking the back-end and front-end of the WonderBlocks component. This, of course, could not proceed until we fixed repository issues. It seems as though something was not properly committed to the repository, so we temporarily could not use the work we had already completed the day before. Fortunately, we figured out what the problem was and were able to continue.

We then wrote a method that draws a WonderBlock in-world using Java3D, utilizing objects from the WonderBlocks backend (rather than using generic Java3D code, like we’ve been doing up to this point.)

Because Gary requested to see some design notes regarding the WonderBlocks backend, we spent today writing them. You can download our first draft here:

WonderBlocks Backend Design Notes (First Draft)

Please let us know what you think in the blog comments!

We also made some more progress on the front-end half of the coin, as well–we finally figured out how to set the origins of Java3D primitives in-world. It turns out that setting an Origin for an object or a cell is just a transformation (Transform3D) on this object. Today, we eliminated the need for a defined origin and rotation in a WFS xml file. This means that the meshing together of the front and back-end of the WonderBlocks is going to be simple (and hopefully a little less painful).

The only thing left to do before writing the client <-> server protocol is to write a method that can visually connect two in-world WonderBlocks, so that connections that are read in from the XML file can actually be displayed in-world.

We’ll dive into working on the protocol after the weekend.

Yesterday we did not get to meet with Gary, but we did stand at the Sun booth at the WPI Career Fair. We gave fellow students insight into what it is like to work on an MQP project at Sun.

Today we spoke with Gary on the phone to discuss our progress and our plans for upcoming work. Additionally, we finished up the JUnit Tests for the back-end. The coverage of the tests looks good, but we have had a difficult time using the coverage tool in Netbeans. For the front-end (Java3D/Wonderland,) we’ve decided that connections between WonderBlocks will be visually displayed as thin cylinders, creating the illusion of 3D lines. We’ve started writing code that examines two Blocks and calculates approriate parameters to size and position a cylinder acting as a connection between them.

Now, we can finally start working on the core client <-> server communication protocol that will bridge the front-end and back-end code together. By early next week, we hope to be able to read in data describing a series of WonderBlocks and their connections from an XML file, and actually display them in-world.

We spent most of today writing JUnit tests for the WonderBlocks backend code, and exploring how connections between WonderBlocks can be implemented in-world via Java 3D. There are several different options. We can depict a connection by drawing a reallly long, thin cylinder between two blocks. Java3D also includes functionality for drawing lines in 3D, so this may be a better option.

Tomorrow, we’re meeting with Gary at WPI to discuss our progress, and then we’re talking to students about the work we’re doing on our project at the Sun booth/table at WPI’s career fair!

The WonderBlocks back-end is nearly complete. Jordan reviewed our code and made a few helpful suggestions. We are are making the changes suggested and continuing on the right path. We’ve also heavily documented the back-end code with Javadoc. Tomorrow, we’ll perfect our JUnit tests for it. After the initial back-end work is complete, we need to start thinking about designing the WonderBlocks client <–> server protocol, which we’ve mentioned here in previous blog posts.

We also did some front-end work today. Experimenting with different shapes, sizes, and colors of the blocks proved to be fun. It seems that it will be a smooth transition from the back-end to the UI. Some investigation has been done on to visually represent connections between WonderBlocks once they are created. We also had a phone-call with Jon today to discuss how to move away from WFS XML files when placing our WonderBlocks in-world. Things like how to place an object in a specific place without using the WFS were discussed.

A rough idea of how (extremely large) WonderBlocks could look

We spent today doing two things.

1) Expanding the the backend classes that we started working on yesterday.

To facilitate easy storage/serialization as XML, block objects are mapped to unique IDs through the use of a singleton class called BlockManager. We’ve also started implementing connections between blocks. Connections are separate objects (not inherently built into Blocks) that are also mapped to unique IDs through the use of another singleton class called BlockConnectionManager. The purpose of using these manager classes is so that no redundant data written to the XML file when the state is saved: one class contains only blocks and the other contains only connections. The managers allow blocks and connections to reference each other via IDs, making XML serialization straightforward. We’ve been able to do some basic testing in the console. We can successfully create block objects and connections between them, then store all of the information in an XML file, and finally create new objects by decoding/de-serializing the same XML file.

So far, the backend code is well commented but still needs Javadoc comments, as well as JUnit testing to ensure that all of the connection behaviors are working properly.

2) Exploring how things will integrate with Wonderland.

Although we still have a lot of work ahead of us before tying the aforementioned WonderBlock backend into Wonderland, we thought it was worth revisiting how creating 3D primitives (Box, Sphere, Cylinder, and Cone) works inside Java3D, and in turn inside Wonderland. We revisted Jordan’s ‘Extending Wonderland’ tutorial, and were able to place untextured, colored primitives in world (what WonderBlocks will be theoretically comprised of,) although we’re still having some issues with the shading of the primitives that need to be addressed.