I was reading over the Selection Sets Errata thread and the inclusion of the .NET framework, and I have to agree that it’s one of the biggest features to come out in recent years. My next question though is what does it mean for scripters? I’ve been out of the lower-level programming crowd for a while (mainly scripting), and .NET is a magical far away place for me right now.
I wanted to get thoughts from other programmers as to what .NET access in maxscript could do for our tools, and if/how it will change the way we do things.
I’m just guessing here as I haven’t tested 3ds max 9 yet. I don’t know the possible limitations (if any) in the .NET uses.
But if you can use any .NET class could mean that you could use your own .NET assemblies created using any .NET language (Managed C++, C#, VB.NET and whatever language that can output MSIL code). And that would be awesome because creating extensions for MAXScript (that in theory it would run faster than plain MAXScript) would be really easy. Imagine that you already have a C# class that contains a lot of useful math methods. You could call all this methods inside MAXScript. Using your own matrix, vector or quaternion classes should be possible too (obviously some MAX data types <-> .NET data types conversion could be required).
Even (and as I said, I’m just guessing) you could create your own .NET compiler using MAXScript as is being done in games and tools nowadays. So this way you could use C# (for instance) as scripting language (inside another scripting language like MAXScript :applause: ). That means that you can put your C# plain code (not compiled) and let MAXScript/.NET compile your classes into MSIL code. This way, you can modify your C# classes easily without the need of a .NET development environment (MS Visual Studio 2005, for instance) because the compiler is already in the .NET framework.
It would be great if someone could confirm or deny this things.
Anyway things paint really promising!.
im intrested in this too.
ive had a look through the max help at the dotNet stuff. Is it mainly for UI stuff? Or can we actually write a c# plugin without the use of maxscript?
the examples in the maxscript help are mainly maxscript mixed with .net forms and such.
Hopefully C# can be done on its own, which would hopefully mean very fast scripts?
I agree with others that the .NET feature is the biggest new feature in years.
Here’s what is really happening. The .NET framework is really just namespaces, classes, functions and enumerations that target the Common Language Runtime (CLR). The common language runtime is a kind of abstraction layer between the operationg system and your application. Right now Microsoft offers 4 programming environments that target the CLR. First is C#, which is the nicest, sweetest programming language currently available. The rest are j#, C++ and visual basic.
The Maxscript .NET exposure is more along the lines of making maxscript one of those 4 languages. The python people made a bridge to the CLR. Now I’m not saying maxscript is an equal citizen like c#, since maxscript operates only in a limited place (no one has tried to create a ‘class’ with inheritance in maxscript… ), but now maxscript can access the .NET framework just like any other programming language. So usually when I need to access information in the MSDN library, I just filter the documentation by C#, since that is closest to maxscript.
Anyways, the one of the big things that is now possible is to create your uber, wiz-bang controls in c#, and use those in maxscript.
Other benefits of .NET.
- No memory leaks
- safe code… No pointer mismanagement that has characterized / plagued C / C++ for the last 25 years…
- .NET doesn’t rely on the system registry
- This is what programming and the microsoft API should have been like 20 years ago. etc…
I highly suggest Jeffrey Richter’s book “CLR via C#” by microsoft press if you want a good introduction to the .NET framework.
Last of all, in a practical sense, it means I can now easily use the .NET framework’s XML classes to easily and quickly output data. Very cool in my opinion.
The other thing I’m looking forward to using is regular expressions.
I hope they keep Maxscript and the other programming languages as far apart as possible, but it sounds like it’s too late. My reason… I don’t want to learn C# or C++ or JAVA or what not, just to do my Maxscript. But, if the .NET functionality was introduced as an available addition, not an attempt at replacement, then I guess I can live. I just don’t want Maxscript to become what the SDK essentially is, a higher level programming API. If they don’t keep Maxscript relatively simple, I’m not going to be able to keep making fun tools for myself. I already tried briefly to get into Visual Studio… I own a 2002 version of the whole pack but I just can’t spend that much time dedicated to programming to learn it. I have a full time job that does not involve Max or maxscript.
create your uber, wiz-bang controls in c#, and use those in maxscript.
Can we use Visual Studio C# 2005 Express for this?
Ooooh… hell yeah!
Thanks for the breakdown chris!
Stay cool, Mane.
There is no attempt to replace MAXScript (that would be an amazing trick on itself), there was (as CJ explained in another thread) just an attempt to replace ActiveX controls because MS decided to more or less abandon them on 64 bit Windows.
The goodness coming from the DotNet exposure of MAXScript is thus just a side-effect of the necessity to support DotNet Controls and a testimony to the dedication of the MXS developers who went the whole distance with this implementation (and then some).
So if all you need is another TreeView control in a MAXScript Rollout, instead of using an ActiveX control, you would use a DotNet control (see example of porting TreeView from ActiveX to DotNet in the MXS Reference 9 and you will see how similar the syntax is).
For those who already work using C# (for example the majority of code at Frantic Films is written in C#), this means whole new possibilities for integration, code sharing and functionality reusage. But it is really just a new option.
.NET controls in rollouts. Fantastic! Well done 3dsmax devs.
Bravo guys, can’t wait for this implementation!
I don’t see why not. Though I would probably want to look at the break down of features for Visual studio 2005 proffesional and the express edition.
In fact you don’t have to use rollouts at ALL… if you don’t want to… Just use forms instead
function whenButtonIsPressed a b = ( print "Pressed from a .NET button" format "Arg a: <%> " (classof a) --The sender showproperties a format "Arg b: <%> " (classof b) --the parameters, args etc... showproperties b ) local mButton = dotNetObject "System.windows.forms.button" mButton.text = ".NET Button" mButton.size = dotNetObject "System.Drawing.Size" 100 100 mButton.location = dotNetObject "System.Drawing.Point" 50 50 local hForm = dotNetObject "System.Windows.Forms.Form" hForm.controls.add mButton hForm.topmost = true dotNet.addEventHandler mButton "click" whenButtonIsPressed --Finally display the image hForm.show()
besides other statements you made - that’s the one i sure don’t believe …
or can you elaborate ?
Good to know that!. Our last 3D game engine was developed entirely in C# + Managed DirectX and it worked great.
Hey, that was one of the doubts I had. So you can use normal MXS functions as event handlers/callback functions. Great!.
I wish they would create a C# wrapper for the SDK but I think this is something that carry a lot more work (and maybe a lot of headaches). Do exists plans for that?. I used to code in C++ but since I tried C#, is a pain to go back to C++ (but sometimes it’s irremediable).
As of now, I wouldn’t want that to happen. The SDK needs a little polishing up to clean up the rust from 6 years of being locked.
Jeffrey Richter in his book “CLR via C#” states that “framework components are not referenced by the registry. … Installing most .NET framework applications require no more than copying the files to a directory and adding a shortcut to the start menu, desktop or Quick Lauch toolbar. Uninstalling the application is as simple as deleting the files.”
Thanks for clarifying… much appreciated and relieved. I’m not against adding additional options or functionality, obviously. I was just scared that Maxscript had just become much more complicated than it used to be. Now I can try to expand my knowledge and scripts as time permits.
I see you’ve spotted my fiery temperment .
Cheers, and regards,
Well i agree, this is a big one!
What alpine said really has the biggest impact on the way you develope tools and interfaces in max. personally i will never write a rollout again, except for custom attributes.
you can now use .NET forms to write your complete UI. this includes very very easy to manage tabbed interfaces, just to mention one very basic example.
the biggest advantage of .NET forms over classic rollouts is their openness. anyone who ever had to dynamically generate rollout code using strings and ‘execute’ knows what i mean. (this is probably every intermediate maxscript user)
the next biggest thing (this is one of the things that i would consider ‘the whole distance and then some’, to quote bobo) is that you can actually store maxscript values on .NET classes using their .tag property.
e.g. let’s say you write a controller tool using .NET treeview, you can store the controllers on their corresponding tree nodes/leafs. very similar to what you can do with kees’ helium.
also, .NET controls have dozens of event handlers, instead of 1 or 2 for some maxscript ui controls. if you ever wanted a right click event handler for some button, this is your solution.
way to go autodesk!
to really get an idea of what is possible now, you might want to take a look at paint.net on the microsoft site, which is written with .NET. with maxscript, .Net and some C# additions you can do all of this in max now.
I think this is all good, but people who writes code that support more than 1 max version will not be able to put them into use, right?
Only for tools that need to work under max 9 and forward, which is good too.
Rollouts are just the beginning.
(more examples of DotNet usage coming…)
Also see my WIP reference of most Forms and classes referenced by them: