Notifications
Clear all

[Closed] The MCG Thread: Post Tools, Compounds and questions here!

here are simple alternatives… what would you prefer?

choice #1: cool node based editor which allows a non-technical person design and develop a plugins

choice #2: make the max ~10 times faster allowing to work with 1M verts models and 100K nodes scenes

what is your pick?

2 Replies
(@pacermike)
Joined: 10 months ago

Posts: 0

Why can’t we have both?

(@denist)
Joined: 11 months ago

Posts: 0

we can… but one after another

Nah… Always the extremes situations… millions of polygons… You dont always have to work with millions of polygons. As far as it works fluid enough and you dont have to wait hours for the result, it’s perfectly acceptable…

(Ok I know MCG is not perfect at all, but so far it’s good enough for a start… :))

Klunk: Denis, as developers you know better than anyone how important feedback is to improve a tool. So instead of complaining and arguing against MCG

I’m not complaining or against MCG, I’m just skeptical about the claims being made about it, by autodesk dev team and some of the advocates on here.

  1. it’s easy to use, so much so any artist will use it. so far not proven and absolutely no chance if the tool they want to make requires a custom node. Seems like most have been created by hard core devs.
  2. it has a fast turn around, again not proven, and again if it requires a custom node it will probably be the same as any other development method.
  3. custom nodes in c#, mleh if it was c++ i would probably only too keen to chip in.
  4. it’s performance, on some stuff great on some other pretty mundane stuff slower than the mxs equivalent.

Actually I’m not OK, at all. What I wanted to say is that artists like me can’t see what is rotten or not, our only parameter is if it tastes good and we do not get sick. So this is why I said what I said. But as a developer, you know what they are cooking, that’s why you are skeptical about what they offer. I more than understand that especially because I’ve seen the benefits of these “under the hood” changes made in other softwares.

But AFAIK these changes involves a lot of work and take a long time. As an artist, my priorities are what I need now. It turns out that what artists like me need is different than what developers like you do. If I have to wait long years for them to rebuild the house until they can start working on what I need, I rather them try to do what I need first and slowly rebuild the house. Would you believe if they say they’re going to rebuild the house? Project Excalibur was supposed to do that, remember? This is what was told at the time. At this point they have to find their way through the mess.

  1. Saying that any artist can use it is just the usual propaganda. But although right now most stuff have been created by more hardcore devs, working with nodes is less about coding knowledge and more about understanding coding concepts and data types and above all, a TD mindset. For that you don’t have to be a hardcore dev.

  2. For a coder, I too can’t see why to go with nodes. This is what I tried to say about Houdini. It allows both because nodes and code are the same thing there. The VOP nodes just generate messy VEX code, so hardcores users code directly. But if instead of coding you want to connect nodes, you still can add a “code” node called “Inline” for cases where nodes can get too confusing, often the case with long math calculation which can consume a lot of nodes even for something simple. So it’s not like any other development method because it bypasses most of the bureaucracy involved in lower level programming like SDK.

  3. That’s my point about you guys giving feedback. Yes some performance right now it crap but it doesn’t mean there’s no solution to that. How can Genome be fast if it lies on top of the same max as MCG? I trust MCG performance can/will be improved a lot. This might not be enough for you guys, but will be loads of other people.

A point in MCG’s favour… no recompiles necessary for future version of max…

Well, “code” without closing max, is also a plus (I know we can do mxs without closing ).
I already used alot of MCG tools in production (can’t share, and they weren’t cloner’s), and its way faster then either write mxs or go to C++ and write something, be it a dlx or some new modifier, since i didn’t had to leave or close max to do the job. Of course, not everything is possible in MCG, and I still have to go the mxs route or MaxSDK either C++ or C#.

patently untrue, only c++ dlx script extension require max to be shut down. If a plugin uses function publishing it won’t be updated (throws a mxs system exception) and there are a few issues with modifiers if the plugin is in the current modifier set otherwise all good.

Sure, you are right (and my bad sentence tried to say the same), only .dl? require a restart session, since you can’t unload and load the plugin when testing, and making changes. Of course mxs (maxscript script) doesn’t need any restart session.

but maybe you can tell us what your ‘alot’ does do, can’t you?

i don’t have max 2016 to play with right now. but i see some examples made by using the MCG.

couple years ago i’ve posted the full list of max actions… could anyone post the list of all currently available nodes of the MCG? only names would be perfect… thanks

Page 21 / 24