Subscribe for FREE

Discussion Area

VRML by the Pound

People Linking to Us
Tell a Friend

We'll Link to You!!

Aereal, Inc.
Instant VRML World
Proteinman's Top Ten VRML Worlds

view me!

Authoring VRML 1.0 (Part 3 of 4)
by Len Bullard

Up to this point, we have been building individual objects and making compound objects. Creating a scene with VRML is simply a matter of doing this with larger and more complex objects, then arranging the objects in the positions and sizes that you want for the final scene. This is when the WWWInline is very useful.

Layout is where the theatre stage model is most evident. You are taking set pieces and placing them on a stage in a position so that they are convincing representations for your scene, and the lighting of the set works to maximum advantage. Now you really are world-building.

Using A Main File
Many VRML modelers advocate the use of a "main" or "hub" file. This file simply repeats the exercise of using multiple separators, WWWInlines and USE statements to build a composite world made up of compound objects. The file is organized something like this:

	VRML Declaration 
	Root Separator 
	Extension Nodes
		First Object Separator (Usually the ground or stage floor)
			Transforms and Materials
		Second Object Separator
			Transforms and Materials
	... and so on.

It is uncomplicated to layout a scene when you organize it like this because the position of each object is figured independently from the world origin. This makes it easier to adjust each object and debug any errors, making for cleaner files. In fact, some VRML 2.0 browsers, on loading a world such as this, point directly to the offending inline so you can fix it. Some 1.0 browsers don't. I spent a very tortured evening working on just such a problem until Joel Tanis found the bug and told me where it was.

God Bless The Web. If you apply a USE statement, things will get complicated because the Transform values will begin to jostle each other. My advice is not to USE inside a main file.

it is often a good idea to sit down with a piece of graph paper

When planning the layout, it is often a good idea to sit down with a piece of graph paper and outline on the grid where you want objects to be. That allows you to figure out in unit positions (meters, hopefully), exact distances. This lets you see if objects will obscure lights or camera angles, etc. If you have built your objects to scale, this works very nicely. If not, and I often don't, you have to insert scale nodes to get things to look right in contrast to the other objects in your world. Don't worry; this gets easier as you do it.

Sometimes, a builder uses objects that were built for other scenes or that were "noodled" into existence, or, like me, gets enthralled and doesn't plan things well. In those cases, it helps to insert cameras at different view positions so you can load the scene in your browser, see where things are at, then make adjustments and look again. North/West/East/South/Above/Below positions work well.

I get beat on a lot for using frames

To Frame Or Not To Frame
Although this topic belongs under extensions, frames are an HTML property. I get beat on a lot for using frames. Framing and interframe targeting are classic hypermedia techniques to enable a stable focus for interactivity. For example, using a frame lets the user select and load different files without having to back up or reload a VRML world used as a Table of Contents. VRML takes significantly longer to reload, so as a focus frame, it isn't very effective. Do as you will. I find frames to be very useful. The WWW Luddites can take their silliness elsewhere. If you choose to frame, layout and camera technique have to be applied. Think hard about what you want in the frame views and set the camera appropriately. Test this and ensure that the frame makes a good picture.

Inserting Cameras
Cameras are quite easy although, if you don't layout the world and document object positions, it can take hours to get cameras right. A camera is a viewpoint. Here is a description of a Perspective camera and its most useful properties.

	DEF OpenView PerspectiveCamera {
			position 0 50 500
            	orientation 1 0 0 -0.25
			heightAngle .0034

  1. position - an XYZ coordinate of world.
  2. orientation - radian value for turning the camera through an axis. The orientation flags for XYZ are floating point values. You can use combinations to create isometric view angles, etc. It helps if you have an editor or program to do this, because the calculations are complex. You can treat these as integer flags to turn the camera. Note that the movement is orthogonal to the axis used. Think of this as a camera lens with three steel bars through them.
    1. X axis turn: camera lens tilts up and down
    2. Y axis turn: camera swings left or right
    3. Z axis turn: camera tilts left or right (view is upside down)
  3. heightAngle - view volume. Use with care. Like a fish eye lens, it can produce distortions, but also, it lets you see more when camera is closer to an object. Err... "objects are closer than they appear in the mirror" effects.

There are other properties of cameras. Consult the specification or good VRML book for these field definitions.

There are two types of VRML cameras: perspective and orthographic. Perspective cameras have a vanishing point, and orthographic cameras don't. A perspective camera looks more natural to the human eye, so I use it mainly. An orthographic camera does not allow objects in the distance to disappear as one moves away. This is useful when one object is the center of attention such as might be the case in a parts catalog. Try them both.

Most VRML 1.0 browsers enable one to animate between camera selects. Some users don't realize that in some browsers, one can select new camera viewpoints while traversing to one, and thus, switch the path the camera is moving on while in motion. It makes sense to set the cameras up both for focal interest, and also for logical space traversal. Here is a set of camera nodes from the Talosian Spaceport:

 DEF Cameras Switch {
	whichChild  0

	DEF OpenView PerspectiveCamera {
		position 0 50 500
            orientation 1 0 0 -0.25

	DEF Ships PerspectiveCamera {
		position -22 2 27
            orientation 0 1 0 -0.25


	DEF SunFlyer PerspectiveCamera {
		position -33 8 0

	DEF SunFlyerFront PerspectiveCamera {
		position -45 8 -15
            orientation 0 1 0 -1.0

	DEF RightHigh PerspectiveCamera {
		position -45 14 -15
            orientation 0 1 0 -1.2

	DEF RearHigh PerspectiveCamera {
		position 0 13 -50.0
            orientation 0 1 0 -3.14

	DEF WirAmp PerspectiveCamera {
		position 34  10  -30
            orientation 0 1 0 -3.37
	DEF HighRight PerspectiveCamera {
		position 58 12 0
		orientation 0 1 0 1.57


	DEF RoganBorer PerspectiveCamera {
		position  5 5 35
		orientation 0 1 0 -1.20

	DEF Portal1 PerspectiveCamera {
		position 40 5 0
		orientation 0 1 0 -1.57

	DEF Portal2 PerspectiveCamera {
		position -40 5 0
		orientation 0 1 0 1.57
	DEF Portal3 PerspectiveCamera {
		position 0 5 40
            orientation 0 1 0 -3.14

	DEF Portal4 PerspectiveCamera {
		position 0 5 -40

Notice the following:

  1. Cameras can be inside a VRML switch node. The whichChild field can be set to 0 which tells the browser to use the first camera as the opening view. If set to 1, it will use the second camera and so on. The browser will use this order if the user animates or selects a NEXT control.
  2. My cameras are ordered and positioned so that if the user uses NEXT and Animate, they go to each object logically and without collisions. It is mainly a circular tour, so if the user knows where to select NEXT multiple times or PREVIOUS multiple times, they can short-circuit the tour and get new animations.
  3. The Portals are all at the end. The intent is to make these a set of exit points to other worlds in the series and let the user get to them easily.

As I mentioned in the scene layout section, I recommend putting in a few cameras while laying out the scene to help you navigate. For example, I will usually put one in front of every object I want to work with, four in corners of the scene, and sometimes one above the world oriented down.

learn good camera angle and view composition techniques, you can read books

To learn good camera angle and view composition techniques, you can read books. Looking at paintings is revealing, but the best thing is to learn to look at the real world with an idea that you might want to "virtualize" what you see. Then intuit where a camera would have to be to capture the view (usually between your eyes). It develops a sense of proportion and perspective similar to the habit of decomposing complex objects into primitive shapes, and both can become obsessive habits.

We are only going to dip lightly into this illuminating subject. (Owwww!!) The reasons are that lighting is a complex art and I am not qualified to teach it, although I was a lighting technician. Color mixing is a subtle subject. Lighting a VRML world and lighting a stage set have subtle differences. The Material node properties for coloring an object contain fields for how that object is rendered under light and the color of reflected light:

  • Transparency - light shines through the object, like a window or lace curtain
  • Shininess - what else, makes objects shiny vs dull
  • Diffuse - light reflects off object in random directions
  • Emissive - light color an object emits, like a lightbulb
  • Specular - light reflects at the same angle it hits an object like a mirror. Used to produce shiny, plastic effects
  • Ambient - sift unfocused light, like a wash, it fills the scene

These properties plus the positions, colors and types of lights determine the overall lighting of a scene. I refer you to better tutorials and a lot of experimenting. Otherwise, we look at four basic topics:

  1. Using the headlight
  2. Selecting types of lights and setting properties
  3. Positioning Lights

Using the Headlight
A headlight is a default light provided to you by the browser. It does not have a node in the language. Some browsers give you an extension node to turn it on and off because by default, it is on when you enter a world. There is also a menu selection for doing this. It acts like a miner or spelunker's lamp. It emanates from your view (as if it were mounted on your forehead) and lights what is front of you, usually, the entire scene. It is the VRML equivalent of a par38, or area light so often seen in sports stadiums and on the front of your Dad's garage.

Isle of Jeenix

If you are using the other types of lights, you should turn the headlight off. On the other hand, it is computationally a very cheap way to light the scene, so if you aren't using lighting for effects such as mood, use the headlight. I've used it for most of my worlds except the Isle of Jeenix.

Selecting types of lights and setting properties
VRML 1.0 has three lights besides the Headlight. These lights have VRML nodes:

  1. DirectionalLight - Light from a great distance, like the Sun.
  2. SpotLight - focused light. Creates a cone within which objects are illuminated.
  3. PointLight - emits light in every direction. Like a lamp with a shade removed.

Properties of each type of light vary. They all have on/off, intensity, color, and location fields. The DirectionalLight has a direction field. The Spotlight has the direction field, plus a dropOffRate and cutOffAngle. Browsers vary in how much they support these types of lights and properties. Since this is so, and lighting effects can vary, it is a chief source of browserHell. Experiment!

In theory, different colored lights can be combined to get different object renderings

Positioning Lights
Lights have a location field that enables you to position them just like objects. This plus the intensity field settings can sometimes, depending on browser support, be used to create different mood effects on the illuminated object. In theory, different colored lights can be combined to get different object renderings. I mention elsewhere the technique of backlighting transparent objects.

Creating Hyperlinks
Because VRML is a hypermedia hub language, like HTML, it gives you the capability to link to other worlds. This uses the WWWAnchor node. It looks like this:

	WWWAnchor {
		name "talos.wrl" 
		description "The World of the Talosians"
	     Sphere { 

This is straightforward:

  • name - name of a VRML file to go to; a URL address
  • description - a string to display when the cursor passes over the anchor object, e.g, the sphere
  • an object - in this case, a sphere. Clicking on the object initiates traversal of the hyperlink
  • In the extension on Netscape extensions, two other uses of the WWWAnchor are shown.

    Talosian Spaceport

    We are formally at the end of good VRML 1.0 building techniques. My best example of a layout that combines all of these techniques is the Talosian Spaceport. In next month's article, we will discuss the heretical/black art of extensions.

    Len Bullard is a systems analyst and a married father of two children. He splits his consciousness between his job as a hypermedia consultant and his rock band of ten years, Ground Level Sound. His interests in VRML spawned from a conviction that this was the technology that would rejoin his divorced psyches and help him fight a lifelong addiction to endorphins. He spends his copious spare time recording original music with his band at their studio, Blind Dillo, performing in the southeast region with GLS, beta testing and answering email.
    Back Contents Next
    Have you tried out our new Discussion Area yet?

    LinkExchange Member

    Need sponsorship or advertiser information? E-mail adrian@aereal.com.

    Have an idea for an article? Thought of a way we can improve VRMLSite? E-mail suggest@vrmlsite.com.

    Please Tell a Friend about VRMLSite!

    © 1997 Aereal, Inc. All rights reserved. VRMLSite is a trademark of Aereal Inc.