Thanks Thomas, your impressions are largely accurate, and the GUI is hardly very useful without a plugin, at this point. If you wanted to draw a parallel, it would be more akin to the rendering GUI in something like maxwell, rather than as its studio application. However, since we are able to build much UI automatically from node definitions, it ends up having quite a bit more functionality, and may fall in a place where it is easy to see it as a “lame studio” rather than as a “rendering GUI on steroids”.
Documentation, which I am working on presently, should help with this, since though it is possible to build a working scene (but only using procedural geometries, as you cannot currently construct a mesh), you would have to infer quite a bit about the scene structure to get it working. We are also working on some ready-made scenes for people to load up and play with — and then there is the task (scheduled for after we finish non-coding things and officially release) of adding the capability to import/reference OBJ and such.
All told, I will continue to extend the GUI, but plugins are going to take priority. As you mention, the Bella GUI lacks a 2D node graph surface, but Maya does not, and neither does Rhino, through grasshopper, and so forth. Because of this, our lack of one is deliberate — I have resisted the temptation to write my own yet, and have instead used Bella’s lack of one, to force myself to make the GUI work as comfortably as I can without one, since if I wrote one first, I know it would basically become a crutch, by which I could avoid improving how things work in the base-level auto-generated UI.
I will mention also, that the situation is roughly similar with respect to a custom material-editing UI; the “material editor” we have is also still mostly automatic, and this has forced us to think hard about our node definitions, and to extend the node definition system, to a point where an automatic UI can be passable for normal use. This is important, because such UI is built algorithmically, where the algorithm can be re-used in other contexts, using other GUI frameworks — and this will enable Bella to be more consistent across its plugins.
Regarding the settings, indeed you can have multiple settings; and it goes further than that. The absolute base of the scene model is the global node, which has a list of state nodes, one of which is current at any given time. A state node has references to a settings node, and a world xform. A settings node holds what would otherwise (in the absence of this global/state paradigm) be considered global to the scene, and the world xform defines the root of the visual hierarchy. We are currently using basically none of this machinery — the maya plugin writes one global node, one state, one settings, and one world xform — but it is there, nonetheless, in order to support files containing completely different states.
So, apologies for writing a small book here, but this is the basic rationale underpinning what you currently see, when you look at a Bella plugin, or the Bella GUI.