Efficient Scene Descriptions Using Advanced Modelling Techniques ...

Efﬁcient Scene Descriptions Using Advanced Modelling
Techniques in the RenderMan Context
R. Schultz
H. Schumann

University of Rostock
Abstract
overview of a modelling system in the RenderMan envi-
ronment, then show how the concepts for compact storage
In this paper methods for efﬁcient scene storage in the
can be realized and how much memory can be saved in the
RenderMan context using concepts like instancing (refer-
next sections using example scenes.
encing), procedural objects, and tool objects are discussed.
We introduce the concepts for efﬁcient storage in general,
give a system overview of a modelling environment us-
2
Concepts for Compact Storage
ing RenderMan, show how these concepts may be used in
of 3D Scenes
the RenderMan context and discuss advantages, disadvan-
tages, and possible extensions.
In this section we introduce the concepts for compact stor-
Keywords: efﬁcient scene storage, instancing, procedu-
age in general.
ral objects, tool objects, RenderMan
2.1
Instancing/Referencing
1
Introduction
For scenes with many similar objects it is desirable to save
just the properties that are different between those objects
The storage complexity of a scene is an important as-
and not to save e.g. the full geometric representation for
pect of rendering because ﬁle operations and swapping
each object. Instancing is an approved method to realize
due to high memory consumption can become extreme
this desired behaviour, but nevertheless it is not used in
time and resource consuming processes. To reduce the
general. A yet unsolved problem is the automatic conver-
amount of memory (on disk as well as in RAM) used
sion of scenes modeled without the instancing paradigm
for the storage of complex scenes different concepts may
to scenes that use instancing. However, this problem is not
be used.
These are for example multiresolution tech-
addressed in this paper.
niques, instancing (referencing), procedural objects, and
According to Foley et al. [1] the ﬁrst use of instancing
tool objects. However, multiresolution techniques as in-
in computer graphics dates back to Sutherlands Sketchpad
troduced by Hoppe et al. [10, 11] are not scope of this
system that has been introduced 1963. Sutherland deﬁned
paper. Commercially available modelling and rendering
the terms Master as an object which holds full geometric
packages (like Maya [6] or 3D Studio Max [5]) use the
information and Instance as a transformed variant of the
concepts instancing, procedural objects, and tool objects
Master object.
internally. The RenderMan Interface is a standard inter-
There are two major ways to model with instances:
face between modeling programs and rendering programs.
In this paper we discuss the following questions:
¡
Modelling with instances of primitives:
In this case, the Master object is not element of the
¡
How can the concepts for compact storage be used in
the RenderMan context?
scene itself, and it’s speciﬁc geometric representa-
tion cannot be changed. Roth [8] points out, that
¡
Are there any special requirements that have to be
this instancing paradigm contains another distinc-
met in order to use these concepts?
tion. Namely the global coordinate system, where the
scene is assembled versus the local coordinate system
¡
What are the beneﬁts and what the drawbacks?
where the primitive is deﬁned in.
¡
How can these methods be improved further?
¡
Modelling with instances of arbitrary objects:
To answer these questions, we ﬁrst describe instancing,
In contrast to the ﬁrst method, the Master object is
procedural objects, and tool objects in general. We give an
here an object that is already element of the scene.
¢
Fachbereich Informatik, Universit¨at Rostock, A. Einstein Str. 21,
The Master object may be changed by the user, thus
18051 Rostock, Germany; e-mail: rschultz@informatik.uni-rostock.de
changing all instances too.

Instance objects can be used to save storage or to ease
objects. An example for this is e.g. a tool that creates a
operations on objects that would normally have been done
surface of revolution from a curve. In a modelling system
on many objects separately. The amount of saved mem-
without tool objects the tool create surface of revolution
ory can be very high, but this depends highly on the scene.
would be applied to a curve object of the scene creating
If there are no objects that share certain properties in the
a surface (a patch) from that curve and possibly deleting
scene one can hardly use instancing. Properties can, for
the curve object. In a system with tool objects a tool ob-
instance, be geometric information, textures or other ma-
ject surface of revolution would be created and the curve
terial descriptions.
object would be connected to that object so that the tool
object can create the patch from the curve. The connection
2.2
Procedural Objects
can e.g. be established using the hierarchy concept known
from CSG modelling systems. In our example, the curve
Instead of describing complex objects using e.g. many
would be a child object of the tool object.
polygons it is desirable to save a small set of parameters
To summarize, a tool object may be deﬁned as a pro-
for an algorithm (a piece of code), which is able to cre-
cedural object that takes other objects in the scene as pa-
ate e.g. the polygonal representation of the object when
rameter for its procedure which in turn carries out certain
needed. Of course, this is feasible only if such an algo-
modiﬁcations on the parameter objects or creates new ob-
rithm exists for the given object and the set of parameters
jects from them. Tool objects are e.g. used in Maya [6].
is smaller than the actual geometric representation.
A ﬁrst similar approach can be found in the GENMOD
Procedural objects are objects, whose geometric repre-
modelling system by Snyder [2].
sentations will be created on the ﬂy whenever needed, us-
Advantages of tool objects are a compact scene descrip-
ing code (a procedure) and a set of parameters.
tion and easier modelling. The example given here shows
The code may be compiled machine code (e.g. C) or
that a class of tool objects are sweeping objects but tool
interpreted code (for instance a Tcl script). Both meth-
objects are more general because the parameter objects are
ods have speciﬁc advantages and disadvantages regarding
not limited to curves and the operation is not limited to a
speed and safety of execution. Machine code is fast but
sweep.
may crash the host program. Moreover, it is difﬁcult to
implement in a platform independent way, because of the
different concepts of dynamic loading that exist in current
operating systems. Scripted code is safe to execute and
platform independent, but slower than machine code.
2.4
Current Usage of the Concepts for
The main advantage of using procedural objects is that
Compact Storage
the set of parameters is often many times smaller than
the full geometric representation of the described object
The concepts for compact storage of three dimensional
so that a commonly used term for the generation of geo-
scenes are not new and widely used in the internal stor-
metric information from the set of parameters is actually
age facilities of the commercially available modelling en-
data ampliﬁcation (see [3] p. 201). More beneﬁts of us-
vironments like Maya [6] or 3D Studio Max [5]. How-
ing procedural objects are that the geometric information
ever, when using the RenderMan interface some of these
may be created just when it is really needed (this presumes
concepts are often ignored; e.g. simple NURB patches are
that a bounding box is known for a given procedural ob-
used instead of tool objects.
ject). Furthermore, the accuracy of the created geometric
The same problem occurs when converting scene data
representation may be adapted to a given context. The res-
from one modelling environment to another, because of
olution of the created geometry is just as good as it needs
the lack of support for these concepts in the intermediate
to be. A good example of this approach is given by We-
ﬁle formats. We show how these concepts may be applied
ber et al. [9]. Here, the authors create procedural models
in the RenderMan context and discuss the problems that
of trees that are more detailed when nearer to the camera.
led to the current situation.
Another well known example for a procedural object are
fractal landscapes. However, we will show, that procedu-
ral objects (with certain extensions applied) can be used to
model other classes of objects too.
3
Efﬁcient Scene Storage in the
2.3
Tool Objects
RenderMan Context
Tool objects reﬁne the concept of procedural objects. In
most current modelling systems there is a sharp distinc-
In this section we show how a modeling environment is
tion between the objects in the scene and so called tools
embedded in a RenderMan system and discuss the applica-
that modify objects. But certain operations on objects may
tion of the concepts for compact storage in the RenderMan
be thought of as an object in the scene too. These are tool
context.

RenderMan Interface
On the other hand, the caches in the ﬁle system can now
b
be better utilized to improve parsing speed (when reading
Modeller
Renderer
the scene into the renderer).
a
The amount of memory that may be saved by using in-
stances instead of real objects depends highly on the scene.
RAM
RAM
A classic application of instancing is an architectural scene
with many similar elements as shown in Figure 2. The ﬁle
Scene
RenderMan
Image
size for a partial scene of Figure 2 (see Figure 3) is 140882
Storage
Interface
Bytestream
byte (without instancing) and 55404 byte in 8 ﬁles with
the use of instancing (the compression factor is 2.5). Note,
Figure 1: System Overview
that we can create the upper left wall for the original scene
(Figure 2) by creating just another single instance object
from the wall.
3.1
Modelling in the RenderMan Envi-
ronment
RenderMan is a speciﬁcation of an interface between a
modelling system and a renderer. The viewpoint of the
speciﬁcation is renderer centric, modelling itself is not
sufﬁciently considered. Figure 1 shows a simpliﬁed sys-
tem overview for the link of a modelling environment to
a RenderMan compliant renderer. Usually, the modelling
system itself has its own scene storage on disk. To actu-
ally render a scene the RenderMan Interface is used. This
is done using a so called client-library that writes a RIB
ﬁle (RenderMan Interface Bytestream) to disk (this route
is labeled ”a” in Figure 1). The renderer then reads this
byte-stream and produces an image ﬁle. The byte-stream
is not meant to be read by modelling environments but
only by renderers. It is also possible to send the byte-
Figure 2: Instancing Example
stream directly to a renderer using the Unix pipe mech-
anism without creating a RIB ﬁle (this route is labeled ”b”
in Figure 1). This approach has several disadvantages (re-
garding control and ﬂexibility) and is not used much. The
byte-stream may be either pure ASCII or binary data.
3.2
Instancing and Procedural Objects
in the RenderMan Context
The RenderMan Interface offers functionality for instanc-
ing and procedural objects.
There are two different
approaches for instancing.
The ﬁrst method uses the
RiObjectInstance() mechanism that is part of the
original RenderMan Interface speciﬁcation 1 (see [3] pp.
133). This approach is limited to instances of the basic
geometric primitives deﬁned in the RenderMan Interface
speciﬁcation only, and is therefore deprecated. The sec-
Figure 3: Instancing Example, upper middle wall
ond approach, which uses RiReadArchive() is more
ﬂexible. It works like an include mechanism known from
Procedural objects in the RenderMan context may be
e.g. C preprocessors. Consequently, the scene is no more
deﬁned using RiProcedural() (see [3] pp. 201). Ar-
a single ﬁle, but consists of a main ﬁle that includes other
guments to this call into the RenderMan Interface are
ﬁles. This can be a drawback because it is more difﬁcult
1. a block of data
to handle the scene now (because the references have to
be resolved). Furthermore, if the ﬁles are smaller than the
2. a bounding box
block-size used in the ﬁle system, they may easily require
3. a pointer to a so called reﬁnement procedure, that cre-
more space.
ates the geometric representation from the parameters
1the current version of the speciﬁcation is 3.1 from 1989
(the block of data)

4. a pointer to a free procedure, that disposes the object
Mops [13] and implemented a tool object, that creates a
surface of revolution (a NURB patch) from a NURB curve
In order to make the procedural object dynami-
that is given as parameter.
cally loadable shared code 2 an additional procedure
Thus, tool objects may be created using the RenderMan
(ConvertParameters()) is needed. The convert pa-
Interface, but how much memory can be saved? We an-
rameters procedure converts the parameters given in the
swer this question by comparing the sizes of the control
RenderMan Interface Bytestream in ASCII representation
and knot vectors of the parameter objects for various tool
to a form usable by the reﬁnement procedure. The set of
objects with their NURB patch counterparts.
parameters may contain arbitrary information. We show a
Surface of Revolution:
£
£
£
NURB patch
9 n 4
9
3
n
o
¤
¤
¥§¦
¦
¥§¦
¦
¥
£
£
tool object
n 3
n
o
¤
¥§¦
¦
¥
Table 1: Surface of Revolution from a curve with n points
The surface of revolution tool object (Table 1) needs a sin-
gle 2D curve as argument that will be rotated around an
axis in space thus forming a surface. The axis may be
Figure 4: Collection
constrained to one of the world axes, so that it does not
need to be saved. The size of the resulting NURB patch
new example for a procedural object, that creates e.g. sea
for a complete 360 revolution is 9 n (where 9 is de-
¨
¤
shell shapes. This object was used to create the shells in
rived from the standard NURB circle as described in [4]
Figure 4. The size of the parameters for the procedural
and n is the number of points in the curve). The mem-
sea shell object is 12K, whereas the full geometric infor-
ory needed for the control vertices sums up to 9 n 4
¤
¤
mation in form of NURB patches is 330K (which yields a
numbers, because the patch is always rational. But there
compression factor of 27.5). But the new procedural ob-
is more memory needed, because of the two one dimen-
ject is not limited to sea shells, in Figure 3 and 2 it is used
sional knot vectors. Those are sized 9
3 and n
o (3
¦
¦
to model the capitals of the columns and the cap stones.
is the order of the standard NURB circle and o is the or-
der of the generating curve). Alltogether, the patch needs
£
£
£
3.3
Tool Objects in the RenderMan Con-
9 n 4
9
3
n
o numbers. The parameter ob-
¤
¤
¥©¦
¦
¥¦
¦
¥
ject for the tool object (a simple NURB curve) can be a lot
text
£
£
smaller, namely n 3
n
o . For the simple example
¤
¥§¦
¦
¥
In contrast to instancing and procedural objects, the Ren-
of a revolved curve with n
4 and o
4 the patch needs

£
£
£
derMan Interface offers no direct functionality for tool ob-
9 4 4
9
3
4
4
164 but the tool object just
¤
¤
¥¦
¦
¥¦
¦
¥
£
£
jects, but the mechanism for procedural primitives can be
4 3
4
4
20 numbers. The NURB patch requires
¤
¥©¦
¦
¥
used to realize these. As mentioned before, the parameters
8.4 times the space of the tool object.
of a normal procedural object may contain arbitrary infor-
Extrusion:
mation. The parameters may e.g. contain a complete ob-
ject description as it is needed for a tool object. However,
the parameters may not establish relationships to arbitrary
objects in the scene and the procedure of the tool object
has no access to the internal scene database of the ren-
£
NURB patch
2 n 4
4
n
o
derer. Consequently, those parameter objects would have
¤
¤
¦
¦
¦
¥
£
tool object
n 3
n
o
to appear twice in the RIB. When using parameter objects
¤
¦
¦
¥
like curves that are linked to the tool objects with a CSG-
like hierarchy the existing functionality in the RenderMan
Table 2: Extrusion from a curve with n points
interface is sufﬁcient.
For example, we used the code for the generation of a
An extrusion is a surface that results from moving a curve
surface of revolution from our modelling environment The
along a linear path (Table 2). Similar to the surface of revo-
2a so called dynamic shared object, short DSO
lution we constrain the curve to extrude to 2D and the path

to a world axis. The height of the extrusion is ﬁxed to 1.0,
control vertices and knot sequences the resulting skinned
an additional linear transformation is required to change it.
patch is generally smaller than the tool object. Neverthe-
The memory needed for the corresponding NURB patch is
less, under certain circumstances some memory may be
£
2 n 4
4
n
o and the memory for the extrude tool
saved with skins too. This happens e.g. if the number of
¤
¤
¦
¦
¦
¥
£
object is n 3
n
o , which leads to a factor of 2.2.
control vertices or knot vectors differ between the cross
¤
¦
¦
¥
General Sweep:
section curves. A skin of two curves with both 4 control
vertices but one with an order of 2, results in a skinned
patch of 10 2 control vertices (see [4]). The compression
¤
factor for this example is 2 2.

Table 5 gives an overview about the compression factors
achieved by the tool objects discussed so far.
Revolve
Extrude
Sweep
Skin
£
£
NURB patch
nc ns 4
nc
oc
¤
¤
¥§¦
¦
¥¦
compression
£
ns
os
¦
¥
factor
8.4
2.2
n.a.
n.a.
££
£
tool object
nc
nt
4
nc
oc
¦
¥§¤
¥§¦
¦
¥¦
£
nt
ot
¦
¥
Table 5: tool objects without extensions
Table 3: General Sweep from a cross section with nc and
The examples show considerable compression factors.
trajectory with nt points
However, those factors are theoretical ones and cannot be
achieved in practice because of multiple overheads that re-
A general sweep is a surface that results from moving a
sult e.g. from the size of the code of the tool object. This
curve (a cross section) along a second curve (a trajectory),
code has to be stored and loaded with the scene. The code
possibly arranging all cross sections to be perpendicular
does not have to be written each time a scene gets writ-
to the trajectory (Table 3). Let nc be the number of con-
ten by the modelling environment, but it has to be loaded
trol vertices of the cross section, nt be the number of con-
into the renderer each time the scene is rendered. The size
trol vertices of the trajectory, and ns the number of sec-
of the compiled code is platform dependant (on the MIPS
tions used for the sweep and os the desired order. The
platform the size of the code for the surface of revolution
number of control vertices used to save the two curves for
is 16K). Furthermore, the code makes the scene itself plat-
the sweep tool object is nc
nt and the number of knots
¦
form dependant! A possible solution could be to distribute
£
£
nc
oc
nt
ot . The number of control vertices of
¦
¥¦
¦
¥
just the source code and compile it when necessary (the
the corresponding NURB patch is nc ns and the number
¤
size is then just 6.5K for the surface of revolution).
£
£
of knots nc
oc
ns
os . Moreover, all points are
¦
¥¦
¦
¥
There are other overheads involved resulting from the
three dimensional and rational. The compression factor
bounding box (6 numbers) that has to be saved for ev-
depends on ns and the desired order in the direction of the
ery procedural object in the RenderMan context and from
trajectory. The parameter ns may e.g. be derived from the
additional numbers that have to be saved for every curve
number of control vertices and the knot vector of the tra-
and patch specifying e.g. length and order. The number of
jectory or set to any number
2. If ns may be set freely

bytes that can be saved is very hard if not impossible to
by the user, the tool object may be even bigger than the
predict.
corresponding patch.
As an example we saved the part of the scene (from Fig-
Skin:
ure 3) with four revolutions as tool object instead of NURB
patches. The RIB is then 42868 Bytes big compared to
55404 Bytes, when using NURB patches.
In order to save more memory the tool objects revolve,
extrude, sweep and skin may be extended in various ways.
The control vectors of the parameter curves may be saved
in two dimensional and/or non-rational coordinates, where
NURB patch
n.a.
applicable.
tool object
n.a.
Since many curves are created with standard knot vec-
tors (NURB, Bezier, B-Spline, see [3] pp. 105) those do
not need to be saved in explicit form but may be re-created
Table 4: Skin
on the ﬂy easily.
A normal skin tool object does not generally save mem-
A skin is a surface that is controlled by a certain number
ory, but if the section curves of the skin are similar in terms
of cross section curves that may have different character-
of instancing, this concept could also be used for the skin
istics (Table 4). Since all section curves are saved with
tool object. An example for this is shown in Figure 5.

Here, the body of the cactus is modeled as a skin from a
single curve with 29 rotated and scaled instances. Instead
of saving 30 curves with 8 controlpoints and 12 knots, just
one curve has to be saved, and 29 instances with transfor-
mation attributes.
Figure 6: Extrude Object with Holes, Caps and Bevels
eller and with the RenderMan Interface more intuitive. On
the other hand, they increase the size of the tool objects
because of the controlling ﬂags and parameters that need
to be saved and they increase the complexity and size of
the tool objects code, which has an impact on execution
Figure 5: Cactus
time.
In addition to the simpliﬁcation of the parameter ob-
3.4
Usage of Tool Objects in Modelling
jects, the procedures for the tool objects may be extended
and Rendering
to include more functionality.
Current trends in freeform modelling (e.g. the Teddy
¡
Creation of caps: Where closed planar curves are
sketch system by Igarashi et al. [12]) show, that intu-
used to mark the ends of an object, caps (surfaces
itive approaches gain increasing importance. Neverthe-
that ﬁll the curve) may be created automatically us-
less, those new modeling techniques are mainly used with
ing trimmed NURB patches (see Figure 6 for an ex-
ﬁxed rendering algorithms. It is highly desirable to use
ample). The NURB patch is trimmed by the afore-
the intuitive and efﬁcient new techniques like tool objects
mentioned curve that needs to be transformed appro-
in the RenderMan context to take advantage of the differ-
priately.
ent available rendering algorithms that are available here.
Even further application in the VRML context is possible.
¡
Bevels: To round the otherwise sharp corners be-
However, the RenderMan Interface currently does not re-
tween object and cap, bevels may be created auto-
gard the modelling environment and its advantageous ob-
matically (see Figure 6 for an example).
ject descriptions enough.
¡
Closed objects: The missing surfaces to make an ob-
The current route (implementation of tool objects us-
ject totally closed (e.g. to make it usable in set theo-
ing the interface for procedural objects) will lead to pro-
retic operations) could be created automatically. This
prietary solutions. But the tool objects as discussed here
way, they do not have to be modelled and saved ex-
are general enough to let a standardization seem worth-
plicitly.
while. A standardization in form of the RenderMan spec-
iﬁcation is necessary to make the tool objects that have
¡
Holes for extrusions: The extrude tool object may
been discussed here usable for and available to a wider
extrude two or more curves at once, forming an ex-
user base with different modelling environments. We sug-
truded object with holes. Figure 6 shows an extrude
gest to standardize the basic parameter objects (curves) the
tool object from three NURB circles, that makes use
tool objects (revolve, extrude, sweep, skin) with the pro-
of holes, caps and bevels.
The tool object needs
posed extensions and the resulting NURB patch represen-
£
£
only 3
9 3
9
3
117 numbers, whereas
¤
¤
¦
¦
¥¥!
tations.
the NURB patches that are created by the tool object
For instance, curves could be saved as:
£
£
£
£
need 3
2 9 4
9
3
2
2
extrusions
¤
¤
¤
¦
¦
¥"¦
¦
¥¥
¥"¦
££
£
£
£
£
2
2
2
2
2
2
2
2
3
9
3
ot oid (n o kt [kv] cvt cv)|(tr)
¤
¤
¤
¥#¦
¦
¥#¦
¦
¥$¦
¤
¤
¦
£
£
£
£
£
£
9
3
caps
2
3
9 3 4
9
3
3
¦
¥¥¥
¥¦
¤
¤
¤
¤
¦
¦
¥¦
¦
where ot is 0 - reference, 1 - NURB curve; oid is an
£
3
bevels
264
266
756
1286 numbers.
¥¥¥
¥%
¦
¦

object identiﬁer; n is the length and o the order of the
This sums up to a compression factor of 11, neglect-
curve; kt (knot type) is 0 - normal knot vector, 1 - B-
ing the various small overheads from the parameters
Spline knot vector, 2 - Bezier knot vector, or 3 - NURB
for beveling, caps and extrusions.
knot vector; kv is the knot vector of length n+o, which is
It is clear that the proposed extensions help to save
just present, if kt is 0; cvt (control vertex type) is 0 - 3D
memory. Furthermore, they make the work in the mod-
rational, 1 - 2D non-rational, 2 - 2D rational,

or 3 - 2D non-rational; cv is a vector of length n of control
[5] 3D Studio Max R2 Reference Manual, Autodesk,
vertices of type cvt. Using ot and oid referencing may
1998; Discreet:
be realized with tr used as transformation matrix.
http://www.discreet.com/
And an example for a surface of revolution is:
[6] Learning Maya, Alias Wavefront, 1998;
&
ot oid (tm cl c)|(tr)
Alias Wavefront:
&
http://www.aliaswavefront.com/
where ot and oid are used as above (but ot is e.g. 2); tm
is the ThetaMax parameter of the revolution; cl is 0 - not
[7] John C. Hart, The Object Instancing Paradigm for
closed, 1 - totally closed, 2 - has upper cap, 3 - has lower
Linear Fractal Modeling,
cap, or 4 - has both caps; c is the curve from above.
Proceedings of Graphics Interfaces 1992, pp. 224-
231
4
Conclusions and Future Work
[8] S. D. Roth, Ray casting for modeling solids, Com-
puter Graphics and Image Processing, 18(2), pp.
In this paper we demonstrated the application of instanc-
109-144, February 1982
ing, procedural objects, and tool objects using the Render-
Man Interface. Using various examples, we have shown
[9] J.Weber, J.Penn, Creation and Rendering of realistic
the potential of tool objects.
However, the amount of
Trees, Proceedings of Siggraph 1995, pp. 195
memory saved is generally not easy to predict because
[10] H. Hoppe, T. DeRose, T. Duchamp, J. McDonald
there are simply too many dependencies. It is always pos-
and W. Stuetzle, Mesh Optimization, ACM Com-
sible to save memory with the surface of revolution, and
puter Graphics (Proceedings of Siggraph ’93), 1993
extrusion tool objects. For general sweeps and skins the
RIB exporting code has to be more careful. Extensions
[11] M. Eck, T. DeRose, T. Duchamp, H. Hoppe, M.
are important for the discussed tool objects because some-
Lounsberry and W. Stuetzle, Multiresolution Anal-
times the memory savings depend heavily on them.
ysis of arbitrary Meshes, ACM Computer Graphics
Future work includes ﬁnding answers to the following
(Proceedings of Siggraph ’95), 1995
problems. It is unclear, whether a single universal tool ob-
ject or a number of small specialized tool objects are more
[12] T. Igarashi, S. Matsuoka, H. Tanaka, Teddy: A
advantageous. A single universal object may contain code
Sketching Interface for 3D Freeform Design, ACM
that is not used by a given scene, while small specialized
Computer Graphics (Proceedings of Siggraph ’99),
tool objects may contain code, that is identical in all tool
1999
objects.
[13] R. Schultz, The Mops Home Page:
How can we convert a scene, that is modeled with NURB
http://www.informatik.uni-rostock.de/
patches to a form using tool objects?
˜rschultz/mops/
We completely neglected the existance of a binary RIB
representation in this paper. More tests with this type of
byte-streams are necessary.
Acknowledgements
The authors would like to thank the reviewers for their
constructive suggestions.
References
[1] Computer Graphics - Principles and Practice, J. D.
Foley, A. van Dam, S. K. Feiner, J. F. Hughes, Addi-
son Wesley, 1995
[2] John M. Snyder: Generative Modeling for Computer
Graphics and CAD, Academic Press Inc., 1992
[3] Steve Upstill: ”The RenderMan Companion”, Addi-
son Wesley, 1989
[4] Les Piegl, Wayne Tiller: ”The NURBS Book”, 2nd
ed., Springer Verlag, 1997