1 files changed, 26 insertions, 18 deletions

diff --git a/README.md b/README.md
index f0b103d..491761d 100644
--- a/README.md
+++ b/README.md
@@ -20,32 +20,35 @@ educational purposes.
 ### Gfx
 
 The `Gfx` object represents the graphics subsystem and is at the center of the
-library's high-level API. The `Gfx` object exposes a `Render` backend and a
-`Renderer` and allows the caller to create `Scene`s.
+library's high-level API. The `Gfx` object exposes a render backend (`GfxCore`)
+and a `Renderer`, and allows the caller to create `Scene`s.
 
 ### Render Backend
 
-The `Render` backend is a thin abstraction layer over low-level graphics APIs
-like OpenGL or Vulkan. It holds GPU resources such as geometry, textures,
-shaders, etc, and exposes functions to manipulate them.
+The render backend (`GfxCore`) is a thin abstraction layer over low-level
+graphics APIs like OpenGL or Vulkan. It holds GPU resources such as geometry,
+textures, shaders, etc, and exposes functions to manipulate them.
 
-Currently there is only one implementation of the `Render` backend based on
+Currently, there is only one implementation of the render backend based on
 OpenGL.
 
 #### Ownership
 
-The `Render` backend owns all rendering resources: buffers, geometries,
-textures, shaders, etc. Even resources that point to other resources do not own
-those other resources (geometries pointing to buffers).
+The render backend owns all rendering resources: buffers, geometries, textures,
+shaders, etc. Even resources that point to other resources do not own those
+other resources (geometries pointing to buffers).
 
-There is no ownership tracking in the render backend. It is up to the client to
+There is no lifetime tracking in the render backend. It is up to the client to
 manage resource lifetime.
 
+### Low-level Renderer
+
+`ImmRenderer` is a low-level, immediate mode renderer.
+
 ### Scene
 
-A `Scene` encapsulates a scene graph. A scene graph contains the elements that
-make up a scene: nodes, cameras, lights, objects, etc. The current scene graph
-implementation includes:
+A `Scene` graph contains the elements that make up a scene. The current scene
+graph implementation includes:
 
 - Camera
 - Light
@@ -64,7 +67,8 @@ 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):
+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
@@ -76,9 +80,9 @@ glTF 2.0 spec [enforces this](https://github.com/KhronosGroup/glTF/blob/master/s
 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.)
+   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.)
+   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))
@@ -87,10 +91,10 @@ 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.
+   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).
+   you follow?), or any attribute that is derived from its parent(s).
 
 In our case, we stick to strict tree hierarchies.
 
@@ -131,6 +135,10 @@ Code under `util/` provides functionality that need not be in the core part
 of the library (Gfx, render backend, scene or renderer). This includes functions
 to compute irradiance maps, create procedural geometry, etc.
 
+### Memory management
+
+TODO
+
 ## Ideas for Future Work
 
 - Render graphs to allow for custom multi-pass rendering algorithms.