Idea

K'nex is a building toy made up of struts and connectors that can be snapped together to create a variety of interesting structures. K'nex Viewer is an online model browsing application that allows users to explore K'nex creations that have been documented digitally.

Users can orbit and zoom around each K'nex model as well as auto-zoom into a particular connection to examine how the pieces fit together.

The K'nex Viewer includes a file loading interface to preview and load other K'nex creations. The 'Component View' function provides information on how many of each piece are used in the scene and how much the creation will cost based on the K'nex website's per part cost.

This version of the K'nex Viewer includes four models to choose from; these models were created for testing purposes and will be replaced as soon as I can document some of my own K'nex creations.

How to use:

Cick on the link below, keep in mind the presentation may take a moment to load.

Once the presentation has started click on the 'HELP' tab for help.

If the presentation doesn't start, you may be experiencing plugin difficulties. For help check our Tech Support Page.>>

Click here to start:

K'nex Viewer

About:

I've always been a Lego fan, but recently I've begun experimenting with the K'nex building toy. As a child I had envied my uncle's complex Meccano creations, and to my delight I discovered that K'nex allowed me to create similar feats of toy engineering. The problem with creating an 8 foot toy ferris wheel is that once you've finally decided how to put it together, you're afraid to ever take it apart again.

I decided to begin documenting my creations. Unfortunately photos don't really help to make the designs understandable; this seemed like a perfect opportunity to showcase interactive 3D.

I have noticed that there is a distinct difference between documenting Lego and K'nex. When creating Lego instructions, the primary concern is to show what order the pieces are assembled in; Lego creations are so tightly packed that they need to be taken apart to be understood, an idea which I explored when creating my Lego Builder. K'nex creations are wide open by comparison, the real concern is not in what order the pieces are put together but in how each particular connection is made.

The K'nex Viewer is based on this idea of exploring the connections. The primary function of the viewer is to allow users to quickly focus in on a particular joint and examine the pieces attached to it. Apart from the primary function of examining joints, the K'nex Viewer gave me the opportunity to explore some other useful model browsing techniques.

Here is a brief description of how the K'nex Viewer is structured:

File size optimization:

Like most building toys, the K'nex system is made up of a limited number of components. This makes modelling the objects fairly easy. Most of the work is expended in assembling those pieces. Naturally one would assume that the file size of a virtual K'nex model should be fairly low, since most of the model is made from repetetive elements. This is not the case.

Most of the web3D technologies available do a less than perfect job of recognizing these kinds of duplicated elements, so in order to solve this problem I had to go around the Shockwave exporter.

I created one Shockwave 3D file that contained a library of the most common components, this file is loaded with the K'nex Viewer as part of it's initial download.

I then create a Maxscript that would list the names and position data of my K'nex assembly as a text file. Compared to the model data these text files are tiny, ranging from 3kb for a 30 piece model to 140kb for a 1500 piece model. When the K'nex Viewer loads a model, all it downloads is this small text file and then generates the 3D scene based on the library of components.

If an assembly uses a component not available in the core library, a tag can be added in the text file indicating the location for an additional library of components. When called, this library is loaded and it's elements are added to the viewer's library.

Although this would be overly complicated for viewing a single model, it is ideal for viewing multiple models. This approach also helps to streamline the process of creating these virtual documents. The only work in creating the virtual documentation is in assembling the model components.

Render optimization:

Shockwave has a wonderful set of tools for creating these kinds of dynamic models, however the Shockwave3D render engine is much weaker than most of the other 3D engines available. Users with slow machines are pretty much out of luck when viewing this kind of content. As a result I tried to optimize the load on the render engine as much a possible.

I ended up creating 3 versions of the individual K'nex components at three different levels of detail. By default the medium resolution versions are used when the whole scene is being viewed. If the number of components exceed 700 then the low-res versions are used by default. When the user Alt-clicks on a components to zoom in on it, all of the components are hidden except those in the immediate vicinity of the chosen piece. As well as hiding the excess pieces, the high-res versions of the models are swapped for the components that do remain visible.

This allows the user to explore the connections they are interested in at full resolution and without the clutter of the surrounding pieces.

Model independant structure:

Most of all I wanted this Viewer to be reuseable. My model-library approach made this fairly easy. All I have to do is to replace the text file that describes the assembly and re-initialize the scene.

In order to structure the viewer so that someday it might be database driven the initial model that is loaded is specified in the embed tag of the Shockwave viewer. The viewer does not need to be recompiled to change the default model.

The only failure I encountered in making the Viewer truly model independant is the file loader. Shockwave security rules won't allow the viewer to query the files on the server so the list of files available to be loaded has to be entered into a text file.

Now that the viewer is mostly complete I intend to start documenting some of my creations, I'm no longer afraid to take them apart.