Printable Version of Topic

What happened was this: They were about to infiltrate a corporate facility, and instead of giving them the usual aerial photographs, floorplans, etc., I took out my laptop, placed it on the table, and opened a browser window showing them a fully 3D model of the complex. I built the model using the VRMLanguage, which most of you should have at least heard about.
Although the introduction of 3D models has helped me a lot to improve the gaming experience, I've found that the standard VRML interface is absolutely not suited for this kind of application. There are three native navigation modes in VRML, namely "WALK", "FLY", and "EXAMINE", and neither one of them can provide the kind of navigation that I have in mind. So now I'm programming a custom interface, called the Site Viewer, which I'd like to tell you about.

What it is
Right now, the Site Viewer allows a user to navigate a VRML scene in either Internet Explorer or Netscape (or any other web browser capable of displaying VRML scenes) by clicking on any building / structure that he wants to examine. Upon clicking on a building, the view will focus on that building, and place the viewer at a predefined distance from the selected geometry. Now, the user can orbit around the building, zoom in, zoom out, and also select another building at any time. The advantage over the standard interface is that when using the Site Viewer, you always retain a preset horizontal viewing angle (usually 30° down) which prevents you from getting lost or finding yourself at an odd viewing angle. (which happens A LOT when using the standard FLY or EXAMINE modes)

What it isn't
The Site Viewer is not a tool to build your own sites from scratch, sorry. But, and this is a big but, once you do have some kind of VRML model, you can use the Site Viewer infrastructure to assemble your models into a scene which can be viewed comfortably. Also, the Site Viewer is not intended as a replacement for floorplans; paper is just so much more flexible than a PC, it would require obscene amounts of programming to achieve that level of flexibility on a computer. Besides, in the end you'd end up with Neverwinter Nights anyway...

What it will be
In its current state, the Site Viewer infrastructure allows exterior viewing of separate buildings, but nothing more. I'm planning to enhance its functionality by adding the ability to select single floor, and then viewing the interior of that single floor. Imagine clicking on a multi-storied building, viewing the exterior, then selecting one floor from a list, phasing out the rest of the building, and then viewing only the selected floor.

Bottom Line
I do realize that 3D modeling isn't exactly everybody's bag, but I'm more than willing to share my ideas on the topic with anybody who's interested. Personally, I've found that the introduction of 3D models has been a huge improvement for my game, especially since you'd expect this kind of thing to be commonplace in the sixth world. I'll probably throw together a Proof Of Concept scene later, and post the code for it here. Relax, VRML code is very small - usually less than 200 lines of code total.

Okay, that's it for now. Expect the POC scene later today.

This will make a lot more sense if you compare it with the script node and ROUTEs contained in Sceneview.wrl.

I think this example illustrates pretty well that even if you're not 100% familiar with VRML, you can work with the basic framework of the Sceneviewer (which is, basically, the SVIII script file and everything in Sceneview.wrl up to the start of the actual scene geometry) and produce some helpful models.

If you want to add a comment to your file, just add a #, followed by your comment. Now, let's add something to the scene. How about a box?

http://www.virtuality.gmxhome.de/VRML_tut01.wrl

Now, save this file as, oh, I don't know, whatever.wrl and open it with your browser.
...
Yuck! This box looks like ass! This is because the Box node specifies only geometry, but not material properties. The node that specifies things like color, transparency, etc. is called:

Material
{
diffuseColor 0.3 0.9 0.1 # This is an RGB value; 0 0 0 is Black, 1 1 1 is White, and so on
emissiveColor 0.1 0.1 0.1 # This is also an RGB value specifying a material's self-illumination
}

The Material node is usually contained by an Appearance node, like so:

Appearance
{
material Material { ... } # material is another field that has a node as its data type: Material
}

Now, all we need is a node that combines geometry and material. This node is called, reasonably enough, Shape:

http://www.virtuality.gmxhome.de/VRML_tut02.wrl

Ok, now we've got a nice, green box. Let's expand our Scene a little by adding one of each of the other standard primitives (cone, sphere, cylinder). For that, we'll need three more shape nodes, and for each we'll specify a new diffuseColor. Like so:

http://www.virtuality.gmxhome.de/VRML_tut03.wrl

Now we've added a cylinder, but wait: I smell BS - The cylinder and the Box occupy the same space! What gives? This is so lame! Ok, so let's fix this by translating the box and the cylinder a little, like so:

http://www.virtuality.gmxhome.de/VRML_tut04.wrl

Allright. Now go and experiment a little. Nodes you should know by now:
- Transform
- Shape
- Appearance
- Material
- Box
- Cylinder
- Cone
- Sphere

In the next tutorial, I'll go into more detail about the Transform node, individual coordinate systems, and object dimensions. Expect the next part to be up sometime early on monday.

If you've got any questions / suggestions / complaints, please don't keep them to yourself! Let me know what you think, and don't be afraid to post your own .wrl's if you've got a specific question.

http://www.virtuality.gmxhome.de/VRML_tut05.wrl

The answer to the above question is actually quite simple. Geometry is placed in a scene so that its center coincides with the origin. Look at the box. Its center is at half width, half height, half depth - basically, right in the middle. So at what height is the box's top? To determine this, simply go up on the Y axis for 1.5 units. (which is the box's specified height, divided by two) Likewise, its bottom is at -1.5 units on the Y axis. You can determine the box's front, back, and side positions the same way: The sides are at +/- 1 on the X axis, while front and back are at +/- 2.5 on the Z axis.

Ok. Now let's place another box on top of this box. The second box shall be 1 unit wide, 0.5 units high, and 1 unit long. We can put this box on top of our first box by applying a translation to it - which means that we'll put our second box inside a Transform node. You should remember Transform nodes from the last tutorial, but just so that we all know what we're talking about, here it is again:

Transform
{
translation 0 0 0
rotation 0 0 0 0
scale 1 1 1
children [ ... ]
}

Look at the node's fields. What a Transform node does, is that it applies a local coordinate system to all it's child nodes. All geometry contained in a Transform node's children field is placed at the local coordinate system's origin - and that local origin is specified by the Transform node's translation field. Let's see how this works in our current example.

The box we wanted to add is supposed to sit on top of our first box. This means that we want our second box's bottom to be at the same height as our first box's top. Our first box's top is at a height of 1.5 units on the Y axis, and our second box's bottom is at -0.25 units. This means we need to move our second box up 1.75 units on the Y axis, like so:

http://www.virtuality.gmxhome.de/VRML_tut06.wrl

Voila, a blue box on top of a green box. Let's get fancy, and place the second box so that its front and right side coincide with the lower box's front and right side. The first box's right side was at 1 units, our second box's right side is currently at 0.5 units, so we need to move it 0.5 units to the right. To make the fronts coincide, we need to move the second box 2 units along the Z axis. The scene now looks like this:

http://www.virtuality.gmxhome.de/VRML_tut07.wrl

The mechanics to determine your geometry's boundaries apply to the other primitves as well: A cylinder with a height of 10 and a radius of 3.5 with its local origin at 3 9 21 would have its top at 3 14 21, its bottom at 3 4 21, and so on.




Part Five: Rotating Geometry

You may have already noticed that the rotation field has a standard value of 0.0 0.0 0.0 0.0, which isn't a 3-d vector since it's got four elements instead of just three. This kind of data is called a rotaional value: Its first three elements specifiy an axis of rotation, and the fourth element specifies an angle, using radians for its unit. (Degree to Radian conversion: (x°/180) * PI, so 90° = 1.5708, and so on) Personally, I've found using more than one value for the axis of rotation to be a pain. That's why I recommend using only a "pure" axis, like 1 0 0 (X axis), or 0 1 0 (Y axis), or 0 0 1 (Z axis). Most of the time you won't need to rotate geometry around more than one axis anyway; but if you do, you may find the technique I'm about to describe helpful. Also, I'll explain some more small details about VRML that will be of help to you.

Allright. I can smell that y'all are getting tired of boxes, so we'll be using some other kind of geometry now. Our next project is to create a model that displays the three axes of the standard coordinate system. To do this, we'll create three arrows out of standard primitves, and then rotate them to align with the corresponding axis. Let's get started.

The first step is to create an arrow. We'll take a Cylinder, and add a Cone at it's top using a Transform node. Since the Cylinder and the Cone of each arrow should look alike, it would make sense to define an Appearance node that can then be shared by the two Shape nodes. VRML allows this through the DEF statement. You can use a DEF(ine) anywhere where you'd normally put a node. The syntax for a DEF statement goes like this:

DEF [valid name] [node] { ... }

Anytime you want to use the predefined node, you simply use a USE statement wherever you'd normally put your node. Valid names begin with a letter, use only letters, digits, _'s and -'s, and don't use any already existing names, like Box. Remember: VRML IS CASE SENSITIVE!

http://www.virtuality.gmxhome.de/VRML_tut08.wrl

Ok, now we've got our first arrow. It's pointing up, which is fine, but the arrow's bottom is 2 units below the origin. We want the arrow to start from the origin, so we need to modifiy our scene like this:

http://www.virtuality.gmxhome.de/VRML_tut09.wrl

I feel like I should explain a few things here. The first Transform node speficies a local coordinate system for both the Shape node and the second Transform node. The second (nested) Transform node in turn specifies its local coordinate system in relation to the coordinate system that this node itself is placed in. I could have just as well used one Transform for the Arrow_Line, moving it up 2 units, and one separate Transform for the Arrow_Head, moving it up 4.5 units. But this method is more elegant, since it groups elements that belong together.
Now, we'll add a second arrow, using the geometry nodes we DEF'ed earlier, but with another appearance.

http://www.virtuality.gmxhome.de/VRML_tut10.wrl

This time, I added a rotation to the second root Transform node. This rotation specifies (a) a rotation along the Z-axis, and (b) a counter-clockwise rotation of 90°, or 1.5708 radians. If you want to find out along which axis you want to rotate your geometry, the left-hand rule I introduced last time comes in extremely handy. Also, positive rotational values specifiy clockwise rotations along the specified axis, while negative values mean counter-clockwise rotation.
Ok, now it's time to add the last of our three arrows, like so:

http://www.virtuality.gmxhome.de/VRML_tut11.wrl

Looks nice, doesn't it? Let me go back a little and talk about rotations along more than one axis. I said above that it's a pain, and it totally is, if you try to rotate along multiple axes at once. But, just like we nested translations, we can also nest rotations. For example, in the last example we could have made life a little harder by using two instead of one rotations for the last arrow, like so:

This is the same Transform as for the second arrow, but rotated 90° ccw along the Y axis.
Now, let's take a look at scaling geometry.




Part Six: Scaling Geometry

So far, we've translated and rotated geometry like mad, and had lots of fun doing it. Right? Next we'll take a look at the Transform node's scale field. The standard value for scale is 1 1 1 - which means that every axis of the local coordinate system specified by the Transform node is multiplied with 1. Just for giggles, let's take the last example, but specify scales for the X and Z axis arrows.

http://www.virtuality.gmxhome.de/VRML_tut12.wrl

You'll notice that the ends of the scaled arrows no longer coincide with the standard coordinate system. That's because scale changes are applied at the center of the local coordinate system. So, if we wanted to fix our arrows so that the ends again meet at the origin, we would have to proceed like this: First, we need to determine the new length of our arrows, and then we need to adjust the root transforms accordingly. Our scaled X-Axis arrow is now 8 units high instead of 4 (since the scale change is applied at the LOCAL Y axis, it affects the height value, but not the radius), so we need to translate it right 4 units instead of two. That way, the bottom of this arrow again lies at the origin of the standard coordinate system. Likewise, since the Z-Axis arrow now is only 2 units long, we need to adjust the translation to 1 instead of two units, like so:

http://www.virtuality.gmxhome.de/VRML_tut14.wrl

That fixed it. To tell the truth, most of the time you won't be needing to change the scale of stuff, except when you want special kinds of geometry. The real strength of the scale field is that you can specify non-uniform scale changes, which let you easily create flat arrows (try shrinking the Y-Axis arrow from the above example along its local Z-Axis, for example), or elipsoids (by scaling a sphere to shrink along one axis while stretching it along another).

This wraps up this tutorial. You should now know a little about the following things:
- Translating, rotating, and scaling geometry
- How coordinate systems are applied
- How to find a shape's boundaries
- How DEF / USE statements work




Outlook

In the next installment, I'll introduce you to the Inline node, run a few examples of how you can combine standard primitves to create simple objects like trees, buildings, bridges, cars, etc., and finally explain in detail how you can inline your stuff into the Site Viewer.
I can't give you any exact date when the next part'll be up, but you can expect it before Friday.