@RGhost did you read Bobo’s comment? Or read the post on the Area about MCG? It shares concepts and foundations with Houdini’s VEX, and it’s speed is between Maxscript and SDK made plugins. It’s not slower than Maxscript, but don’t take my word, test it yourself.
I’m really impressed on how Max’s guys are bitter! You all didn’t even TOUCH the tool and are already deeming it crap! Get to know it first. Then tell what you think, without prejudice.
QFA!
We get high level programming tools that can do awesome things in very little time and produce high quality tools. What’s not to like? Sure you can think of examples where it doesn’t shine but on the other hand you can make a limited push modifer that is multi threaded and uses Intel’s Embree ray tracing engine for optimal performance is less then 15 minutes. And this is just the start…
I’m really impressed on how Max’s guys are bitter! You all didn’t even TOUCH the tool and are already deeming it crap!
comes from all the half baked, bug riddled and undocumented “features” we have to deal with, would be nice for them to actually finish everything first before adding something new.
@KLvnk I see your point, and you have all the right to complain. But do that after testing the tool. Not before
you’ve missed the point, I want the tools I use to work I would also like the instruction manual for those tools to be up-tp-date and comprehensive… not a new tool.
I like the fact that we’ve now going to get a new class of scripted modifier plugin and we still can’t extend editable splines via mxs without it crashing (and that little chestnuts been around forever). Inspired.
No, I’m missing no point here. I too rant from time to time and have my fair share of disappointments and things I’d like exposed to use on my scripts. But getting these to the surface on this thread IS missing the point entirely!
As I said before, this was the no. 1 requested feature on the uservoice. And they are delivering it. Is it complete? I suspect no. Is it bug free? Guess no too. Buy it’s still being developed and it is very much capable of doing very nice things.
And bugs, incomplete features, missing documentation… Well, everyone can jump ship and use any other piece of software. But you will still be jumping to another ship with bugs, incomplete features and missing documentation.
Once MCG is a compiled language, I don’t thing that it will be slow. Even if it’s slower than the SDK, I don’t think that it’s slower than maxscript. .NET is about half of the speed than native C++ complied codes, so if MCG uses .NET to compile, it must be faster than maxscript. C++ plug-ins are 100x times faster than MXS, so I’m sure MCG won’t be as so slow as MXS, even if it’s unoptimized.
The other thing:
Houdini is base on a nodal system, and it’s fast as hell, it doesn’t suffer from any kind of optimization issues.
No, I’m missing no point here. I too rant from time to time and have my fair share of disappointments and things I’d like exposed to use on my scripts. But getting these to the surface on this thread IS missing the point entirely!
who’s ranting ?
Hum… Maybe you were (just a wee bit?)
All I want to say is – try the tool (I didn’t yet) see its strengths, its weak points, and get the word out.
as i understood MCG finally makes a .ms file which handled by the system as any other max script.
how can it be faster than max script?
#1 is it optimized better? (very unlikely)
#2 uses new mxs extensions? (that’s what Klvnk talks about:“Extend the current system with new functionality first…”)
#3 ???
how can it be faster? why? i don’t want to complain, i want to discuss the tool before its release. i want to know – do we have to switch from max 2014, for example, to max 2016 because of this new feature or not?
No, it compiles to C#, it does generate an XML/ms file which is just the node layout and a helper file but all the heavy liftig is done in dynamically compiled c#.
so we need .ms file ONLY to register our tool as plugin or utility, use as UI description, communicate with the system through modifier panel for example, but all heavy stuff c# dll will do.
so we are talking about scenario #2 – mxs extension, and we don’t talk about new class of mxs plugins.
well… let’s try to imagine how new simpleMod can be:
here is a very known example from the mxs help (the class simpleMod)
plugin simpleMod saddle
name:"SaddleDeform"
classID:#(685325,452281)
version:1
(
parameters main rollout:params
(
amount type:#integer ui:amtSpin default:20
angle type:#float ui:angSpin default:0
)
rollout params "Saddle Parameters"
(
spinner amtSpin "Amount: " type:#integer range:[0,1000,20]
spinner angSpin "Angle: " type:#float range:[0,1000,0]
)
on map i p do
(
x = p.x*cos(angle) - p.y*sin(angle)
y = p.x*sin(angle) + p.y*cos(angle)
p.z += amount * sin((x * 22.5/extent.x) * (y * 22.5/extent.y) + angle)
p
)
)
the question is – where the c# will start work?
#1 possibility:
on map i p do
(
CMG.simpleMod.Saddle.map i p amount angle
)
#2:
on map i p do
(
CMG.simpleMod.Saddle.map i p
)
#3:
on CMG.map do () -- this will be new for mxs pluging event handling
do you see the difference?
It only uses a MAXScript Scripted Plugin to host the UI and object representation. The actual calls of the modifyMesh handler of a modifier for example are going through a DotNet compiled function. So the paramblocks storing input parameters are MAXScript, the rollouts are MAXScript, but it is more like extending a C++ plugin with a scripted UI – fast under the hood, flexible at the UI level – we did this with Stoke and Krakatoa PRT Loader and they are in no way slower than the C++ code running underneath, but I have full control over the UI.
What I don’t like it is that they stuffed the menu access to the MCG in the “Scripting” menu (formerly “MAXScript” menu), instead of “Graph Editors”. So now everybody is free to assume MCG is using MAXScript under the hood. MAXScript is just the bridge between Max and MCG.
Finally, I expect things to get faster as time goes by (despite what people might think from historical experience).
Hope this helps…
it just confirms that we the same way stuck with modifier and plugin classes allowed to use with mxs. MCG doesn’t a step forward for sure (IMHO). But maybe it’s a good step aside.
some people say: “I don’t want to learn coding, I want just connect inputs and outputs”.
well. look at this Graph: 
it doesn’t look very clear for me (who made hundreds of tools).
and here is a basic code that makes the thing
delete objects
t = teapot ishidden:on
m = editable_mesh()
count = 6
radius = 60
step = 360.0/count
for ang = 0 to 360-step by step do
(
t.transform = pretranslate (angleaxis ang z_axis as matrix3) [radius, 0, 1]
meshop.attach m (snapshotasmesh t)
)
update m
i’m absolutely sure that is much more helpful to understand how the code above works than why the nodes connected this way in the graph.
You really can’t see the point do you?
Not everyone is a senior technical artist, or it’s better to say: a programmer.
Many of my colleagues simply don’t want to learn maxscript, especially not C++, but sometimes they want to have the ability to make their own tools, making their job easier and more fluent.
This tool is designed for advanced C++ programmers. It’s designed for artists…
actually i see the point very well. “We don’t want to learn programming and math! We want to make tools!”
i could be an old school but things like these never worked at time when i was a student.
that’s why i’m very skeptical about a quality of tools made with this aim.
From my understanding they implemented a new compiler/language on top of the .net-framework.
So it might spit out msil code that gets compiled to native code at runtime.
At least that`s what i get from Chris Diggins post here.
Honestly, i could not even imagine working today without slate. It is indeed unusable as long as you have a single monitor. Once you have two screens, it speeds up creation and management of materials by order of magnitude. I could never go back to old material editor.
Node based solutions are preferred by majority of users, that speaks for something. Of course there was not a boom of material libraries, because custom materials are not anyhow related to material editor being node based. It’s simply because now, creating custom materials, even very complex ones, is very simple task, partially thanks to the slate editor.
Things like node based programming have their place too… Just look at the boom and glory of custom tools ever since Softimage got ICE. It was ICE this, ICE that. For what 3ds Max users needed expensive plugins like ForestPack or Ornatrix, Softimage users done themselves using ICE (multiple very capable scattering plugin and Kristinka hair solution).
I can imagine MCG will not be nearly as good as ICE, because obviously, it was executed Autodesk. But that does not in any way mean node based solutions are bad.
Here’s the ms from a simple twist modifier I just made:
plugin simpleMeshMod test
name:"test"
classID:#(0x3401A356, 0x5D09D7FF)
category:"Max Creation Graph"
(
local pluginDefinitionFile -- the plugin definition file
local pluginInstance -- the plugin instance created from the plugin definition
local _meshWrapper -- the dotnet wrapper around the stack mesh pointer
local argsType = dotNetClass "System.Object[]" -- used when creating args array
local dotnet_ValueToDotNetObject = dotnet.ValueToDotNetObject
local tmHandler
-- function wrappers
local _meshWrapper_SetValue
local pluginInstance_UpdateMesh
-- value wrapper local and function wrapper declarations
local meshWrapper, meshWrapper_SetValue
parameters main rollout:params
(
angle ui:angle default:0 type:#float animatable:true
_dummy type:#boolean -- this exists to enable easy invalidation of the object
pluginGraph type:#filename assettype:#MaxCreationGraph readOnly:true enumAsAsset:true
pluginGraphDependencies type:#filenametab assettype:#MaxCreationGraph readOnly:true enumAsAsset:true tabSize:0 tabSizeVariable:true
)
rollout params "Parameters"
(
spinner angle "angle" range:[0, 100, 0] type:#float
)
fn initialize =
(
pluginDefinitionFile = @"C:/Users/xxx/Desktop/test/test.maxtool"
local c = dotNetClass "Viper3dsMaxBridge.ModifierPluginInstance"
local cid = this.classId
local refMakerWrapperClass = dotnetclass "Autodesk.Max.MaxPlus.ReferenceMaker"
refMakerWrapper = refMakerWrapperClass._CreateWrapper this
pluginInstance = c.CreateInstance cid[1] cid[2] pluginDefinitionFile refMakerWrapper
pluginInstance_UpdateMesh = pluginInstance.UpdateMesh
local meshWrapperClass = dotnetclass "Autodesk.Max.MaxPlus.Mesh"
_meshWrapper = meshWrapperClass._CreateWrapper undefined
_meshWrapper_SetValue = _meshWrapper._SetValue
pluginGraph = pluginDefinitionFile
pluginGraphDependencies = #(@"C:\Program Files\Autodesk\3ds Max 2016\MaxCreationGraph\Compounds\Twist.maxcompound",@"C:\Program Files\Autodesk\3ds Max 2016\MaxCreationGraph\Compounds\DeformMeshPoints.maxcompound",@"C:\Program Files\Autodesk\3ds Max 2016\MaxCreationGraph\Compounds\RotatePoint.maxcompound",@"C:\Program Files\Autodesk\3ds Max 2016\MaxCreationGraph\Compounds\ProjectionLength.maxcompound",@"C:\Program Files\Autodesk\3ds Max 2016\MaxCreationGraph\Compounds\MeshBoundingSphere.maxcompound")
-- value wrapper local initializations
local meshWrapperClass = dotNetClass "Autodesk.Max.MaxPlus.Mesh"
meshWrapper = meshWrapperClass._CreateWrapper (undefined)
meshWrapper_SetValue = meshWrapper._SetValue
)
fn updateMesh =
(
if (pluginInstance == undefined) then ( return undefined )
local args = dotnet_ValueToDotNetObject #(meshWrapper, angle) argsType
pluginInstance_UpdateMesh (currentTime as integer) _meshWrapper args
)
on modifyMesh do
(
try
(
_meshWrapper_SetValue mesh
meshWrapper_SetValue mesh
updateMesh()
_meshWrapper_SetValue undefined
)
catch()
ok
)
on create do
(
initialize()
)
on clone fromObj do
(
initialize()
)
on load do
(
initialize()
)
on update do
(
initialize()
)
)