does a tool exist in blender which is similar to the Maya Node Editor? I mean an editor, where you can just connect channels, like the shader editor, but with object parameters?
Currently there is not, in the future, however, blender does plan on making most everything a node in the “everything nodes” project. Currently work is being done on particles to make it all node based. After the that the plan is to tackle modeling nodes, for procedural modelling.
Rigging nodes has had some talk as well, but i’m not sure when that would be.
No, that’s not really how Blender works. There is a driver system though, which allows you to “connect” (although not visually as with nodes) any properties in the scene.
Blender used to have something like that, it is for sure in the oldest 1.0 releases, but it got dropped along the way
The OOPS Schematic view was purely for visualization of the scene-graph and the data dependencies.
I think that, as great as Maya’s node-based organization structure is, it’s also Maya’s weakness. Because anything can plug into anything else, miles of spaghetti-code are needed to duct-tape everything together. Now, I haven’t seen the code because it is proprietary, so take that with a grain of salt.
On the other hand, there are projects out there that enable similar workflow. Animation Nodes, for example. I’ve been poking around in the node API and I’ve hacked together a simple Rigging Nodes idea (haven’t published it yet, I’d like to make a full proof-of-concept).
I suppose so, but Houdini does it just fine, it rarely crashes compared to Maya. I think maya just has some really old code in it dragging things down. Not a programmer though, mind you, so what do I know.
There are few node editors addons available.
Sverchok and sorcar - procedural geometry editors.
Animation nodes - visual scripting system for motion graphics.
Maybe there are more, I don’t know about that.
Also, blender has few node projects - particle nodes, and “nodes everything”.
That would be the UI : hypershade, hypergraph, node editor… sadly none of them work well in every situation. Maya’s philosophy of being able to connect any attributes is wonderful though. Of course you can’t connect things that don’t make sense together : they have to be the same data type (int, float, enum, and so on).
@o_Oliver I think you might find the driver editor suitable to most needs, although if your question was aimed at rigging there are also constraints which allow to do many things that would take a lot of node-connecting in Maya. In the driver editor there is an “scripted expression” field that allows to do exactly what the expression node does in Maya. Add your variables, write an expression using them, and that’s it.
One of Maya’s features since v1 I think is … making custom tools … eg. Do a set of operations on a face, copy the MEL(Maya Embedded Language ) commands from the console to the toolbar, select an icon and BOOM … that can be reused as a tool.
When I saw the Workspace tabs in Blender 2.8 that’s what I thought they would do… Can only hope.
as far as I know (it’s still in design and fining process) is to save node groups as assets. Creating custom tools and node groups is already possible in Blender.
No, I meant in general. And being able to connect and attribute with any other is the source of the spaghetti, since Maya is, after all, the hideous Frankenstein’s monster of a dozen different softwares. Handling all those possible connections (or rather, not handling them…) is IMO a big part of the reason for Maya’s instability and slow development.
Also, Blender’s driver expressions are better! Maya’s expressions have to name specifically the object they affect/drive. Blender’s don’t need to be explicit about that, because the driver is an f-curve associated with a property. They’re much easier to copy and paste in Blender. Also, I think the way they interact with the depsgraph is better… but I don’t know about that one.
bpy does the same. You can do that in blender. There is a window that shows you what command was to be made when you made an action.
It’s not entirely as straightforward since there is a notion of context, whereas in Maya, afaik, any command can be executed at any given time. You can’t just take the output log in Blender and re-execute it, I mean it won’t work in every situation. I might be wrong, not an actual expert.
This is already doable on Blender. You can easily add custom commands (and access them with F3 if nowhere else). Check some simple addon for an example.
Having written a fair bit of MEL myself, I feel qualified to say… it isn’t actually a good thing! Yes, making macros easily is good for artists, but I would argue that any situation where an artist needs to make a macro should have been solved with an addon, operator, or tool. Thus, macros are band-aids over deeper issues. Furthermore, the structure of the language, MEL, lends itself well to making macros, but not… not to actually programming. Putting aside the esoteric syntax, the design of the language is entirely procedural. I don’t mean procedural in the sense of precedural generation, no, I mean procedural as in USER: GIVES COMMAND – MACHINE: DOES THING. Everything is done this way, side-effects galore. It’s not easy to write code in a generic, reusable way when the order of commands matters, and context doesn’t. It’s especially difficult when, by making commands, the data you are working on can change. New data can be created. Connections can be made and broken between nodes and now you have to find things all over again.
Let’s contrast this with Blender’s Python API: There are two methods of working,
bpy.ops which is similar to MEL’s procedural approach. It’s commonly used for creating macros, but it’s not used much in addons for… essentially the same reasons I outlined above. Then there’s
bpy.data – where the programmer doesn’t give commands, but rather declares what the data shall be-
object.property = value. Sure, MEL has
setAttr, yes, but it’s limited in its usefulness because you can’t, for example,
node.connection = other_node, while it is possible to do something like that in
bpy.data. It’s easy to write clean code in Blender with bpy.data, because once you’ve gotten the important information out of the context, you can do things in just about any order and set the values of properties however you wish.
It’s a bit hard to explain without pointing to more specific examples. The point is, MEL makes creating macros easier for non-technical artists at the expense of technical artists. That isn’t a good trait for a programming language. Blender isn’t always easy for non-technical artists, so maybe there’s something we can do to improve the existing API to extend
bpy.ops to make it even better for making macros. Then, we can have the best of both!
Anyhow, I went somewhat off-topic with this, but I didn’t start the off-topic tangent!
EDIT: before anyone says anything, I know that there are other ways of accessing Maya that are more object-oriented… but we don’t want five APIs in Blender, then it will be as hard to maintian as Maya is. Yes, five: MEL, Python (Mel Wrapper), PyMel, C++, Python (OpenMaya). Really. Five APIs.
I never knew it was so terrible in terms of interface. Never used pymel but I know it encloses the data structures in an oo manner, same as say mesh data is presented in bpy (or anything else really). I suppose the absence of context or ownership does make things less tidy.
Openmaya is what ? something community made ?
I haven’t used PyMEL myself, because when i tried to learn it the documentation page had some kind of error and I couldn’t navigate it. I was in a rush, and I didn’t want to learn the “unofficial” way of doing things first, anyhow. And from what I understand, PyMEL has two branches with different capabilities than each other … “Less tidy” is an understatement.
“OpenMaya” is the dishonestly-named Python version of the C++ API if I recall correctly.