Blender Node API, what do we want?

[Lord Crc]

So, I was contacted by Lukas Tönne, a Blender dev, who started working on a Node API for Blender back in December.

I'll quote what he said:

Code: Select all

<lukas_t> hey :)
<lukas_t> DingTo pointed me at the BA luxrender/cycles/render API/custom nodes discussion yesterday ;)
<lukas_t> i had put the custom node project on ice a few weeks back, but seeing the demand growing makes me want to pick it up again
<lukas_t> part of the problem with the code was that it was simply too broad and unfocused
<lukas_t> but i think i have a better idea of what can be done with reasonable effort and without breaking too much glass
<lukas_t> i need to set some tangible goals (which will also make funding from blender dev fund possible :D)
<lukas_t> and luxrender devs and users are probably a good source of suggestions and feedback :)
<lukas_t> also the vfx guys (big topic atm of course)

The discussion he refers to is here, and spans a few pages.

I've also been talking with the Yafaray developers, who also would like to be able to create custom nodes in Blender for their exporter.

So, I was thinking if we can figure out what we "need" from a Node API, and then coordinate with the Yafaray guys to find some common feature set which is essential for us both, then we have a much greater chance of getting this implemented.

Now, I've not used the node stuff in Blender much yet, so I'd like some feedback from you blender pros in terms of workflow. I think initially it's best if we aim for workflow and highlevel features to present to Lukas, and take it from there.

[A-man]

I'd suggest something similar to the current workflow for the cycles material nodes. Input nodes would set up the shader type (glass / diffuse / metal / etc) which would go to the output node on a per object basis. On the input nodes you would enter in parameters like color/specularity and whatnot. In between the input and output nodes would be space to modify those parameters like texture inputs to affect the material's parameters. I'm a little busy, but I'll try and whip up a picture with the current nodes to get the just of what I'm saying.

[J the Ninja]

For those who haven't worked with Cycles before, here's a really simple node setup for a matte red surface:

The material output node represents the final result of that Blender mat, and the diffuse bsdf node gives the surface its properties. It has sockets on it for textures.

In Lux, a mesh has several different shaders, surface, interior, exterior, and emission. The way this maps out in Blender is that each Blender material acts as a group of all 4 shaders, so I figure the material output node would represent that. Cycles adds two types of material nodes, "shaders" and "textures". What I would propose doing would be to add 4 for Lux: "surface shader", "volume shader", "emission shader", and "texture". For surface, those would be the normal mat types, matte, glossy, metal2, etc. Volume shaders would be a "clear" and a "homogeneous" node (with exponential/cloud/whatever nodes as we need them ). Emission nodes would just have one node called "emission". Kinda awkward, but I can't think of a better way of doing it with the way Blender's node editor is set up. Then there would be a texture node type for all of our texture types.

So given that, I made some quick mockups in Illustrator so you can visualize how the node graph would flow. Here's the Lux version of that red matte material:

node-mockup-matte-01.png (11.3 KiB) Viewed 1508 times

And here's some glass2 beer with measured absorption from the file delicious_beer.dat:

EDIT: Forgot cycles screenshot

[J the Ninja]

So for what we need to accomplish that:

-The need to define our own nodes (duh) and which groups they are part of in the "add node" menu. These should only appear when Lux is the active render engine. For reference, see how the "shader" and "texture" groups are added to material nodes when Cycles is selected
-The ability to define custom input/output types (we would need: color texture, float texture, fresnel texture, surface shader, volume shader, and emission shader)

[B.Y.O.B.]

Btw. I think it would be cool if the "old" system could still remain besides of the nodes (like it is in Cycles atm). When you are really working some things are very faster to accomplish with nodes, but in some other cases the "old" system is faster (like when you just need a glossy material quick - add a material, switch it to glossy).
Nodes are mainly an advantage when building very complex materials (like the ones that were submitted to the Materials & Textures Competition), the "old" system is faster when you just need a simple material.

[J the Ninja]

Btw. I think it would be cool if the "old" system could still remain besides of the nodes (like it is in Cycles atm). When you are really working some things are very faster to accomplish with nodes, but in some other cases the "old" system is faster (like when you just need a glossy material quick - add a material, switch it to glossy).
Nodes are mainly an advantage when building very complex materials (like the ones that were submitted to the Materials & Textures Competition), the "old" system is faster when you just need a simple material.

Honestly, having a "use nodes" button that switches between the current panel UI and node materials using a UI almost identical to the way Cycles does is probably the way things will wind up. Because it's both the best solution and will probably be the simplest to do anyway.

[B.Y.O.B.]

Honestly, having a "use nodes" button that switches between the current panel UI and node materials using a UI almost identical to the way Cycles does is probably the way things will wind up.

Will this button only switch the "use nodes"-state for a single material or for every material globally? What do you think would be better?

[jeanphi]

Hi,

Nice!
To sum up:
- a node is a container of internal properties, inputs and outputs
- each property has a type, a name and eventually a value
- types will include floats, filenames, colors, string, bools, user defined types (with no explicit value)
- inputs can be connected to outputs if and only if the types matches
- it'd be nice to have 2 views for the graph: a node view and a hierarchical list view (that one would provide the current GUI)
- the graph needs to be saved within the blend file

Am I missing something?

Jeanphi

[dougal2]

Screen Shot 2012-02-27 at 6.19.44 PM.png

Compare also with my original prototype diagram

[Carbonflux]

I think a node editor is a great idea. Nodes make things more complex but nodes seem to have emerged as a meme so I think we should switch to them because it makes things more consistent and comfortable for users. Looking at dougal's screen shot, on the left we see a clean compressed display of all the options, on the right we see a psudo flowchart which takes up a lot more space with nice lines connecting them.

I think there is a video which really captures this idea, something I am sure LordCrc will remember: http://www.theonion.com/video/breaking- ... ati,14204/