Marble-ous Week of Code results

August 26, 2009

marble-ous logo

Our Week of Code project to build a physics simulation resulted in us “exceeding customer expectations”, as Mike put it (but we suspect he’s easily pleased!) However, our expectations were really exceeded by the above logo that our designer Gary Ritchie created for us.

To summarise the project, here’s Mike’s initial list of ideas for what he wanted:

  • Design
    • Only element of motive force is potential energy
    • Variables:
      • Gravitational force
      • Mass of object
      • Size of object
      • Diameter of Loops, Angle of Banks, Length of Track
      • Aerodynamic coefficient of friction
    • Equations for potential and kinetic energy along with rolling and aerodynamic resistance should be displayed in design mode
  • Race Mode:
      1. # of loops
      2. # of turns
      3. height of launch
      4. mass of marble
      5. lateral acceleration
      6. gravitational force
      7. aerodynamic coefficient of friction (this will be varied from vacuum, earth’s atmosphere at sea level, perhaps underwater
    • Hidden designs until ready for race
    • First person, Third person, Bird’s eye view and follow-me cam
    • Selection of backgrounds: Earth, Other planetary object (Moon, Other Planet, Asteroid), Space – {either Earth’s atmosphere or none}
    • Objectives can vary:
      • “Design” track to accomplish:
        1. stay on track
        2. get marble to end first
        3. launch marble certain distance
        4. launch marble to achieve a certain height + distance
        5. or cross finish line fastest
        6. longest distance covered on track
        7. longest time in motion
    • Display vertical and horizontal acceleration as objects go through tracks
    • Display energy as objects go through tracks
    • Game will define objectives randomly (so it’s a different race every time) and variables will be constrained by certain parameters defined by game logic:
    • These variables should be selected secretly by collaborators / players. The game logic should determine success or failure mode prior to “launch” based on “level of difficulty”….easy means remaining variables will be selected to ensure success
  • Crash / Impact Mode:
    • Skee ball
    • There is no lateral acceleration that can be accommodated without a bank in the turn, this will simplify that component
    • Spatial coordinates as to the target need to be specified (x,y,z)

However, we managed to negotiate our way to something that seemed achievable in four days of development. Miriam wrote up a great summary of our approach and Mike’s acceptance tests. I’m pleased to say that the team achieved and exceeded everything we had promised Mike and had no known outstanding bugs by the time we presented the final software to him on Friday afternoon. The test script that Mike agreed was:

  1. Login from two users
  2. Insert cell by one user
  3. Add/remove segments BUT NOT ALL AND NOT THE FIRST
  4. Change properties of a segment
  5. Run a sim by one user
  6. Stop sim by same user
  7. Replay by same user
  8. 3 x view billboard, shift-click
  9. Reset by one user
  10. {Repeat x2, with alternate user}

Unfortunately, we missed the one additional goal that we set ourselves: to produce a short video of the project. Better late than never, here’s a very brief demo that follows the test script.

Those of you with a physics interest might be interested to know why energy has decreased as the marble goes around the loop: what we’ve modelled as friction is simulated by collisions of the marble against the tracks.

Immersive Ed High School and RezEd Podcast

August 21, 2009

There are two news items this week that I thought you might find interesting: 

Immersive Education High School – One of our Wonderland community members, Wes Williams, is setting up a new school in the Boston area to allow expelled, incarcerated, or shut-in students to attend high school remotely. Follow the link to view the Roxbury Institute of Technology announcement on YouTube.

Roxbury Institute of Technology

RezEd Podcast – A Discussion on Project Wonderland – Kevin Roebuck and I, plus Warren Sheaffer from St. Paul College and Matt Schmidt from University of Missouri were interviewed about Wonderland and some of the ways it is being used in education. RezEd is an interesting community for educators interested in virtual worlds. Please join the Wonderland discussion on RezEd which Kevin started.

Project Darkstar Adoption Survey

August 20, 2009


I wanted to make people in the Project Wonderland community aware of a Project Darkstar adoption survey we are conducting. This (admittedly non-scientific) survey is an attempt to find out more about who is using Darkstar and for what. The Sun team will consider these results as we update our plans for the future.

The survey contains just five multiple choice questions and a couple of open-ended questions for people to tell us whatever they like. All responses will kept confidential within the Sun team and the survey is anonymous.  

Further details are available in this post on the Darkstar project blog. A direct link to the survey can be found here.

We are encouraging anyone using Darkstar to develop a game or other application to fill out this survey.

Thank you!

Karl Haberl

Director, Project Darkstar 

Week of Code Finale

August 14, 2009

Today was our Week of Code grand finale. By 4pm, both teams had a working demo, which we showcased at the Sun Labs West monthly "Show and Tell" session. Were there bugs? Of course! Did we get everything done we had hoped? Of course not! But there were a lot of smiles at the end of the day. The general consensus was that we met or exceeded our goals of testing out the APIs, filing bugs, creating some useful new sample code, identifying areas that need documentation, and having some fun doing it all. Although both teams did have to fix some bugs in core, neither team needed to make any core changes, so that was a major triumph and the sort of validation of the APIs that we had been hoping for.

I want to say thank you to everyone who participated in the week, especially Bernard and Nigel, our two full-time work-from-home team members, who lead the Marble-ous and Timeliner teams. It’s a privilege to work with such a talented group of people.  Next week, when we’re less tired, we’ll post some final screen shots and a recap of the event from a technical perspective. In the mean time, please do your part to help stabalize Wonderland v0.5 by helping with testing.

Wonderland Week of Code Participants

Back: Bernard, Nigel, Miriam, Nicole, Jonathan, Joe, Deron, Kevin R, Drew
Front: Matt, Mike, Jordan, Paul, Doug, Kevin M

Wonderland Week of Code: Team Marble-ous Day 4, Integration

August 14, 2009

Day four finds team Marble-ous boisterously integrating code. Doug implemented really cool shaders for the track and ball, Paul finished the rendering and editing for the track and ball, Deron finished the simulation trace, Jordan and Deron wrapped up multiuser issues, Jordan got the reset button working, and Bernard finished the segment editor.  Kevin is still working on the stretch goal of adding sound effects.  The day’s goal of having an adequate demo for Friday was met, with revision 922.  Team Marble-ous has checked in 7197 lines of code this week, so far.

The plan for Friday: fix bugs and polish things up until lunch, then prepare for the demo at 4.

Here’s a recap of the project: 

Big Picture: Teaching Newtonian Physics

Goals: Usable software by the end of the week; reflecting on using Wonderland as a developer and improving the developer experience to make Wonderland the best platform for developing virtual worlds.

Approach: Nominate a non-developer as a customer (Mike), and capture user requirements. Provide incremental value to the customer during the week. "What’s the simplest thing that could possibly work?" (Don’t boil the ocean.)

Acceptance Test Scripts:

  • AT1: Student user uses 3 fixed pieces of track (straight, loop, ramp) to construct the track and then drops a marble on it.
  • AT 1.5: The user is able to remove segments of track.
  • AT 2: Multiple users are able to achieve the above
  • AT 3: After dropping the marble the user is able to see a timeline of the position and velocity of the marble as it traveled down the track and other data than can be derived, including acceleration, potential and kinetic energy, and force.
  • AT 3.5: The user is provided with icons identifying types of track segment.

Stretch Goals:

  • Stretch 1: The user can select more types of track segment
  • Stretch 2: The user is able to change the properties of a segment of a track
  • Stretch 3: The user hears an appropriate sound when dropping the marble on the track (Plus a non-customer goal of documenting how to add sound to a cell.)

Developer Tasks:

  • Find and integrate a physics simulation engine
  • Create track, segments and segment types
  • Create visual representation of track, create specialised shader for the track and marble
  • Integrate physics engine and collision system with representation of track
  • Create 2D HUD to add/remove track segments, and start/stop/reset sim
  • Make the whole thing multi-user
  • Add icons to 2D UI
  • Capture simulation data
  • Add 2D timeline slider
  • Add billboarded data points
  • Add sound
  • Create 2D UI for editing track segments
  • Extend the number of segment types

Here’s the latest screen shot:

And for those of you who’d like more details on the code interfaces, here’s a diagram: 

Week of Code Day 4 – Timeliners Report on Progress

August 13, 2009

Nigel, the lead Timeliner, explains that the timeline application has a fundamentally different life-cycle than any other Wonderland application we have built in the past. Timelines include three main features: creation, curation, and navigation. The unique thing about creating a new Timeline is that the cell cannot be instantiated until after the user has specified a set of parameters. The unique aspect of curation is that manual placement of objects on a timeline is extremely difficult, so the application needs to assist the user in placing objects. And finally, as was mentioned in a previous blog post, navigating the spiral is a challenge, so the application also has to help users get around.

In today’s blog post, I’ll give you an update on what each of the Timeliners has been up to and provide a glimpse of what all the pieces look like put together.

Timeline on Day 4 of Wonderland Week of Code

Starting on the visual side, Matt has been working on the math and graphics code to generate a spiral. While it’s conceptually easy to take a simple trapezoid and tesselate it around a core to create a spiral, it’s been a little tricky to accomplish this in Wonderland. Every single point on every trapezoid has to be individually calculated and there was a learning curve to figure out how use quaternions – representations of rotations. In addition, the JME quad meshes didn’t work properly, so after a lot of hair pulling and double-checking the math, Doug suggested that Matt try using tri meshes instead, and finally the timelines started rendering as expected as you can see from the image above of our first automatically generated timeline.

Drew is implementing a cool slider on the HUD for navigating the spiral. As you move the slider up and down, your avatar zips around the spiral. The HUD panel also shows your current position in the form of a date.

Nigel is building and hooking up what seems like a million dialog boxes. There’s the main dialog for creating the timeline. This one collects the basic information about the start and end date of the timeline, the desired units of time (hour, day, week, month, year), and the size of each unit. We spent quite a bit of time deciding how best to express the size of the units. For example, if you set up a timeline by day, do you want one day to take up a 10th of a turn of the spiral, or do you want it to take up 2 full turns. This will depend on how much data you want to display for each day. We finally decided on expressing this in terms of revolutions. So you can set the scale of the timeline to make one revolution equal to values such as 1 hour, .5 days, 2 weeks, 3 months, or 100 years. You can also specify a variety of other parameters that govern the look of the timeline.

Other dialogs include one for manually entering text, images, audio, or 3D models, one for setting up "keyword collections," and one for adding "timeline providers."  Jon is working on these last two features. He has written a timeline provider API that is an extensible mechanism for adding dynamic data to a timeline. Each provider is specialized for a certain type of content. Examples of providers might be news, wikipedia events, Time magazine covers, NPR podcasts, personal calendar information, a twitter feed, stock quotes, or any other information source that is time-ordered. Each provider decides what input it needs from the user. For example, a news provider, which might aggregate news from a variety of sources, might take a user query and ask the user to make some decisions about which news sources to search.

Since images are easy to render in Wonderland, Jon tackled a Flickr provider first. In its simplest form, this provider takes a query and uses the "date taken" field to decide where on the timeline to place the resulting images. The default is to display one image per time slice. In the advanced configuration panel, users can specify the number of hits per time slice to display, whether to search the full text or just the tags, whether to select the images based on relevance or interestingness (that’s a Flickr term), and whether to use just Creative Commons licensed photos.

Drew is responsible for figuring out how to lay out the results of each provider. He is taking a two-step approach to creating a timeline layout manager. The first step is finding the correct cell type to display the data from each provider. For example, if the provider returns images, we use the image viewer cell and if it returns text, we use the sticky note cell – a new feature conveniently contributed to unstable modules by a community member just yesterday! The next step is to put each object into the appropriate time slice and figure out where in that time slice it should go relative to other objects. To the right is a video of the first timeline generated with Drew’s layout manager.

One thing we quickly realized is it can be difficult to populate a whole timeline with a single query. Also some sources of data, such as Wikipedia articles, do not provide date information without requiring complex parsing, and other sources of data, such as Flickr, do not provide reliable date information. For example, I’m working on curating a timeline on the life of Frank Lloyd Wright. I want to include Wikipedia articles about each of Wright’s famous buildings along with photographs and 3D models. If you do a Flickr search for the famous house Wright designed in 1934 known as Fallingwater, you get over 18,000 hits. The oldest photo in the collection, however, was taken in 1971. I want a picture of Fallingwater to appear on the timeline in 1934, not 1971. To address this issue, we came up with the idea of keyword collections. These are a way of doing date-specific queries. For example, here are a few lines from my keyword collection for Frank Lloyd Wright:

1934 Fallingwater
1937 Hanna-Honeycomb House
1940 Goetsch-Winkler House

These queries will be handed to each timeline provider configured for the timeline. For example, if I have a Flickr provider, a Wikipedia provider, and a Google 3D warehouse provider, the same queries will be sent to all three services and I’ll end up with a photo of Fallingwater, the Wikipedia article about Fallingwater, and a 3D model of Fallingwater placed on the timeline at 1934.

Of course, we won’t be able to build all these providers by Friday, but hopefully we’ll have a Flickr provider and a New York Times news archive provider automatically laying out the data on a dynamically generated timeline. Others can then extend the functionality by writing new providers.

The last piece of the puzzle is audio, which Joe is working on. As people navigate around the timeline, we want to have audio associated with time segments. For example, while navigating the Frank Lloyd Wright timeline, you might want to hear top hits of the day, audio recordings of Frank Lloyd Wright talking about his architecture, or recordings of other experts talking about a particular building. The big challenge for Joe is figuring out how to get the audio to play just within a time slice, keeping in mind the irregular shape of spiral timeline segments. In addition to the non-rectangular footprint of the segment, the audio also can’
t bleed above or below the segment, or people will hear it in the wrong place. At first this problem seemed daunting, but Drew came up with a service to send notifications when an avatar transitions from one time segment to another, which dramatically simplified the audio calculations. Another challenge is nicely blending the audio so that it doesn’t sound jarring as you navigate from one segment to the next.

 Just to explain why we’ve been so heads-down, the Timeliners have written 12,333 lines of Java code in 4 days!


Get every new post delivered to your Inbox.

Join 56 other followers

%d bloggers like this: