Get More from 3ds Max with Custom Tool Development

KEVIN VANDECAR: All right, so I think that's our cue to get started when the door closes. So welcome everyone. Thank you so much for getting up at 8:00 in Las Vegas. How many people went to the beer bus last night at the expo hall? Well that's why you're here so early, you didn't go to that.

So I did walk through. Some pretty cool things out there. If you haven't had a chance to go through, definitely check it out. I especially like the electric cycle that the Orange County Chopper guys put together. They use Fusion 360 for that.

So this is the 3ds Max custom tool development. And specifically we're going to talk about .NET API and Python. These are the newest API environments in 3ds Max, and we're going to kind of compare those two things.

My name is Kevin Vandecar. I'm with Autodesk. My title recently changed to Forge developer advocate. So we go out and we do these kinds of events to spread the knowledge around the APIs. So Forge is our new cloud-based platform, so that's why we're kind of focusing on that as the newest technology.

So this is a programming course. So in the past, I'm not sure if I've advertised it incorrectly or whatever, but I've had some negative feedback saying, well that was a programming course and I expected something else. So feel free, if it's not your thing, don't feel like you have to stay. I'm fine with that, because this is kind of a little bit of dry material because it has to do with programming.

I'm from Manchester, New Hampshire. My email address is here. I have a Twitter handle. And we also have a blog. The blog is not as active as I would like it to be, but we're trying to get better at that. So certainly check it out from time to time if you're doing regular customization in 3ds Max.

So this is the class summary. And again, we're going to specifically talk about the .NET API, and then we'll talk about Python. At the beginning we'll spend a little time comparing the two. And it's meant to kind of give you an idea of maybe which direction to go if you haven't started customizing in either of the environments yet.

So a quick show of hands, is anyone using .NET API in 3ds Max today-- someone. OK, how about Python? OK, one. OK, great. So this is probably the right course if you're interested in programming topics. So these are the class objectives. I'm sure you read those. So I'm going to get started.

So customization is such an important aspect of our products. 3ds Max has been around a long time. You can kind of put it in the same bucket as AutoCAD. In fact, it's probably been around nearly as long as AutoCAD if you go back to the DOS version 3D Studio. Even then it had a programming environment. It was called IPAS and it was basically four different plugin types. So customization has been just really, really important to the success of 3ds Max.

So before we dive into the two new environments, I just wanted to cover a quick overview of some of the other customization aspects. Because generally when you decide to make a tool, you're going to not just program in one environment, but you're going to probably use some of the other environments as well.

So first of all, the Customize UI, how many people are familiar with that Customize User Interface dialog box? OK, a few of you, that's fantastic. That Customize UI dialog box is really your entry point to customization.

So it's found on the Customize menu. And this is 2017 I'm running. Things kind of moved around in recent versions, so you may find it in a different place. But when you when you bring up this dialog box, you'll see on the left, in most of the tabs, the actions that can be customized. What that means is basically you can take those actions and move them or assign them to various UI elements. So this first tab is the Keyboard tab. So any of these actions, which in a sense are commands, can be assigned to the element of the tab-- so in this case, a keyboard shortcut.

Now the sample code that I'm going to be showing in this, I've not programmed it to show up in the UI. I've simply used this dialog box to create a menu and put my actions on it, because it's easy. If you're just creating tools, scripts, that sort of thing, it's a lot of extra code to actually build, for example, an action that programmatically goes into the menu. Now if you're creating a commercial tool, you may want to do that. But if it's an in-house tool, drag and drop it and you're done.

So the nice thing about the Customize UI facility is that you can also take this, and you see down here at the bottom, you can say save. You can save these CUI files. And if you're kind of an IT manager or something like that in your office, you can take those CUIs and you can share them as well.

So maybe you have a roomful of artists or a roomful of designers, and all they need is maybe the modeling tools or the rendering tools. You can make them a nice little menu, and then you can share it and everyone will have kind of the same set of tools as well.

All right, so just as an example, you can see, this is my custom menu that I've created. And down here is where it was actually customized. So to customize something-- and this is something that's not always obvious, how to use this dialog box. But it's a drag and drop kind of thing. So I can pull it and drop it over here.

And if you want to create a new menu, you'd come up here and say New. It's going to ask you for a name. And at first glance you'd say, well what happened to it? Well it actually goes down here. And let's see, what did I call it-- Fred? And it's here now. So this isn't actually on the menu bar yet. It's just a menu that's in the menuing management system.

So if I want that to be an actual menu, I can drag it over here. And you'll see now I've got the start of a dropdown menu. And then I can take one of these commands-- I need to open it first-- and I can pop it there. And now you'll see it there.

So it's pretty simple. But I have to say the layout of this dialog box is less than ideal. So you start up here. You go over here. You go down here. You go over here. And then you go back up here to bring it over here. So it's a little bit funky, but it's a fantastic system once you spend a few minutes to figure out how it works.

So something that came to 3ds Max in the last few releases is the MAX Creation Graph. Anyone using that today-- so a couple of you. So MAX Creation Graph is a visual programming environment. It allows you to drag and drop these different behaviors and combine them with different object types. And it's basically a flow graph. So you have an output and an input, and the flow through the graph defines what the behavior is. So you pass in a cube. You do some modifications to it. And maybe you have a bendy cube with animation at the end.

So, I would encourage you, if you're not a strong programmer but you want to do some customization, definitely take a look at MAX Creation Graph, because it can be a lot of fun just playing with it, dropping things. And you get immediate kind of feedback on that.

MAXScript, of course, has been with 3ds Max for a very, very long time. How many people use MAXScript? So in order to use Max well, you're probably driving some MAXScripts whether you wrote them or not. So MAXScript is pretty powerful environment.

It is a proprietary environment. So learning MAXScript isn't going to get you a job using Maya, for example. So you have to kind of keep that in mind. And I think that's where the power of Python coming into 3ds Max helps that, because you learn Python. And that's a skill that, even though the APIs are different, you can take that programming skill with you.

And then the last one is the C++ SDK. So this is the heavy lifting area. If you want to do anything with performance in mind, you want to do anything where you're protecting your code base-- so maybe you're a commercial developer and you're writing something really important with some IP, some algorithms that you don't want to share, C++ is really the environment to consider.

The drawback to C++ is that C++ itself is very difficult to use. You have to do things like manage memory. So you have to create something, and then you have to remember to delete it. Otherwise you can actually cause Max to get into a bad state, consuming too much memory. You can cause it to crash very easily. And so those things kind of raise the barrier to entry.

So we're going to talk about .NET and Python, in detail. And so the first thing I'm going to do is compare the two and kind of give you an idea of which one might be better for your environment.

So first of all, the environments are quite different. So on the left here we have the .NET environment. It requires Visual Studio to be productive. You can get open source compilers that will build different .NET languages. But Visual Studio has a community edition, and it's free, so there's no reason not to use Visual Studio.

It does come with a really nice debugger. So that's built in. There's a package manager called nuget. This was one of the limitations early on with .NET in general is that it was hard to kind of consume these larger packages of functionality. So they've added this now, and what that does is it allows you to kind of pull these packages from other sources and manage them for you. This is kind of similar to the Python pip system.

So in order to use it, you have to use a framework. So this is the thing that, when 3ds Max installs itself, if your computer doesn't have the framework, it will install it, because 3ds Max uses it as well. So somewhere along the line-- and Windows now with Windows 10 is also using it very heavily. So the framework will probably already be there.

In order to build a .NET API plugin for Max, you need to use the same framework version as 3ds Max. So there's a version associated with these frameworks, and you have to use at least that minimum version to be compatible. You can use newer versions, but it's kind of limited to the functionality that's in our assemblies as well. So if the new features in a later framework don't require anything to be implemented by the APIs themselves, it'll work fine.

On the Python side, it's changed quite a bit. So first of all, in 2017, we added the ability to write Python using the MAXScript editor. So this a brand new feature. There is a type on the dropdown menu in the MAXScript system, in the editor, that says I want to do Python. And it does syntax checking, has the nice lines that show you where your tabs and indents are, and so forth.

But you can also use PyCharm. So prior to 2017, you had to use some other tool. So you could use Notepad, whatever you wanted to because it's a scripting environment. But PyCharm I would highly recommend because it's designed for Python, and it also has a debugger. So that can help you. It will work with 2017 as well, but as we'll talk about a little bit later, there's a problem with the debugger in 2017.

So as far as adding extra functionality, it's the standard Python pip mechanism. So with 2017, we are now providing a custom Python distribution. So it's no longer a standard Python.exe, standard C Python distribution. So that makes it a little bit trickier to install, but I'll give you the instructions on how to do that later. With 2016 and previous versions, you just use the standard Python tools to install any extra libraries.

The main thing to keep in mind is versioning. If you've installed a library and it doesn't seem to be loading or working for you, you may have installed a version that's not compatible with the version that Max has. So currently in 2017, we're using 2.7.6. And this is documented. Prior to 2017 it was 2.7.3. So you just have to keep that in mind. It can get a little bit confusing, especially when the difference in the version is on the third number.

So another piece that's interesting, that you may not ever use, but it's good to know, this one time inspection concept. So .NET has a facility called reflection. And .NET in itself is a pretty strongly typed language. Even though you can do things like var equals and have those morph into other types, that is managed underneath by the framework, where every API has to return a specific type. And you can cast, similar to in C++, to types that are in that hierarchy.

With Python it's called introspection. And this, because of the more loosely typed nature of Python, is not as interesting. So when you query for an API there, you may not get back the exact information that you're looking for.

Now in both cases what this allows you to do is, at runtime, you can ask for information about an API that you don't know about. So it's good for writing test harnesses, for example, because you can run this against, let's say in .NET, against an assembly, and you can query for everything without having any documentation or knowing anything about that assembly.

So we use this a lot internally to write our test harnesses for our APIs. But you might find this interesting if you maybe are using a third party API, and not everything is well documented. This concept could help you out.

Now the tools that you will use, especially in .NET, actually use this concept. So if you use the Object Browser in Visual Studio, it uses reflection to be able to list all those APIs. That same idea doesn't exist in C++, for example. So that's a huge benefit with .NET is you can basically open an assembly and see everything that's available in that API.

So the evolution of these tools, just to give you a little bit of history-- and this is why I say these are relatively new environment. So we're going back to 2012 for the first complete .NET API. But if you look at 2012 compared to 2014, they came relatively at the same time in the legacy history of 3ds Max.

So the .NET API kind of came in chunks. So they started writing .NET utilities to help them with different parts of their UI, especially. So the ribbon, for example, is a managed .NET tool. So they kind of started writing them for their own purposes. And then they realized, well this is kind of useful. So then they exposed it to MAXScript so that you could actually load DLLs through MAXScript and access other people's .NET utilities.

And then they said, well, we need a .NET API. So they went out and-- there's a company that was producing the State Sets that we acquired. Their name is Ephere, E-P-H-E-R-E. And they had their own .NET API that they consumed for their feature. And that piece came with it.

So the interesting thing about this is this assembly, Autodesk.Max, is what we call autogenerated. So there's a tool that looks at the C++ SDK and builds the .NET API wrappers from that. So it's kind of an efficient way to build an API, but it's not the best, from a user standpoint. So it's not very user friendly. And we can run into problems.

So one of the biggest ones is this IntPtr problem. So an IntPtr is a type in .NET. IntPtrs are a wrapper around a native C++ pointer. So because we're wrapping a C++ API, if we can't map that C++ type to a managed type, it defaults to IntPtr. And there's not a lot you can do with an IntPtr by itself. So for example, if you see an API that is-- maybe it's a function that one of the parameter types is IntPtr, inside that function, you may not know what the IntPtr stands for.

So the first thing to do is look for what we call marshaller code. And that is basically a class that will take the pointer and convert it back to a managed type. So node is a pretty good example of this situation. In some cases, node doesn't get mapped properly, and you can use the marshaller code to convert that IntPtr to a proper managed node.

The other drawback here is that the docs-- we have much fewer docs. So it's actually part of the C++ SDK. And let me just click here to show you real quick how this works.

So the latest Max help has now got this really nice table of contents. The SDK documentation is in the 3ds Max developer help section. And in that developer help, there is a .NET SDK section. So this gives you information kind of at the high level of how to work with .NET and use it in 3ds Max, but it doesn't have an API reference.

So the reason for that is because we are wrapping the C++ SDK. They decided not to put a lot of effort into specialized documentation. So what you really have to do if you want to learn about a particular API is go to the C++ reference and put your C++ hat on in terms of what it looks like. The naming conventions are the same. But you'll look at it and you can read the documentation and how it's supposed to behave that way.

Now, we go back to the Python side. So this is more recent. So this first showed up in the 2014 extension release. And at that time it was definitely not complete. So they started with this MaxPlus API. A good example of where it wasn't complete was they exposed the standard TriMesh, but they didn't expose MNMesh, which is the quad mesh or polygon mesh. So you could do things with tri objects, but you couldn't do things with poly objects. So it was a huge limitation, and people complained immediately. So that's the case of where, over here, having a full wrapped API can be more useful because it's there, as opposed to being more nicely formed but not complete.

So in 2017, we made a significant change. So one of the things we did was we wanted to make the Python API more complete. And without creating new APIs for every single function, we decided to expose the MAXScript API through Python. So now you basically have a complete API, but you have to think in two places. So the first MaxPlus API is a C++ oriented wrapper. And the rest of it is a MAXScript runtime wrapper.

And this did get some special documentation. So the nice thing here, so when you go into the Python help, it's actually a top level section in the documentation. So it's got its own section. It's got its own API reference, much better formed documentation.

So let's talk a little more specifically about .NET. So why would you use this one? Why would you choose this one over Python, for example, or over C++? First of all, it's a very mature environment. It's in other products. Does anyone use any of our design products as well, Revit, AutoCAD? So .NET becomes kind of a natural choice because those products also have .NET APIs. So you're already probably familiar with the .NET environment. So use the same environment, just learn the API.

The other great thing is that .NET has been on the market for a long, long time. Microsoft is continuing to support it very well. They use it as well. So it's a very good, highly mature environment, lots of community people, lots of network or internet resources. So if you get stuck, you don't have to rely just on our help, but you can go and find community help.

So what can you do? You can automate tasks. So you can interact with MAXScript. So this is an interesting concept is if you want to expose, for example, some functionality out of .NET to MAXScript, you can do so. So you could write some of the maybe more performance-oriented algorithms in .NET where you're getting kind of that C++ level of performance, export those functions, and maybe continue to build your UI or have some other basic scripting things going on to call your .NET functions when they're needed. So that's definitely possible.

If you're a C++ programmer and you have a plug-in already, you can also use C++ CLI to provide .NET APIs. So if you, for example, might be a commercial developer and you wanted to provide your customers with a .NET API, this is the facility to do that. So it's kind of a heavy area to learn, but if you're already in C++, it's not not too bad.

And from a UI perspective, so we definitely support the older Windows Forms. But the newer UI mechanism is Windows Presentation Foundation, WPF. This uses a combination of .NET code and what they call XAML code. And you basically build these partial classes that bind together at runtime. And you can build some really nice UIs. The Visual Studio tools provides WYSIWYG, so you can basically drag and drop controls and get some really nice behavior there.

And you can also use other .NET API components. So features of the language, for example, Linq is a really powerful facility. It's a simple idea, but it basically allows you to do database-style queries from runtime data structures. So let's say, for example, you've iterated the scene and you have a list of the nodes in the scene, and you want to select all the lights or all the, I don't know, the cameras out of that list. Linq will give you the ability to do that in one line of code. So it's basically a query. You say something like, for all the lights in this list, give me a collection back. And it's as simple as that. You don't have to iterate the list. It's really powerful.

So to set up for .NET, you're going to create a new class library. So this is called a Windows class library. It basically produces a DLL assembly.

Typically people use C#. But the nice thing about .NET is that it is language agnostic. So if you prefer VB.NET, for example, you can use it.

Know that C# is probably the most dominant language used in this environment. All of our code samples are written in C#. So if you haven't started and you don't have a preference, I would highly encourage you to consider C# as your language. Very useful, nice syntax, it's a good language.

So once you have that class library, you then simply reference our assemblies. So we'll talk about the assemblies next.

So the most important assembly is this Autodesk.Max DLL. So you'll reference that probably in all cases. This is what provides you with that full functionality of the Max API.

These other ones are useful. So don't exclude those. But know which ones are useful and which ones are not. When you look at our samples, you'll see a mixture of this one, CSharpUtilities. And the ManagedServices is also one that you'll see.

And then this one is really important for creating an action item. The name itself is kind of a weird name. And it was for another project. That's why they created it. But it has a utility in there that creates these user actions that register themselves back with that CUI system so you can drag and drop them on the menus and toolbars.

So how is your code loaded? .NET is a little bit restrictive in this capacity. You have to place them in this folder. That is your main option. So the problem with this is that it's part of the install location, and so there's the Windows security that you have to deal with. So every time you put something there, it's going to ask you, really, do you want to do that-- yes. Are you an admin-- yes. Are you sure-- yes. And then it will go.

For that reason, because I'm primarily developing all the time, I usually put my install location outside of Program Files. So that's just a trick. If you're not just a daily user and all you're doing is kind of writing code, that might be an option, because you get away from that security then. It's not a Program Files issue anymore.

And this location basically is there already. So you don't have to create it. We have some components in there. And you just simply copy your DLL into that location and it will load automatically when Max starts up.

We also have the app store folder that you can use. And that's another alternative. But it requires a special XML package to define what that assembly is doing and where it's at and which version of Max it can run with. So it's definitely doable, but there's a little bit of more work to do to get it to--

AUDIENCE: Is that similar to [INAUDIBLE]?

KEVIN VANDECAR: Yeah, it's exactly the same. Max has a few tags that are a little bit fussier than AutoCAD, but it's the same idea. So you just create that XML, put your assembly in that folder structure, and it will autoload then. The sample code that I'll show later, the Explode Geometry, has a bundle, so there's a great example of a .NET assembly going in that location.

So once the assembly gets loaded, how do you get your code to actually execute? So there's two fundamental ways. The first is the CuiActionCommandAdapter-- terrible name. I don't why they called it that. But you can see it's at least CUI and action. So those are your main clues that this is an important class.

So this allows you to easily hook into the UI using that action system. And it simply asks you to implement a derived class with a few strings that show up in the menuing system, or the UI system. And that functionality is provided in this assembly. So you need to reference this assembly just for this functionality, at a minimum.

The alternative is the Assembly Loader. So this allows you to do something similar to the global utility plug-in. It basically will allow you to execute code when 3ds Max starts, and execute code when 3ds Max shuts down. That's its primary function. It also has a loader facility. So if you want the majority of your assemblies to be located somewhere else, anywhere else, you can actually use this. The main class in this assembly will allow you to load from other locations as well. But this one has to be in that bin assemblies folder in order for it to load at start. And then whatever code you have in here can manage loading the other assemblies.

The limitation to that is that the loader here will not initialize this. So you don't get the CUI action behavior if you load your assembly through the Assembly Loader facility. So it makes it kind of useless.

I have seen people use it though. They tend to use the Assembly Loader mechanism and execute code on startup to set up their scene. And so then they have a whole bunch of these assemblies that do different things, and they load the one that's appropriate.

Again, interop-- so by default, any classes and functions that are defined as public can be exported to the MAXScript environment. The drawback here is that only primitive types are shared, so things like ints, floats, doubles, types that are built into the language. A node, for example, you cannot return a node to the MAXScript environment.

But there are ways around it. So node is the most popular question. I need to get my node passed back and forth. So instead of returning the node, return the node's anim handle, which is an integer, and then you just convert it back to a node on one side or the other. So that allows you to pass the node identifier back and forth, and then work with the node on either side. And then again the, C++ CLI. So there's good help topics in both of those cases.

Now to debug, there's two ways. So to use the direct debugger, the first thing you have to do is you have to point the debugger at 3dsmax.exe. So you can't just debug a DLL without having a process to drive it.

So you point the debugger at 3dsmax.exe. And then you press debug. And then any of your breakpoints will be hit once Max loads your assembly and starts executing your code.

In order to use it in Visual Studio 2015, you have to set this specialized flag in the debugger within Visual Studio. This is because Visual Studio came out with a better debugger. And if you're just working in the managed world, it is better. But when you have-- [COUGH]. Excuse me-- a mixed mode application like Max-- Max is written in native code and it has this managed layer-- you have to check this in order to get the legacy debugger. So if you miss checking this, the behavior you'll see is that as soon as you start the debugger, you'll get the [INAUDIBLE] dialog. So you'll know oh, I've got to remember what Kevin told me.

You can also attach to process. And this does not require you to change that flag. This is a little bit more effort to get your debugger started. So you will start 3ds Max. You'll be in a fully running instance. And then you'll go back to your debugger and say attached to the 3dsmax.exe process. And you'll want to use the managed native code option, because again, Max is a mixed mode application. And that sets the debugger to the right mode to debug.

So samples are a little bit limited. We don't have any samples that come with the .NET SDK. So we've provided a few from my group, from the ADN group. So first of all, this Explode Geometry, it is available as a full app. So you can go to the app store and you can just download it and try it and it's there. And then the full code is provided in a GitHub repo here. And this is using the CUI facility.

So let me just show this as well. So I've already started 3ds Max under the debugger. So you can see Max is actually running here. Let me see here, let me start this.

OK, so this is the dialog that accompanies the plug-in. This was written with WPF in mind. I can basically have a node selected in the scene. When it comes up, it's going to check to see if a node is selected. And if not, it'll warn you, say we need a node. And then the dialog displays. And here's where you can select different options.

So I'm just going to go ahead and run this. And you'll see that I have the debugger active, and it just immediately steps into my code. So this is a very nice environment for doing detailed applications because you have a nice debugging tool that's easy to set up. Python-- I'll show you that in the next section-- is a little more difficult to get this to work in and be useful.

So the first thing you're going to see is the entry point into the API. So this code right here, you'll see is using our Autodesk.Max. So that's the namespace from the Autodesk.Max assembly. And what I need to do is get the global interface for the API, and get the running instance of that. So this gives me that global instance of the highest level entry point into the API.

Once I get that I can drill down. And Max has this idea called the Core interface. That's why my blog is named GetCOREInterface because that is really the entry point into a lot of the things you might want to do with the editor, geometry, et cetera. So usually you'll have these two lines of code to start any type of programming in the Autodesk.Max interface.

And you'll see here, this is a function that is exported to MAXScript. So it's receiving an integer. It's an unsigned integer. And it's the node handle. So the first thing I do is I convert that node handle back to a node. So you can kind of see how you can pass identifiers back and forth, but you have that limitation where you can only use the primitive types.

And then as we drill down through here, you can see there's a lot of code that does specific things to the geometry. And in the end what it's going to do-- let me just go ahead and run this-- it takes whatever you've selected, and it iterates the entire mesh, looks at every face in that mesh, and builds a new face, and then applies-- oops, let me select one again-- and then applies these various options to that individual face. So it shows a lot of basic ideas that are useful in the API-- iterating a mesh, converting that to something else, building new geometry, the faces, adding a modifier, collapsing the modifier stack, so things that you might want to automate. So hopefully that's a pretty good sample.

It's pretty detailed and we've we've had quite a few downloads of it. So as a utility, I think it's useful in itself. So feel free to go get it.

The other samples here are just showing various UI aspects. So I'm going to just demo this particular one. So first of all, I want to show the CuiActionCommandAdapter. So let me go back up here. So you can see what I've done is I've created an abstract class off of that command adapter. And I've implemented some of the things that you would repeat each time you create a new command. So it's just kind of a base class to provide a common category for that CUI dialog.

And then from there, I implement my specific command. In this case, this is the command text. And this is what-- let me just go ahead and run this. This is what you see up here, WPF viewport sample.

All right, so this particular sample is an interesting one. It's not well-formed. If you have a lot of things in the scene, you're going to get this big long list. But it shows the power of WPF. In this particular case, it's got a transparent dialog holding the controls. So you don't see the outline of the dialog itself. And then the controls have a transparent characteristic applied to it so you can see through the controls to the viewport.

I've also implemented listeners, so using the event system, to know when the active viewport has changed. And then I move that dialog into the viewport that was selected. So this shows some UI behavioral things that you might be interested in.

It also uses what I mentioned earlier, the Linq facility to subset out of a big list. What I can do is, you can see here, this is the scene list of all the nodes, and there's a lot of faces now. If I wanted to list only the lights, there's one line of code that actually does that work to subset the lights out of that big list of nodes based on its type.

So the sample code shows how to work with that as well. And it also shows doing scene selection through a dialog. So by name, I can say I want to select those nodes. And using the Core interface API, I can actually make those nodes selected.

So before we move on to Python, any questions with .NET so far? Yeah?

AUDIENCE: Is both 3ds Max from the [INAUDIBLE], or do we need to add [INAUDIBLE]?

KEVIN VANDECAR: I didn't catch the first part of the question.

AUDIENCE: Can you basically do a headless [INAUDIBLE], like headless, you don't want the UI from Max at all? You want to just [INAUDIBLE] the Max [INAUDIBLE]?

KEVIN VANDECAR: So Max itself has the ability to run headless. So using the assembly loader where you can execute code on startup, you could definitely do that.

AUDIENCE: [INAUDIBLE].

KEVIN VANDECAR: Yeah. There's no extra .NET functionality though that tells Max at runtime to go headless or switch modes or anything. But certainly at startup, using Assembly Loader, you could execute some code and drive it that way. Was there another question over here? OK, all right.

So just a few tips and tricks before we move on. One of the big things in .NET is that there is this idea of a Global Assembly Cache. I call it the GAC, which is a nice word to say, GAC. Oh, you can't see it very well.

So over here you see, for example, there's the CSharpUtilities assembly. And in its properties, there's this flag called copy-local. Now whenever you reference an assembly from disk, like you have to do for 3ds Max or AutoCAD or whatever-- it's the same ideas as in AutoCAD and Revit-- this flag, by default, is set to true. The reason they do that is, they make the assumption that when you build an app, whatever assembly you're referencing needs to be copied to the project folder of that app so that there's never a version change. You're always running with that assembly that you started with.

But that doesn't work well for mixed mode applications like 3ds Max or AutoCAD. So you need to set that to false anytime. Just get in the habit of remembering, reference assembly copy-local false. Because otherwise what will happen is, you'll be copying an assembly. And then when you move to the next version of Max and you update your project, it won't get the next version of the assembly. And you'll have the wrong assembly. And now it will crash Max when you're running. So you want to reference this directly from the Max EXE folder, and you want that reference to stay for Max EXE folder. So when you move forward, you'll get the new DLL automatically. And that helps you to manage your projects going forward. So just remember that. That's an important one.

If you actually build your code to that folder, it can cause even bigger problems, because it copies also all the dependent modules along with it. And it can pollute that bin assemblies folder. So this is really an important thing to keep in mind.

Max has some environment variables too, if you're not aware. So I encourage you to get used to using those. They all start with ADSK. And for example, for 2017, there's the environment variable. So you can use this environment variable in your projects to point to your assemblies. And then when you upgrade your project, all you have to do is change the environment variable to reference the new assemblies. You don't have to go through the UI and unreference and rereference. You just edit the Visual Studio C# project file and change your environment variable there.

So think about adding a post build event to copy your assembly rather than just build to that location. So build it locally and then add a post build to copy it to the bin assemblies folder. And that way you eliminate some of that copy local issue. And then, like I showed, create an abstract version of the CuiActionCommandAdapter that has the base stuff filled in, and then you only have to implement the specific command name in the following command.

Use reflector tools. So Object Browser is a type of reflector tool. But there are some third party ones as well that are really useful. ReSharper is one that's from the same people who make PyCharm.

Make sure you error check. So you'll see in the sample code, it's not perfect, but every single API call is at least wrapped in a try catch block. OK so that's important to trap any of the exceptions that might occur so that they don't get passed to the Max EXE and cause it to crash. So if you capture them in the ManagedProcess within your code, you can handle it, and then Max doesn't have to freak out and die.

And make sure you use all the assemblies. Don't just think that Autodesk.Max is the complete deal. You'll definitely mix assemblies.

And the last thing is something we talked about before the class started is, you want to be careful to not derive from this Max plug-ins type. In theory you could create a full plug-in in the C# world, but there's a lot of problems with it. And we're not supporting it. So we've even documented, it's not advised to do this.

And last one is, the Python MaxPlus API actually has a .NET counterpart. So you'll find it maybe if you're poking around and say, wow, there's some useful APIs here too. So I like to use them, but be aware that we are not officially supporting that particular assembly for .NET, because we might remove that .NET aspect of it at some point in the future. So it's useful for the version you find it in. Just know that ahead of time if you're going to use it. Don't expect it to be maintained going forward.

All right, so let's switch over to Python. All right, so Python, same kind of thing. It's very mature. The thing with Python that I like to think of is that it's kind of the M&E choice. There's Maya, MotionBuilder, FBX SDK all have Python interfaces. So if you're interfacing with those tools already, then Python's a logical choice.

It has a very large community. If you're a person who writes in Python, usually you love Python. You dream about Python. You talk to your wife about Python. You get divorced over Python. So it's just a very, very powerful community out there. And it is open source as a technology as well. And that's why a lot of companies have chosen Python, because for free you can go and get a language environment and put it in your product. So that's just one aspect that makes it really, really popular. And there are tons of third party libraries.

Now the thing you have to be careful with here is, is that third party library-- does it have a compatible module that works with the 3ds Max version of Python? So you have to be careful. Before you get really excited, try to install the library and make sure you can import its namespace. That will tell you if you can use it or not.