Is developing .net plugins for 3DS-Max deprecated?

Is developing .net plugins for 3DS-Max deprecated?

Anonymous
Not applicable
2,013 Views
4 Replies
Message 1 of 5

Is developing .net plugins for 3DS-Max deprecated?

Anonymous
Not applicable

We invested some time trying to figure out, how to write .net plugins for Max3ds with C#. This would have been an incredible gain over maxScript.  What we've learned:

 

  • Most documentation is either poor, incomplete or outdated (or a combination of the above)
  • There are no working examples that can be build (and loaded) with current versions of Visual Studio or Visual Studio Code  (although this and this might help you).
  • The "plug-in-manager" only lists c++ plugins (which is a severe bug IMHO).
  • Loading .net plugins for custom paths (other than C:\Program Files\Autodesk\3ds Max 2020\bin\assemblies\) doesn't seem to be supported.
  • 3dsMax depends one the no longer maintained .net version 4.0 for which development SDKs are not longer available by Microsoft.
  • There is no proper why of testing the loading of  .net plugIns (e.g. console, log files, or other means) besides clicking around in the UI.

 

Our current assumption is, that this technology is no longer maintained or supported by Autodesk and the documentation should point this out. If this is not the case, the documentation needs a complete overhaul, and a step a step guide that illustrates how build plugins can be loaded. Especially how to validate that plugs have been loaded correctly other than ProcessExplorer.

 

@drew_avis  If we missed something, we're very happy for any pointers.

2,014 Views
4 Replies
Replies (4)
Message 2 of 5

kevinvandecar
Community Manager
Community Manager

Hi, I have also replied similar to the other thread where you posted similar: 
https://forums.autodesk.com/t5/3ds-max-programming/net-plugin-quot-lesson-7-quot-sample-doesn-t-work...
Adding info for the custom paths question...
* You can use assembly loader for pure customer paths
* You can also use the package loader (see explode geometry example mentioned below) This is best solution as it keeps it independent of 3ds Max install location and is used by other Autodesk products.

yes, I agree the .NET API environment in 3ds Max is not well documented or supported. But, the .NET API is still supported. There were some improvements to docs in more recent releases. See this section for latest:

http://help.autodesk.com/view/3DSMAX/2020/ENU/?guid=__developer_3ds_max__net_sdk_html

The Autodesk.Max.DLL is a wrapper for the C++ SDK, so the reference docs come from there. For example, the wrapper will pull reference docs from C++ to show info in intellisense. Yes, it's C++ context, but at least there is some description of the functions and parameters.

One very important aspect for .NET projects is to make sure the project setting "Copy Local" is false as mentioned above in this thread.
We also have an example here: https://github.com/ADN-DevTech/3dsMax-Explode-Geometry  and we try to ensure it's updated and working in each release.

Note there was a bug in early 2020 releases, but was fixed in 2020 Update 2.
The blog also has some topics. You can choose ".NET" keyword to find all topics. But I would suggest these mainly:
https://getcoreinterface.typepad.com/blog/2017/10/updated-net-api-samples-for-3ds-max-2018.html
https://getcoreinterface.typepad.com/blog/2013/09/some-net-api-samples.html
From support and documentation perspective, C++ and MAXScript have better coverage, but .NET is still possible and is supported. 

 

You mentioned broken links. Can you elaborate on what you found that is broken, and I can report the issues? We do know about the plugin manager doesn't manage .NET DLLs, but are there other problems you found? I clicked through some of the 2020 info and didn't find any broken links. thanks.

Hope it helps,

kevin


Kevin Vandecar
Developer Technical Services
Autodesk Developer Network



0 Likes
Message 3 of 5

Anonymous
Not applicable

Hello, Kevin,

 

Thank you so much for your quick reply. We started our research with google and were very pleased to find numerous references for .net development in the documentation, e.g. http://docs.autodesk.com/3DSMAX/16/ENU/3ds-Max-SDK-Programmer-Guide/index.html?url=files/GUID-572EF4...

Our first problem was that Google always links to outdated manuals and there is no clear reference to the latest version (e.g. like in the documentation of Unity for older versions).

 

Based on your answer, we invested two more developer days and were able to actually create running code with .net. But we didn't find a solution for the following problems:

1. the hot reloading of plug-ins doesn't seem to work ( after building the DLL, the max-UI is reloading for several seconds. But afterwards the old code is still executed)
2. we want to port large blocks (several 10000 LOC maxScript). The wrapped APIs do not support the UI elements of maxScript. We did not find a way to e.g. create and initialize a rollout. The documentation seems to be mostly auto-generated from code. As far as we could see there are currently only three ways in .Net to write UI components for 3dsMax: a.) Windows Forms (obsolete), b.) MaxForms (Windows forms variant that leads to massive styling errors in our system) c.) WPF/Xaml (very complex compared to maxScript UIs). d.) There also seem to be 3rd party tools (ephere max/net) that we have not further evaluated.

 

We then evaluated Python as an alternative to maxScript. Again, there seems to be a zoo of completely different APIs and wrappers for UI components. None of them is compatible with maxScript. On some Max installations we couldn't import PySide (and we couldn't find any help in the documentation). The most useful combination is Python with PyCharm and Qt. But for this our developers have to learn the Qt-API first.

In our eyes this experiment leaves the following impression for programming in 3dsMAX: either development with C++ or scripting (no refactoring, no type security, no IDE) with maxScript. The documentation, the tools (comic sans as font for the integrated editor?!), and the stability of the application need a lot of work.

 

Thanks again

 

 

0 Likes
Message 4 of 5

kevinvandecar
Community Manager
Community Manager

Hi, Yes for sure the google approach to our documentation is not ideal. I would recommend for Autodesk M&E products to bookmark this MURL: https://autodesk.com/me-sdk-docs Here you will find the latest developer docs for M&E products (note that Maya is sometimes listed on "previous version" because their release cycle is not on same schedule as 3ds Max and FBX.)

We are also aware that search, even within our own docs, is not always ideal. @Anonymous is working with the Autodesk docs team who manages the framework to improve our developer experience.

About your questions, here is my input...

 

1. Hot reloading I think is synonymous with "Edit and Continue" functionality? No, this is not supported in 3ds Max. Also if you did not see already, you do have to specify the "Use Managed Compatibility" option for debugging. This allows you to set the 3dsmax.exe as target and start 3ds Max from debugger directly (rather than "attach" approach which I have found to be more hassle; With direct, you can use "run" with code changes and one step startup).

 

2. My question here is "why" do you want to port so much MAXScript code? I saw your later comment about "no refactoring, no type security, no IDE" and agree those are strong reasons... but MAXScript is pretty stable over each release, so maintenance is not usually a big issue and existing code will continue to work fine.

About Python, in my opinion the Python support is merely a wrapper/convenience for MAXScript API (like .NET API is for C++). Currently there is no connection to IDE tools either. The PyCharm and other IDEs worked in the beginning when Python was introduced, but at the moment they are not.

About UI, yes... it's also a bit confusing. Because .NET API is not being used within 3ds Max for much core functionality, as you saw it does not have the best focus. As you mentioned the UI options for .NET is Windows Forms and XAML. XAML has rich capability and I found it easy to work with (has a WYSISYG editor, too). But yes it is different and very much bound to .NET/Windows.
3ds Max itself is migrating to Qt UI. There is support in Qt for .NET applications, but I have never tried it in the context of 3ds Max, so you would want to experiment there. but Qt UI could then be reused via it's definition for your environments if needed.
So in summary, my opinion of .NET API is that it is supported in 3ds Max, but is not being focused on. It's a great way to write "automation" style code. For example the "Explode Geometry" sample was nice to develop in .NET due to the IDE and debugging tools. But if you need full-on plugins, I would suggest C++. And personally I would not spend a lot of time to convert existing code from MAXScript into .NET (or even Python).

Hope it helps,
Kevin


Kevin Vandecar
Developer Technical Services
Autodesk Developer Network



0 Likes
Message 5 of 5

istan
Advisor
Advisor

@Anonymous wrote:

But for this our developers have to learn the Qt-API first.

In our eyes this experiment leaves the following impression for programming in 3dsMAX: either development with C++ or scripting (no refactoring, no type security, no IDE) with maxScript. The documentation, the tools (comic sans as font for the integrated editor?!), and the stability of the application need a lot of work.

I'd like to comment this too:

I agree with you - we only use either C++ (for RT and/or time consuming stuff) or MXS. Both are well documented and whatever is missing in MXS we simply expose it from C++. With C++ we can also use Edit&Continue, although it very often fails. Concerning the font in the MXS editor: I use my own fixed pitch font and my own color settings. There exists a user-option XML to override everthing.

0 Likes