The risk you take with not having a node system at all is that you then are consigned as a developer to develop special shaders or options for each use case that the user can’t do yet (something which is more or less likely to happen because there’s only one or two ways to do most effects).
So instead of just having to code an SSS shader and some nodes to fetch vector data for instance, you have to create a generic scattering shader, a skin shader, and a slope shader (the last one actually being a feature in Cinema4D that had to be added because you couldn’t construct it using lower-level data).
Cinema 4D also has a number of other specialized shaders such as a weathering one because, again, they don’t have much of an actual node system for their built-in renderer.
On that, without a somewhat low-level node system, you also end up finding it almost necessary to add a specialized glass shader, a specialized metal shader, a specialized layer and/or coated glossy shader, a specialized blending shader, the list goes on, Brecht had to do none of that for people to emulate such types in Cycles because they were all built by the community using the components provided. It has even been shown that Cycles can even do spectral effects like chromatic dispersion because of the way you can put nodes together to work around the fact there’s no easy support out of the box (and speaking of making slope shaders in Cycles, someone on this forum even made a slope shader that worked on sculpted spheres and not just a flat plane, now how many non node-based engines do you know can do that in a procedural manner?).
Arnold is entirely node-based, in both MtoA and (more powerfully) in SItoA. The fact that you can edit shaders in the material editor is thanks to the fact that there is A.) the aiStandard ubershader and B.) an excellent node->traditional UI framework in place in both packages. But do anything more complicated than a single layer shader and you’re right back into the nodegraph or even (gasp) their C+±esque shader API. No one is doing themselves any favors by avoiding nodes…
“And, by node based I mean having to play in Nodesville for much of a setup”. And, just what did you not understand about that statement. Which was put in there because I suspected probably all raytraced renderers are node based like I give a flying rats ass one way or the other. The point is I didn’t see him connecting a node in two different tutorials.
A single layer shader. Just what parameters did he not have in that panel. I’d like to look over an artist shoulder using that renderer on a commercial job and see how many times they connect a node in a days work.
See the point is who really gives a damn how it works. The interface on Arnold is what keeps you out of nodes and as I said sliders are more intuitive for me. And, a hell of a lot of other people obviously. Here’s a thought they devoted time to that interface for a reason. Do you think speeding up the workflow might have been part of it. Or, could it also be sliders and value boxes are more intuitive to most people.
So our little exchange has established this. I don’t know what MtoA or SltoA stands for. And, that Arnold has a fine interface for a renderer. The latter is all I was interested in. It has now reached a state where you can’t mention Cycles without getting in a pissing contest on this forum. And, as for avoiding nodes. You give me a copy of Vray or Arnold and I’ll take avoiding nodes to a whole new level without ever wanting for a material. Or, even thinking about a damn node setup and that was the whole point.
yeap nodes are an ugly way to deal with complex and very flexible/ modular interface. Especially when the node setup becomes complex you are overwhelmed with the spaghetti effect. Android GUI looks a lot more intuitive, the principle of “intelligent gui” in the video “AI shaders” is pretty much how ideally you deal with complex setup like very complex shaders. Its nice to see that some people understand the value of well designed GUI. But then nodes are way easier to implement than a GUI like the one implemented by Arnold and Blender has not the man power to afford to focus on such GUI. In the end we need to be realistic about these things.
I start to see now that the 1000 euros that Arnold asks may be well worth it.
This one is just the settings for the first specularity layer.
I’m with theoldghost on this one as far as the nodes, I’d rather use these two aforementioned material editors. Luftmensch raises the question of why someone would choose one engine over another other than price or render times…well those are some pretty valid reasons right there, but I would have to say material-based nodes are a deal-breaker for me, although I still use them, and Cycles. For what I do, I don’t need a material with 20 node groups, complete with effects that no one will ever notice anyway, even in extreme closeup.
When I see Arnold, what I see is Cycles, the way I want it to be. Preview rendering with a proper material editor. If they fixed the material editor panel (by “fixed”, I mean not having the menus/tabs hidden, and changed the wording)for Cycles, I would certainly use it a lot more than now.
That’s one major reason why Blender allows one to make node groups and groups within groups, I could have a material that contains upwards of several dozen nodes, yet only a fraction of them are seen at once because the rest are packaged in multiple node groups. If you needed, you can stuff the entire material into just one node group with a few parameters and the like and copy it around to the other objects.
They are also a major reason why you can quickly build materials in Cycles, node groups allow for the modular construction of shaders using somewhat high-level shading techniques, if you don’t have a resource filled with group nodes to import from to quickly get started and instead construct everything from scratch, it’s not solely the fault of the render engine developers. (though I do think that the node group system in Blender could still be expanded to allow the embedding of widgets inside of the created interface).
Also, perhaps in time, Brecht will have the interface features needed to get the Cycles ubershader done (which I recall it’s the interface and not the shading part holding it back), this will make it much better for those who just want to use a legacy-style system of sliders and input boxes.
How can this relate to Arnold though, if the node grouping features help build Cycles materials, they would also help you build Arnold materials as well providing the host app. lets you do that with plugins. I do hope that no one here is advocating that the Cycles engine ditches nodes in favor of a BI material interface (minus the ‘use nodes’ part), because that would effectively neuter it’s shading and texturing abilities and might lead to many users abandoning Cycles in favor of other solutions that still have a node-based system.
hiding a problem does not make it go away. I have been working with nodes since 1996 mainly via Reaktor which is a platform that builds virtual synthesizers , its node system is way deeper than blender’s entire node system and also better designed it offer several interfaces to simplify node structure which are not limited to just node groups. Python scripting is actually way easier to interface than node structures. Nodes excels for simple structures because of the low level curve but the moment you go complex with them they become very difficult to manage.
Its not that a node system cannot be easy to use on complex structures it would however require quite a sophisticated GUI to do so and Blender currently is far from it, neither I have ever seen such a node system inside or outside 3d graphics. I am not advocating or pushing for Cycles materials or compositor or whatever else to lose its node system. Thats not my style. But I am not afraid to state the fact that nodes may look cool in the start but are really a bad idea once you understand that they cannot offer the kind of workflow you will need to deal with very complex data.
I think nodes are better than having a non modular GUI at all. So they are definitely an improvement to the Blender GUI.
Let me ask you this, do you think the Houdini software from SideFX is wracked with bad design then because of their heavy emphasis on nodes, do you think that the big VFX houses then are delusional because it is their software of choice (Houdini in general is hard to learn, but the results you get because of the node system are spectacular)?
You even claim that you’d rather work with raw programming than dealing with nodes, well, just switch Cycles to use OSL then and start writing your shaders in the text editor (and then use that to create a material that uses just one or two script nodes). If you think the GUI of the node editor in Blender is woefully inefficient or even broken, why not produce a detailed proposal with mockups to illustrate what you would prefer to see?
On top of that, perhaps it’s time to take discussion on node-based interfaces to a new thread, we’re getting off of the subject here which is the Arnold engine.
I’m curious what people think is better than nodes. Text files? People complain about nodes as if writing text with absolutely no visualization for what is linked to where would be better. Nodes are a means and a structure; they’re not any one thing other than a method of visualization where there normally wouldn’t be one. You could condense nodes as an easily recognizable visual entity more so than you could a word. The difference is people generally have more experience with words in programming and more infrastructure has been built around that legacy.
No matter your angle on it nodes are inherently more graphical. You can progress how they’re handled graphically, how you organize projects and the pieces within the pieces and what is linked to what and how, unlike text which has a convention for use (you need to read it, the structure is limited to how we type documents which is very error prone).
It depends , if its anything like Blender yes. As I said its possible to have a node system that is heavily optimised as a workflow. I have not used Houdini , so I can’t offer an opinion on it. I was talking about Blender.
You even claim that you’d rather work with raw programming than dealing with nodes, well, just switch Cycles to use OSL then and start writing your shaders in the text editor (and then use that to create a material that uses just one or two script nodes). If you think the GUI of the node editor in Blender is woefully inefficient or even broken, why not produce a detailed proposal with mockups to illustrate what you would prefer to see?
Well basically what Blender offers is nodes and node groups. Thats the end of the story. OSL is a great idea which I will probably use. There is no such thing as “raw” programming, you either programming or not. I don’t plan to produce a detailed proposal for 2 reasons: 1) I dont like to say to the developers what they should do .I am mere stating my opinion. If they ask me to explain further I will do but they most likely ignore because afterall I am a single opinion and may not necessary in agreement with other people who also finding Blender’s node system underwhelming. 2) I have the choice of using python and OSL. And to throw another reason I just came back to learning Blender, there is still like gazilion things to worry about learning before even I face the possibility of creating very complex node setups . When the time will come most likely I will be creating a collection of python libraries to speed up my workflow.
So I don’t even need to wait for node system to improve since I can optimise it myself to a large and most importantly to fit my personal need and desires.
Plus if I was making a detailed proposals about everything I don’t like about Blender would have no time to practice 3d. I come here I make a couple of post per day and go back to my hole studying 3d , thats all I can afford.
On top of that, perhaps it’s time to take discussion on node-based interfaces to a new thread, we’re getting off of the subject here which is the Arnold engine.
Someone mentioned something about Arnold and I replied about Arnold. This is a thread about Arnold and Blender, no ? I wont be creating a new thread about Blender’s node system but you are welcomed to do so.
That pretty much the reason why people choose nodes to python scripting. They believe that nodes are inherently more graphical. Its one of the stereotypes together with the stereotype that learning to code is hard. But thats not the case, there is nothing stoping anyone from visualising python or any programming language. As a matter of fact this is a standard feature for all serious IDEs (IDE is a software dedicated to programming which is what most coders use). But outside code it possible to have modular graphical interfaces that does not use nodes. For example nothing stops you from replacing node cables with drop down lists etc. Nodes are just one way to interface with the user. There are endless possibilities out there.
I could explain in detail but as Ace Dragon said I would be derailing the thread and I would not want to do that. As I said I am happy to see Arnold having such an interface from the vimeo video linked here.
-Nodes can have widgets (like curves editors, gradient editors, the ‘normal’ node ball ect…), embedded within them.
-Nodes can have previews of what the result is like at that specific point in the tree, this isn’t seen in Cycles, but is seen with the node system for BI and the compositor.
-Nodes can offer a guide to how different types of data is transferred and which is safe to plug in to which without running the program (the multiple socket colors for instance).
To be able to concoct that level of visualization in your mind from pure code can be very difficult to do in many cases, especially if it’s something of high complexity, and being able to spot errors without any sort of guide without running the program can be quite tricky as well. I have written a lot of scripts to produce logic for the BGE for instance, and it can be a long-winded task to find those one-liners that are preventing the whole thing from working, imagine if I had to start doing those bug-hunting quests while making art and find out it’s only misplaced syntax or a (case-sensitive) typo(hey, it’s just something I wouldn’t want to do for general art creation).
Nodes are awesome and the way Cycles can mix nodes to create more complex shaders is awesome. I look forward to a node-based particle system and I hope blender can become more node-based overall so, for example, a shader node can hook up to a particle node or modifier node and drive it.
People with this strange disdain for nodes are simply going to be left behind. I can’t think of a single package out there that isn’t making a BIG push to nodify huge parts of their workflow.
So the main complaint is that nodes are slow when dealing with very complex things?
If you’re dealing with very complex things in your shader, that just means your shader is probably inefficient anyway. On the rare occasion when a simpler shader isn’t an option for some reason, nodes and node groups will do. You generally shouldn’t be constructing very complex shaders on a daily basis, and when you do, just can the effect in a node group, save a .blend and reuse indefinitely.
Nodes are definitely awesome and very powerful. I can understand however why people don’t want to use them. Complex node setups can be very daunting and you need comments from the creators if you are going to look at someone else’s node setup or modify it or you are not going to have a clue what they do.
For example, this is a very well-structured node setup for a compositing shot in Nuke. Tell me that it isn’t daunting to look at.
This is an incredibly exaggerated example of what nodes can do.
A node set up is supposed to be simple, simple in the same way a characters topology is supposed to be simplified.
If I got handed a shader setup like this in softimage I would hand it right back to whoever made it and tell them to re-do it. Because if it takes you this many nodes to get to where you want to be, especially in terms of materials and shaders, then you have no idea whats actually going on.
It is actually not exaggerated at all, not even close. When you are doing complex VFX shots in Nuke you can easily get handed a setup that is 5 times more complex than that one. It’s true that you generally don’t come across a shader that complex though, my example is more for compositing.
This is more what you would expect from a shader. This is a (nice) water shader for UDK. However even this can cause headaches for someone that is not “in the loops” with nodes.
These examples are certainly not typical, though not unreasonable. I’d point out both of these would probably be much simpler to understand if the authors had used node groups. I’d also point out I’d have no idea where to even start if I had to recreate that water shader with the clunky dialog boxes of Cinema4D or Vray like someone posted above.
