Project List


Interview: Player 2.0
Authoring for 3D Nav
ITV Design Principles


1000 Cranes
Paper Chess Set

< previous project project list next project >

Authoring for Navigation in 3D Worlds

This article was originally published in Fall 1997 in the "Tips & Tricks" section of vrml.sgi.com, a news and resources site for the VRML (Virtual Reality Modeling Language) developer community. It is still used as a teaching tool in week 4 of Matt Lewis' Building 3D Virtual Environments course.

Let's face it: navigating a 3D world using many of the current VRML browsers is a difficult proposition at best. Users often wind up upside-down, staring off into space, or miles from where they intended to be. And frustrated users are unlikely to come back for repeat performances.

Much of the difficulty can be addressed by browser writers. As browser developers do user testing, learn from the gaming and research communities, and iterate on designs, the browsers will get more usable. But until then, there are plenty of things you, as a VRML author, can do to help users have a good experience.

One, one thousand, two one thousand...

The first three things to think about when designing worlds for good navigation are frame rate, frame rate, and frame rate. As the frame rate drops below about 5-7 frames per second, navigation gets increasingly difficult. If the user is moving at all quickly, there will be large jumps in position between each frame. First you're here, then *poing*, you're 30 meters ahead. This is disconcerting, to say the least, and makes both quick movement and fine positioning very hard to do.


  • Test your worlds on the target platform, and make sure that they run quickly enough. It is better to remove some polygons or textures than to have a beautiful world that no one can see or move around in.
  • Embed your VRML world in an HTML page, as if it's a one-frame comic strip. Smaller windows into the scene will generally render faster.

Help, I'm blind! (or Nobody told me this thing had feet.)

Try this: take a piece of posterboard and cut a six-inch by three-inch rectangle out of the middle of it. Now, hold it up in front of you and (ignoring all the funny looks you will get) try walking around, looking only through the rectangular hole. You will probably trip over a few things and bang your knuckles on a doorframe before you get very far. That's the experience that we're all having in 3D worlds. Users can't see or feel their outer perimiters, so when they hit their shins or shoulders on something, it's difficult to understand what is happening.


  • Pay attention to the avatarSize field in the NavigationInfo node. Set these values so that they make sense for your world.
  • Build wide doorways and short steps, so that the user can confidently navigate without needing to look to the side or down.
  • Don't leave your skateboard in the driveway. Again, looking down while navigating is tough. Don't build objects that are taller than the step height that's in the avatarSize field, and yet are so short that the user can't see them at the point of collision. (The default step height is 0.75)

The first step to a cure is recognizing the problem...

"Yesh, ossifer, I can walk a straight line if I could just get this browser to do what I want..." In many browsers, it's rather tough to make fine corrections. Getting from here to there often involves a few swings back and forth as the user corrects, then overcorrects, then corrects again, etc.


  • Don't build worlds with sharp corners. Turning corners is particularly difficult, and often involves much banging into walls and cursing before the user makes it. Gentle, sweeping curves work best.
  • Build wide doors. Once the user has collided with the edge of a door, it can be very hard to get straightened out. Best to just make it wide enough in the first place.

Where am I? Where was I?

We can learn from folks who have been studying the problem of people navigating for a long time. It turns out that there are a few basic ways that people divide up the world when they're thinking about navigating [1,2]:

  • Paths - hallways and passages
  • Edges - walls and fences
  • Landmarks - things that stand out from their surroundings
  • Nodes - pieces of the world with similar characteristics
  • Districts - logically separate sections


  • Use landmarks. Putting a tall yellow neon obelisk in your main square is a great way to ensure that users can find their way back there from anywhere in the world. (Okay, so a neon obelisk would be ugly, but you get the point.)
  • Create nodes. Use color, theme, or shape (or whatever) to group parts of your world. "I remember I was in the blue section when I saw the paisley whale."
  • Use audio. Sound can create a powerful sense of place, and the spatialization can act as a direction finder. Environmental audio can create both landmarks and districts.

Now what?

You've gotten the user to click on your very snazzy world, they've waited for the inlines to appear, they're all ready to have a great experience, and ..... How does a user know what there is to do and to see??


  • Use viewpoints. Well-named viewpoints can tell users a great deal about what they might find interesting. By just using page-up and page-down (in most browsers), users can get a quick idea of where all the good parties are.
  • Use in-scene widgets combined with viewpoint animation to navigate for the user, as Sam Chen did in OOBE using arrow images like small signposts. This relieves the user from figuring out how to navigate and where to go. If the main point isn't navigating, but instead what to do when you get there, this method can be very effective.

How do I get off this crazy ride?

You click down, give the mouse a confident sweep.....and suddenly end up feeling like a bird who smacked into a window. The world revolved around you, and you're up-side down and backwards. What happened?? You thought you were in "Walk" mode, but you were actually in "Examine". Ooops.


  • Use the type field of the NavigationInfo node. The truth is that Examine mode works great for single objects floating in space, but is lousy if the world has a floor and a ceiling. The new changes to the spec mean that authors (yes, you) have much more control over type. If you specify type as ["WALK", "FLY"], then the user won't be able to get to the Examine viewer in the first place.


[1] Lynch, K. (1960). The Image of the City. Cambridge: MIT Press.

[2] Darken, R.P. and J.L Sibert, A Toolset for Navigation in Virtual Environments, in UIST '93. Atlanta, GA: ACM Press.

Also see portfolio project: Cosmo Player 2.0

< previous project project list next project >