you say that MCG is fast for development… hmm. well…
check the example in the article. a ring tool (utility)
using the mxs i can write this tool for … (let me try…)
… done.
it took 3 minutes. but does it make any sense to do it for 3, 5, 20 or 60 minutes?
but i can see MCG as a tools for prototyping.
it can be like:
an artist with minimum knowledge of programming can make something –
and show this something to a developer –
see! that’s what i want –
please make this but working fast and with a nice interface
something like that
I have no idea what you are talking about (although I know a similar anecdote)
You said in #4 the UI would look ugly.
I answered that the auto-generated UI which is a scripted plugin with one paramblock and one rollout can be edited and injected back into the tool so it is used instead. So you can customize the UI to look like any other scripted plugin, and the customizations become part of the tool’s definition.
No helicopters, no submarines.
I don’t necessarily disagree with most of what else you said.
But because a new Scripted Plugin class (SimpleMeshMod) had to be introduced to host modifiers that change the topology on the stack, we can now benefit from that and develop scripted modifiers that take incoming geometry and output new geometry. So all those clone modifiers etc. can be written in pure MAXScript without any MCG… That makes ME happy.
you told us about several steps about how to make bad better.
but i know two built-in tools(mechanics) in the max with the similar idea: visual maxscript and ‘add custom attribute’… technically both allow to modify UI after. but… in practice people just not use them with this option.
i had knew nothing about the SimpleMeshMod. it might be really cool!
If MCG runs faster than max script, it’s liable to be a winner for the vast majority of us.
Actually does anyone know if you can input other objects such as splines or lights for instance?
Well then I’ll stick to max script. It won’t take long to find out
ARingClone Tool is a good example of bad way of the idea realization.
what does it do?
#1 makes number of instances of a specified mesh
#2 puts them in a specified transformations (position, orientation)
#3 combines in one mesh (attaches)
correct? correct
what part is the most memory expansive? it’s #1
what part is the slowest? it’s #3
who causes #1 and #3? the count
who causes #2? the radius
that means if we change only radius we can do not instancing and attaching! we need only (!!!) move specified verts.
now try to modify the corresponding graph taking this fact into account.
it’s not a minutes to change anymore, is it?
do you know what kills all node-based paradigms? switches! conditions.
“if at least five kids are playing on the playground and boys are less than 4 or at least one of the girls are older than 7 or the playground is big enough and it’s not too late …”
it’s a couple lines of code… but… hmm… try to count the number of visual nodes needed yourself.
have to say never been a fan of this kind of visual approach, there always something that doesn’t work the way you want it, It becomes a mess real quickly and trying to work out what going on a right pain.
So if MCG will be slowest then maxscript I don’t see why this feature is needed. ADSK every release brings to max features which “can do” but doesn’t concern “how fast can do”.
Another problem that Max goes to be like Poser, not the tool for creators but want be tool for “who doesn’t want learn complex tools”. Populate one of such “tools”, this is not crowd system even if we compare with Biped crowd this is toy.
It seems MCG will be step back in general. If MCG would be like Genome it would be step forward.