Technical Report TUBS-CG-2004-08

Generative 3D Models: A Key to More Informationwithin Less Bandwidth at Higher Quality

Rene Berndt, Dieter W. Fellner, and Sven Havemann{r.berndt, d.fellner, s.havemann, }@tu-bs.de

Institute of Computer GraphicsUniversity of Technology

Mühlenpfordtstr. 23, D-38106 Braunschweighttp://graphics.tu-bs.de

c© Computer Graphics, TU Braunschweig, 2004

Generative 3D Models:A Key to More Information within Less Bandwidth at Higher Quality

Rene Berndt∗ Dieter W. Fellner† Sven Havemann‡

Computer Graphics, TU Braunschweig, Germany

Abstract

This paper proposes a novel, yet extremely compact model repre-sentation method. Its main feature is that 3D shapes are representedin terms of functions instead of geometric primitives. Given a set of– typically only a few – specific parameters, the evaluation of sucha function results in a model that is one instance of a general shape.Particularly important for the web context with client systems ofwidely varying rendering performance is the support of a semanticlevel-of-detail superior to any low-level polygon reduction scheme.

The shape description language has the power of a full program-ming language, but it has an extremely simple syntax. It can be re-garded as some form of a ’mesh creation/manipulation language’.It is designed to facilitate the composition of more complex model-ing operations out of simpler ones. Thus, it allows to create high-level operators which evaluate to arbitrarily complex, parameter-ized shapes. The underlying shape representation is a boundaryrepresentation mesh in combination with Catmull/Clark subdivi-sion surfaces.

CR Categories: I.3.2 [Computer Graphics]: Graphics Systems—Distributed/network graphics; I.3.5 [Computer Graphics]: Com-putational Geometry and Object Modeling—Curve, surface, solid,and object representations; I.3.6 [Computer Graphics]: Methodol-ogy and Techniques—Graphics data structures and data types;

Keywords: generative modeling, subdivision surfaces, boundaryrepresentation meshes, interactive modeling

1 Introduction

According to a study by Lyman et al [Lyman et al. 2000] the worldproduces between 1 and 2 exabytes (i.e., 1018 bytes or a billion gi-gabytes) of unique information per year. From that vast amount ofdata printed documents of all kinds only comprise 0.003%. Themajor share being taken by images, animations, sound, 3D modelsand other numeric data. Of course, a large and increasing propor-tion of the produced material is created, stored and exchanged indigital form – currently ranging at about 90% of the total. Yet, littleof this information is accessible through internet enabled archivesor Digital Library collections.

Slowly but steadily, information systems do experience changein the interpretation of the term ’document’: Rather than seeinga document in a classical context of being a ’paper’ predominantlycompiled of text with a few figures interspersed a more general viewtakes place which considers a ’document’ as an entity consisting ofany media type appropriate to store or exchange information in agiven context. Only this shift in the document paradigm will opennew application fields in areas from simple information archives toDigital Libraries (DL) for the mutual benefit of DL’s and applica-tion domains: DL’s offering an unprecedented level of functionality

∗e-mail:r.berndt@tu-bs.de†e-mail:d.fellner@tu-bs.de‡e-mail:s.havemann@tu-bs.de

and (new) application domains (e.g., digital mock-up in engineer-ing) benefiting from a more powerful DL technology.

Just focusing on the aspect of 3D documents it becomes clearthat a purely triangle/polygon-based representation scheme willneither be suffiently powerful (in terms of expressiveness and ac-curacy) to support the envisioned development nor will it scale tothe demand in model complexity.

Just looking at the aspect of 3D documents we believe that oneof the main reasons for a limited growth of 3D archives is due tothe inadequate representation schemes available today: almost allof the more complex 3D information is based on polygon/trianglemeshes. Of course, triangles do exhibit nice and easy to handle fea-tures and they are well supported by graphics hardware. However,triangle/polygon-based representation schemes are not suffientlypowerful in terms of expressiveness and accuracy: a triangle meshis only a discrete approximation of the true surface and, for curvedsurfaces, it needs an infinite amount of infinitely small triangles toaccurately describe a model. Just assume that the used representa-tion scheme does not know about spheres. Storing/transmitting asphere from the sender to the receiver will indeed need an infiniteamount of triangles as the desired accuracy at the receiver’s side isgenerally unknown be the creator of the object. But the problem oflimited expressiveness is not the only one. We have identified thefollowing problem areas that negatively affect the cost-efficiency ofWeb3D. If these issues are not addressed, Web3D will continue tofight an uphill battle.

1.1 Model File Sizes

Obviously the size of a model depends on the representationmethod, such as pointclouds, triangles, NURBS patches, implicitfunctions, and many more. With triangles as the lowest commondenominator to represent surfaces, mesh compression, model sim-plification, and sophisticated multi-resolution shape representationshave become the methods of choice to deal with complexity. Pro-gressive Meshes (PMs) are a great tool do deliver a continuous levelof detail for interactive applications.

The problem remaining is that the complexity of a compressed orprogressive mesh, although (sometimes drastically) smaller in ab-solute size than the original, is still in the order of the input mesh.The highest possible display resolution on the other hand is limitedby the input resolution. Secondly, through the post-processing, thedirect relationship between the mesh and the modeling history isno longer available. The third problem is that simplification breakssymmetry: automatic mesh simplification is based on an error met-ric which is insensitive to the intended structure of a model, so thateven completely regular shapes become distorted in irregular waysinstead of “simply” removing high-frequency detail.

While automatic multi-resolution techniques are great forscanned datasets, it should be possible to do better with syntheti-cally created objects. Instead of removing the nice rounding of anobject’s edge by mesh simplification to decrease the LOD to main-tain interactivity, the runtime engine could simply undo the round-ing operation, or even better, only perform it on demand (i.e., onlywhen detail is important).

1.2 Digital Libraries of 3D Objects

The aforementioned problems become even more drastic if a greatnumber of objects needs to be maintained and updated in a con-sistent way, e.g., with model repositories or component databases.With complex industrial assemblies and cooperative design, geo-metric verification and version management become indispensable.Ideally, a model repository is amenable to typical database oper-ations, such as indexing, searching and markup, i.e., attachmentof meta-data. In this case, the term digital library is appropriate,where a 3D object is understood as a generalized document.

For obvious reasons, the efficiency of such a digital library de-pends heavily on the model representation format. When nothingis known about the object structure, eg. with raw triangle meshes,searching leads directly to the shape matching problem, which isnotoriously hard to solve. Collections of many slightly differentobjects are a nightmare for large-scale databases (large car manu-facturers, for example, have to deal with approx. 5000 variationsof windshield wipers), especially when objects are created in aforward-modeling way: Structural similarities of just slight vari-ations cannot be exploited to facilitate database management.

1.3 Interactivity

The distinction between sophisticated modeling software on onehand and the viewer, or runtime engine, on the other hand has theconsequence that in most virtual worlds and 3D applications theenvironment is mostly static. Things that move or deform have tobe explicitly designed to do so, which considerably diminishes theperceived level of interactivity. This limitation is of course alsocaused by the different passes of post-processing, just to mentionglobal illumination, that are necessary to create a convincing, highfidelity virtual environment.

On the other hand, it should be possible to go beyond an under-standing of virtual reality as being able to change transformationmatrices in a hierarchical scene graph, or to switch between differ-ent snapshots of a model for animating 3D objects. To do so againrequires modeling capabilities in the runtime engine, i.e., the possi-bility to modify a mesh both geometrically and topologically. Ar-bitrary modifications are not even possible with high-end computergames, which are today probably the leading technology for deliv-ering online ’content’ over the internet. In most shooting games,not even with the biggest guns is it possible to shoot a hole into awall, or to disassemble and re-assemble objects. But true modelingcapabilities are available only to the game designers.

2 Overview

In summary, we have identified the following problem areas:

• limited changeability and re-usability of 3D objects,• heavily increasing model complexity and file sizes,• the maintenance and usability of potentially huge libraries of

3D objects, and• to provide truly interactive 3D environments with an interface

to third-party software.

We think that one way to cope with some of these problems isto emphasize the importance of structual information of 3D objectsover low-level primitives. This follows the information reductionparadigm: Our aim is to store only the essential information that isneeded to represent a shape, and from which the full model can begenerated on demand, eg. in the runtime engine.

We introduce the Generative Modeling Language (GML) andpropose it as a smallest common denominator for procedural shapedescriptions. While in principle still being able to represent rawtriangle meshes, i.e., only the result of the modeling process, the

GML adds, and actually encourages, the possibility to create para-meterized objects. It can represent advanced concepts like a mod-eling history, separation of data and operations, a semantic level-of-detail, event-driven animations, or data-flow networks. It is aninterpreted language, and is, with its runtime engine, also genuinelytargeted at interactive applications. The software is implemented asa C++ library, with a runtime engine based on OpenGL. As it issupposed to be used for instance as a 3D plugin to third-party soft-ware, the API is designed to be easily usable and extensible. Wehave created an internet browser plugin, which we call ActiveGML,to demonstrate the advantages of this technology.

We are aware of the fact that language-based modeling is nota new subject. Especially in the parametric modeling communitythere’s a diversity of approaches, as, e.g., nicely summarized by[Hoffmann and Arinyo 2002]. Our approach differs from these inthat we, to a large extent, target at the interactive aspect of 3D mod-eling. Other approaches include HyperFun, a language to describeimplicit objects, which was used, e.g., for cultural reconstruction[Vilbrandt et al. 2004], and PLaSM, which is a language for gener-ating parameterized VRML models [Paoluzzi et al. 1995]. Our ap-proach slightly differs from these in terms of the model representa-tion (meshes+subdivision surfaces), the language paradigm (stack-based), and the web integration.

The original motivation for our work, the creation of shapesthrough generating functions, goes back to the book on GenerativeModeling from Snyder (thus the title of the article). The differencehere is that Snyder originally considered no meshes, but continuousfunctions. The central role of sweeping in his approach is paral-lelized by the various forms of extrude operations used with theGML.

From a technical point of view, our approach is basically a com-bination of several well-established techniques:

• Catmull/Clark subdivision surfaces,• BRep meshes,• Euler operations, and• a stack-based programming language.

They are arranged in an architecture made of three software lay-ers (see below) that are presented in a bottom-up fashion in thefollowing three sections.

ApplicationGenerative Modeling Language GML

Euler Operators + Euler MacrosCombined BRep Meshes

Subdivision SurfacesGraphics Hardware

3 Combined BRep Meshes

The backbone of the proposed architecture, and the actual shaperepresentation, is the Combined BRep mesh, short CBRep. TheCombined BRep is a multiresolution data structure. It operates onany given input mesh by recursively subdividing its faces using theCatmull/Clark scheme, thereby generating new vertices, edges andfaces. The subdivision process quickly converges to a smooth limitsurface which is C2 continuous almost everywhere.

While BReps usually represent polygonal objects, CombinedBReps can represent both polygonal and curved shapes: Any partof the mesh can be used as the control mesh of a Catmull/Clarksubdivision surface [Catmull and Clark 1978]. Thus a CBRep pro-vides a uniform representation for a surface with both polygonaland free-form parts. The overhead in the mesh is only small: Onesharpness bit per (half-)edge. Any edge can be toggled between

sharp and smooth – with the exception of faces with rings, whichmay only have sharp edges.

For interactive display, each curved face is adaptively tes-selated, and OpenGL display primitives are generated on de-mand. In contrast to the technique proposed by Boltz andSchroeder [Bolz and Schröder 2002], CBReps realize a cachingstrategy where, once computed, the face resolution can be adap-tively adjusted on a per-frame basis without any further compu-tations. But on-line modifications to the control mesh are stillpossible, as CBReps provide a method for selective (local) up-dates of the tesselation. For full details the reader is referred to[Havemann and Fellner 2003].

Figure 1: Street lamp model rendered as polygonal model (left) andas (Catmul-Clark) subdivision surface (right) (courtesy ViewpointData Labs)

For modeling, BReps have advantages over using just triangles.BRep faces provide a higher degree of abstraction as they can haveany number of vertices, and they do not have to be convex. More-over, while the border of a face, the baseface, is a simple CCWpolygon, Combined BRep faces can also have any number of rings,which are simple CW polygons contained within the border poly-gon. Consequently, a face can be a complex-shaped object.

Figure 1 shows a street lamp rendered as a subdivision surfaceand for comparison as a polygonal model. It can be seen how faith-ful the freeform representation captures the intended shape, actuallysynthesizing model detail beyond the resolution of the polygonalmodel.

Figure 2: Compbined usage of polygonal and of freeform geome-try. Profiles are swept along a complicated curve, not just along astraight line. Furthermore, mirror symmetry is involved.

The combination of polygonal and freeform geometry within thesame mesh representation is illustrated with the model of an orna-ment in Figure 2. There, profiles are swept along a smooth curve,not just along a straight line. Despite its consistent framework, themesh structure makes a clear distinction between ’normal’ edgesresulting from tesselation steps (e.g., on free-form surfaces) and’feature’ edges which essentially control the object’s shape.

By generating the tesselation of the subdivision surface on de-mand at runtime, we follow the information reduction paradigm: A

single quadrangle face of the CBRep may unfold to 16x16 = 256OpenGL quads, a reduction by more than two orders of magnitude.This makes the control mesh much more manageable than the tes-selation, or an equivalent triangle mesh.

3.1 Data Structures

Combined BReps are based on a conventional half-edge data struc-ture, with the following topological incidences:

A half-edge holds pointers to its face, to the vertex it emanatesfrom, and to the counterclockwise next half-edge in its face. Thereis one array containing all the half-edges and they are allocated inpairs, so that a half-edge with an even array index finds its otherhalf, its mate, at the next array position, and vice versa. The sizeof a half-edge is therefore three pointers. A pair of half-edges isreferred to as one edge of the mesh. A vertex contains one pointerto an outgoing half-edge. A face also contains a pointer to one in-cident half-edge, and two additional face pointers, namely nextringand baseface. A face is either a baseface (counterclockwise order)or a ring (clockwise order). For a face with no rings, nextring isNULL and baseface points to the face itself. Faces can have anynumber of vertices and rings. A mesh consists of three dynamic ar-rays for vertices, edges, and faces. For topological consistency, wedemand that the mesh must be a valid manifold mesh, i.e. a closed,orientable surface. This guarantees that all pointers of the incidencerelation are valid. The limitation to manifold meshes considerablysimplifies some consistency issues mentioned below in Section 4.

Besides the connectivity of a particular mesh, the vertex posi-tions and the sharpness flags of the edges are input data for the sub-sequent tesselation. All the other data members of vertices, edgesand faces are thus computed by the tesselation pass.

This pass proceeds by first classifying vertices, then faces, andthen computes the tesselation for each face that needs an update,according to its type.

Vertices are classified by the number of incident sharp edges. Avertex with less than two incident sharp edges is a smooth vertex,with exactly two sharp edges it becomes a crease vertex, and withmore than two it becomes a corner vertex. The face classificationis based on both, vertex types and sharpnes of edges. We have ba-sically adopted these classification rules from [Hoppe et al. 1994].He did not treat the special case of sharp faces as we do.

3.2 Polygonal Faces

If a mesh has only sharp edges, it is processed as a regular polygo-nal mesh: In order to display it, a standard triangulation algorithmwhich can process simple polygons with holes is used to compute atriangulation of each baseface. Triangulation algorithms are typ-ically very fast, and they are O(n logn), so that it is possible tocompute triangulations on the fly. The index arrays are held in amemory pool (dynamic array with fast allocation/deallocation), sothat triangulations can be updated easily if the mesh is changed.

A polygonal face is a face which contains only sharp edges andall vertices are corner vertices. It may have holes.

3.3 Smooth Faces

If edges are not sharp, they are called smooth. A mesh with onlysmooth edges is regarded as the control mesh of a Catmull/Clarksubdivision surface. In this case, it is processed differently:

For every half-edge, a CCPatch structure is allocated, that con-tains basically a grid of 9× 9 vertices together with normals. Foreach vertex and each face, a CCRing data structure is allocated,which contains the position of a Catmull/Clark vertex point for allfour levels of subdivision, and the limit position, by applying the

appropriate vertex stencils. For faces, it also contains the face mid-point, which becomes a vertex point in the Catmull/Clark schemeafter the first subdivision.

Every face with at least one smooth edge is treated as a smoothface, i.e., subdivided. The Catmull/Clark scheme has no rules forrings, so if a face with rings contains smooth edges, these edges areforced to be sharp.

3.3.1 Creases

According to this definition, a smooth face can also have sharpedges. Now suppose there is a path of sharp edges in an otherwisesmooth mesh. Such a path is called a crease in the surface, and allvertices along the path are crease vertices. For Catmull/Clark sub-division, the canonical way to deal with a crease is to regard it asa uniform cubic B-Spline curve. The subdivision stencils on bothsides of the crease are decoupled: For computing the tesselation ofa patch next to a crease, the vertices on the other side of the creasedo not matter. An example of a sharp face is shown in Fig. 3.

3.3.2 Tesselation on the fly

In order to display the object interactively, the first subdivision levelis computed: The face, edge, and vertex points are stored in theCCRing and CCPatch structures of the appropriate entities. Withthe Catmull/Clark scheme, the mesh consists merely of quadran-gles after the first subdivision, regardless of the original topology.At this point in the tesselation process, the CCPatch data structuretakes over, where each patch corresponds to one quadrangle of thefirst subdivision. Each patch can be subdivided a maximum of 3times, which makes for a maximum of 4 subdivision steps of theoriginal control mesh (including the first subdivision). This meansthat in order to interactively display a smooth quadrangle of thecontrol mesh, it is represented by up to 16× 16 = 256 quads athighest resolution.

View-dependent on-line tesselation and interactive display isthen performed using a scheme that is very similar to the one de-scribed in [Havemann 2002].

For patches along a crease edge the neighbour resolution, theccSteps, is increased by one. This improves the visual quality ofcreases, as can be clearly seen in Figure 14.

4 On-line Mesh Modeling

The purpose of Euler operators is to give a well-defined accessto the mesh, to modify both its connectivity and geometry. Withour implementation, which basically follows the proposal from[Mäntylä 1988], there are five Euler operators which affect the con-nectivity of the mesh, together with their five inverse operators.Each operator basically creates (or deletes) an edge together witha vertex, face, or ring.

Although well-established, the Euler operations are informallyintroduced in the appendix for reasons of self-containedness.

4.1 Euler Operators and Progressive Meshes

There is an interesting relation between Euler operators and pro-gressive triangle meshes. The split sequence of a progressive meshcan be regarded as a procedural description for building up a shape:The original, highly refined mesh can be reconstructed from the ex-tremely simplified base mesh by issuing vertex split operations, i.e.,by undoing the edge collapses from the simplification. This marksin fact a paradigm shift: From a static shape representation, suchas an indexed face set, to understanding a shape as the result of ansequence of (invertible) operations.

The original paper used only edge collapses for coarsening,which cannot change the genus of an object or glue objects together,and more general operator sets have been proposed since by differ-ent authors [Garland and Heckbert 1997; Borodin et al. 2002].

For manifold meshes, all such operators can be expressed alsoin terms of Euler operators: An edge collapse for instance is basi-cally a killEV and two killEF, as it removes three edges, two verticesand a face. Consequently, a split sequence could equivalently beexpressed as a sequence of Euler operators, exploiting their invert-ibility for coarsening and refinement.

4.2 Euler Macros

In database terms, each Euler operation is an atomic operation, andan arbitrary sequence of them can be grouped together to form atransaction, which we call Euler Macro. The granularity of themacros with respect to the length of the operator sequence is notprescribed: It is up to the user – where the word user is used syn-onymously for any kind of external application, and simply means:not determined by the calculus.

The rationale for introducing Euler Macros is the SemanticLevel-of-Detail (LOD). This was based on the observation that ex-perienced modelers often work in a coarse-to-fine fashion: Theystart with some basic shapes or primitives and successively add de-tail, a modeling style that nicely lines up with the macro concept.The drawback when a new macro is started every now and thenin the modeling process, i.e., with a low macro granularity, is thatundo/redo gives popping artifacts. But the great advantage on thepro side is that the user can steer the refinement process, and actu-ally author a multi-resolution mesh. It is possible to group model-ing operations together which belong to the same level of structuralrefinement. Thus, user-defined macros can be based on the modelsemantics instead of on the output of a simplification cost measurecontroling the coarsening of the model.

4.3 The Macro Graph

There is a canonical dependency relation between macros: TheEuler operations are formulated in terms of halfedges, and opera-tions later in the sequence have input values produced by operationsearlier in the sequence: A macro mA is a parent of mB iff an opera-tor from mB has an input value that is produced by mA. In this casemB is called a child of mA.

The parent-child relationship in the macro graph can be regarded– and used – as the continuation of a scene graph below object level:the object graph or model graph. Macros also keep track of theirlocation in space: At present, we maintain a simple axis-alignedbox (AABox)for each macro. It contains the 3D points occurringin the operator sequence and the union of the parent boxes. Thepurpose of the AABox hierarchy is to use them for culling and forspatial queries (see Fig. 3).

5 The Generative Modeling Language

The Generative Modeling Language (GML) is based on the core ofAdobe’s Postscript language. It does not have Postscript’s extensiveset of operations for typesetting, though. The GML is targeted in-stead at 3D modeling, and exposes the functionality from Section 3and Section 4 to a stack-based interpreter. It has many operationsfrom vector algebra and to handle polygons, and others that convertback and forth between polygons and meshes.

While it is standard that 3D modeling packages have a built-inscripting engine, the Postscript language has a number of uniquefeatures. It seems that many operations that are frequently usedwith 3D modeling can be conveniently described with a stack-based

Figure 3: The front face is a sharp face. All Euler Boxes active(left); Active boxes as a result of a spatial query (right). The spatialquery is the small blue point; all other macros are deactivated.

language, and a number of concepts from modeling nicely map toGML constructs.

5.1 Just yet another 3D model format?

The outstanding feature of the GML approach is the simplicty ofcode generation. This is supported by the great number of, e.g.,Postscript printer drivers available. We are typically not aware thatprinting a document on a Postscript printer makes the printer in factto execute a program that, as a side effect, creates the bitmap thateventually appears on a sheet of paper. In terms of quantity of au-tomatically generated code, Postscript as a programming languageis probably unparalleled.

And just like PostScript, the GML is designed as an ’invisiblelanguage’: The code can be generated in background, and GMLprograms may be interpreted even during user interaction to createcomplex three-dimensional shapes. But looking behind the curtain,how concisely can a complex shape be described with it?

The key to the generality of the approach is the operator con-cept. A vast but extensible set of built-in operators for vector al-gebra, polygons, conversion to meshes, and mesh modelling op-erations exists. But no finite set of modeling operations will eversatisfy all modeling requirements. With the GML, new operationscan be formed by combining the elementary operators – possiblydirectly from the operations interactively applied to a 3D model bythe designer. This reflects a paradigm shift from objects to opera-tions: Instead of designing only one instance of a particular shape,a whole object class is identified with a set of parameterized con-struction steps. And due to the functional language, anything canbe a parameter. A construction can even be parameterized in termsof the sub-constructions (or combined operations) to be used. Thenet gain for the user are two key advantages:

• Changeability – by isolating the key parameters of a complexconstruction, design variants can easily be tested

• Re-Usability – once a modeling problem is solved, the solu-tion can be re-used

5.2 Postscript

The core of Postscript is concisely specified in the Postscript Lan-guage Reference [Adobe Systems Inc. 1990]. We informally de-scribe how Postscript works and, for a more concrete understand-ing, also some implementation details.

Postscript is a stack-based language without the need for a syn-tax parser. The runtime system consists of only a lexical scannerand an interpreter. The job of the scanner is to convert a characterstring into an array of tokens. An executable array is then processedby the interpreter, which simply executes it token by token. A Post-script interpreter that contains only the language core (without op-erations for typesetting) can be implemented with a few dozens oflines of C++ code.

The basic data structure is the token. Tokens are atomic valuessuch as integers, floats, 2D and 3D points, and markers: [, ], {, and}. Only two compound data structures are availabe, arrays and dic-tionaries. A token can also be an operator, and refer to a globalarray where the available operations are stored. Operators are im-plemented as classes derived from an abstract class Operator, andso must overload a virtual function

bool Operator::execute(Interpreter& interpreter);A token can be either literal or executable, which is important for

the interpreter to process an array and a name. Executing a GMLprogram from C++ is as simple as

interpreter.execute(token);When the interpreter encounters an executable array, it is exe-

cuted by stepping through it and executing each token. Executinga literal token simply means to push it on the stack, which is whathappens with numbers, vectors etc, and also with literal tokens thatrefer to an array or dictionary, and with literal names. But whenan executable name is encountered, it is looked up in a dictionary,and the value, a literal or executable token, is executed: If an ex-ecutable array is found, it is pushed on the execution stack and isexecuted. When this is finished, it is popped and the execution con-tinues with the array from before. If an operator is encounteredor found through name lookup, its execute method is called. Thecurrent dictionary is the topmost element of the dictionary stack.Name lookup is done by going through this stack top to bottom,and the first dictionary where the key is defined delivers the value.The dictionary stack is independent from the execution stack andcan be changed at any time, a very flexible method for scoping aswell as for function overloading.

If the interpreter encounters an opening marker, it is put on thestack. When it finds a closing marker, it searches the matchingopening marker on the stack, creates an array from the tokens inbetween, and puts the array on the stack (i.e., a token referring toit). A curved bracket puts the interpreter in deferred mode: Nowall tokens being executed are considered literal and are put on thestack, until the matching closed curved bracket is found. This ishow an executable array is created. It is possible to convert betweenliteral arrays and executable functions by just changing the array’s’executable’ flag.

5.3 Operator Libraries

All functionality of the GML comes from the operators. The oper-ators are organized in several libraries, implemented as a thin layeron top of underlying C++ libraries. The library methods are ac-cessed from each operator’s execute method.

An operator is characterized by its signature, i.e., by its name, theinput parameters it takes from the stack, and the output parametersit pushes on the stack after processing. Abbreviations such as Efor edge, P3 for 3D point, {f} for functions etc. are used. The addoperator for instance can equally add ints, floats, and 2D and 3Dvectors, and is an example for function overloading. An operatorcan equally check types and values of stack items to decide whether

an operation is legal or not. The following operator libraries arecurrently available:

The Core library contains the basic Postscript operators: stackmanipulation, dictionaries and arrays, and flow control, i.e., if, for,repeat etc. The forall operator, for instance, iterates through an ar-ray, puts each element on the stack, and executes a given function.In a similar way the map operator iterates through the array but ap-plies a function which leaves a value on the stack, from which theoperator assembles a new array at the end of the iteration.

The Geometry library contains the usual operations from vec-tor algebra as well as for computing distances and projections, forpoints, lines, segments, and planes. The operator project_ptplane:p:P3 nrml:P3 dist:F → q:P3, for instance, projects point p ontoplane (nrml,dist).

The CBRep library provides Euler operators and functionalityfor handling macros, as well as for navigating in the mesh and inthe macro graph. It also adds a new literal token, the edge typerepresenting a halfedge, whose string representation is “Er,m,k” ,where r,m,k are integers (see Sec. 4.3).

The Modeling library contains higher-level modeling operatios,most notably several forms of extrude, polygon/face conversions,and for gluing faces together in various ways. Additionally, opera-tors for ray/mesh, ray/face, face/plane intersections and for follow-ing a ray over the mesh are available.

The Interaction library contains operators for handling inputevents and for displaying other data types, such as 3D text and pro-gressive triangle meshes.

5.4 Simple GML Example

Figure 5: Variations of the Simple house model, each created witha single line of GML code. The parameters are varied from (10,7,0)3 12.0 simple-house to (2,2,0) 1 2.0 simple-house .

We will shortly develop a GML example that shows the cre-ation of a very simple, parameterized house model, shown in Fig.5.The result of the following three lines of GML code are an axis-aligned box with minimum and maximum corners (−10,−7,0) and(10,7,4):

(10,7,0) 0 quad5 poly2doubleface(0,4,3) extrude

The quad operator in the first line yields an array with four 3Dpoints [ (-10,-7,0) (10,-7,0) (10,7,0) (-10,7,0) ], which is put on thestack. Line 2 converts it to a mesh face, as poly2doubleface pops thearray and pushes one mesh halfedge. This halfedge is consumed bythe extrude operator, which after an extrusion by 4 units pushes thehalfedge of the extruded face.

Operators can work in different modes, as specified by supple-mental parameters. With (10,7,0) 1 quad for instance the quad op-erator creates a different polygon, namely with minimum and max-imum corners (0,0,0) and (10,7,4). Similarly, the 5 and (0,4,3)parameters specify how the poly2doubleface and extrude operatorsare to process the data on the stack.

This example demonstrates the technique of operator chaining.Chaining means that in a sequence of operators the result of oneoperation serves as input to the next operation. It is quite efficientwhen functions have compatible signatures, so that more specificcombined operations can be created by concatenating generic op-erations with specific parameters. A slight variation of the aboveexample shows the power of the generative approach:

(10,7,0) 0 quad5 poly2doubleface4 { (0,4,3) extrude } repeat

The extrusion is repeated four times, to create a crude approxima-tion of a four-story building: The code size is decoupled from thesize of the mesh it creates. The next step is to provide the buildingwith a simple roof. This is done using a function collapse-mid thatexpects a halfedge on the stack:

{ usereg !e:e vertexpos:e mate vertexposmidpoint_2pt !p:e edgeflip :p moveV:e killEV

} /collapse-mid exch def

Postscript offers basically two alternatives to store a value for lateruse: on the stack, which can be tedious, or in a dictionary, whichcan be slow. We have introduced named registers as a third alter-native. The usereg operator opens a register frame where !myvari-able pops and stores, and :myvariable retrieves and pushes a registervalue. The register frame is automatically closed at the end of thefunction, so that a register is only valid within a function.

The mesh can be accessed exclusively by using halfedges. Ahalfedge uniquely defines a position in a mesh, i.e., one (ver-tex,edge,face) combination. With mesh navigation functions it ispossible to move a halfedge over a mesh: The mate function re-places a halfedge on the stack with its corresponding other halfedge(in reversed direction). Similarly, faceCW, faceCCW, vertexCW,vertexCCW operators exist to navigate in clockwise and counter-clockwise directions over faces and vertices.

Lines 1 and 2 of collapse-mid push the positions of both endvertices of edge e on the stack. Line 3 computes p as their mid-point. The moveV operator in line 4 then moves the vertex of e’smate to the new position. This changes the mesh, creating a non-planar face, which is shown as subdivision surface. The last line ofcollapse-mid finally uses the killEV euler operator, which is essen-tially an edge collapse, to remove e and its vertex from the mesh.This finally creates two non-planar faces (see Fig. 4).

The planarity can be restored when collapse-mid is applied alsoto the opposite edge of the original quad. Yet this kills only two ofthe four edges from the original quad, which turns it into a 2-gon.One of these edges is redundant and can be killed using killEF,which is the Euler operator for joining two faces. So providedcollapse-mid exists, the complete GML code to create the housemodel in Fig. comprises only the six lines of code to the left:

(10,7,0) 0 quad5 poly2doubleface4 { (0,4,3) extrude } repeatdup faceCCW collapse-middup faceCW collapse-middup faceCCW killEF

{ usereg !roofheight !floors !quadpoly:quadpoly 5 poly2doubleface:floors { (0,4,3) extrude } repeat0 :roofheight 3 vector3 extrudedup faceCCW collapse-middup faceCW collapse-middup faceCCW killEF

} /simple-house exch def

Figure 4: Creation of the simple house model. The extrude operator is repeatedly applied to the ground polygon. To create the roof, thecombined operator collapse-mid is applied to the faceCW and faceCCW edges of the edge returned by the extrude operation.

It is immediately obvious that the code to the left can be used tocreate more than just one single house. A whole variety of differenthouses can be created with essentially the same operator sequence,but using slightly different parameters. The GML encourages theconversion of specific shapes to general functions because replac-ing concrete values by parameters is so simple. The simple-housefunction to the right is one possible parametrization of the houseconstruction sequence. A few variations of the simple house areshown in Fig. 5.

Note that the simple-house function expects the ground quad-rangle on the stack. This demonstrates an important concept: Theseparation of data and operations. A very lean city database mightrepresent each building by only a 4-tuple: (position,size,floors,roofheight). A sample city generated this way is shown in Fig. 6.

Figure 6: Sample city generated by the GML house model in Fig. 5from the footprints of the buildings augmented with the parametersnumber-of-floors and roof height.

Even more important: Functions can be parameters – just likeanything else, because they are just arrays. So the example couldalso be parameterized in terms of the extrudepoly function or thetransformation to create the second polygon (the body of the mapoperator).

5.5 The Gothic Window

The basic stylistic pattern in Gothic architecture is the circular arc,or circle segment. A pointed arch, for example, is constructed withtwo vertical line segments continued by circle segments to the pointwhere the circles intersect. A circle segment can be represented bythree points, the start and end points and the center of the circle,and a normal. The normal is important if angle(p0−m, p1 −m)is supposed to be greater than 180 degrees. Just as a circle corre-sponds to an n-gon, the function converting circle segment expectsa resolution. In GML notation it is created simply by:

[ p0 m p1 ] norml resolution circleseg-polyThe poly2doubleface operator of the Geometry library produces

smooth vertices by default, and creates corner vertices only wherethe polygon contains the same point twice (in analogy to BSplinecontrol polygons), i.e., segments of zero length. This is useful forthe pointed arch example, as the different parts of the polygon’soutline can be combined simply by concatenating arrays.

Figure 7: Gothic Window: basic ’style’ in left image is augmentedwith a rosette and then applied recursively once and twice to thewindow geometry in the center image and right image, respectively.

The Geometry library’s extrude operator can also shrink or ex-pand, and it can do multiple extrusions on several faces, so it ex-pects an array of edges and an array of (dx,dy) extrusion values(actually 3D points), which is essentially a profile.

The creation of Gothic style windows or ornaments is then amatter of creating the right circle segments. An analysis of someexamples reveals that the most important operations are offsetting,scaling and rotation, and, curiously, to compute the intersection ofan ellipse and a circle (to determine the radius of the top window).

Some results are shown in Figures 7 and 14. Note the varietyof different styles that can be obtained by changing the profile, orsome parameters. This effectively shows the separation of structurefrom data. Another point is the effect obtained from coarseningthe resolution of the circular segments, a simple way to obtain asemantic LOD (see Fig. 8).

5.6 The Arcade

The Arcade example demonstrates the versatility of our approachwhich is capable of supporting the separation between basic ’shape’and the ’presentation’ aspect – similar to the separation of ’markup’and ’presentation’ in the text domain. The example also documents

Figure 8: Illustration of semantic LOD. This is the gothic windowin the left part of Fig. 7 in an extremely coarsified version. Aswe have the knowledge about the construction history, we can stilldistribute edge sharpnesses correctly to obtain an appealing shape.

the usefulness of a data flow concept for 3D modeling, and it un-derpins our claim that 3D modeling has to be supported with aspowerful tools as used in programming.

Primary input parameters are a ground polygon and an arcadestyle. It uses the offset-polygon operator to generate a new polygonin a specified distance.

6 Web Applications: The ActiveGML Plugin

The GML calculus as presented in this paper provides the necessaryinfrastructure for an extremely compact yet very powerful genera-tive representation of 3D objects, based on operations instead of(low-level) geometric primitives.

The ActiveGML web browser plugin is realized as an ActiveXcontrol widget that can be embedded in any standard HTML page.Currently, the plugin will only work with the Internet Explorer.But next steps include implementations for Netscape, Mozilla andOpera browsers, which use the old Netscape client plug-in API.Scripting support for these browsers will be added by XPConnect1

which uses XPCom2 (Cross Platform Component Object Model).Since GML is also running (and being developed) under Linux, acorresponding browser plugin will be released in the near future.

The ActiveGML plugin provides only three methods that can beaccessed from JavaScript. With these functions, a GML model canbe loaded, messages can be sent to the plugin, and a textual repre-sentation of the token on top of the stack can be retrieved. Typically,these functions are used in the following way:

ActiveGML.call(document.GMLCommand.value);ActiveGML.loadModel(document.GMLFilename.value);var stacktop = ActiveGML.getStackTopAsString();

6.1 Integration of Non-Generative 3D Data

The concept of a stack-based language is quite general and as welladaptable to concepts other than BRep modeling. This can be illus-trated by the following two examples which map existing 3D web

1http://www.mozilla.org/projects/plugins/scripting-plugins.html

2http://www.mozilla.org/projects/xpcom/

formats, namely .OBJ (Fig. 11) and VRML (Fig. 10), into the GMLframwork.

v -1.0 -1.0 -1.0v -1.0 1.0 -1.0v 1.0 -1.0 -1.0v 1.0 1.0 -1.0v 0.0 0.0 1.0

f 1 2 4 3f 1 3 5f 3 4 5f 4 2 5f 2 1 5

(-1.0-1.0 -1.0) v(-1.0 1.0 -1.0) v( 1.0-1.0 -1.0) v( 1.0 1.0 -1.0) v( 0.0 0.0 1.0) v

[ 1 2 4 3 ] f[ 1 3 5 ] f[ 3 4 5 ] f[ 4 2 5 ] f[ 2 1 5 ] f

{ beginreg !faces !points:points { addVertex } forall:faces { addFace } forallendreg

} /create-IFS exch def

[ (-1,-1,-1) (-1,1,-1)(1,-1,-1) (1,1,-1) (0,0,1) ]

[ [ 1 2 4 3 ] [ 1 3 5 ][ 3 4 5 ] [ 4 2 5 ] [ 2 1 5 ] ]

create-IFS

Figure 10: Versatility of the Postscript syntax: a cube as indexedface set in .OBJ file format syntax, and how it translates to GMLwhen v and f are functions. The similarity is obvious, but note thereversal of the order of keywords and arguments.

The .OBJ file format is conceptually quite simple, as the examplein the left column of Fig. 10 indicates. In GML, a function to createan indexed face set would expect on the stack an array of 3D pointsand an array of index arrays for faces, and simply loop over them,vertices first, as shown in the right box. A solution with a moreobvious correspondence is shown to its left, where addVertex andaddFace are redefined as v, f.

Transform {translation 0 8 0children [

Shape {appearance Appearance {

material Material {diffuseColor 0 0.5 1

}}geometry Cylinder {

height 18.0radius 0.5

}}

]}

Transform(0,8,0) translation[ Shape

AppearanceMaterial

(0,0.5,1) diffuseColorendnode

materialendnode

appearanceCylinder

18.0 height 0.5 radiusendnode

geometryendnode

] childrenendnode

Figure 11: Versatility of the Postscript syntax: the left columnshows a portion of a hierarchical scene graph in VRML syntax. Itcould be translated to GML by using functions for nodes and fields.

VRML in turn is based on the concept of a Directed AcyclicGraph (DAG) of nodes with fields containing values. It naturallycorresponds to a hierarchy of dictionaries, so that the definition of acylinder would read: dict begin /nodetype /Cylinder def /height 18.0def /radius 0.5 def currentdict end. This leaves the dictionary on thestack to be used by its parent node. A more sophisticated way torepresent a VRML scene is to realize node types as functions. ACylinder operator would put a dictionary containing the field defin-ing functions (like height and radius) on the dictionary stack.

Of course, we do not advocate to use GML just to intrepret .OBJor VRML data sets. Instead, we suggest to increase the seman-tic level in which the 3D model is being represented to the highestpossible in order to exploit all described features from compact rep-resentation, resulting in negligible downloading times, to seman-tic LOD, catering for varying rendering performance at the client’s

Figure 9: Separating basic geometry from ’presentation’: the styles ’building’ and ’arcade’ are applied to a basic u-shape (left and middle)and then the basic shape is changed independently from the applied style (right).

side.

Figure 12 and Figure 13 show the GML ActiveX-plugin in ac-tion with a chess game and the Cologne Cathedral, both at fullyinteractive rendering speed (displayed at a standard notebook). Thechess game takes 13.113 bytes of XML code (2.922 bytes withgzip compression) and the Cologne Cathedral, which has all in-terior structures fully modelled, takes 132.716 bytes (19.507 byteswith gzip compression). LOD (i.e. Euler Macro) evaluation andtesselation-on-the-fly of curved surfaces are controlled by an ap-pliaction through the parameters rendering speed, projected patchsize, curvature, and contribution to a silhouette.

Finally, it is worth mentioning that the extensibility of the GMLis also key in protecting intellectual property rights: The wholecurrent runtime system has a size of about 2.5 MB, so it is feasi-ble to create a custom viewer that will only display models carry-ing a particular security code issued by a Digital Rights Manage-ment (DRM) system – in contrast to sending a fine tesselation fromwhich reverse engineering is easy. Of course, the DRM key can alsocontrol various levels of detail the client/plugin will render therebyserving different user groups with just one (and consistent) model.

7 Conclusions

We have presented a novel technique for representing geometricobjects more accurately and in an extremely compact way basedon high-level shape descriptors (in contrast to lowest-level polygonmeshes). In addition to introducing a new level semantic compact-ness and quality of shape preservance the new represenation has thepotential of clearly separating basic geometric features from orna-mental aspects in a similar way modern publishing systems clearlyseparate content from presentation. As illustrated in Figures 7 and14 the content would deliver the fact that we are dealing with a win-dow of a certain extent and at a certain position but the ornamentaldetail is a matter of presentation, something we must be able tochange from ’gothic’ to ’baroque’ as easily as switching the LATEX-style from ’article’ to ’report’.

Also, the presented approach suggests a new measure for geo-metric complexity by replacing the (in many cases meaningless)polygon count by the constructive model complexity. It is alsoworth noting that the model file sizes for Figures 7 and 14 are onlyin the order of a few kilobytes.

Acknowledgement

The support from the German Research Foundation (DFG) underthe Strategic Research Initiative Distributed Processing and Deliv-ery of Generalized Digital Documents (V3D2) [Fellner 1998-2003]to address basic research challenges in the field of Digital Librariesand from the European Commission under the EPOCH Network ofExcellence is greatly appreciated.

References

ADOBE SYSTEMS INC. 1990. PostScript Language ReferenceManual, 2 ed. Addison-Wesley.

BOLZ, J., AND SCHRÖDER, P. 2002. Rapid evaluation of catmull-clark subdivision surfaces. In Proc. Web3D 2002 Symposium.

BORODIN, P., NOVOTNI, M., AND KLEIN, R. 2002. Progressivegap closing for mesh repairing. Advances in Modelling, Anima-tion and Rendering (July), 201–21.

CATMULL, E., AND CLARK, J. 1978. Recursively generated b-spline surfaces on arbitrary topological meshes. Computer-AidedDesign 10 (September), 350—355.

FELLNER, D. W., 1998-2003. Strategic Initiative V 3D2 – Dis-tributed Processing and Delivery of Digital Documents. Ger-man Research Foundation (DFG), http://graphics.tu-bs.de/dfgspp/V3D2.

GARLAND, M., AND HECKBERT, P. S. 1997. Surface simplifica-tion using quadric error metrics. In Proceedings of SIGGRAPH97, ACM SIGGRAPH / Addison Wesley, Los Angeles, Califor-nia, Computer Graphics Proceedings, Annual Conference Series,209–216. ISBN 0-89791-896-7.

HAVEMANN, S., AND FELLNER, D. W. 2003. Progressive com-bined breps – multi-resolution meshes for incremental real-timeshape manipulation. Tech. rep., Institute of ComputerGraphics,TU Braunschweig. submitted for publication.

HAVEMANN, S. 2002. Interactive rendering of catmull/clark sur-faces with crease edges. The Visual Computer 18, 286–298.

HOFFMANN, C. M., AND ARINYO, J. 2002. Parametric modeling.In Handbook of CAGD. Elsevier.

Figure 12: GML-plugin in action: the chess game takes 13.113 bytes of XML code (2.922 bytes with gzip compression). left: full model,right: zoomed subsection (LOD evaluation and tesselation on the fly done by the receiving client).

HOPPE, H., DEROSE, T., DUCHAMP, T., HALSTEAD, M., JIN,H., MCDONALD, J., SCHWEITZER, J., AND STUETZLE, W.1994. Piecewise smooth surface reconstruction. Proceedings ofSIGGRAPH 94 (July), 295–302. ISBN 0-89791-667-0. Held inOrlando, Florida.

LYMAN, P., VARIAN, H. R., DUNN, J. D., STRYGIN,A., AND SWEARINGEN, K., 2000. How much infor-mation? http://www.sims.berkeley.edu/research/projects/how-much-info/index.html.

MÄNTYLÄ, M. 1988. An Introduction to Solid Modeling. Com-puter Science Press, Rockville.

PAOLUZZI, A., PASCUCCI, V., AND VICENTINO, M. 1995.Geometric programming: A programming approach to geomet-ric design. ACM Transactions on Graphics 14, 3, 266–306.www.plasm.net.

VILBRANDT, C., PASKO, G., PASKO, A., FAYOLLE, P.-A., VIL-BRANDT, T., GOODWIN, J. R., GOODWIN, J. M., AND KU-NII, T. L. 2004. Cultural heritage preservation using construc-tive shape modeling. Computer Graphics Forum 23, 1, 25–41.www.hyperfun.org.

Appendix

Euler Operators

We informally describe the working of the five Euler operators formesh manipulation. We use a C++ syntax, where e0, e1, eNewdenote halfedges, p, p0, p1 are points of type Vec3f, and s is aboolean value, the sharpness of a new edge. On the C++ level, theEuler operators are the basis of the implementation of higher levelmodeling tools (extrude etc.), but they are also available as GMLoperators.

The first operator reads makeVertexEdgeFaceShell and creates anew connected component consisting of two vertices connected viaa pair of half-edges: eNew = makeVEFS(p0,p1,s) with halfedgeeNew directed from point p0 to p1. Its inverse would be kil-lVEFS(eNew). Note that both half-edges are incident to the sameface. At this point, this face is not what is usually understood asa face (i.e., there is no face normal). It can be expanded using thefollowing two operators.

The second operator creates an edge and a vertex at p: eNew =makeEV(e0,e1,s,p). Edges e0 and e1 must emanate from the samevertex, and they denote the two faces between which the new edgeis created. If e0 equals e1, a dangling edge is created. Its inverse iskillEV(eNew).

The next operator splits an existing face by making an edge be-tween two of its vertices, thereby creating a new face: eNew = ma-keEF(e0,e1,s). Consequently, e0 and e1 must belong to the sameface, or to the same ring. Its inverse is killEF(eNew).

Figure 13: GML-plugin in action: the Cologne Cathedral with fully modeled interior structures takes 132.716 bytes of XML code (19.507bytes with gzip compression). left: full model, right: zoomed detail, also opening the view into the interior of the cathedral.

These three operators (plus their inverse) are sufficient to buildup any mesh of genus 0, i.e., a single connected component that istopologically equivalent to the sphere. The remaining two operatorsare related to rings and the modification of genus.

To understand how a ring is created, note that nothing preventsboth halfedges (e0,e1) of a pair from being incident to the sameface. By issuing killEmakeR(e0) in the situation shown in the fol-lowing figure, the inner quadrangle is decoupled from the borderand is turned into a ring while the border becomes its base face.

Note that the ring is clockwiseoriented, which is consistent withthe rule that the face interior is tothe left of a halfedge. The inversemakeEkillR(e0,e1) is used to con-nect the ring containing e0 withthe other ring or base face con-taining e1. The genus modifica-tion also uses rings, which makesit extremely simple.

Suppose two connected components are given, for example twoaxis-aligned cubes, one of them bigger than the other. They canbe placed next to each other so that geometrically, one face of thesmaller cube lies in the interior of a face of the bigger cube. If e0and e1 are edges which belong to the smaller and the bigger face,killFmakeRH(e0,e1) will simply turn the smaller face into a ring ofthe bigger face. Thereby the two connected components are gluedtogether into one. In the same fashion, a torus, thus a topologicalhole, is created when the two faces belong to the same connected

component.Any orientable manifold mesh can be created by these five pairs

of operations.

Figure 14: One of the many gothic windows from Figure 13: detailed view on resulting shape and tesselation.