Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
■ grouping of nodes and being able to label the group (drawing a block around it and changing the color, like nuke, substance designer... etc.) ■ node editor re-arranging the nodes after you have put them in specific locations (this is an annoyance and should be a option to be able to turn off)
■ Dot nodes (like what they added to the newest update to Substance designer)
Just to emphasize the need, to work not only on high-end features – and that also other software teams always develope the very basic UI inbetween: Now Katana and Substance independantly introduced "dot nodes". These are tools just for sorting, no further function. Of course this requires a fix UI, that doesn't change its layout. And the ablility to add "favorites" to the creation list… yes, when I just think of the amount of clicks that each time a simple texture file node needs...
It's great to see voices here. Remember though that Autodesk will only really listen when people submit their own individual reports of individual requests.
Two years ago I attempted to build a pipeline around the ‘container’ framework. I eventually discovered a fundamental bug with keying that made it unusable for rig encapsulation. I found this surprising, since the online documentation pitched containers for exactly this purpose.
I reported this to Autodesk. They acknowledged the bug but could not tell me when, or even if, it would be fixed. Since then, I haven’t come across a single studio that uses containers to encapsulate rigs.
Two years on, my conclusion is that the system was shoved in, marketed and then abandoned. And this is a terrible thing to realise; it undermines your confidence in the whole development cycle.
Yes, my confidence in maya is at a very low point. I have absolutely no idea whats going on there (AD). Having a functional nodeEditor is in my opintion so absolutely essential that I think there is something fundamentely going wrong in the Maya department. 2012 I asked Eric (luceric back then at CGTALK) when they will add container funtionality to the nodeEditor and he had to admit that he just cannot say when of if ever.
The uncertainty with Maya makes me mad. Even though they now have a better integration of bifrost I mainly think: ah, it looks like its really planned to replace the whole DG with bifrost finally. And then: mmmm...isn`t that a completely different program in the end? It really feels like they are forcing me to make the jump to Houdini. Maybe it will cost me quite some time to rewrite all my plugins then. But I know; H works and is great _and_ I don't have to fight with bugs in every step of my development and production.
Its such an ongoing pain, I cannot stay it much longer.
I think that autodesk needs to pull more guys from 3Ds Max and put them on the maya code...
There are so many features in max that just work, I come from a max background and for years I have found it to be more stable and more intuitive in how certain things work.
Maya is slowly pulling things in from max (the modeling toolkit for one) and its a good approach. but in saying that, they need to stop adding "new" features into maya and FIX WHAT IS THERE. Its going to start becoming bloatware if they are not careful
Firstly, Autodesk calculate that not many people use containers, so they can’t be bothered to fix them. This is strongly implied by the questions they put you through when you report a bug: How many people in your company are affected by this? Is this ‘production critical’? And so on.
Despite this, they’re happy to leave them ‘showing’ in the documentation to ‘pad out’ Maya’s feature list. And this is awful, because you reach a point where you start assuming that, if a feature or node in the docs is a bit technical / esoteric, it’s probably been forgotten about, and therefore broken. You become too cautious to play around and explore.
Secondly, there is no real way to implement a functioning Node Editor in Maya, because Maya’s node system itself is broken. The longer you dig around the factory MEL scripts, the more you realise that even off-the-shelf networks need a lot of script-assisted initialisation to work. You can’t really pipe things around and expect them to work.
This is why new features now come with their own, either partly or completely closed node graphs (see MASH and Bifrost, respectively).
This negates the ‘visual programming’ paradigm itself and points, again, to a fundamentally antiquated codebase that’s now beyond repair.
Many years I had that thoughts and heard from others saying similar things.
But I never wanted to believe that AD (and the companies before) really would let us rely on such a messy piece of potentially non-fixable software without trying to address all these fundamental issues and being honest about that.
Don't get me wrong. I see that they try to do something. But I have such horrifying years after me where I stepped from bug to bug that I feel I am at the end of the road with Maya and finally have to make a deep cut.
Why should be Maya's node system "beyond repair"? You can do everything from scratch again, of course not very fast but step-by-step...And this is a chance to enhance everything.
Less need of work-aaround-coding later means more speed and reliability, too. Just watch the by far highest voted feature request "improve construction history". I imagine, this all belongs together.
And I personally agree to @snake3y3s , that there is no urgent need to add new features. I would prefere a sound reliable software. This is what counts first in daily routine and when trying to convince people to enter into Maya.
I would be interested to see where the whole 'node graph' thing might go in the future. But for now, can it just stop re-graphing everything all the time so I can stop pulling out what remains of my hair?
As far as I understand, most people are asking for features added to the node editor to just make it work a bit better (with regards to maya not popping nodes all over the place when you make new ones and so forth) for visual organization and workflow, not necessarily a complete rework of the node editor.
With regards to "improve construction history" this is something, that as far as my understanding goes, will not be something that will be easy to implement in maya without a complete core re-write.
Maya works on a construction history workflow... Max works on a modifier stack workflow... fundamentally they seem similar but under the code they behave very differently.
@abercaine The partly part of what I wrote re: MASH refers to the fact that it encourages you to use its various custom GUIs instead of the Node Editor. This is because even basic MASH node manipulation can’t be attempted without factory script assistance. The factory module deleteMashNode.py is a good example.
@BenediZ Maya’s node paradigm is fundamentally broken for the reasons I already mentioned. I don’t know what ‘do everything from scratch again’ refers to. ‘Convincing people to enter into Maya’ is not my concern.
@kimonmatara "This is because even basic MASH node manipulation can’t be attempted without factory script assistance. The factory module deleteMashNode.py is a good example."
You don't have to use the GUI, you want to delete something in MASH just delete the node in the node editor. Most of the time i use MASH directly in the node editor by wiring things, it also works perfectly with SOUP out of the box and that's because the data is just the same as the maya native data.
The GUI thing and script assistance is just an attempt to make things easier for people that are not really into nodes and make it works with a nice interface, which is a good thing having both approaches.
@abercaine If that were true then deleteNode.py would be one line:
m.delete(node)
Instead, it is over two hundred lines that clean up connections and work around Maya bugs which are clearly mentioned in comments:
# see if we need to delete the solver (MAYA-81531)
I’m happy that Maya works for you as-it-is. But I get the impression that you are looking for evidence that I am somehow misunderstanding, or worse, misrepresenting how Maya works.
If recruiting, or even keeping, Maya users is your ambition, this is not an effective way of achieving it. People are interested in doing good work, not demonstrating their loyalty to Maya.
@kimonmatara it's not a matter of loyalty or defending maya or whatever.
But saying that "MASH node manipulation can’t be attempted without factory script assistance" is just a wrong statement. And the deleteMashNode.py is to handle special cases with dynamics. It's like the delete history by type, you can see it as a conditional delete function.
But you can manipulate the nodes like any node in maya that's it.
I feel like with all the recent developments of other 3d packages, and many years since xsi got cancelled, Maya 2020 really needs to show something promising. If it doens't happen then, I can't see it happening at all tbh...
