Designing a fast material editor with most of the functionality of nodes

Forums Wish List Designing a fast material editor with most of the functionality of nodes

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
  • #2184
    Jeremy HillJeremy Hill

    We can certainly accommodate such behavior, since for example, a single color transform (rgbXform node in bella) can be connected to as many rgb (or other — it can drive scalar inputs as well, for example roughness, through its outMin/Max/Average outputs) inputs as desired.

    The real trick will be exposing this optionally, since in some cases you would like to connect an input to the output of an existing node, while in others you want to create a new node to connect, not potentially sharing with other nodes.

    A common theme I have been developing in the gui so far is that of using CTRL-down to select more advanced or destructive behaviors; for example when you stop a render, whereas the safe action is to wait for the engine to stop and write its output, it may also be that you are a pro-level user, don’t care about the output and just want the engine to abort as quickly as possible; so I have used this CTRL-down model here, such that you get the safe action by default, while also being able to get the advanced/destructive one, without cluttering the gui with extra buttons and such.

    So, we could possibly use some combination of drag & drop, along with holding CTRL, to select the most appropriate action. Furthermore, the node system is rich with information, such that if we apply a little careful thought and design, we can do “smart” things, depending on what is being connected to what.


    Also we could we see a number on top of the map icons to remind us which channel they are in, sometimes that catches me out, esp when the error only has a subtle impact on the material.

    I also want to ask about the efficiency of only having a ‘metal’ bsdf, Would it be better to offer a ‘diffuse’ bsdf (roughness limited from 66-99.9 for example) If that could be made to render quicker it would warrant the added user effort which would be minimal. If this subject is better discussed privately let me know, else I’ll start a thread.

    Jeremy HillJeremy Hill

    Regarding channels, we have quite a bit more flexibility than you may be used to. Everything you render in bella is an instance of some geometry, and each instance may have not only its own material, but its own per-triangle materials, and furthermore, different textures may be associated with different UV sets on each instance. Here is an example:

    There is only one mesh plane here, instanced five times, with different combinations of material, per-triangle material, and per-instance use of UVs.

    Regarding the question of a specialized metal, I think Albert would say that for the lambert case we do have the bella lambert material, while for other cases, the conductor material should already be optimized as well as we (currently) know how to do. And even if not, we would not need a separate type to handle a medium-to-high roughness case, since if a further optimization was possible, we could just detect that the chosen value was in the optmizable range, and have it use a different piece of code.


    To be honest this is all new to me, no idea what it’s for, but the UV thing sounds good.

Viewing 4 posts - 16 through 19 (of 19 total)
  • You must be logged in to reply to this topic.