|
University of California, Berkeley EECS Dept, CS Division |
||
| Jordan Smith |
SLIDE: Scene Language for Interactive Dynamic Environments |
Prof. Carlo H. Séquin |
| Home | Goals | Publications | People | Gallery | Assignments | Distributions |
SLIDE is a 3D scene language and rendering system. The two main purposes for SLIDE are to educate students about 3D Computer Graphics and to provide a solid base for investigating new rendering algorithms and applications. To meet the requirements of education, the core of SLIDE is a very simple set of 3D geometric constructs and a powerful instancing mechanism. This set of geometry functionality is small in scope but is surprisingly powerful and useful for teaching the fundamental algorithms of 3D Computer Graphics.
To make SLIDE a useful tool for investigating research topics in Computer Graphics and building applications the language and rendering system has been made readily extensible. The SLIDE renderer was setup with a C++ class structure such that it is easy to add new primitive objects to the system. Recently, spline surface patch and surface subdivider modules were added to the SLIDE system.
SLIDE was originally designed for the purpose of teaching college undergraduates about 3D modeling and rendering. Towards this purpose, a completely software based SLIDE viewer was written, so that students could learn from it. This software pipeline is very similar in form and function to the standard OpenGL rendering pipeline.
Through the course of a semester, students learn about the inner workings of the rendering pipeline. As reinforcement of ideas presented in lecture, the students do a series of 8 software laboratories where they build a SLIDE software renderer. This style of building up an interesting software system by way of a set of highly structured laboratories is modeled after the NACHOS Operating System by Tom Anderson for teaching about Operating Systems. The SLIDE labs force the students to digest the information presented in class. The labs also provide a unique opportunity for the students to get behind the scenes of different rendering algorithms and really understand their purposes and how they work.
The "hands-on" labs are programming assignments in C++ using the OpenGL and Tcl/Tk standard library packages. The weekly assignments incrementally build up a full 3D rendering system. The first assignments allow the students to get used to the programming environment. This includes understanding how a UI driven application is organized as well as becoming comfortable with the coding style which is constant throughout all of the assignments. As the semester progresses, the topics of the assignments move more to understanding the mathematics and algorithms involved in different phases of the rendering pipeline.
A nice attribute of the students programming environment is that they are implementing an OpenGL-like rendering system with OpenGL as a safety net. This means that in early assignments the labs can use OpenGL as a crutch to do a lot of the work that the students are not yet ready to deal with. Later as the semester progresses, the labs tend to rely less and less on OpenGL. Another nice property of using OpenGL is that students can debug their algorithms visually. For instance, the students have to implement a polygon clipping algorithm. The lab is set up such that the students code is supposed to clip to a viewport which is a subviewport of an OpenGL viewport. If the student's algorithm is incorrect, then it will render spurious pixels outside their viewport. In the SLIDE laboratory environment, the students are able to view this behavior in real time which is helpful diagnosing their algorithmic mistakes. If they did not have OpenGL as a back drop, their program would probably just have crashed. Then they would have to debug either by tediously probing values in a debugger or by printing out text values as the program is running.
The laborartory setup is also good for students who fall behind on one assignment or another. Even though the ultimate goal of the labs is to incrementally build a full 3D renderer, every week the students are given a fresh beginning. The starting point of each lab is basically the solution of the previous week's lab plus extra skeleton code to start them in the right direction for implementing the next phase of the renderer. As stated before, this is very similar to how the NACHOS's laboratory assignments are structured.
We also believe that the SLIDE language itself, not the C++ rendering program, is a good educational tool. By using SLIDE to model scenes, students learn about 3D transformations, scene hierarchies, and procedural modeling. They also learn about advanced rendering techniques by modeling in SLIDE and having the SLIDE renderer output a RIB (the RenderMan file format) description file. This file can then be run through RenderMan or BMRT to make non-interactive high quality frames using ray tracing and radiosity.
The SLIDE language tends to share some of the same characteristics as the old LOGO programming language. It is a programming language for describing 3D geometry and 3D animations. Creating and playing with SLIDE models might be an activity that could get children interested in mathematics, geometry, logic, and even computer programming.
The basic SLIDE language in itself is a powerful modeling tool. It gives a rich set of geometric primitives and a powerful instancing mechanism which is useful in describing 3D geometries. The SLIDE renderer then allows the user to view these geometries in real time. There is a user interface known as the "crystal ball interface" that allows the user to rotate their object so that they can view it from any arbitrary angle.
The SLIDE language allows for interesting interaction between designers and their geometries. The dynamic aspect of the SLIDE language allows designers to set up their geometry description so that they can modify parameters of the geometry and view the result in real time. An example of such a task might be trying to select a scaling value such that a peg tightly fits into a hole. The designer could simple link the scaling value of the peg to a variable and interactively change that variable until the geometry looked right. Because the SLIDE dynamics scripting language is Tcl, it is also possible for designers to call apon the rich set of graphic UI widgets presented by Tk during the initialization phase of their SLIDE description. So a designer could describe a parameterized 3D object as well as a Tcl/Tk GUI to control the parameters of that object, all from within the same SLIDE file.
Another advance in the SLIDE modeling methodology is to allow for the description of objects as small Tcl programs. Using Tcl's ability to link Tcl procedure names to C or C++ procedures created by developers, SLIDE is able to provide a Tcl interface to the SLIDE geometry parser. With this facility, it is possible to make Tcl calls that create geometry during the initialization portion of a SLIDE description file. It is then possible to create a Tcl based procedural modeler within a SLIDE file. The geometry created through this interface acts exactly the same way as geometry flatly listed in a SLIDE file, thus procedural geometry can readily be combined with other scene geometry.
In the future, it would be nice to have an incremental drag and drop interface for creating additional geometry. For now it is more of a programmers interface for generating geometry.
The SLIDE language was designed with dynamics in mind, so it is conceptually possible to describe a full 3D movie within a SLIDE file. This movie could either be based on clock time or based on a frame counter. Time is used if the movie is only meant to be viewed with the SLIDE renderer, and the designer wants the story line to be consistent with elapsed time even if the renderer cannot always keep up the frame rate. A frame counter is useful it the ultimate goals is to make a high quality movie using a RIB renderer. In this case, SLIDE is still useful for interactively building and debugging the scene geometries, and for describing the movie animation. Then the SLIDE renderer can be used to output a sequence of RIB frames which can be run through a higher quality batch style rendering program to create the final movie.
Animations that are targeted for real time or that need real time user interaction are ideal for the SLIDE rendering system. A good example of such an application would be a video game. The dynamic SLIDE geometry can be controlled by arbitrary Tcl code. The logic of a video game could be coded in Tcl, and it could rely on the SLIDE renderer as its 3D rendering engine. In addition, Tcl/Tk's mechanism for binding input devices to Tcl code can be used to create the game's user interface.
SLIDE's rich set of 3D modeling and viewing constructs makes it well suited for virtual reality applications. It is easy to set up of a system of two cameras to create real time stereo images of scenes. Additional features have been added to the SLIDE language to help in outputting the necessary format for VR devices. The stencil statement in the SLIDE render statement allows the designer to use one of three standard stencils when rendering their scene. Some Head Mounted Displays (HMD's) use NTSC interlaced frames for encoding left and right eye images. The left eye's image might consist of only the odd horizontal scan lines while right eye's image is on the even scan lines. The stencil command in SLIDE allows the designer to specify whether the image created by a camera goes to either the odd, even, or both sets of scan lines. Other support for VR input and output devices can be easily added to the SLIDE system.
A major goal of SLIDE is that it will be available on the web for anyone to use. This includes the SLIDE viewer as well as the SLIDE pipeline assignments. Each of the assignments currently contains useful information about the concepts of graphics. To really make this a distance learning tool, more information needs to be added which approaches being an on line text book for introductory computer graphics. Assuming that SLIDE is accepted at a large number of Universities, a SLIDE based bound text book would be another interesting avenue.
Some work has already been done towards compiling and optimizing the scene graph for fast rendering, but there is more to be done. I will be working on algorithms to optimize CSG graphs to resolve and render 3D booleans in real time. I will work on an incremental algorithm for compiling scene graphs. This will make it possible to modify the scene graph while an animation is running. And it will make it possible to have extension packages which add primitives to the language and parser.
Tcl/Tk has a nice mechanism for dynamically loading share object libraries (Unix) or dynamically linked libraries (dll's on NT) while an application is running. This has many useful applications. The two main categories of SLIDE plugin libraries will be dynamics libraries and extension geometric primitives.
The dynamics libraries are a pretty straight forward extension. The idea is to have compiled C or C++ code which provides utilities for doing 3D animation or some external simulation which can be called from Tcl in a SLIDE simulation. Such utilities could be easily programmed in Tcl, but the Tcl language tends to be too slow to do anything computationally intensive.
The geometric primitive extensions will be more of a challenge. To make them fully integrate with SLIDE's core scene graph engine it will be necessary to make the parser be extensible. The idea being that a .slf file could load a new geometric primitive type from a shared library, and then create instances of it in the scene geometry the same way they would a sphere or a polygonal object. This will be very useful for attempting to keep the core SLIDE kernel as small as possible. It will also make SLIDE an ideal platform for investigating new geometries.
Two such animation add on modules will be a 3D inverse kinematics solver and a 3D path generator. The inverse kinematics solver will be useful for animating articulated modules. The 3D path generator will compute the Frenet frame information for a number of different classes of 3D curves. These curves will include a set of predefined closed form space curves like the torus knot or a circle. Splines will also be supported. The Frenet information is valuable for many applications. Cameras could be guided through a scene to give the effect of flying. Objects could follow spline paths to simulate rollercoasters.
This plugin library based architecture will make SLIDE a nice platform for collaborative research. The core of the SLIDE renderer can be frozen or maintained by one or two programmers. But extra functionality can be added to the system by many contributors from all around the world. They can all make there own application specific add on libraries which could then be shared to make more and more interesting functionality.
More work needs to be done to make SLIDE smoothly integrate with C++ shared libraries. Tcl has a nice interface to pure C functions and variables, but the support for C++ objects is non-existent. I need to find or build an interface between Tcl and C++ so that Tcl could make calls to create and manipulate C++ objects in an integrated fashion. In addition, I need to separate the core math functionality of SLIDE out into a library so that later libraries could leverage off of it.
Continuing with the concept of dynamic scene graph topology, a necessary ability will be to view a conceptual graph of the scene while viewing the 3D scene and then make edits through the graph interface or the 3D interface. Currently we can output a scene graph description in the dot language (Bell Labs/Lucent Graphviz Tools). Then the scene graph can be viewed in the dotty program. But there is also a Tcl/Tk library for dotty which could be integrated into the SLIDE system.
[an error occurred while processing this directive]