another conclusion from this example… the thing shown is a toy. it’s too far from being a tool. any idea works only with a good UI.
I was think much the same, we used to term this sort of stuff “programmer art”. I also reminds me of all the demo’s I used to have to watch of max at exhibitions when it was first introduced back in the day “Wow look what you can do…”. No one ever used the features demoed in production
I think that’s a tad harsh from both of you. You’re both exhibiting classic programmer resistance to node base work flows I’ve experienced with other programmers for years. “It’ll never be as fast”, “node graphs are incredibly hard to read, not nearly as easy as code” etc. This tool is clearly not aimed at you, nor does it appear to be aimed at replacing the usefulness and raw speed of plugins written in the SDK. Node graphs are infinitely easier to read than code if you don’t know how to code in the first place. Sure they can be messy if you’re lazy but that’s not a fault of the tool and if you allow sloppy work into your pipeline, that’s your fault.
The only real disappointment for me is that we don’t appear to be able to write our own nodes as far as I’m aware. That would potentially help with speed issues.
I agree with you!
First, because the people who are writing here are mostly maxscript and C++ ,C# developers, so it’s totally not significant, what we are saying, especially, because most of us haven’t written tools with MCG, or at least, not as complex tools that we have seen from Clovis Gay for example. Since it’s a tool that is still in development, we can’t really compare to any other systems. (or we can, but I can’t see the point, maybe a year later…)
And the most important thing is that this tool has been created for artists and for people who are not familiar with MXS or any other languages, and not for advanced developers. I will be pretty curious about what people are going to make with MCG later on.
but we want to participate too and be welcome in this party.
It’s not really aimed at me either but I like a drink so I’ll join in and leave if early if I get bored
Seriously though, I’m sure we’d all love to have you figuring out stuff in this tool because you’ve been so helpful with max script on this forum. The negativity you’re showing for something that’s only just come out, something you’ve not actually used yet is disappointing though.
Clovis’s example is quite promising. I have an idea of just what he’s doing, math wise and the fact it’s faster than his max script version is a good sign. It’s doing a lot more than just pushing verts out so the apparent speed issue with that push example points to something more specific in that push node than a general issue with MCG.
We need guys like you Denis to help us figure out the pitfalls more than ever because a lot more artists are likely to use MCG than learn max script.
You’re both exhibiting classic programmer resistance to node base work flows I’ve experienced with other programmers for years. “It’ll never be as fast”, “node graphs are incredibly hard to read, not nearly as easy as code” etc. This tool is clearly not aimed at you,
this is what I said earlier in the thread,
Its more about the idea/demand/end user requirements not the tool “creation tool”. a tool prototyper for artists I can see that maybe useful.
banging out random tools is all well and good but a pointless exercise if of no value to the end user (where the tool demand comes from and that Usually means making UV unwrapping a less tedious exercise ). As Denis has said many times above, for most artists it all about the user interface. And adding splines to scene to create mesh deformations for example maybe all well and good for the person creating the scene but it can add unexpected levels of complexity for other users of the scenes. Which is again all part of creating effective well crafted user interfaces. Not saying different is bad by the way we just tend to create tools in ways the artists expect and try and keep surprises and oddities to a minimum. It also doesn’t help if we turn around to our studios hey we’ve got great new tools, makes our job much quicker, a bit like the old tools but super cool only slower.
At the moment both of you leave some kind of party-crasher-twins impression
Once again, if you let sloppy work into your pipeline, that’s your fault not the tools fault. Your opinion on the usability of Clovis’s example is I think largely irrelevant to the discussion on the qualities of MCG. It’s merely one example and does not show that this is all MCG is good for.
My personal opinion on how I intend to treat MCG in the work environment is that I’ll tell the artists they should feel free to play around with it but that they should pass any tools they write to the tech team before it gets used in work and thus relied upon. I’ll be the gate keeper to the pipeline but I’ll not stop anyone trying to improve it.
Your final comment is a tad close to the “we know best” territory. That’s not good considering that as a tools programmer, you’re not the end user and thus will not have to put up with any inadequacies in the tools you write day in, day out
ha-ha-ha… do we break your party? sorry… party is going, everyone has a fun… but who will tide it up tomorrow
Na – was just nonsen joking
It’s good that both of you give MCG a serious rattle to uncover the weaknesses it definitely has
But don’t forget that this is an initial release, shortcomings and limits are to be expected…
i see your understood the problem… we have too many ‘innovations’ now in the max which are kinda in stage between ‘fun to play with’ and ‘ready to use’.
do you know how many cool plugins i could write having a simpleMeshMod? but i’ve written my own just only 3 years ago.
And at least use it before you write it off