Bella GUI (as of 2019.10.03)

Forums General Bella GUI (as of 2019.10.03)

Viewing 15 posts - 1 through 15 (of 35 total)
  • Author
  • #2293
    Thomas An.

    Spent about 15 min looking around the GUI.
    (I always approach it from a lowIQ perspective with the premise that if I can’t reason myself around it and requires adaptation, then it is not yet ergonomically intuitive).

    First impressions:

    1. I suspect it is not meant to be used completely stand-alone yet. There is no grid, no viewport navigation, no default camera … and even after instantiating a number of these nodes from scratch (threw in a cube node and a skydome for good measure) nothing really happens and the camera complains about some xform. Basically it is meant to open and read Bella files generated via the plugins
    2. I notice the term “nodes” mentioned a few times in the interface, which brings mental images of grasshopper nodes, or a Blender nodes GUI with boxes and connecting neurons, but all I see is window panes with a heap of items created in them without any clear method to figure out how they interact or how many are needed to create a basic scene to render.
    3. Somehow I ended up with a “settings” and a “settings0” node. Sounds cool. I suspect it allows for multiple setting versions on the same scene to switch back and forth.
    Jeremy Hill

    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.

    Thomas An.

    At first I thought you relying on third party nodes APIs would become a bottleneck in your plugin development, but I didn’t realize how many 3D apps out there actually implement nodes (practically everyone that matters).

    The help menu in Bella sends me to a web page which explains a number of bits and pieces of an elephant to a blind man, but doesn’t explain the shape of the elephant itself. So I am glad you outlined your thoughts here, since initially I was thinking Maxwell studio; just as you guessed. Maybe some of this explanation about the GUI could find itself in the FAQ section at some point (?).

    Right now we are looking at a chassis, but I really like the amount of syllogistic effort you put in the ergonomics and design foundations of your apps. I think automation and simplicity that hides most of the gnarly esoteric detail from the user is the way to go (the opposite of Vray). I would even go as far as hand holding for Industrial designers and add a “studio” environment (next to color-dome and sky-dome) complete with a back drop and three key lights. Industrial designers would want to go from zero-to-render in no time. Despite popular belief I prefer simplicity myself; just slap a material and do “awesome” without having to worry about abbe and snell.

    Heck, with AI these days I wouldn’t be surprised if rendering goes this way:


    maverick render (fryrender) is catering to designers if the hype is believable, I didn’t watch their vids, automated stuff is not my cup of tea..

    Thomas yes I played with that Gaugan once, I fed it my render and painted roughly what I wanted (for the rear of my scene, for reflections) It worked quite well (in theory, reality now is low res 8bit)

    JD, are you planning a layered ui plugin for c4d, or is it only nodes?

    Jeremy Hill

    @thomas — A nodal system may seem like something for the user, but it is just as much for the developers, and there’s no way our small team would stand a chance of making something like bella without it. It affects so much; to create a new node type is just adding some lines in a json file, and using it is even simpler, such that the other guys are able to prototype things, and have UI while they do it, without any need for intervention on my part. Beyond this, the basic principle (from a programming perspective) is that a node represents a pure function, producing outputs based solely on its inputs, with no knowledge of the world outside, which of course tends to produce a more robust system, programming-wise.

    The elephant-view help you accessed is the node definition help file, which was generated on-demand and written to a local HTML file when you clicked the button. What I am writing now is the more conventional documentation, the higher-level view of how the system, and how the GUI works. The node definition help is written by the person defining the node, and allows for every single node and attribute to be documented.

    On your last points, we are beginning to reach the (very fun) point where we can build on the things we’ve previously built, for example with the new simple materials, and we’ll continue on that theme. Bella, right now, has as many wires hanging out the back (or well, out the front 🙂 )as we will ever see — as we proceed, a person will always be able to access those wires if necessary, but by default, we’ll have more and more abstractions built on top, so that it is an optional thing.

    Thomas An.

    User directed visual programming, like nodes, is an intriguing way of doing stuff. Conceptually simple, it allows the users to build their own legos however simple or convoluted they want them without the rigid confinements of traditional paneled UIs (which clutter quickly like a castle with a thousand rooms and takes exponential amounts of UI design to keep them from being confusing).

    node definition help file, which was generated on-demand and written to a local HTML file when you clicked the button

    Dynamically generated stuff are “tight” 🙂
    Reminds me of database design ethic; you change something in one place and is automatically referenced everywhere.

    Jeremy Hill

    Heh, well you should like this system then, as basically everything is dynamically generated. 🙂

    The core scene model is really not even specifically rendering-related; it could just as well be used for about any purpose, as long as you abstained from trying to use any of the 3D-scene-specific convenience functionality. When we were just getting started, there was not yet a file format for defining nodes, so they were defined entirely through code, and it is still possible to do that. I will provide a .NET wrapper (and eventually ruby, python, maybe others), so at some point, maybe you could have some fun dabbling with it, for who-knows-what purpose.

    Even from c++, I am really happy with how the client code ends up looking. Here is a favorite example, where I am reading an older scene file, which contains attributes which have been moved around in the structure; since nodes are defined at runtime, the scene happily reads the outdated node structure, and I then move things to their new locations if necessary:

    // Move old layer["surface"] inputs into layer.
    for ( auto node: scene.nodes( { "layer", "sheet" } ) )
        if ( node.hasInput( "surface", AttrType_Object ) )
            const auto inputs = ds::Vector<String>() =
                "opacity", "roughness", "anisotropy", "rotation", "ior", "coating"
            auto surface = node["surface"];
            for ( auto input: inputs )
                if ( surface.hasInput( input ) )
                    node[input].set( surface[input] );
            node.removeInput( "surface" );

    I like this piece of code, it really shows how simple and expressive the model has ended up (the same fixup took significantly more code in maya). But I’ll stop geeking-out now .. I could go on forever about this stuff. 🙂


    maverick render (fryrender) is catering to designers if the hype is believable, I didn’t watch their vids, automated stuff is not my cup of tea..

    Thomas yes I played with that Gaugan once, I fed it my render and painted roughly what I wanted for the rear of my scene, for reflections. It worked quite well in theory, ofc its only a low res 8bit image.

    JD, are you planning a layered ui plugin for c4d, or is it only nodes?

    Jeremy Hill

    Oh hey sorry Eric, I did not see the question in your post, earlier — I’m not fully sure what you mean by saying layered ui, are you asking whether bella materials, with their layers, will be represented similar to how layered reflectance materials have been done in cinema since R16?

    Thomas An.

    Hallelujah, somebody is finally using the Allman convention. Although I would de-nest the for-loop by negating the if statement
    if ( ! node.hasInput( "surface", AttrType_Object ) ) {continue; }

    Personally, I am into Javascript these days (can’t do without brackets) especially with the advent of nodeJS and web assembly in the works it seems limitless and far reaching. I wonder if JSON would work for creating a file format for nodes

    Thomas An.


    Thomas yes I played with that Gaugan once, I fed it my render and painted roughly what I wanted for the rear of my scene, for reflections. It worked quite well in theory, ofc its only a low res 8bit image.

    If that technology matures, it will melt minds and completely change a lot of paradigms …. that’s an IF.

    Jeremy Hill

    In fact, I did use json for the node definition file format, for example, here is the sphere definition:

        "sphere": {
            "bases": [ "procedural" ],
            "inputs": {
                "radius": {
                    "type": "real",
                    "value": 0.5,
                    "minex": 0,
                    "max": 1e11,
                    "smax": 10,
                    "step": 0.1,
                    "prec": 3,
                    "help": { "en": "The radius of the generated sphere, centered on the local origin." }
            "layout": [
            "help": { "en": "A procedurally-generated sphere." }

    The quoting of everything gets tedious — I’d prefer to write it in javascript instead — but since this has to be consumed from various languages, and since we will want to be able to send it over the network and such, I bit the bullet and went with plain old json (though you can infer from this example, I preprocess it, in order to support comments).

    On code style, the funny thing is that in javascript, and javascript only, I do always put opening braces on the same line, because javascript is insane — for the rationale, see here.

    Thomas An.

    You are right. Those quotes are tedious as hell.
    The thing with javascript is that it’s so flexible and allows people to be slobs and then complain when we have to read each other’s sloppiness. It can be as elegant as the self-imposed coding ethic you will choose to follow. For example you will never catch me start defining anonymous functions in the middle of a function argument list unless it’s an uber sort and straight forward arrow function. A lot of people think the less characters typed across the screen the more readable it must be creating a vertical readability cluster-flap.

    Anyway, I’ll wrap it up here, because if we start geeking out. Nothing will get done 🙂

    Jeremy Hill

    Heh, no doubt, though I am making some headway on the docs. 🙂



    JD, sorry saying ‘layered’ was clumsy, I just meant a regular traditional stack type of UI like maxwell.

    Thomas, yes it’s a big IF, and to be useful for 3D it would be good if the ‘AI’ generated parallax output, with seperate foreground / midground / background plates.

Viewing 15 posts - 1 through 15 (of 35 total)
  • You must be logged in to reply to this topic.