The document presents a 3D revision control framework that uses MongoDB as a central repository to store and retrieve scene graph components and their non-linear revision history. It supports various clients including C++, WebGL, and Android applications. Scene graphs and revision histories are stored as documents in MongoDB collections in a schema that embeds metadata and component data or references binary data. The framework enables collaborative editing of 3D models through version control of hierarchical scene graphs.

1. 3D Revision Control Framework
Jozef Doboš & Anthony Steed

2. 3D Repo framework
 Is an array of clients: [C++, WebGL, Android]
 Uses MongoDB as a repository to store:
 Scene graph components
 Non-linear revision history
 Supports wide range of 3D assets
 Provides powerful 3D Diff tool
 Offers sub-object retrieval

3. Engineering Doctorate
Like PhD but:
• Done in a collaboration with a company (Arup)
• 4 years instead of 3
• Taught courses alongside of research
• Awarded degree of Doctor of Engineering
(EngD)
• Higher stipend :)

4. Introduction
• Collaborative editing and sharing of 3D models

5. Framework overview
 Plain vanilla MongoDB in the centre
 Various clients perform version control at the
application level

6. Scene graph – a tree or a graph?
Scene:
∟Roof
∟Chimneys
∟ Chimney barrels
∟Columns
∟Façade
∟Windows

7. Non-linear revision history

8. Why ?
 NoSQL
 Data stored as binary (BSON)
 DB communication in binary (BSON)
 UUID can be a document identifier
 Geospatial indexing
 Wide language support
 Proven and scalable

9. DB schema considerations
 DB is going to be read-heavy
 Needs to retrieve sub-graphs
 Each project is one DB with collections SG and
RH (holding a DAG each)
 SG has all delta changes as well

10. 3D repository
Scene Graph (SG)
• Directed acyclic graph
• SG node: any scene component
• Metadata = (ID, RH#)
• Used in:
• 3D modelling
• Real-time rendering
Revision History (RH)
• Directed acyclic graph
• RH node: single revision
• Metadata = (ID, RH#)

11. Full tree in a document
 Representation: all in one document
 Insertion: 1 update
 Sub-graph retrieval: load all in memory
 Size limited to 16MB or use GridFS
 Either all 3D data embedded or references

12. Parental or child links
 Representation: immediate parent/child
 Insertion: 1 update
 Sub-graph retrieval: recursive hierarchical
queries
 Can use aggregation framework (but not for
DBRef)

13. Adjacency or incidence matrix
 Representation: connectivity is 2D bool matrix
 Insertion: 1 update
 Sub-graph retrieval: 2 queries if 1 object
 Suitable for directed and undirected graphs
 Sparsely populated most of the time
 Memory management of very large matrices is
difficult

14. Nested sets [Celko 2004]
 Representation: two integers as boundaries
 Insertion: re-indexing of all the nodes
 Sub-graph retrieval: 1 query
 Fixed by using reals as quotients [Hazel 2008]
 Each node has exactly one parent (trees)

15. Array of ancestors or materialized
paths
 Representation: full path from root to node
 Insertion: 1 update if leaf, partial re-indexing
otherwise
 Sub-graph retrieval: 1 query
 Potentially a lot of repetition for graphs

16. Modified materialized paths
 Representation: full path from root to node
 Insertion: 1 update if leaf, partial re-indexing
otherwise
 Sub-graph retrieval: 1 query
 As a context-free grammar:
G = {{S, A},{n, n_root, ɛ}, P, S}
S → [n_root  A]
A → ɛ |n|(A)|A  A | (A V A)

17. Modified materialized paths
  is a parent-child relationship
 V is a logical disjunction

18. Transformation object (SG)
{
"_id" : BinData(3,"JGdmZwYAAAAAAAAAAAAAAQ=="),
"type" : "aiNode",
"revision" : 0,
"path" : [BinData(3,"NSVykEkAAAAAAA")…],
"mName" : "Sphere",
"mNumMeshes" : 1,
"mMeshes" : [0],
"mTransformation" :
[
[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]
]
}

19. Mesh object (SG)
{
"_id" : BinData(3,"dodAEUAAAAAAAAAAAAAAAg=="),
"revision" : 0,
"type" : "aiMesh",
"path" : [BinData(3,"NQaYYQkAAAAAAAAAA")…],
"mName" : "mesh 2",
"index" : 2,
"mPrimitiveTypes" : 4,
"mNumVertices" : 24,
"mVertices" : BinData(0,"AACAwAAAgD8AAIA/…"),
"mNumFaces" : 12,
"facesArraySize" : 48,
"mFaces" : BinData(0,"AwAAAAAAAAABAAAAAg…"),
"mNormals" : BinData(0,"AACAvwAAAAAAAACAAACAv")
}

20. Material object (SG)
{
"_id" : BinData(3,"F1NiSWQAAAAAAAAAAAAAAw=="),
"revision" : 0,
"type" : "aiMaterial",
"path" : [BinData(3,“MKFYHTkAAAAAAAAAA")…],
"AI_MATKEY_NAME" : "Material.004", "index" : 3,
"AI_MATKEY_COLOR_DIFFUSE" : [ 1, 0, 1, 0 ],
"AI_MATKEY_COLOR_SPECULAR" : [ 1, 1, 1, 1 ],
"AI_MATKEY_COLOR_AMBIENT" : [ 1, 0, 0, 0 ],
"AI_MATKEY_SHININESS" : 384.313720703125
}

21. Revision object (RH)
{
"_id" : BinData(3,"l55gEB0OQ5edDjOXHQ4zlw=="),
"revision" : 0,
"author" : "jozef",
"path" : [BinData(3,“OPDMTdAADFAAAAAA")…],
"timestamp" : ISODate("2012-10-30T15:02:09Z"),
"message" : "The very first commit."
}

22. Revision management
Revision retrieval
 Return all the newest SG nodes for a given RH#
Revision commit
 Delta changes as new revision
 Potential conflicts require conflict resolution
Node deletion
 Store NULL in the next revision
 Recursively check children

23. Revision retrieval
Require: revision >= 0 // revision to be retrieved
revisions ← GetSearchSpace(revision)
ids ← DISTINCT(‘id’ in DB) //get all ids
for each id in ids do
list ← FIND(‘id’=id & ‘revision’ in revisions)
← SORT(‘descending’)
← LIMIT(1)
end for
return list

24. Revision retrieval
function() {
var arr = db.nodes.distinct('uuid');
var results = new Array();
for (var i = 0; i $lt arr.length; i++) {
var cursor = db.nodes.find({
'uuid':arr[i],
'revision':{$in: {0:0}}
}).sort({'revision':-1}).limit(1);
results[i] = cursor[0];
}
return results;
}

25. Tier 1 – 3D revision control viewer

26. Tier 1 – 3D revision control viewer

27. Tier 2 – web client
 Driven by JavaScript
 MongoDB Java driver loads BSON from DB
 WebGL renderer displays in web browsers

28. Tier 1 – 3D revision control viewer

29. Tier 1 – 3D revision control viewer

30. Tier 2 – Android client
 Driven by Java
 MongoDB Java driver loads BSON from DB
 OpenGL ES 2.0 renderer displays in mobile
devices

31. Tier 2 – Android client

32. Tier 2 – Android client

33. Discussion
 Interaction via import/export of 3D files
 Files now considered only temporary
representation
 Smallest unit of change is SG node (BSON doc)
 Each SG node can be 16MB max (GridFS?)
 Assume the 3D file to preserve metadata
 Lack of data validation on insertion
 DB gets slower over time

34. Conclusions
 Novel approach to storage and revision control
of 3D assets
 Represented hierarchical scene graphs in
MongoDB
 Preserved associated revision history
 Successfully decoupled modelling from long
term storage

35. References
• CELKO, J. 2004. Joe Celko’s Trees and
Hierarchies in SQL for Smarties. Morgan
Kaufmann, May.
• HAZEL, D. 2008. Using rational numbers to key
nested sets. CoRR abs/0806.3115

36. Sponsors
Arup Foresight
 http://driversofchange.com

UK Engineering and Physical Sciences
Research Council
 http://www.epsrc.ac.uk

UCL Engineering Doctorate Centre in
Virtual Environments, Imaging &
Visualisation
 http://engdveiv.cs.ucl.ac.uk

37. http://3drepo.org

38. • 3D Diff: An Interactive Approach to Mesh
Differencing and Conflict Resolution
• Visualizing 3D Models in Aid of Public
Consultation