This lecture is based on Lectures 4 and 5 of the course "Building Virtual Worlds", which was taught in the fall of 1997. The demonstrations are based on a software product called Community Place Conductor, which was originally downloaded for free from Sony Virtual Society. However, they have gone out of business and so I am providing it for our class only, at this location. You are not required to get this software (it is about a 12 mb download, and will take a while). I only recommend it for those of you who take a serious interest in 3d graphics, but who don't have the time to take CAP4021 or CAP5725 at some later date.
Background. VRML was developed by a consortium of people in response to the ideas in the nifty book Snow Crash by Neal Stephenson. I recommend it to everyone who plans to have a future in cyberspace. In Snow Crash, Stephenson describes a shareable 3d world which, many computer geeks immediately realized, could be built with 1994 technology.
VRML has fallen on hard times since the mid 90's however, as nobody has figured how to make money from it yet. There is a hardy band of true believers who push onward with the concepts and are developing an XML-based updated successor to VRML; see www.web3d.org.
I continue to teach about VRML because I believe that scene graphs are fundamental to the future of computer graphics.
Basics. The VRML universe has a coordinate system with X to the right, Y up and Z coming out of the screen at you. This is called "right handed" because if your right hand's fingers go from the X to the Y axis, your thumb is pointing along the Z axis. The coordinates are normally thought of as having the meaning of meters, though you can think anything you want of course.
Below ("example 3.1") is a simple link to a local copy of the program we'll start with today. If you click on this link AND your Netscape or Internet Explorer is VRML-ready, then you will get a quick peek of a large purple cylinder. The reason it's called "Example 3.1" is that this is the number in the VRML 2.0 Handbook, which we used in the VWorlds course.
If your browser cannot handle VRML, it needs the Cosmo Player plugin, which is available from Computer Associates. These folks bought up the remnants of Cosmo Software from Silicon Graphics, and also the remnants of Intervista's WorldView. They don't seem to offer WorldView on their web site, however.
And here's the actual source for Example 3.1:
#VRML V2.0 utf8
# Your basic purple cylinder - Example 3.1, Page 38 of V2H
Shape {
appearance Appearance{
material Material
{
diffuseColor .5 0 .5
shininess .5
}
}
geometry Cylinder {
radius 3
height 6
side TRUE
top FALSE
bottom TRUE
}
}
We'll discuss the following concepts in class.
Scene Graph - a part-whole hierarchical description of a scene, of which a VRML file is an example. We often represent Scene Graphs (an abstract concept) with concrete Scene Diagrams.
The structure of a scene diagram is organized as follows: (this display is from Community Space Conductor)
Each of these types of nodes will contain a bunch of information. We
see in Example 3.1 that the appearance node can specify a material, which
in turn can specify surface properties such as diffuseColor (red green
blue, 0 to 1) and shininess (0 to 1).
The Geometry node can specify a number of basic objects including cylinder, Cone and Box, as well as user-defined shapes. The parameters of a geometric object are rather obvious, but in general, you need the book to explore the legal values for parameters as well as to find about parameters that might not be in the examples you are exploring.
The order of presentation nodes at a given level in the scene graph is up to the display system. CPC, as you see above, puts geometry before appearance, whereas V2H puts the appearance first.
Working with VRML using Community Place Conductor. At this point, please refer to the Brief Tutorial which I have extracted from the one that came with CPC. (It's in PDF format, so you will need Acrobat Reader.) It's 29 pages long. The full-scale 79 page tutorial is built into the CPC download, in case you get enthusiastic. We'll informally introduce some theoretical concepts as we go along through the tutorial, including:
Sensor Node
Routes
Events
Here are some Queries for today, based on Chapter 1 of the Tutorial.
Query 16.1. Try opening the Cylinder example using CPC. You should see the above Scene Graph. Now try adding a TouchSensor to the Cylinder, like we added it in the Tutorial. What happens? Why?
TouchSensors, like almost every other structure in VRML, expect to hang off of a Transform node. The simple Cylinder example did not include a Transform node, and so the TouchSensor had no place to go.
Query 16.2. What would happen if, instead of routing from TS1.isActive, you routed from TS1.isOver? Use the DELETE button to get rid of the previous route, then add the new route.
The behavior is much as one would expect. But now, for some more soul searching, how about:
Query 16.3. Try putting BOTH routes in place at the same time. Without deleting the route from TS1.isOver to PL1.on, add a new route fromTS1.isActive to PL1.on. Is there any behavioral difference? It would seem that "isOver" would always be true whenever the mouse cursor is in any position to trigger the light, and thus it would seem that the isActive command would be useless.
To understand why this is NOT the case, you need to think about how Events work. Events are different from Boolean state variables, because they are always (effectively) instantaneous. The following text describes events.
The modern paradigm is "interrupt-driven". A sophisticated operating system (or even Windows 95) runs on top of hardware capable of generating interrupts within a priority structure. An interrupt is a procedure call that may happen without your program knowing it's happening. Your program's state is saved and the CPU goes off to do whatever it has to, such as updating the on-screen clock once per second. Then your program resumes.
Interrupts were originally thought of as hardware-generated. Thus when a tape drive had moved to the next available data block, it would interrupt the CPU and a service routine would read the data and store it in RAM or on disk. But the usefulness of having software interrupt other software quickly became apparent. Plain old procedure calls require that you know where the called procedure is, whereas interrupts are just like pulling the fire alarm. Let the fire department worry about where it keeps the trucks; just get them to the fire on time!
Event-driven programming was the result of this evolution. WIMP (Windows, Icons, Mice and Pointers) interfaces are inherently event-driven. A mouse-movement or a mouse-click generates a series of events which are handled by the window management system, and directed to the program associated with any particular window. If you click on something within the window belonging to your Web browser, the browser will be notified. If in turn, you click on something within the part of the browser's window which contains VRML, then your VRML plug-in will be notified.
VRML then has to decide what kind of event just happened. Your VRML code will provide a rich collection of sensors which, when clicked on (for instance) generate events. In VRML an event has a very specific meaning: it results in the change of value of a variable associated with a sensor. That new value has to go somewhere, to have an effect.
Fields and Events. We have already seen several fields, which are the parameters describing any node. These included the size and color of the Cylinder, for instance. Fields we've seen so far are static, specified when you write the code. "Events" in VRML look a lot like static fields but they can change values. They change when sensors sense something going on. It could be a collision between a moving and static object, a mouse click, or other conditions that come into being.
We use "routes" to connect sources of events (of type eventOut),
with places that should know about them (of type eventIn.).
The name of an event is a kind of classifier, telling you what to do
with it. For instance, if a check arrives, you know you have to deposit
or cash it. The check's actual value is distinct from its "check-ness."
Consider the following example. If XFORM1 and XFORM2 are two transformations,
the following code will force XFORM2 to have the same translation as XFORM1,
because every time XFORM1 changes, its values will automatically be sent
over to XFORM2.
ROUTE XFORM1.translation_changed TO XFORM2.set_translationIn addition to the "implicit" events defined by exposed fields, there are also events that are explicitly defined. These are indicated by eventIn or eventOut in the node description. Here's an example of how you can make a light come on while you hold down the mouse button.
Group {
children [
DEF LIGHT_CONTROL TouchSensor { }
Inline {
url [ "lightswitch.wrl" ] # Click this to light the light
}
]
}
DEF LIGHT PointLight {
location -6 4 2
on FALSE
}
Inline { url [ "table.wrl"] } # objects to be lit
ROUTE LIGHT_CONTROL.isActive TO LIGHT.set_onNow when the user points to the light switch and presses the left mouse button, the touch sensor named LIGHT_CONTROL generates a Boolean event named isActive, with value TRUE. The ROUTE statement sends this event to the node named LIGHT.
Working with VRML Using a Word Processor. If you don't have a tool like CPC, you can still manipulate VRML as follows. In fact it's good to know how to do this, too, because you shouldn't be totally dependent on a single tool.
The above example source code can be stored in a folder on your computer; use Netscape or Explorer to follow the link, then 'save as' into your folder of choice. Now you can use any convenient editor like Microsoft Word to edit the file. When you SAVE, make sure the extension is .wrl and the file type is plain text. (Word loves to put .txt on, instead.)
Then, use your browser's OPEN command to browse down to that file in that folder (file:/// etc.) and open your VRML file (this whole strategy works for HTML just as it does for VRML.) If your Cosmo plug-in is properly installed, you will now see your VRML model. (If this doesn't work, just open CP Browser to look at the model.)
Now you can minimize the browser, maximize the word processor, and change the file. Then minimize the editor, maximize the browser and click the RELOAD button. You can alternate back and forth between the editor and browser like this and make rapid progress.
When you learn how to work with links to other VRML files, it's best to use relative links rather than absolute ones. For an example of this concept, follow this link:
This file is a copy of the Example 4.2 from the SGI VRML site.
NOTE: This object does not load correctly into CSC. You will have to view it with your Netscape or Internet Explorer browser's VRML plug-in.
More Concepts
Transforming the Cylinder. A 'transformation' is an operation
that moves data through space. A point (x,y,z) can be moved by a distance
of (dx, dy, dz) by simply adding the values pairwise, so we get a new point
(x+dx, y+dy, z+dz). In VRML, that looks like the following:
#VRML V2.0 utf8
# The cylinder somewhere else - Example 3.2, Page 41 of V2H
Transform{
translation -2.4 2 3
children [ # NOTE the square bracket
here!
Shape {
appearance Appearance{
material Material {
<<NOTE: This is as far as we usually go with CAP4020. For those
who are fascinated with 3D graphics, I left the rest of the notes from
CAP4021 in place. JMM>>
Begin with Chapter 2. As it says, 2.1 and 2.2 involve creating a cone and touch-sensor and naming the touch-sensor TS1.. Do it.
Chapter 2. Step 2.3 is a bit tricky. The instructions are to click "View/Appearance" on the menu in the Main window. However if you just do this, you are likely to get a display that says "not available". This is because you haven't selected a scene element that has an Appearance node. Select View/Scene Graph, then click on world/transform/shape/appearance. This is the appearance node of the shape (cone) we're working with.
Even though we're about to work with a Java script node, don't worry - you don't have to learn Java. I will ask the Java Experts in class to identify themselves. If you subsequently get in trouble, ask one of them for advice. That's what I'll do, anyhow.
When you come to step 2.7, the Java Console window must be visible to see the output. Minimize other windows until you see a window titled 'Vscp java console output.' It will display the message "_inBoolCB() called: true" and then false, etc. as you move the mouse over the cone and off again.
Click the square-box STOP button to return to editing the Java code.
After you make the changes to the Java code described in 2.9, don't forget to right-click and COMPILE the Java again. Then proceed to 2.10 and test it.
Now we get to some creative work.
Query 16.4: Add a box to your world. See if you can figure out how to attach a touch-sensor to it, and to route the touch-sensor's "isActive" event to the Navigationinfo.headlight. When you run this world, you will be able to turn the headlight on and off by clicking on the cube.
If you get stuck, instructions are below on how to do this query. But you will learn more by fumbling around and trying to solve it yourself.
Query 16.5: Experiment with the Text node to position the word ON, in red letters, on the front of the cube. Hints for this Query are also found below.
Query 16.6: The annoying thing about this example was that the light only stays on while you hold down the mouse button. Can you figure a way to make our example into a two-button switch, by adding another cube with a green OFF label on it?
And finally:
Query 16.7: If you designed your answer to the previous query in such a way that the light only goes off upon the RELEASE of the mouse-click on the OFF box, how would you improve your script so that it goes off upon the PRESS of the mouse-click on the OFF box?
If you designed your answer so that the light goes off on the PRESS of the OFF-box mouse click, I bet you already have figured out how to make it go off on the RELEASE thereof. If not, figure that out now, too.
Now I need to insert some text here so that you won't just look down
below and read the HINTS without realizing it!
HINT for Query 16.4. Initially the box will be so big that it covers up the cone. You can see its X, Y and Z dimensions by double clicking on the Box node in the scene graph. Modify its size so that it's a cube with side length 0.5 meters.Then modify the transform in which it lives, so that its translation is +4 meters in Y direction. The cube should appear up above the cone. Name the box. Now, by analogy to the cone, construct a touch-sensor on the box. Give the sensor a name, like TS2.
In the scene graph browser, select NavigationInfo and give it a name. Now you can route the TS2.isActive message to the navigation info's headlight. Test the results.
HINT for Query 5.2. Adding a Text object to the scene is done by dragging the big T down into the window. But its transform will wind up attached to the World, and you want it attached to the Box's transform. So drag the text's transform (in the scene graph) onto the Box's transform.
Now you can work with the Text's transform to move it around - IN THE COORDINATE SYSTEM of the box. This means that if its translation is 0,0,0 then it's in the middle of the box. Translate the text by -.1, -.2, 0.4. That should move it out in front of the box. Be able to explain, interms of the cube's size, why these numbers work.
HINT for Query 5.3. I don't know of any way to do this without providing some simple logic via Java. What you obviously (?) need is a way to strip off the TRUE events only (or the FALSE events only) from an event stream. That way you can run the TRUE isActive events from your ON box to the headlight, but filter out the FALSE events which would turn it off.
The operative line is this:
if (ev.getvalue()) m.outTrue.setvalue(true);
You use the Scripts Expert again to create a Java script named TrueOnly. whose output event is named outTrue. Then you put the above line into it, as the body of the inEventsCB method (just like we did with the color selection logic in the textbook example.)
You then route the output of Box 1's sensor to this script node, and the script node's output to the headlight. You can test this first stage, by routing Box 2's script node directly to the headlight.
The OFF box even works - almost. That is, when you click the ON box, the light comes on. When you click the off box and then release, the light goes off. The only problem is that you can still use the OFF box to turn the light on. Why is this?
To remedy this problem you need to define another Script node type, called FalseOnly. Its key line is
(but wait - can you figure it out for yourself?)
if not, here's ONE of several possible lines.
if (!ev.getvalue()) m.outFalse.setvalue(false);
That's enough about VRML to give you the flavor. We'll now shift to the Next Great Thing (or something like it), called
Fahrenheit's Components
The most relevant part of Fahrenheit is Fahrenheit Scene Graph (FSG). This part corresponds rather directly to VRML in its concepts. It rests on a deeper layer called Fahrenheit Low Level API (FLL). This level deals with primitives such as points, lines and triangular polygons. FLL was intended to replace Direct3d Immediate Mode as the low level graphical API for windows, sitting next to OpenGL.
According to the SGI site: "Fahrenheit Scene Graph API (FSG) builds on the services offered by the rendering API (whether OpenGL, D3D IM, or FLL). It offers a tree-like data structure in which a scene can be described in terms of geometry, textures, lighting, etc. Applications that make use of this layer are concerned with describing what to draw rather than how to draw it.
In addition to the geometrical description of the scene it is possible to provide high-level instructions to FSG indicating the intent of the application. For example, it will be possible to indicate to FSG that image quality is of primary concern, strongly influenced by Silicon Graphics scene graph technology as found in Performer(TM), Open Inventor(TM), Cosmo3D(TM), and OpenGL++. "
Query 16.8: I'm planning to write a 3d computer game, and trying to decide whether to use VRML, Fahrenheit or Direct3D. What properties of my game should I list, and how should I use this list to decide which system to use?
Answer: Direct 3D is elaborately supported and the other two aren't. So it doesn't matter what's good or bad. Use what works. Actually, Direct 3D works pretty well.
Back to previous
lecture
Forward
to next lecture
Back to the
Index
Back to the
Syllabus