1 files changed, 0 insertions, 75 deletions

diff --git a/gfx/include/gfx/scene/README.md b/gfx/include/gfx/scene/README.md
deleted file mode 100644
index c8cdadb..0000000
--- a/gfx/include/gfx/scene/README.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# Scene Graph
-
-A scene graph implementation that includes:
-
-- Camera
-- Light
-- Material
-- Mesh
-- Node
-- Object
-- Scene
-
-## 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
-not a more general DAG. Given this, and to avoid confusion, we instead expose
-functions to set the parent node of an object/camera/light. If we exposed the
-former, the API could create the illusion that the hierarchy can be a DAG.
-
-The strict tree hierarchy should not be that restrictive in practice. Even the
-glTF 2.0 spec [enforces this](https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#nodes-and-hierarchy):
-
-> *For Version 2.0 conformance, the glTF node hierarchy is not a directed
-> 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)