Sure, you can think of a VFrame as a canvas in the sense that you can attach arbitrary and arbitrarily many shapes to it, but the important part is that everything in that canvas is fixed in that canvas, but the VFrame itself can translate and rotate. A Scene is composed of VFrame's.

Tarun, you have an understanding of what the implementation/internals require (data/json, webgl), and I don't, so you probably have a clearer idea about the distinction between what we decided to call a VisualizationManager and a Scene; I don't see the difference really. But maybe what you're saying is VisualizationManager would be composed of a Scene, and a Scene would be composed of a graph (or in the simple case, a list, which is graph with a depth of 1) of VFrame's. VisualizationManager then could handle the higher-level stuff like data I/O, creating the WebGL window and filling it with the scene, etc.

Jason: It's possible that VFrame is an abstract base class (perhaps using the `abc` package and related decorators). Even if it's not, though, we would not use VFrame's to do our multi-body simulations; we'd use a subclass, MultibodyDynamicsVisualizationFrame (MBDVFrame for short, haha). Similar to what you're saying, the properties of a VFrame would be a Point and a HomogeneousTransform, as well as a Shape or list of Shape's. The properties of a MBDVFrame is either just a RigidBody, or a Particle and a HomogeneousTransform, or something like that. I don't think you should work directly with VFrame when doing simulating multibody systems.

This subclass, MBDVFrame, could only have one RigidBody, but could have an arbitrary number of Shape's. So I agree that VFrame does not have `add_rigidbodies`, but I think `MBDVFrame.rigid_body` exists, and it can only have 1 body. As for "one VFrame per shape", I think I agree but I would word it differently: "VFrame's are composed of Shape's".

It doesn't completely make sense to me how to implement this Shape where a Shape can be a combination of Shape's. If you guys have an idea of how to implement it, that's cool. It would be awesome, though likely superfluous, to combine shapes using boolean operations. ShapeA & ShapeB does an intersection and ShapeA | ShapeB does a union. The use-case for that is probably very small. However, that's the reason I see why you'd want to have this type of Shape class where a Shape is either a single Shape or a combination of Shape's.

What sounds easier to implement, and perhaps easier for the user to use, is if VFrame's just have a list of Shape's.

It would be fantastic if, while we're concurrently writing example use-cases, we had a place to sketch out the classes themselves. I'm going to create a gist right now, though I know that isn't the best place for this (it's easier than pulling pydy-vis =] )