Max Script is used for the UI only and not the calculations. It is all calculated in C#.
I can read either just as well. Also, the tool that you just created is of no use to an artist that doesn’t want to change variables and evaluate code.
I don’t understand why you are so negative about this.
MCG has been written in the last year, not four.
http://area.autodesk.com/nab2015
http://livestream.com/autodesk2015nab/events/3963481/videos/83861904
Gary shows a bit of MCG in his presentation.
i’ve only asked to show any example how MCG works by people who already get it and use.
i’m usually using everything that works well in the max, and i just want to understand how useful MCG might be for me and how much my time i can spend playing with it.
I think that you have done far more complaining about it and telling people that it isn’t any good and you have not even used it or seen it used. I agree with some of your points, a seasoned veteran like your self can produce a better product with C++ or well scripted Max script then can probably be done by an artist with MCG. But from there on in I think you are completely missing the point of it.
Here’s an old example I did during beta, it does volumetric calculations based on the amount of length a ray spends inside a mesh while traveling from a vertex to a given light position. (amount traveled inside results in a darker vertex color, poor man’s SSS without the scattering)
I did this in my Voluminance maxscript as well, 10 to 20 sec to calculate a setup as shown in the viewport grab, with MCG and Embree it is actually interactive.
http://www.jdbgraphics.nl/clients/mcg_volumetric_0000.mp4
And there is a delta mush as well… will all be released in due time, here is an older proof of concept demo of it in action: http://www.jdbgraphics.nl/clients/deltamush.mp4
i just wary that our company framework will be littered pretty soon by very unsafe and amateur tools produced by MCG. as well as max scripts resources …
That is for you to manage. It doesn’t mean that the tool can’t be used to create excellent and fast solutions to production problems. Really what you want is to have MEL, Python and Max Script removed from the software so that only you can create tools.
I have worked on many productions and many haven’t had the man power to be able to create every tool in the most effective methods and any method that will help the production get done is used. In fact MCG will solve many of those problems for you since it is just in fact nodes tied together and does much of the error checking for you.
I have been on MCG for some time now and I have never had it crash, even in alpha. It is very easy to write a Max Script that will fast exit Max or a MEL script that will blow up Maya. Does that mean that all MCG flows will be perfect, not a change, what it will allow is any productions that can’t afford high end programmers on staff to have a tool set that will give them fast and flexible solutions to problems. Your argument against MCG is the same argument that the C++ programmers had about Max Script but here you are using Max script and telling us that you would rather use it.
MCG is a tool some where between hard core C++ and Max Script and opens it up to a community of artists that would rather not take the time, or don’t have the time to learn C++. I’m sure that I will use it all the time when I need a solution that it is best suited for.
another my point is that many old bugs and issues are still remains untouched for many years… but developers add new source of the max system instability.
and again… can anyone tell me what MCG was designed for? what is the area covered by its products? who is a target user?
Target user is everyone. It is not a replacement for Max Script or C++.
As for bugs still being there please tell me that Maya doesn’t have any next.
I think that we have already discussed what MCG is for. It is for visual programming anything that you need. At this stage it works on geometry only.
looks good… but i remember you as a solid tools developer before MCG.
my question is – will you not be happier to get this tool written on c++ ?
Maybe it would but that doesn’t invalidate the usability of MCG does it. If he can do this in MCG and doesn’t know how to do it in C++ then it is the perfect tool for the job. Being that it is real time does it need to be done in C++?
Yes of coarse! But there is not always time for that, I’m a generalist and half the tools I make I use maybe a few times on specific projects so I just throw something together quick and dirty that does the job. If I need to tool more I’ll refine it, maybe even add a UI So my tools grow and evolve when I use them more often and are left to die in the archives if I don’t. Basically this:
win = Time spend on developing tool < time won by using tool.
And MCG will for a lot of people reduce the time spend on development a lot, Even if the tool is ‘less pure’ of not the highest speed, it will still gain them an advantage in their workflow. (Not to say MCG is slow! ) And MCG has it challenges as well, it’s still programming, you can do things in different ways and there are puzzles to solve.
but you have to agree that having a code is much easier to appraise its safety.
I don’t think that I can. I have not crashed MCG even once. So far I have not had any issues with it at all other then growing pains of its development. You assume that every one that writes code can do it as well as you can.