Shading Workflow Feedback

Now that quite a a few people have tested Cycles, it”s time to get some feedback on the workflow. Since the initial commit, there have been changes to texturing workflow and 3d view draw modes. It”s still incomplete, but should give you an idea of where things are going and how it all fits together.

An overview of the planned design can be found here:

Ideally other render engines will use the same system once this is available in trunk, so in those case you would see different nodes and outputs, but the workflow would be roughly the same.

Updated 3D view draw modes

There”s a short explanation per topic and then questions that I”d like to find the answer to. Ideas and mockups for how to improve things are welcome, as well as issues you might have found that I did not address. You can give feedback here in the comments, or on the associated wiki discussion pages.

Recent builds can be found on GraphicAll.org.

Thanks,
Brecht.

57 comments
  1. FREEMND I think you are dead-on in what this needs to be and the workflow. Node based is the way to go and offers immense flexibility. I think a live material preview is certainly a must. having surveyed many of the commercial packages out there and used many professionally, Cycles is a long time coming. It’s good to see new development in this area. Brecht excellent work and I hope you continue to survey the commercial packages and take in to consideration the good feedback you have received so far.

    Gustave-

  2. Agree with Daniel Glenn about a tree view could solve the problem of the properties editor getting unclear with a lot of nodes..

    Maybe some hierarchy lines, like the ones from the outliner, could help to visually organize the info at the properties editor.
    like this, but better!! =D
    http://imageshack.us/photo/my-images/851/hierarchylines.jpg/

    ..this “+” “-” buttons to hide the nodes could help, and there should be also a button to hideAll/showAll nodes. (or maybe shift+click could do that, or show/hide all hierarchy below nodes)

    shift+clicking on a node from the NodeEditor could also highlight the node in the Properties editor?

    I hope you can get the best of all the Brain that we’ve been Storming.

  3. I didn’t read all the post above.

    But I think it would be nice if the user can choose which properties in the node tree will show up in the material property tab.

    In many node system, when you create a macro, group or gizmo..whatever.
    you can create custom parameter for the group node which link to the parameter inside the node tree.

    For now I don’t think blender node group can do that.
    I think this could be a good way to show only the useful information for later adjustment.
    Also the beginner can just download other people’s material node tree and use it right away.

    Finally really appreciate for this great renderer. very efficient and easy to use.

  4. Hi! I don’t know if you have though about this but would be nice to have control over maximum bounces per light-path type (with type I mean: diffuse ray, reflection ray, transmission ray, etc)

    For example, you could make a simple non-GI sky-dome-based lighting setup with 0 diffuse bounces but a couple of reflection bounces for glossy materials (currently, glossy materials with 0 bounces is a mess)

    Or you could limit diffuse bounces to 2 (enough for most cases) and give a higher value to other light path types if necessary. To avoid calculating a lot of bounces when it could look great with only a few, just because one material needs more bounces.

    Well I don’t know if this is possible but would be cool! Thanks!! Cycles is great!!!

  5. Facepalm.
    You just ignored everything I wrote.

  6. Actually, BI is pretty fast. It’s built for animations.

  7. In order to reduce the visual clutter in the tree view display, I suggest that all materials should themselves form a “node group” where material inputs can be explicitly declared. This way there could be a tree view mode that exposes only the relevant inputs and in this way the setups like the old material settings could be emulated. Blender could ship with a set of presets, so that users need not learn/use nodes right away.

    Also, FEATURE REQUEST :)
    I require the object space normal for triplanar texture mapping on moving/rotationg objects!

    @FREEMIND: You’re comparing apples and oranges, that renderer is of course faster than Blender Internal because:
    1. It uses the GPU and GPU Rasterization, which has become feasible only very recently
    2. It does not do Raytracing and it does Ambient Occlusion in Screenspace (like Games) which has some non-obvious artifacts and drawbacks like not being able to use correct reflections on normal-mapped surfaces. These are the two main reasons for high render times in BI. Also as far as I can tell it does not do blurry reflections or SSS which are also expensive in BI.
    If you added Photon Mapping to BI it would be very close to renderers like Mental Ray or Vray which are also hacky and messy, also have long render times but are extensively used in production.
    Bottom line: It’s not as bad as you think and to make something look really good requires just a bit more experience – just look at the gallery on blender.org.

  8. I don’t hate BI because it can’t do realistic stuff. I hate it because it’s extremely slow, outdated, messy, hacky etc etc etc.
    What ever BI renders, most of the time look like modern game graphics, not to much better. and these are rendered IN REAL TIME.

    If blender had a great renderer dedicated to unrealistic stuff, I’d be already happy, and I’d just use luxrender for realistic stuff.
    Take this thing for example:
    http://furryball.aaa-studio.eu/
    Same or better quality then BI in real time.
    What this thing renders in seconds, BI takes an hour.

    But Cycles is even better. It’s the best of both worlds.
    The shader nodes are that powerful, that you can write nodes that are not physically based, but object based too (like specularity is)! And It could render such things in real time on GPU.
    BI becomes Obsolete, and still having it after cycles is feature complete would be silly.

  9. You’re contradicting yourself! You say you want a faster, not-as-realistic renderer alternative, but you’re saying you hate having BI around, which is exactly what you’re asking for.

  10. And I hope they don’t.
    Having a crappy outdated integrated renderer as an alternative is bad design.

  11. Then I hope they keep BI.

  12. “I dunno. It makes sense.”
    I wouldn’t say so.
    If we will have other methods, not just physical based, to get speed out of situations that don’t need to be to realistic – fake reflection aka specularity is definitely needed.

  13. I dunno. It makes sense. With Object based lighting, the lamp would show up in a glossy reflection, which is basically what spec is.

  14. No, I don’t like your idea at all since you explained it.

    “I think I recall Brecht saying that Spec is antiquidated and no longer needed since Cycles uses object based lighting”

    That would be strange of him.
    As I read somewhere, cycles will have various shaders, not just physically based.

  15. You know how you can convert curves and text to Meshes, or import other formats? It would take the BI material and turn it into a Cycles node material. Of course this would require the closure being broken down. (Example- Glossy is made of Mirror, Glass is made of Transparency and Fresnel, and IOR)

    And the Materials panel would not affect the whole material, just the individual properties. It works like the Material Node editor in BI. The BI Mat panel might not understand Color Ramp and Mix nodes, but it still controls the material inputs.

    “That just basically looks like BI, has many Un-Cyclish stuff in it…
    How do you mix two different Glossy closures with this?”

    It is BI, adjusted for Cycles. Note how Volume is now a Property, Emmision has been added, and Raytrace and BI specific properties have been removed. The goal of that mockup is to stay as close to original BI as possible.

    “I don’t really like what i see here lol…”

    It’s just for concept. It just shows what the new individual Prop nodes would look like and how they would be added together into a material.

    ““and sadly, Specularity isn’t coming back”
    Yes it is.”

    I think I recall Brecht saying that Spec is antiquidated and no longer needed since Cycles uses object based lighting. He says it’s going away forever, and I don’t really mind as long as there is a way to use RGB curves or something to fake the spec reflections if I really need it.

    “I wasn’t talking about zooming.
    I was talking about resizing the editor, like, grabbing the edge an moving the edge.
    The image does not change, it just gets cropped (perspective or no perspective)”

    Yeah, that is kind of annoying and unneccesary. Hopefully it’ll get fixed soon, but probably not until Cycles is in polishing stage or something.

  16. Ah, mistake:
    In blender the view does not change only when scaling it vertically, but it does get smaller when scaling the view horizontally…
    oh well..

  17. “should have a Preview window, so you can go completly into the N.E”
    I’m not sure if he can make it render the scene behind the nodes…
    But material previews on nodes – definitely needed!

    “Maybe a “Convert” Function could solve this. However, the material Panel would be an Editor, not actually having the Material.”

    I didn’t quite get that.
    What would the “Convert” function do exactly?
    And what do you mean “An editor that doesn’t have the material”?

    “http://www.pasteall.org/pic/show.php?id=14959”
    That just basically looks like BI, has many Un-Cyclish stuff in it…
    How do you mix two different Glossy closures with this?

    “http://www.pasteall.org/pic/show.php?id=14959”
    I don’t really like what i see here lol…

    “and sadly, Specularity isn’t coming back”
    Yes it is.

    “Oh and with scaling, if you are in Perspective mode, Cycles has to rerender when you zoom in.”

    I wasn’t talking about zooming.
    I was talking about resizing the editor, like, grabbing the edge an moving the edge.
    The image does not change, it just gets cropped (perspective or no perspective)

  18. Oh, and I see you don’t like the cramped font either. I hope Brecht changes it back. :P

  19. Man, you are a FAST replyer! :P

    “But you’d have to use the node editor either way. Just that in your case, more rarely.”

    Typically, when I jump to the Node Editor to do some compositing, I just switch editors, because the Compositor has a Backdrop function. Actually, that gives me an idea. If Brect is going to stick with Node Based Materials, the Node editor should have a Preview window, so you can go completly into the N.E. and maximize space.

    “What happens to the material tab when you fiddle around those nodes and do something that the material tab doesn’t understand? For example – Math nodes, or nodes from other render engines?”

    Maybe a “Convert” Function could solve this. However, the material Panel would be an Editor, not actually having the Material.

    And, this is a Cycles-Compatible Version of the Materials Panel that I made in GIMP.
    [http://www.pasteall.org/pic/show.php?id=14959]
    I know SSS and Strand aren’t in Cycles, and sadly, Specularity isn’t coming back, but I’ve included SSS and Strand because they’ll be restoring them soon. I added Emission, And who knows? Maybe Cycles will come with even more properties like Fresnel.

    And the Nodes that would come with it.
    [http://www.pasteall.org/pic/show.php?id=14958]
    When each property is checked, Blender will connect the Property node to the Mix node.

    Oh and with scaling, if you are in Perspective mode, Cycles has to rerender when you zoom in.

  20. “-That is true. Though having half your screen taken up by a bulky node editor is hardly tight or compact.”

    Tight? Hell yeah.
    Compact? Well… No tragic here…
    Personally, i find this kind of a view acceptable:
    http://img43.imageshack.us/img43/347/cycles.png
    I even scaled the window down to show that it’s kind of ok on smaller screens.
    It’s not like when the T and N take away your horizontal space, it’s vertical. So it’s more B2.49 stile.

    And yes, I did say this is an issue :)
    But you’d have to use the node editor either way. Just that in your case, more rarely.
    I don’t really mind your idea, really. If it’s done right.

    ” If you couldn’t get what you wanted fiddling with the properties, you could go into the node editor to edit the material.”
    What happens to the material tab when you fiddle around those nodes and do something that the material tab doesn’t understand? For example – Math nodes, or nodes from other render engines?

    “But really, the only customization you couldn’t already do in the Mat. Panel would be to create your own node, and I doubt you know how to do that.”
    Group nodes! :D

    “But what about more complex materials? Ones that aren’t one of the closures?”
    Other materials are mixtures of closures. Nothing complicated.
    You won’t really get a hell lot of nodes per material.
    And really, I don’t think that mixing in the node editor can be any more complicated then mixing in the tab.
    And remember – pre-made group nodes, material presets…

    “Materials ARE a property.”
    NODE BASED property. :)
    Same as the compositor. Do you want the compositor also be in the properties too?

    More about the size issue:
    We need to get rid of the scrollbars in the whole blender GUI. Expecially in the compositor. They are not useful, they are ugly, and they take space.
    I like that scrollbars are partially taken out in the cycles branch
    But please, finish the job :D
    They could be replaced with little arrows that show “hey there’s something outside of the view in that direction”.

    Cycles speed:
    When scaling the 3D view down, cycles starts rerendering. The scene is not really changing in any way, it’s just being cropped… Maybe cycles could take this into consideration and simply not restart?

  21. That is a HUGE comment. :P

    “blender artists gave me the impression, that most people like that it’s node based, and only a bunch think that it’s a bad idea… and only because they didn’t learn nodes.
    Perhaps a poll could clear up the actual truth?
    http://blenderartists.org/forum/showthread.php?224668-Do-you-like-that-Cycles-materials-are-node-based

    Okay, seeing as there are way more pronode based materials people, apparently I was looking at the wrong topics, and the wrong comments.

    “Actually, I loved 2.5 from the first sight.
    It’s much cleaner and organised, with a more pro looking design (not yet perfect though). And a tight design is what I want to see in cycles too.
    And **Imho**, what i find as bad design:”

    -That is true. Though having half your screen taken up by a bulky node editor is hardly tight or compact.

    “1) Having the same function in more then one place. The less buttons, the better.

    2) Something that takes to much space.”

    Do I even have to answer this one?

    “3) Something hard to read. Readability is important. And as I said before, I don’t think it’s possible to make this auto generated materials tab look clean.”

    Which is why I’m proposing that the closure system be broken down into their individual properties, which would bring back the BI Materials Panel, and work the same way in the Node editor, because instead of Closures, you have Properties like Mirror and Fresnel as inputs.

    “4) Lack of customization.”

    [See above]. Node based materials would still be in the background, automatically factored using simple math. If you couldn’t get what you wanted fiddling with the properties, you could go into the node editor to edit the material. But really, the only customization you couldn’t already do in the Mat. Panel would be to create your own node, and I doubt you know how to do that.

    “6) Something that is not as fast as it could possibly be. Takes more steps then should.”

    For the simple materials, yes. But what about more complex materials? Ones that aren’t one of the closures? You would have an awful lot of mixing and factoring to do, made even more complicated by the fact that closures are usually two or three properties together.

    “7) Is not consistent with others. For example – properties belong in the properties, actions with actions, similar tools grouped, and so on…”

    Materials ARE a property.

    And BTW, I know how to use the Cycles Materials nodes. I would just prefer to have the old properties.

  22. Now to clear things up:
    I do not hold this opinion to strong. (Not as strongly as the must to lose right click select and trackball atleast, lolz) That’s just what I prefer at the time. However it’s done – I’m fine with it, as long as it doesn’t ruin anything. And maybe I’ll even love it and wonder how could I have thought otherwise.

    Cheers.

  23. “….BI isn’t going away, Quit whining….”
    Actually, it is going away.
    But not any time soon. It will become obsolete once cycles is feature complete.
    I’d give BI perhaps two years, not more.

  24. “from what I’ve heard around Blender Artists, the community is really divided over the issue… ”

    blender artists gave me the impression, that most people like that it’s node based, and only a bunch think that it’s a bad idea… and only because they didn’t learn nodes.
    Perhaps a poll could clear up the actual truth?
    http://blenderartists.org/forum/showthread.php?224668-Do-you-like-that-Cycles-materials-are-node-based
    Done.

    “I bet you were feeling the same way when the UI changed to 2.5, except I don’t see making shading completely node based is much of an improvement.”

    Actually, I loved 2.5 from the first sight.
    It’s much cleaner and organised, with a more pro looking design (not yet perfect though). And a tight design is what I want to see in cycles too.
    And **Imho**, what i find as bad design:
    1) Having the same function in more then one place. The less buttons, the better.
    2) Something that takes to much space.
    3) Something hard to read. Readability is important. And as I said before, I don’t think it’s possible to make this auto generated materials tab look clean.
    4) Lack of customization.
    5) Something to far away from a users intuition. (*cough* turntable, left click selection *cough*)
    6) Something that is not as fast as it could possibly be. Takes more steps then should.
    7) Is not consistent with others. For example – properties belong in the properties, actions with actions, similar tools grouped, and so on…

    Problems fixed if losing the material tab:
    1 – Materials edited only in the node editor, not in two separate places.
    3 – No auto generated clutter, with complicated dotted buttons… less icons on the properties header, so on.
    5 (a little) – If Materials are moved to nodes, means textures are also moved to only nodes. It’s un-intuitive to edit the brush texture in the 3D scene properties.

    Problems gained:
    2 – The node editor takes a lot more space then the material tab. However, having only the node editor is better then having them both (Which you would if you want more advanced materials then materials with single connections).
    6 – It’s faster to go to the materials tab then to the node editor. However, you still need the node editor for more advanced materials…
    This can be fixed by: Adding a screen layout dedicated to material editing + having the shelf for favorites (Also deals with 4)+ built in node presets + Quick hotkeys to call out any editor in a new window + Nodes that take less connections (for example, all closure nodes could be unified, with a “type” menu) = All speed benefit returned.

    Now, if the material tab is gone, that’s not really a tragedy. If you really really miss it, someone can write a plugin to get it back in some form. Let’s leave Brecht away from this though, he has enough work with the renderer itself already.
    But no one can write a plugin to get rid of it, now can they?

    “which would make things SO much easier, simpler, and more flexible”
    Easier – maybe.
    Simpler – yes.
    More flexible – No way is that more flexible then nodes.

    I’d really like to see what Brecht comes up with. So, a response would be nice.

  25. forgot to say that the current implementation is quite good imo, and obviously, every specific node magic would be a node editor task

  26. To bring your two worlds together I’m thinking of this solution:
    creating a new material actually brings up a ready-made complex node-setup with all possible components (closures) in. Or, better, you may choose between a few ready made setups (you know, like plastic, metal, glass…)
    This would let you use the shaing system almost like you do currently with blender internal: you have individual controls for a diffuse shader, a specular shader, mirror, transparency, emit, etc… replace the word ‘shader’ with ‘closure node’ and you may have the conjunction point for property panel and node editor.
    I’d add also little useful things like a “camera hide” button which would add the proper nodes to the setup (transparent, lightpath and mix), or in a similar fashion, “don’t show in reflections”, “don’t cast shadows” and so on.

  27. Freemind-

    “Two thirds? Did you pull that number out of your hat?
    I bet you did.”

    -I’ll admit that “2/3” was an exxageration, but it’s true, from what I’ve heard around Blender Artists, the community is really divided over the issue, Some are saying “The Materials Panel is so much easier and simpler, Don’t make it Node Based!”, Some are saying “Learn to use the Node Editor. BI isn’t going away, Quit whining!”

    2-I bet you were feeling the same way when the UI changed to 2.5, except I don’t see making shading completely node based is much of an improvement.

    (Basic Pro-Node arguements)
    -“Node Based Materials are SO much more versatile and Flexible”
    -How about we do away with this whole Closures system, and just break them down into their individual properties, which could be edited from the Materials panel which would make things SO much easier, simpler, and more flexible.

    “Getting rid of the Mat and Tex Panels would save valueble space”
    -In case you havn’t noticed, the Node editor isn’t exactly compact. And the only reason the new Mat. Panel is so much smaller is because Cycles is an Pre-Alpha and 90% of the stuff like textures and Volume havn’t been restored.

    “What we need here is material presets, ”
    -Common Material presets would be nice.

    “some better automatic connections, ”
    -In case you didn’t notice, that’s exactly what I’m saying: “For example, If I wanted A semi-transparent, shiny, slightly refracting Material, I could set the transparency and the IOR and Blender Cycles would automatically mix and factor the Glass, Glossy, and Diffuse closures accordingly.”

  28. Idea:
    Unlimited slots for the mix closure.
    Add one, a new one appears. In that case it would be much easier to connect more then two closures.

  29. “two thirds of the blender community and I absolutely HATE it being Node Based”

    Two thirds? Did you pull that number out of your hat?
    I bet you did.

    “Materials that would take two seconds to set up in Blender Internal now take two minutes in the node editor.”

    Two minutes? Not really. You are just not used to it, that’s what’s slowing you down.
    And two seconds, also not really.

    But perhaps drawing lines between nodes takes a little longer…
    What we need here is material presets, some better automatic connections, and this speed problem is fixed.

    “Oh and seeing as you were able to create a velvet closure, maybe add a wax closure, which controls SSS.”
    Sure he will. No doubt about it. But not any time soon.

  30. I love cycles, but about two thirds of the blender community and I absolutely HATE it being Node Based. Materials that would take two seconds to set up in Blender Internal now take two minutes in the node editor. Materials should still be editable in the node editor, but it should also be controlled in the Materials Panel to streamline the process. For example, If I wanted A semi-transparent, shiny, slightly refracting Material, I could set the transparency and the IOR and Blender Cycles would automatically mix and factor the Glass, Glossy, and Diffuse closures accordingly. Many of the closures are basically two or more special property sliders set at their highest value.

    Material Controls:

    Glass: IOR, Alpha
    Glossy: Mirror
    Translucent: Shadelesness, Alpha
    Transparent: IOR, Alpha
    Emmision: Shadelesness, Emmision

    Get the idea?

    If these materials could be broken down into their individual properties, we could restore all the settings in Blender Internal, and still keep the shading abilities of Cycles.

    • Oh and seeing as you were able to create a velvet closure, maybe add a wax closure, which controls SSS.

  31. “I think that the materials panel should show options only for one material selected in the node editor.”

    Isn’t that what it’s already doing?

  32. I think node editors should be something of the past.
    It would be better if one could upload some images and let blender create a material shader to mimic the material on the images.
    Let the computer do the work guys.
    :P

  33. Audio GL does have a killer node setup.

    One thing that makes it different is that nodes are setup in a 3d space instead of in a 2d space like they are in Blender.

  34. I think that the materials panel should show options only for one material selected in the node editor. Thanks to this
    1) the Materials panel will be still clear
    2) Setting up a simple material will be easy and use of nodes won’t be even needed

  35. I’m learning currently nodes from scratch since Cycles alpha release and still progressing having fun with it:) As for researching enhanced menus in my opinion the ‘spacebar’ menus related are still to find in Blender,something like in Maya/Modo but I see a room for improvement here. Also TAB shortcut would work as a object/edit switch for each node details which would bring the complicated node scene cleaner.
    Adding material preset would be great to study some final examples:)

  36. I would suggest a Houdini/XSI/Eyeon-Fusion style workflow that is almost completely node-based, for textures, materials, compositing, modeling, particles, animation, etc. Although its not as easy to use initially, the power that such a system offers is unparalleled IMO. Thanks for the hard work Brecht, its great to see Cycles making its way closer to a trunk merge.

  37. I took another look at the N.
    Yeah, everything apart from “View” and “Display” and “Backgrounds”, every panel has a place in the properties. And these three are specific for each 3D view, not global.

    I have no idea for a better place for backgrounds, and figured that my previous idea for “view” isn’t any good either… hmmm….

    Well, alternatively, the “favorite panels/Panel dropbox” can coexist with the N region without replacing it. But the N panel should surely lose things that are not view specific. Pressing N would toggle “Dropbox/View properties/Closed” or it could be seperated just like “last action” and “toolbox” on the left of the 3D view… or something like that…

    Come to think of it.. what the hell is the “Mesh options” panel doing in the toolbox? That’s not it’s place, it’s not a tool! belongs in the data tab in the properties…

  38. The idea behind the ‘n’ pane, is to create an area for editor-specific properties. As in, view settings for the 3D view etc – each editor has its own settings that go in here. Unfortunately it got abused with transform controls, Item name controls. This was not the intention of the original design, and it seems this has confused people. I’d prefer to have these things removed, but I wouldn’t be surprised if there was resistance.

  39. “N Toolbox is not useless at all. All those panels have their place separate from the rest of the properties, no need to convolute more the properties panel.”

    Actually, I see it as “Needlessly separated parts from the properties”.

    Some things are reasonable, such as the transform. But when the “edit multiple objects at a time” comes, this also becomes simply a needlessly duplicated feature.

    “No need to join properties and tools and make a quite clear distinction between tools and properties.”

    N box has no tools!
    It’s for properties. T is for tools. And since they are properties, they should be in properties.

    Now Imagine if it was for Favorite panels: You could reconstruct the current N by dragging and dropping the same panels back from the properties!

  40. Sorry, i meant to say “No need to join properties and tools, since devs have made quite a clear distinction between tools and properties, and this helps to make thinkgs clear”

  41. N Toolbox is not useless at all. All those panels have their place separate from the rest of the properties, no need to convolute more the properties panel.

    No need to join properties and tools and make a quite clear distinction between tools and properties.

    I think the mockup shown by okapi is a good one, and can be put in the tools panel when you select a node. That’s what one think inmediately when see a properties panel: the properties of selected object or node.

  42. In the first post, Freemind said that deleting the material panel would have to disappear. I don’t like that idea, I rather have the nodes in that panel with some extra buttons(like assigning multiple materials). I think that’s a better idea.

  43. I had this idea for a while now:
    The N toolbox is useless. All those panels in N actually have a place in the properties, no need to separate them out.
    Except for view/Display, as they are not global, but for each 3D view it’s own. But I do have a clear understanding on where to put them.

    Now, since the N men is in such a convenient place, it could be put for a better use – Favorite panels! Drag and drop panels from the properties or NODES FROM THE NODE EDITOR, to quickly edit things.

    In this case, the quick editing (texture select, basic color correction) problem is solved.

  44. I think the way the Properties editor displays node inputs is really quite clever. The issue with only having nodes as a visual interface is that it gets incredibly complicated and cluttered, and takes up huge amounts of screen space. Lists of parameters can be stacked compactly on the side. It’s still a node tree, just displayed in a list interface — compared to the current renderer which has two different types of materials; nodes and long-list-of-controls styles.

    For simple materials, setting up nodes is time consuming – the ability to just edit basic colors and add textures without resorting to the node editor is a nice boon. And the fact that it still *is* a node-based material makes it easy to add more nodes to your material down the road.

    Granted, as the node tree becomes complicated, the property list becomes long and unwieldy too. It might be nice to explore ways to consolidate it more. Perhaps a way to mark inputs in the node tree for exclusion from the list? Or ways to visually separate clusters of controls from different nodes or node groups?

  45. While this is a prototype for an audio sequencer, I think the way the parameters are integrated in the node work flow, is done pretty well: http://www.youtube.com/watch?v=bCC9uHHAEuA&feature=channel_video_title

  46. Freemind, having a material editing screen is definitely needed, I was surprised it wasn’t already there. About only using the node editor, it’s an option and would make my life easier of course. I have this workflow in mind where once you have a set of groups set up for a particular production, mostly you just need to tweak values and add textures, and for the properties editor could quite efficient. But it’s hard to know if this would actually work well, or if people would go need to go back to the node editor anyway, in which case the material properties may just waste space.

    Lsscpp, we could make it so that when you add e.g. a mix or mapping node, that gets added inbetween automatically. Not sure if that should be default or if you should somehow have the option for both behaviors in the menu.

    Nik, I think node groups are quite good for that use case already, you can expose just the inputs you want and as an added bonus reuse them.

    Dddjef, the wiki discussion page is a good place to put more detailed comments.

  47. Where do you prefer to discuss? Here or at blender.org?

    I would have many things to say about a node editor. I used Fusion, Maya and XSI professionnaly since 12 years.

    You are in the right way for many proposals I think, but don’t forget unifying things. Phonybone started something great with nodal particles, I think you need to speak with him to get a similar node workflow.

    Blender going to node editing is a great news, I’m 200% with this. Node seems complex to beginners, but it is a very good way to learn things, and a good way to work together too.

  48. About the Material draw mode can be like “Viewport 2.0” on Maya1012 or the new viewport on Max2012.

    http://www.youtube.com/watch?v=zJNF7CZ-VjI
    http://www.youtube.com/watch?v=SR7sLY4hThQ

    Where Occusion, Softshadows, Depth of Field and Motion Blur is implemented, but not in the intend to mimic the final render, but as a tool to help the artist.

    Blender has been always on top with the viewport visualization features (GLSL), but currently other softwares have been improved on that way.

    Regards!!
    Eibriel

  49. brainstorm – i have a brain – that’s new for me
    Q&Idea to http://wiki.blender.org/index.php/Dev:2.5/Source/Render/ShadingWorkflow

    Q: The properties editor gets unclear pretty quickly with deep node setups, where it’s no longer clear which inputs belong to which node. Can we make this clearer? Also as nesting gets deeper there isn’t much space left. A nice mockup about how to draw this would be good.

    Idea: Define a new tree view – (basic outliner) and/or a new outliner view – for fast selection
    Idea: to select groups in a fast way – define a drop-down box for groups – if a group is selected then you see only all group objects in the propertie editor.
    Idea: define a drop-down box for tree depth – if a tree depth is selected then you see only all objects in the current tree depth in the properties editor.

    Q:Groups are displayed collapsed in the properties editor. Is it reasonable to never shower their contents and leave editing them to the node editor?
    Idea:Define only a drop-down with all groups for selection

    Q:Other name for closuer?
    Idea: why not “Composite Shader” the output is a composite with light, refracted, emitted, scattered, etc. the short name can be cs or css..not the web css :-P

    Q:Currently it’s possible to use closures where they have no effect, e.g. a BSDF can be linked in the world nodes, but will have no effect. Should we try to filter these? How does this work with groups then?
    Idea: a group is for me a container with a name with in/outputs connections from the closures inside and nothing more. No need to handle a groups in this situation. Do not link noisy values – you never know what happens.

  50. Hmm, about the shading workflow – perhaps there should be a checkbox for each node in the node editor whether or not to display it in the Properties window (ON by default). This way users will be able to make pre-configured shaders with only the most essential things in the Properties window that can be controlled with ease.

    In that fashion, properties window can be left for only basic settings while node editor can be for advanced tweaking.

  51. I have two problems with the current workflow :

    1) The current property view gets too complicated when the node counts increases.

    I would prefer if it only showed the properties I picked from the node tree, so that I can quickly view and edit the important fields.

    2) The Node Editor as a separate view is cumbersome and it will get
    worse as it gets used for more and more different things :

    – You will have to have the properties and node editor open at all
    times, and that takes a lot of screen space.
    – You have to pick the category (Material/Compositor/Lamp/etc) in the Properties header and in the Node Editor header, it is highly annoying as well.

    I would prefer it they were united in the same view : For each category you could pick the ‘node’ or ‘property’ display.

  52. As a side note, i think that going exclusively on a node design might be fightening for people approaching Blender. Not everybody will be switching from XSI or houdini or whatever. I think many people, other than those coming from old blender internal easy panels, might be vray users, or similar softwares, that don’t make use of nodes…

  53. I disagree with you freemind. Once nodegroups are created the current system is perfect to tweak materials. I also found quicker, for easy shader trees, building a material in the property panel than manually add (scroll the menu, scroll the second level menu) each node, and connecting the tiny pin to each other.
    One thing I miss is that if you have set a closure and change it to something else parameters such as color get lost, or in example, changing a diffuse to a mix closure, doesn’t put the previous diffuse in the first channel of the mix.
    bye

  54. Btw.
    Materials in XSI are also fully node based, with no interpreter.
    As you see, such things work :)

  55. “The properties editor gets unclear pretty quickly with deep node setups, where it’s no longer clear which inputs belong to which node. Can we make this clearer? Also as nesting gets deeper there isn’t much space left. A nice mockup about how to draw this would be good.”

    I suggest not having a material tab in the Properties at all.
    This will make the properties much cleaner (all the header icons would fit), you wouldn’t have to worry about how to draw it and etc. Just port everything to nodes. In my opinion, less is more. No need for duplicates (The same feature in a few places), and I see no way you could make it clean.

    Woorkflow:
    Create materials in the Node editor.
    Select materials in Object/Data tabs. Material selected in object tab overrides the one in the data tab.

    One issue might be: The path to the node editor is slower then into a materials tab.
    Solutions:
    1) Shortcut, or button in the material selection section to open the node editor in a new window. That’s for a quick access for a little edit. If you heavily work on materials, you’d have to have a layout with the material nodes anyway. This leads to:
    2) Have an official layout dedicated to material editing.

    On the side note:
    The Material output should have the material preview. :)
    Sometimes you don’t want to render the whole scene just to see how a single material looks.

    Just my 2c
    Thanks for the hard work.

In order to prevent spam, comments are closed 15 days after the post is published.
Feel free to continue the conversation on the forums.