I see your points and understand them completely. But it’s not like MXS or .NET is going away. You can still write your tools using it Also, I enjoy Slate FAR (FAR FAR FAR FAR) more than the compact material editor hands down. Way easier to see and understand the materials, make instances, copies, etc. It tangles up, yeah! But it’s way easier to handle and one print shows your entire material.
I see MCG as a procedural way to approach Max’s modifiers. And by what I understood, it has some common basis with Houdini’s VEX. If it’s even faster than MXS, even better for me
I expected a comment like that from DenisT, but I’m sure he’ll still manage to school us all on how it should work even if he doesn’t use it to make his tools!
There’s things you can do with MCG that aren’t suitable for maxscript, and the C++ version would require lots of knowledge about the modifier stack. Making quick tools it going to be the best bit about MCG and I think we’ll see some really cool additions to this tool in future updates!
Not true, you can customize the UI.
From the MAXScript Reference:
Customized Max Creation Graph User Interface
The typical Max Creation Graph workflow looks like this:
*Create the node Graph including input nodes to be exposed in the UI.
*Save and Evaluate the Graph to generate all files including the .MS scripted plug-in file.
*Once the initial testing of the plug-in has finished and the UI controls are all exposed automatically, copy the rollout definition from the .MS file into the Custom UI tab of the Graph Properties dialog accessible via the Edit Menu of the Max Creation Graph Editor.
*Modify the rollout definition to reorder the controls, combine common controls into groups, tweak the appearance of the controls, and additional rollouts with info about the tool etc.
*Save and Evaluate the Graph to produce a tool with the custom User Interface and iterate further to tweak its UI appearance.
Also, you can use MCG to define custom functions that you can access in your MAXScript code. While I know you would prefer writing your own DotNet code, for some people out there writing DotNet in a visual editor might make sense, esp. since it is rather easy to inject other people’s MCG creations into the system.
I would expect your benchmarks to show MCG performing somewhere between MXS and SDK level. But YMMV, of course.
it reminds me an old anecdote…
how to make a helicopter…
follow the instruction. if at the end you made a submarine just refine it with a rasp file.
there are more arguments against including the MCG in a development:
#6 debugging… ? in the article i don’t see any idea how to debug tools made with the MCG.
#7 extending (deriving, inheriting)
i see a happy developer now –
“before MCG i could write only one tool a day. but now with it i can write ten! which makes me 50 in a week, and 220 a month!”
I have only tested Ephere’s Lab but I assume mcg is in the same ballpark, so here are my experience from using a visual programming approach. As DenisT points out – it gets really messy and unreadable when you start adding nodes. Simple stuff that is a line or two in code is equivalent to a cluster of nodes and the frustration and readability is in the drain. I hope that mcg comes with the ability of programming custom nodes or a scripting node.
So far I may have sounded negative, but im not It is when mcg gets more and more nodes that does more specialized/custom stuff the fun starts. Lets say you have the heavy lifting of your modifier inside a custom node, then you have 100x more freedom to play with the input and output connections to the node which can really transform the resulting modifier in any new direction you want. Of course you can do this with a standard default modifier, but then you’d have to do the compile/restart 3dsmax dance and that is a real pain.
So it is not a silver bullet and Im guessing it can be a bet off putting for inexperienced users and it has the obvious trade-offs from classical programming like readability and debugging, but it opens up for a more hands on approach and flexibility when you have your main idea converted into nodes
From your comments I take you have a pretty good inner view of MCG, Bobo? Is it similar to Houdini’s VEX?
And Denis, I take this tool isn’t meant to replace SDK made plugins. Since you have a better knowledge of a language closer to the core I say keep using it, but how long a road must one travel to reach that level? Following that line of argument one could say that assembly is the way to go. It’s the faster, most direct and customizable of them all.
MCG is a pretty accessible way to have your custom tools. It’s NOT easy, but easier than Maxscript and .NET for sure. Maybe it’s just not the tool for someone with your level of expertise. But you’re welcome to play with it before ditching it altogether.
i’ve read two posts above, and both of them say almost the same: it’s good for me to make my own tools for my own needs.
so will it be better to call MCG as PTDK (private tools development kit)?
LOL! Of course not Denis! MCG is easy to share and modify to one’s needs. If you read what I said I meant that “MAYBE” MCG isn’t suited for someone who has your level of knowledge and wants to write your own tools “the good old way”.
But have a go with it before coming to conclusions