Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of

Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation). For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way. Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.