[Closed] MCG Loop with current index and value
I just recreated the code in 2018, but I got an error. do you have any tutorial that shows how “PassThrough” works?
hmm…MCG death knell ? Not that it worries me…i’m still doing mostly in 2017 rather than 2018…cozzzz…believe it or not I don’t see 2018 as much of a challenge…it’s like being spoon fed…yes you heard it folks…that means MCG 2018 is easier to use…but I’m a sucker for punishment.
I myself also stopped ‘moderating’ the site, since I ‘sell’ stuff…it’s just simply conflict of interest so I rule myself out…I’ll still help noobs questions tho.
Well at least I know not to expect any new MCG goodies any time soon…it’s alright, got Houdini to keep the brain going.
You’d need another passthrough to tell it it’s an array of integers, not a generic array.
New problem is that my tool failed to open because of that error! I had to recreate it again. Where I should add Pass through?
Would you please describe to me why you used Pair? if you used to pass inputs, what if we have multiple variables that we want to use inside loop, like Val1 Val 2 Val3?
another problem is “TraceWithLabel” should print out the i, but does nothing.
You wanted both i and val so this gives you that, first item in the pair is i, the second one is val.
As for your second question, it does nothing because it’s not an active node, you have to connect its output to something that’s processed for it to make anything at all. Connect it to the plus one
So if we have multiple input? for example:
Val = 0
Val2 = 20
for i = 0 to 10 do
(
Val = i + Val
Val2 = i * Val2
-- >> Out i
-- >> Out Val
-- >> Out Val2
)
Then you use triple instead of pair, but that already smells of bad approach anyway. Usually, you’re better off processing items inside the loop rather than after the loop.
It is possible, though not officially supported.
The math portion is MUCH faster than maxscript, for the rest it really depends. Working with meshes is a tad more complex topic since they went with their own trimesh type that doesn’t support most of the operations native mesh does and adds a few of its own. You can achieve much better results if you avoid the whole maxPlus functionality and use the .NET API directly though (plus you get intelliSense and proper debugging tools) – if speed is what you’re after, I don’t see why you’d choose MCG.
all calculations and data management is usually faster with MCG. but the way how events are handled in MCG final code is not always better than you can do with mxs…
for example:
making a mesh build is four times faster in MCG vs MXS
but MCG makes a build eight times where only one is neccesary
so, what is really faster?
Also when deciding, take into account the cost of immutability when operating on any moderately complex type like a mesh – i.e. every MCG node that does something to a mesh returns a new independent copy of the input mesh. Unless you take that into account (and not just for mesh), you’re in for a nasty performance surprise. Now, immutability is really nice and makes it easier to reason about what’s going on, it’s just that sometimes, that’s not without a cost.
Actually I’m not a professional programmer, So I prefer to use existing functionality within Max, especially when I want to work on performance. So what about this pipeline which is in middle:
Using scripted plugin directly.
Exposing some MCG functions which are faster to MaxScript (for example mesh functions).
Writing some new functions in CSharp and load them in assembly + some WPF custom controls may used for drawing in UI.
Eight times? why this happen? is it not possible to solve this? you don’t think it may change in new feature?
You mean in C++? I don’t think MCG uses c++ at all, just scripted plugin and .Net. if you look at script created by MCG, you see some .net class used like “Viper3dsMaxBridge” to compile codes created by MCG. But I have a general question, do you think MCG is faster than general code inside scriptedplugin?
To tell the truth, that sounds extremely complicated and error prone (plus MCG operations are faster on MCG triMesh, you have to create that from max mesh and then create max mesh from it and set it again; in the process you lose explicit normals, vertex data etc). Pick one approach and try not to mix them; and if you decide to mix them, benchmark a lot, you might find out in the end the speed advantage is lost on translations from mxs to dotnet objects and back.
The more I research about MCG, I find that there is big jump from 2017 to 2018, many operators are completely new. I think they finally changed “What we can do” with “What we should do”. There are many operators that never used in any tutorials, but i think we can make very creative thing with them(based on their name and description) .
No idea who’s in charge of MCG (Autodesk is not exactly transparent, who can name the current 3ds max Product manager off the top of their head, for example?), last I know Martin Coven worked on fluids.
Now I have two main problem with MCG:
We have limitation in inputs, for example we can not create curvecontrol.
We can not control event handlers for example on “Load” event.