COLLABORATION ON SCENE GRAPH BASED 3D DATA

Lorenz Ammon and Hanspeter Bieri

Institute of Computer Science and Applied Mathematics, University of Bern

Neubr

uckstrasse 10, 3012 Bern, Switzerland

Keywords:

Collaboration, DCC (digital content creation), attributed scene graph, automatic merging, conﬂict resolution.

Abstract:

Professional 3D digital content creation tools, like Alias Maya or discreet 3ds max, offer only limited support

for a team of artists to work on a 3D model collaboratively. We present a scene graph repository system

that enables ﬁne-grained collaboration on scenes built using standard 3D DCC tools by applying the concept

of collaborative versions to a general attributed scene graph. Artists can work on the same scene in parallel

without locking out each other. The artists’ changes to a scene are regularly merged to ensure that all artists

can see each others progress and collaborate on current data. We introduce the concept of indirect changes and

indirect conﬂicts to systematically inspect the effects that collaborative changes have on a scene. Inspecting

indirect conﬂicts helps maintaining scene consistency by systematically looking for inconsistencies at the right

places.

1 INTRODUCTION

3D modeling can be a challenging task, and usu-

ally several specialized artists have to work collab-

oratively on different aspects of the same 3D scene.

Especially if content creation is an evolutionary team

process, as it is often the case in highly creative envi-

ronments, a rather immediate collaboration on a scene

is essential. Also, sometimes a scene gets too large

for one single artist to ﬁnish it in time and several

people have to work on it in parallel (e.g. large seam-

less worlds are one of the challenges in content cre-

ation for next generation console games). Quite often

a scene does not evolve just linearly, i.e. alternative

designs are considered, reﬁned, rejected and ﬁnally

taken over.

Unfortunately, today’s professional 3D digital con-

tent creation tools (DCC tools), like Alias Maya or

discreet 3ds max, offer only limited support for a team

of artists to work on a 3D model collaboratively. Usu-

ally they store 3D scenes in a simple ﬁle, and the

ﬁle system’s locking mechanism is applied, so only

one artist can work on a scene ﬁle at a time. A

work around for this locking problem are reference

ﬁles. Reference ﬁles allow the decomposition of a

scene into several parts. A main scene ﬁle then ref-

erences all part scene ﬁles. Artists can work in par-

allel on separate reference ﬁles, but the decomposi-

tion of the scene into parts also puts barriers to the

artists’ collaborative work. In order to see what the

others are doing, an artist has to open the main scene

ﬁle or explicitly reference the corresponding part ﬁles.

Changes to a scene are coordinated using the main

scene ﬁle, but to make the necessary adjustments the

artist always has to ﬁnd and open the corresponding

part ﬁle. Therefore reference ﬁles only make possi-

ble a coarse-grained collaboration on rather statically

deﬁned parts of a scene. In addition, managing the

separately evolving parts can get quite cumbersome,

as more parts and especially lots of revisions of them

are created.

Exactly this problem is attacked by Alienbrain Stu-

dio (Alienbrain, 2005) which is today’s leading digi-

tal asset management solution in content creation for

video games. It stores scenes in a central repository,

manages their revisions and is aware of the reference

ﬁle mechanism. But it does not provide support for

two artists to work in parallel on the same scene ﬁle

and for merging their changes. This support is only

provided for text documents (e.g. program code).

Text ﬁles are merged using a standard line-based diff

and merge approach. Such line-based merging does

not work for scene ﬁles because it would invalidate

their usually complex internal structure. There ex-

ist approaches in software development (Magnusson

et al., 1993) to make use of the structure of programs

within text ﬁles to implement versioning at the ﬁner-

grained level of functions, i.e. not just at the ﬁle level.

Yet such approaches do not translate directly to 3D

scenes because program code is inherently text- and

line-based while scenes of standard DCC tools usu-

ally are coded in a proprietary binary format.

The graphics database system GSCOPE (Collison

and Bieri, 2000) implements versioning at the scene

259

Ammon L. and Bieri H. (2006).

COLLABORATION ON SCENE GRAPH BASED 3D DATA.

In Proceedings of the First International Conference on Computer Graphics Theory and Applications, pages 259-266

DOI: 10.5220/0001357602590266

 SciTePress

graph object level. But it focusses on reuse of 3D

models rather than on collaboration on them. There is

no support for the merging of changes that different

artists have made to a scene in parallel. Another ap-

proach to add versioning support to CAD/CASE data-

bases (Wieczerzycki and Rykowski, 1994) extends

the database version approach by a merge transac-

tion that merges database versions by object compar-

ison. But it focusses rather on extending the version-

ing model and does neither really detail scene graph

and change representations nor conﬂict resolution and

scene consistency.

There exist systems, like Scene-Graph-As-Bus

(Zeleznik et al., 2000), blue-c (Naef et al., 2003),

Mu3D (Galli and Luo, 2000) and Distributed Open

Inventor (Hesina et al., 1999), that directly operate on

the internal structure of a scene to implement a ﬁne-

grained and immediate kind of collaboration. These

systems provide a single distributed scene graph that

usually is replicated on each collaborator’s system.

Changes made to the scene graph by one collabora-

tor are immediately propagated to the replicated scene

graphs of the other collaborators. Objects worked on

by one collaborator are locked for all other collabora-

tors to ensure scene consistency. Because collabora-

tors always share the same instance of the distributed

scene graph, such systems do not have to implement

the merging of scene graphs.

Distributed scene graph systems usually form the

basis for collaboration in virtual reality environments.

But they are not well suited for enabling collabora-

tion between users of standard DCC tools, because

such tools use their own proprietary scene graphs that

were not designed to get distributed. Also their scene

graph APIs tend to hide internal structures and were

not meant to support efﬁcient scene graph replication

and synchronization. In addition, distributed scene

graph systems need all collaborators to be connected

by a common high speed network.

Because there exists always only one instance of

the distributed scene graph, collaboration is immedi-

ate. Artists are not able to privately evaluate different

experimental designs before making an initial version

of their design known to the other artists. Therefore

some collaborators possibly base their work on a de-

sign that might still change heavily.

In the following sections we shall present a system

that supports ﬁne-grained collaboration on scenes of

standard 3D DCC tools. It enables collaboration on

the scene graph at the object level, as opposed to the

coarse reference ﬁle level. Several artists can work on

the same scene in parallel without locking out each

other. Because of that, dynamic work assignments

become possible. The artists’ changes to a scene

are regularly merged to make sure that all artists can

see each other’s progress and collaborate on current

data. Artists may work privately on a scene and make

their results public only when they are really ready.

Merging is carried out automatically if there arise no

conﬂicts between the artists’ different changes to the

scene. In addition, we present a number of strate-

gies for automatic conﬂict resolution. The effects that

local changes may have on a scene as a whole are

tracked, and possible consistency problems caused by

side effects of these changes are registered as indirect

conﬂicts and are brought to the artists’ attention. We

give a practical example for the collaboration made

possible among artists by our system by discussing

its application to the development of a 3D model of

the old part of the city of Bern. Finally, we list some

conclusions.

2 COLLABORATIVE VERSIONS

To enable several artists to work collaboratively on a

single 3D scene, we adopt the concept of collabora-

tive versions which is widely and successfully used in

software development. We only give a short overview

here and then concentrate on the critical points when

applying this concept to enable collaboration on scene

graph based data created by common 3D DCC tools.

Key elements of our concept are a repository for stor-

ing scenes, the versioning of scenes, and the auto-

matic merging of scenes.

working copy

of artist A

working copy

of artist B

repository

check-out check-out

check-in

merge

check-in

DCC toolDCC tool

Figure 1: Collaborative versions.

Figure 1 illustrates how two artists A and B work

in parallel on a scene S. Artist A starts working on

S by checking-out the scene from the repository to a

private local working copy S

on his

∗

system. This

check-out operation does not put a lock on the scene

S. Therefore artist B is also allowed to check-out the

scene S from the repository to a local working copy

on his system, and the same holds for any other

artist. Both artists now make changes to their local

∗

Here and in the following “he” stands also for “she”.

GRAPP 2006 - COMPUTER GRAPHICS THEORY AND APPLICATIONS

260

working copies of the scene using a standard DCC

tool. When artist A ﬁnishes his work or a consistent

piece of it, he wants to make his changes to S avail-

able to the other artists. To do so he simply checks

his local working copy back into the repository. The

repository registers the changes artist A made to S

and stores his scene as the new current version S

S. In the meantime, artist B is also satisﬁed with the

changes he made to S and wants to make them public

by checking his private working copy back into the

repository. Of course, the current version of S is no

longer the version artist B checked-out, but equal to

the version S

which artist A recently checked-in. In

order not to get lost, the changes artist A made to S

must be merged with the changes artist B wants to

check-in. The result is the now current version S

of the scene. If both artists made changes to differ-

ent parts of the scene, these changes can usually be

merged automatically. If there arise conﬂicts, they

must be resolved either automatically by the reposi-

tory or manually by the artists involved. Even if some

changes by artist B were dropped during conﬂict res-

olution, they would not be lost, because before the

merging takes place, artist B’s working copy S



checked-in to the repository as an alternative version

to what artist A checked-in earlier. So the whole

work of artist B can be reviewed again at any time if

necessary.

Obviously the merging of different scene versions

is the critical point of the concept of collaborative ver-

sions. Standard revision control systems, like CVS,

ClearCase, Perforce, etc., are not able to automati-

cally merge 3D scene ﬁles because they are special-

ized in line-based diff and merge of text ﬁles and can-

not handle the usually proprietary binary formats of

3D scene ﬁles. Such tools can detect bitwise changes

but do not know how to interpret them and thus are not

able to merge such changes to form a valid 3D scene

again. Therefore, to implement the concept of collab-

orative versions, a repository must know the internal

structure of scenes and be able to interpret the changes

that are applied to them. Fortunately, 3D DCC tools

share an important common concept for managing

scene data, i.e. the scene graph. That allows us to de-

velop a repository system enabling collaboration on

scenes originating not only from one special 3D DCC

tool, but also on scenes coming from the other tools.

What is needed is a general scene graph model being

able to hold the scene graphs coming from the differ-

ent 3D DCC tools.

3 ATTRIBUTED SCENE GRAPHS

Text books usually deﬁne scene graphs to be directed

acyclic graphs (DAG) that model the composition

and transformation hierarchy of a scene. However,

3D DCC tools normally use a more sophisticated

kind of scene graph, as a careful analysis of Alias

Maya, discreet 3ds max, Softimage XSI, Open Per-

former, VRML, X3D, Java 3D, OpenSG and Open

Scene Graph shows. Usually there is a DAG part

that models hierarchical relationships between scene

graph nodes, but in addition there exist also many

other relationships between nodes which usually ex-

press some kinds of constraints that do not explicitly

form an acyclic graph. Such additional relationships

occur in different forms (e.g. as routes in VRML, as

dependencies in Maya, as references in 3ds max) and

are implemented in different ways (e.g. by explicitly

connecting attributes of scene graph nodes or by using

general message passing between nodes). A general

scene graph model must, of course, be able to model

such additional relationships between nodes. To do

so, we opted for an attributed scene graph model as it

is shown in a simpliﬁed UML diagram in Figure 2.

Node

0..n

child {may be ordered}

{acyclic}

parent {may be ordered}

dependant

0..n

depends on {cyclic}®

ruler

0..n

Attribute

0..n

Dependency

0..1

dependant

0..n

ruler

0..1

Figure 2: The attributed scene graph model.

This model centers around nodes that may have

an arbitrary number of attributes of different types to

store data. Every node has a unique identiﬁer and

a type. Node attributes are identiﬁed by names. A

node can be connected to an arbitrary number of child

and/or parent nodes. The latter enables nodes to be

shared in a scene graph’s composition hierarchy, a

feature that not all 3D DCC tools provide. A node’s

children and parents may be ordered. To order child

nodes is e.g. needed for the so-called switch nodes.

There are no cycles allowed in the parent-child hier-

archy, i.e. this part of the attributed scene graph model

corresponds to the classic DAG structure.

The cyclic part of our model provides dependency

relationships to express that one node depends on an-

other one (e.g. because it needs to access the other

node’s data or adapt itself to certain changes of the

other node). Dependencies bear a description and

may reference attributes of nodes. This feature allows

us to easily map scene graph models that have been

designed or inﬂuenced by Silicon Graphics − and

therefore use some kind of routes − to our attributed

scene graph model.

We have formally deﬁned our attributed scene

graph model in an XML schema which allows us to

COLLABORATION ON SCENE GRAPH BASED 3D DATA

261

code and exchange such scene graphs as XML ﬁles.

We did not use an existing XML based digital asset

exchange solution, like COLLADA (Barnes, 2005),

because these tend to concentrate on aspects that are

less important to our application purpose, like e.g.

ﬁnding common ways to represent graphical and ani-

mation primitives. Our main focus is not on the scene

content’s detailed representation but on its structure

and dependencies. We also need a scene’s mapping to

our general scene graph model to be absolutely loss-

less, which exchange formats usually do not provide:

Creating a scene with a 3D DCC tool, exporting it

into an exchange format ﬁle and then reimporting the

ﬁle into the DCC tool, usually does not yield exactly

the same scene graph, but only a scene that looks the

same. The next section will explain how the attributed

scene graph model ﬁts into the overall architecture of

our system.

4 SYSTEM ARCHITECTURE

The central part in our system is the scene graph

repository server which provides operations for man-

aging and versioning scenes in the attributed scene

graph model. The actual scene data is stored in a

database using an OODBMS, but a graph-oriented

database systems, like GRAS (Kiesel et al., 1995),

would also be a suitable choice. Artists access the

scene graph repository through plug-ins for their DCC

tools. The following example demonstrates how

scene graph data “ﬂows” through the repository sys-

tem’s architecture which is shown in Figure 3.

Let us assume that a Maya artist has created a new

3D scene and wants to store it in the scene graph

repository. He does so by invoking the check-in oper-

ation of the attributed scene graph (ASG) plug-in for

Maya. This plug-in traverses the Maya scene graph

and maps it losslessly to an attributed scene graph

which is encoded in XML and sent to the scene graph

repository. The repository server parses the XML data

into its own attributed scene graph implementation,

registers a new version for the scene and stores it in

the database. If the artist later wants to make changes

to his scene, he uses the Maya plug-in to query the

scene graph repository for the scene and then invokes

the check-out operation. The repository server reads

the scene from its database and encodes its attributed

scene graph data in XML and sends the XML data to

the Maya plug-in. The plug-in parses the XML data

and recreates exactly the same Maya scene graph that

was checked-in by the artist before.

The same processes hold for any other supported

DCC tool, because application speciﬁc tasks (e.g.

encoding losslessly the complete application scene

graph into ASG XML data) are encapsulated into the

corresponding ASG plug-ins. With scene description

languages, like VRML, no plug-in is needed, as the

scene graph data can be directly parsed from a scene

ﬁle. Checking-out or -in scenes that have not been

worked on in parallel by different artists mainly in-

volves the mapping of application scene graphs to at-

tributed scene graphs and vice versa, but not the key

operation of the collaborative versions concept, i.e.

the merging of scenes. In the next sections we show

how to realize this key operation.

5 MERGING

Merging two versions S

and S

of a scene S that has

been modiﬁed in parallel by artists A and B means

combining the changes of both artists into one new

scene version S

. To do so it is essential to know all

changes C

and C

that artist A and B have applied

to the scene S. The merging of the two scenes S

and S

can then be reduced to the merging of the so-

called change sets C

and C

into a single change

set C

. The merged scene S

results from applying

all changes in C

to S. We show now how change

sets can be determined.

5.1 Change Sets

There are two different approaches to track scene

changes, i.e. state-based and operation-based. To de-

termine operation-based changes, a plug-in for every

DCC tool would have to record all the tool’s oper-

ations on a scene as an artist is modifying it. Un-

fortunately, detailed monitoring of operations is not

supported by all DCC tools. In addition, working

with operation-based changes requires the necessary

recording plug-ins to be installed. If an external artist,

who does not have such a plug-in installed, is handed

over a scene from the repository to work on, it is difﬁ-

cult to later incorporate his modiﬁcations to the scene

into the scene graph repository because of the miss-

ing set of changes. Therefore we use a state-based

approach.

To determine changes between two scene versions,

their attributed scene graphs are compared node by

node and changes in state are collected into a change

set. As mentioned before, every node has a unique

ID, and node attributes are identiﬁed by names. This

allows us to reliably and efﬁciently ﬁnd the corre-

sponding nodes and attributes that have to be com-

pared between two attributed scene graphs. Without

node IDs, corresponding nodes would have to be de-

duced from the scene graph structure alone, which is

a costly and error prone task as related work (Cob

ena

et al., 2002) shows that deals with the comparison of

hierarchical XML data. The following list shows the

GRAPP 2006 - COMPUTER GRAPHICS THEORY AND APPLICATIONS

262

Queries

Check-in/-out

Update

Revision Control

Converters

etc.

Operations

Scene Graph Repository

Server

Clients

Conversion

from/to XML

Data Model

Attributed

Scene Graph

Versioning

Change Sets

DBMS

DCC Tools

3ds max

Maya

VRML/X3D

Conversion from/to ASG

ASG-

Plug-in

ASG in XML

write

read

check-out

check-in

Figure 3: Architecture of the scene graph repository system.

types of changes we determine when comparing two

attributed scene graphs:

• AddNode, DeleteNode

• AddAttribute, RemoveAttribute

• SetAttribute

• AddDependency, RemoveDependency

• AddHierarchy, RemoveHierarchy, ReoderChil-

dren, ReorderParents

Each change affects a speciﬁc node and possibly

a speciﬁc attribute (e.g. an AddNode change only

affects a node whereas a SetAttribute change also

affects an attribute). After having determined the

change sets C

and C

, merging can be easily done

by building their union C

= C

∪ C

, but only

if there occur no changes in C

and C

that conﬂict

with each other. How to detect conﬂicting changes

will be explained in the next section.

5.2 Conﬂict Detection

For the detection of conﬂicts we set up a conﬂict de-

tection matrix with the change types listed above as

labels for both the rows and the columns. Each matrix

position holds a Boolean expression whose arguments

are expressed using the change types of the corre-

sponding row and column. If such an expression eval-

uates to “true” for two changes, these changes conﬂict

with each other. Evaluating such a conﬂict detection

expression for each possible change pair would be

rather inefﬁcient. Fortunately it is sufﬁcient to only

evaluate changes that affect the same node, because

changes that affect different nodes obviously cannot

directly conﬂict with each other.

Conﬂict detection may be implemented at the node

level or ﬁner at the attribute level. In the ﬁrst case,

changes from two different change sets conﬂict with

each other if they affect the same node and are not

identical. This leads to a simple conﬂict detection ma-

trix containing simple expressions. For every change

pair it is sufﬁcient to only check the IDs of the nodes

affected by its changes. But such a conservative

scheme may report two changes as conﬂicting that ac-

tually are compatible. E.g. modifying a node’s posi-

tion attributes and adding an additional child to that

node hardly conﬂict with each other.

The second form of conﬂict detection works at the

attribute level and demands more complicated conﬂict

detection matrices. Of course, if two changes try to

set the same node attribute using different values they

always conﬂict with each other. Yet in some other

cases, actual conﬂicts may depend on special proper-

ties of the DCC tool’s scene graph. For a DCC tool

that allows node attributes to have a fan-in of depen-

dencies, two changes adding dependencies which af-

fect the same node attribute do not conﬂict with each

other, but for a DCC tool that forbids such fan-ins they

do. If such properties are global to a DCC tool’s scene

graph they can be directly encoded in the correspond-

ing conﬂict detection matrix’ expressions. But if these

properties are local to nodes and their attributes, they

have to be encoded in the node types, and this infor-

mation has then to be taken into account by the corre-

sponding expressions in the conﬂict detection matrix.

By adding more information to the node type de-

scriptions and more complexity to the conﬂict de-

tection matrix expressions, conﬂicts can be detected

more precisely, but to do so the DCC tool’s scene

graph model has to be analyzed ﬁrst. Therefore when

making a new DCC tool’s scene graph known to the

repository it is reasonable to start with a node based

conﬂict detection matrix and then reﬁne it for cases

where conﬂicts have been detected too pessimisti-

cally.

5.3 Conﬂict Resolution

Merging two change sets C

and C

by building their

union C

= C

∪ C

is not possible if there are

changes c

∈ C

and c

∈ C

that conﬂict with

each other. Essentially there is only one way to re-

solve such a conﬂict, i.e. either c

or c

has to be

dropped. Therefore, resolving conﬂicts means choos-

ing from conﬂicting changes those to be kept and

those to be dropped.

When an artist checks-in his local working copy to

COLLABORATION ON SCENE GRAPH BASED 3D DATA

263

the repository and his changes must be merged with

another artist’s changes, his complete working copy

is ﬁrst registered as a new alternative scene version

before the merging takes place. This makes sure that

the artist’s changes cannot get lost and that changes

that were dropped during the merging can later be

selected and ported to another scene version, if re-

quired. This feature allows us to establish aggressive

automatic merging policies.

If there is a strict hierarchy deﬁned among the

artists, a reasonable automatic merging policy con-

sists in always dropping changes by a junior artist

that conﬂict with changes by a senior artist. If re-

quired, the senior artist may still port some of the

junior artist’s changes later to the current version of

the scene. If the artists are collaborating peers, the

artist checking-in his local working copy of a scene

to the repository may be given the opportunity to de-

cide himself if his conﬂicting changes should override

other artists’ changes or should be overridden them-

selves. Of course, artists may also analyze their con-

ﬂicting changes together and choose the changes to

keep or drop on a per conﬂict basis.

More advanced conﬂict resolution does not only in-

volve discarding changes which conﬂict with other

changes, but also changes that relate to conﬂicting

changes. If conﬂicts have been found in a certain part

of a scene, an artist sometimes does not only want to

make sure that his changes override other conﬂicting

changes in that part but also that the part as a whole

remains exactly the same as in his version. Therefore,

while checking-in a scene, an artist may specify a sub-

graph of the scene where only his changes are taken

into account and where changes from other artists to

this subgraph are dropped.

At the end of the conﬂict resolution process results

the merged change set C

containing changes from

that do not conﬂict with changes from C

and

vice versa. Changes in C

and in C

but not in C

are not lost and can still be applied later to a selected

scene version if required.

5.4 Indirect Conﬂicts

Even if artists A and B make only changes to a scene

that do not conﬂict, their changes might still not be

consistent. We illustrate this by giving a simple exam-

ple for such inconsistent collaborative scene changes

in Figure 4. It shows a scene graph (a) that groups two

rectangles to model the character T in the scene S (b).

Obviously there occurs a problem, i.e. a small gap

arises between the two rectangles. Let us assume that

artists A and B both close this gap within collabora-

tive versions. To do so, artist A extends the vertical

rectangle as shown in (c), and artist B extends the hor-

izontal rectangle as shown in (d). Because both artists

only modify different nodes, merging their collabora-

tive versions S

and S

into S

does not yield any

conﬂicts, yet S

does not look right as it is shown in

(e): The gap between the rectangles in S has disap-

peared, but they now overlap in S

The problem just shown is an illustration of what

we call indirect changes. The group node in (a) aggre-

gates the two rectangle nodes and therefore depends

on them. Changing one of the group node’s children

indirectly also changes the group node itself. More

generally, a change to a scene graph node indirectly

changes all nodes that depend on it, i.e. by propaga-

tion of indirect changes along hierarchy and depen-

dency relationships.

An indirect change affects a node and possibly also

a node attribute. Indirect changes introduced by hi-

erarchy relationships only affect nodes whereas indi-

rect changes introduced by dependency relationships

may also affect node attributes for attribute dependen-

cies. Indirect changes can be computed recursively:

A change or indirect change that affects a node in-

troduces an additional indirect change for every node

that depends on that node by hierarchy or depen-

dency. Because of possible cycles in dependency re-

lationships, care must be taken when computing in-

direct changes. Every indirect change includes a root

change where it originates from and knows its preced-

ing indirect change if there is one.

Computing all indirect changes for all direct

changes c ∈ C

that artist A applied to S yields the

set I

of all changes artist A made indirectly. When

merging the two change sets C

and C

, not only

direct conﬂicts but also indirect conﬂicts can now be

detected. If an indirect change i

∈ I

affects the

same node as an indirect change i

∈ I

, and i

and i

originate from different root changes, the two

indirect changes conﬂict. That is exactly what hap-

pens at the group node in Figure 4 and leads to the

overlapping rectangles in (e). Indirect conﬂicts iden-

tify nodes where the effects of different changes from

artists A and B meet. For the group node in (e) these

changes are the extensions of the vertical and horizon-

tal rectangles caused by A and B.

If an indirect conﬂict has been detected in a node

it propagates along dependency and especially hierar-

chy relationships. Such propagated indirect conﬂicts

are only of limited interest because they are just a

manifestation of an indirect conﬂict that has already

occurred deeper within the scene graph. Therefore

we only consider indirect conﬂicts in nodes where the

changes from artists A and B meet for the ﬁrst time.

For indirect changes i

∈ I

and i

∈ I

affect-

ing the same node n, no indirect conﬂict is registered

if both their preceding indirect changes have already

affected the same node m.

Detecting indirect conﬂicts allows us to systemati-

cally check the effects that collaborative changes have

on each other and to track down unexpected side ef-

GRAPP 2006 - COMPUTER GRAPHICS THEORY AND APPLICATIONS

264

group node

primitives

scene graph

(a) (b) (c) (d) (e)

Figure 4: An indirect conﬂict resulting in overlapping rectangles.

fects of changes that may not have been taken into ac-

count by the artists. Therefore, inspecting nodes with

indirect conﬂicts helps ensuring a scene’s consistency.

If the indirect conﬂict in the group node of the scene

in Figure 4 had been reviewed by an artist, the

overlapping problem would have been identiﬁed and

could have been ﬁxed.

To bring possible problems caused by indirect

changes to an an artist’s attention, nodes with indirect

conﬂicts must be isolated in the scene and, if possi-

ble, be visually presented to the reviewing artist. If an

artist detects a problem, the root changes of the con-

ﬂicting indirect changes can be consulted in order to

ﬁgure out what went wrong. Indirect conﬂicts result

from the effects that changes by two different artists

have on a scene graph. Therefore resolving indirect

conﬂicts is similar to resolving direct conﬂicts: If the

indirect changes i

∈ I

and i

∈ I

conﬂict with

each other, either the root change of i

or that of i

has to be dropped to resolve this indirect conﬂict. Yet

an artist may also prefer not to deal with changes at

all and to directly ﬁx a problem in the scene where the

indirect conﬂict has occurred.

Of course, not all indirect conﬂicts lead to a prob-

lem that needs to be addressed; in fact, most indirect

conﬂicts will not. Inspecting indirect conﬂicts is just a

way to systematically and purposefully look for pos-

sible problems at the right places, as opposed to ran-

domly scanning the whole scene.

For every indirect conﬂict we register the distances

from the originating root change nodes to the node

where the indirect changes meet in a conﬂict. The

reason is that we assume that local indirect conﬂicts,

whose causing root changes are not far away, are more

likely to identify problems than rather global indirect

conﬂicts, whose causing root changes are spread far

away in different parts of the scene graph. This makes

it possible to ﬁrst review indirect conﬂicts that are

more likely to be critical.

Computing indirect changes and detecting indirect

conﬂicts are only possible because of the underlying

general attributed scene graph model which makes the

exact structure of a scene known to the scene graph

repository. In addition to the hierarchy and depen-

dency relationships between nodes, also internal at-

tribute dependencies of nodes have to be taken into

consideration. Such internal dependencies are deﬁned

within the node types.

6 A PRACTICAL EXAMPLE

The authors’ research group is currently developing a

3D model of the old part of the city of Bern. A pro-

totype version of the scene graph repository system

has been applied to this model, and its capability to

enable collaboration could be successfully tested.

To be able to model all the buildings needed in rea-

sonable time a special plug-in for Maya has been de-

veloped (Zaugg, 2005). It allows us to automatically

construct a building typical for the city of Bern from

a building’s ground plan and from some additional

parameters that are directly attached as attributes to

its ground plan polygons in Maya. Historically im-

portant or complex buildings, like towers, churches,

fountains, etc., have to be manually modeled in Maya

from scratch.

There are several people involved in building this

city model. One modeler acquires ground plan poly-

gons and deﬁnes the rough parameters for the houses

to be built upon them. Another modeler erects houses

from the ground plan polygons using the special

building plug-in and ﬁne-tunes their parameters to

achieve a consistent overall appearance of the city.

Some of the ground plan polygons correspond to

those important buildings that need to be manually

modeled in detail by additional modelers. Yet an-

other modeler decorates buildings with advertisement

signs, ﬂowers, etc. to add further “realism” to the city

model.

All these modelers can work in parallel on the same

model without locking out each other. Each time

they check-in or update their scene they can see what

their collaborating modelers added or changed and

can adapt their own work accordingly. This helps to

ensure an overall consistent appearance of the model

and to sort out different opinions on aspects of the

model as early as possible.

A modeler of a historical building can create his

COLLABORATION ON SCENE GRAPH BASED 3D DATA

265

model directly within the city model, which allows

him to adjust his model to the surrounding buildings

at the time he creates it. If he needs to change some

of the surrounding buildings to ﬁt in his model cor-

rectly, he can do so immediately in his own scene and

does not have to search for and to open the reference

ﬁle which contains the buildings he wants to change.

Therefore he will also not run into the problem that

a speciﬁc reference ﬁle might already be in use by

someone else and is not available for him to work on.

Detection and resolution of conﬂicting changes by

the repository system during the check-in of scenes

keeps the city model in a clean state. In addition, the

detection and inspection of indirect conﬂicts helps to

keep the city model consistent. If two modelers have

accidentally decorated the same building this would

result in an indirect conﬂict in the affected building.

During a check-in or an update this indirect conﬂict

would be brought to the modelers’ attention and the

problem could be ﬁxed.

7 CONCLUSIONS

Today’s professional 3D digital content creation tools

only offer limited support for several artists to work

collaboratively on a 3D scene, and also standard

group authoring tools are only of limited assistance,

because they are not able to merge collaborative

changes made to 3D scenes. To make the merging

of 3D scenes possible we have presented an attributed

scene graph model that is general enough to handle

scene graphs of different DCC tools.

We have also presented a scene graph reposi-

tory system that enables ﬁne-grained collaboration on

scenes of standard 3D DCC tools by implementing

the concept of collaborative versions. Artists can now

work on the same scene in parallel without locking

out each other. The artists’ changes to a scene are reg-

ularly merged to make sure that all artists can see each

other’s progress and can collaborate on current data.

We have reduced the merging of scenes to the merg-

ing of state-based change sets and have shown how to

detect and resolve conﬂicts between such change sets

using different conﬂict resolution policies.

We have also introduced the concept of indirect

changes and indirect conﬂicts which help maintain-

ing scene consistency by systematically looking for

inconsistencies at the right places. Computing indi-

rect conﬂicts is based on our attributed scene graph

model’s capability to depict detailed dependencies be-

tween nodes.

Our approach has been implemented in a proto-

type scene graph repository server in Java and a Maya

ASG plug-in in C++. We have successfully tested our

prototype implementation by applying it to our model

of the old part of the city of Bern. Merging different

versions of a city model Maya scene, which is about

50 MB in size, by applying an automatic conﬂict res-

olution policy takes less than 15 seconds on a today’s

standard PC.

REFERENCES

Alienbrain (2005). Alienbrain studio 7. http://www.

alienbrain.com.

Barnes, M. (2005). Collada, digital asset schema release

1.3.0, speciﬁcation. http://www.collada.org.

Cob

ena, G., Abiteboul, S., and Marian, A. (2002). Detect-

ing changes in XML documents. In Proceedings of

the 18th International Conference on Data Engineer-

ing (ICDE’02), pages 41–52. IEEE.

Collison, A. and Bieri, H. (2000). A component-based sys-

tem for storing and manipulating graphics objects of

different representations. In The Visual Computer,

volume 16(6), pages 322–338. Springer.

Galli, R. and Luo, Y. (2000). Mu3d: a causal consistency

protocol for a collaborative vrml editor. In VRML ’00:

Proceedings of the ﬁfth symposium on virtual real-

ity modeling language (Web3D-VRML), pages 53–62,

New York, NY, USA. ACM Press.

Hesina, G., Schmalstieg, D., Fuhrmann, A. L., and Purgath-

ofer, W. (1999). Distributed open inventor: a practical

approach to distributed 3d graphics. In VRST, pages

74–81.

Kiesel, N., Sch

urr, A., and Westfechtel, B. (1995). Gras,

a graph-oriented (software) engineering database sys-

tem. Information Systems, 20(1):21–51.

Magnusson, B., Asklund, U., and Min

or, S. (1993). Fine-

grained revision control for collaborative software de-

velopment. In Proceedings of the ﬁrst ACM sympo-

sium on Foundations of software engineering, pages

33–41. ACM Press.

Naef, M., Lamboray, E., Staadt, O., and Gross, M. (2003).

The blue-c distributed scene graph. In Proceedings of

the IPT/EGVE Workshop 2003, pages 125–133.

Wieczerzycki, W. and Rykowski, J. (1994). Version sup-

port for cad/case databases. In Proceedings East/West

Database Workshop, Workshops in Computing, pages

249–260.

Zaugg, M. (2005). Generische Geb

audemodellierung in

Maya. Master Thesis, Institute of Computer Science

and Applied Mathematics, University of Bern.

Zeleznik, B., Holden, L., Capps, M., Abrams, H., and

Miller, T. (2000). Scene-graph-as-bus: Collaboration

between heterogeneous stand-alone 3-D graphical ap-

plications. In Computer Graphics Forum (Eurograph-

ics 2000), volume 19(3).

GRAPP 2006 - COMPUTER GRAPHICS THEORY AND APPLICATIONS

266