584 VII Software Design
to access the underlying WebGL layer, and to provide a solid foundation for the
development of higher-level components. The library can be downloaded from the
SpiderGL website, http://spidergl.org.
In this chapter, we discuss the most important choices that we made while de-
signing and developing SpiderGL. In Section 41.2, we will brieﬂy discuss the library
architecture. The deﬁnition of 3D objects is detailed in Section 41.3. Section 41.4
discusses the problems arising from the object-binding paradigm imposed by the API
and how we deal with it. In Section 41.5, we describe how SpiderGL wraps native
WebGL objects and how we guarantee a robust interoperability with low-level calls.
Section 41.6 draws conclusions from our work.
41.2 Library Architecture
The global philosophy of the SpiderGL librar y is to provide a procedural interface
to typical CG algorithms and data structures. With the procedural approach, it
is possible to create higher-level interfaces, i.e., scene graphs, that use SpiderGL as
a lower-level library. In designing this software, we imposed on ourselves a series
of requirements, the most important of which was to never prevent the user from
directly accessing WebGL native functionality. Guaranteeing this property means
that a seamless cooperation of high-level SpiderGL code and low-level WebGL calls
can be achieved, giving more freedom to users.
space objects. The top-level object, SpiderGL,servesasthemainlibraryname-
bols within modules create a clean structure but results in more verbose code. For
this reason, we provide a function that opens each module namespace, making con-
tained symbols properties of the global object and thus accessible without qualifying
them. For example, after opening namespaces, the generic object SpiderGL.Some
Module.SomeClass is aliased by SglSomeClass; this means that when adding
new symbols, we have to avoid name clashes across modules.
There are top-level modules intended to provide most of the interfaces needed
by users, and transversal modules, e.g., components whose functionalities are used
by other modules. The following is a brief description of what SpiderGL modules
• Core. Basic constant deﬁnitions and the SglObject class, the base prototype
used by every object of the library.
• Type. Symbolic constants that represents scalar types, i.e., SGL UINT16 and
FLOAT32, as well as functions to convert from and to WebGL-type sym-
and implement prototypal inheritance are also provided.