1 files changed, 49 insertions, 1 deletions

diff --git a/gfx/include/gfx/scene/README.md b/gfx/include/gfx/scene/README.md
index 1910abe..c8cdadb 100644
--- a/gfx/include/gfx/scene/README.md
+++ b/gfx/include/gfx/scene/README.md
@@ -10,7 +10,7 @@ A scene graph implementation that includes:
 - Object
 - Scene
 
-## Hierarchy and parenting
+## Hierarchy and Parenting
 
 Scene graphs typically expose functions on nodes to add/remove objects, cameras,
 lights, etc. This implementation forces the hierarchy to be a strict tree and
@@ -25,3 +25,51 @@ glTF 2.0 spec [enforces this](https://github.com/KhronosGroup/glTF/blob/master/s
 > acyclic graph (DAG) or scene graph, but a disjoint union of strict trees. That
 > is, no node may be a direct descendant of more than one node. This restriction
 > is meant to simplify implementation and facilitate conformance.*
+
+## Instancing
+
+Two use cases for instancing seem to be:
+
+1. Creating N identical clones, but each with a unique transform. (Ex: N
+animated characters animated in unison but located in different locations.)
+2. Creating N copies of a sub-tree, each now being their own unique tree. (Ex:
+The same N animated characters, but each of them now being animated separately.)
+
+Some scene graphs
+([Panda3D](https://docs.panda3d.org/1.10/python/programming/scene-graph/instancing))
+allow two or more nodes to point to the same child, or, in other words, a node
+to have multiple parents. This turns the scene graph into a DAG and adds a
+number of complications for us:
+
+1. Shared ownership of children. We would now need some sort of ref counting or
+deferred GC to delete nodes and their subtrees.
+2. Nodes no longer have a unique parent.
+3. Given a node, we can no longer determine its location (which parent link do
+you follow?), or any attribute that is derived from its parent(s).
+
+In our case, we stick to strict tree hierarchies.
+
+Use case (1), N identical clones with unique transforms, is not a problem for
+us. This is because the bulk of the data -- geometry buffers, etc. -- is stored
+in the render backend anyway. So creating a full copy of the node does not
+present a significant overhead since we need a unique transform for each of the
+clones anyway.
+
+Use case (2) does present a bit more overhead and we currently do not handle it.
+This could be handled in the future by special-casing a node such as
+`InstanceNode` that has one child subtree and N transforms (or other
+attributes), one for each unique instance of that child subtree.
+
+Therefore, to visit the use cases again:
+
+1. N character clones animated in unison in different locations -> future
+   `InstanceNode`.
+2. N unique character copies animated on their own -> copy the character subtree
+   (N unique skeletons; shared mesh data and textures stored in the render
+   backend.)
+
+## Reading
+
+[Panda3D Scene Graph](https://docs.panda3d.org/1.10/python/programming/scene-graph/index)
+
+[Pixar's USD](https://graphics.pixar.com/usd/release/intro.html)