Many Autodesk products include components or dependencies that rely on Microsoft .NET technologies. As part of this commitment to providing highly trustworthy and performant software, Autodesk product teams are planning updates to Autodesk products, where applicable and feasible, to align with Microsoft’s .NET product support lifecycle.

3ds Max 2026, Maya 2025, and Maya 2026 have already rolled out security updates that include an upgrade from .NET 8 to .NET 10. Refer to the respective product release notes for more information:

• 3ds Max 2026 Release Notes

• Maya 2026 Release Notes

• Maya 2025 Release Notes

Note: 3ds Max 2024/2025 and Maya 2024 use .NET Framework 4.8 variants and therefore do not require this .NET 10 upgrade. Microsoft continues to support .NET Framework 4.x versions, including 4.8 and 4.8.1, in accordance with the lifecycle of the Windows operating system on which they are installed. .NET Framework will also continue to be included with Windows. Read more about supported .NET Frameworks here.

Also note: 3ds Max 2027 and Maya 2027 ship with .NET 10 by default, so no changes are required for these versions.

As a result of these upgrades, we recommend ensuring that all related Autodesk products are also updated to avoid potential compatibility issues.

For additional background, see our previous blog post here.

What do you need to do?

There are no API changes in any of these products as part of this update. The only change is that the underlying .NET runtime is moving from .NET 8 to .NET 10.

Existing plug-ins and add-ins should continue to work unless they are affected by breaking changes introduced in .NET 10. In such cases, they may need to be recompiled and retargeted to .NET 10.

Developers are advised to test their plug-ins and add-ins for compatibility with the updated product releases.

If you encounter any compatibility issues, please report them through ADN Support.

Related links

• Autodesk Products: What customers need to know about Microsoft .NET 10 updates

• 3ds Max: Requirements for products affected by the Microsoft .NET 10 transition

• Maya: Requirements for products affected by the Microsoft .NET 10 transition

• Breaking changes in .NET 10

Also posted here: https://blog.autodesk.io/microsoft-net-10-updates-for-autodesk-3ds-max-and-maya/

There was just one problem. The Python version was built on MaxPlus, and MaxPlus is gone (deprecated and removed from 3ds Max 2022).

This post walks through how we brought the sample back, what changed when we moved it onto the modern pymxs + PySide6 stack, and a few things we improved along the way.

The Explode Geometry dialog (screenshots will be refreshed for the new PySide6 UI).

A quick history lesson

MaxPlus was the first official Python binding for 3ds Max, introduced back in 2014. It exposed a hand-curated, object-oriented wrapper over the C++ SDK, classes like MaxPlus.TriObject, MaxPlus.Factory, and MaxPlus.NotificationManager.

It was useful, but it was also a maintenance burden: every class and method had to be wrapped by hand, so coverage was always partial and always lagging the SDK. Meanwhile, pymxs, which exposes the full MAXScript runtime to Python, kept growing into the more complete, better-supported option.

So MaxPlus was deprecated in 3ds Max 2021 and removed entirely starting with 3ds Max 2022. Any sample that imports MaxPlus stops loading; thus the classic Explode Geometry sample sat abandoned because the port wasn’t trivial: MaxPlus and pymxs think about the scene very differently.

The original sample is still in the repo as explode_geometry_classic.py for historical reference. It’s a good before/after companion to everything below, but note it only runs on 3ds Max 2016–2021.

The goals of the port

We set out to do more than merely make it run again:

1. Drop every MaxPlus dependency and target 3ds Max 2022+ (best on 2026/2027).

2. Move the UI to PySide6, the Qt6 binding shipped with modern 3ds Max.

3. Keep feature parity with the .NET sample’s options — shell, edit-mesh, collapse, centre-pivot, delete-original, and the TriMesh/MNMesh choice.

4. Improve the experience while we were in there: a real progress bar, an undoable operation, a debug toggle, and timing feedback.

Wiring the window into 3ds Max

MaxPlus had its own helpers for parenting a Qt widget to the Max main window and making it dockable:

# Classic (MaxPlus) 
form.setParent(MaxPlus.GetQMaxWindow()) 
MaxPlus.MakeQWidgetDockable(form, 4) 

The modern equivalent uses the qtmax module that ships with 3ds Max, plus a standard Qt window flag:

# New (qtmax + PySide6) 
form.setParent(qtmax.GetQMaxMainWindow()) 
form.setWindowFlags(QtCore.Qt.WindowType.Tool) 
form.show() 

qtmax.GetQMaxMainWindow() returns the real QMainWindow for Max, so the dialog behaves like a native tool window — it stays on top of Max and follows it as expected.

Listening for selection changes

The classic sample registered a selection callback through MaxPlus’ notification manager and tore it down by index:

# Classic 
MaxPlus.NotificationManager.Register( 
 MaxPlus.NotificationCodes.SelectionsetChanged, self.updateSelectionLabel) 
... 
MaxPlus.NotificationManager.Unregister(MaxPlus.NotificationManager.Handlers[-1]) 

With pymxs, we go straight to the MAXScript callback system, which is both more capable and easier to clean up because we can tag callbacks with a named ID:

# New 
rt.callbacks.addScript(rt.Name(’selectionSetChanged’), 
 self.updateSelectionLabel, 
 id=rt.Name(’explodeGeom’)) 
... 
rt.callbacks.removeScripts(id=rt.Name(’explodeGeom’)) 

Naming the callback group allows us to remove everything under explodeGeom when the Qt dialog closes.

The TriMesh path: from low-level mesh to one call

The classic sample built each face by hand against the low-level mesh API, casting to a TriObject, grabbing the Mesh, setting vertex and face counts, copying verts, and invalidating the geometry cache:

# Classic — manual mesh construction 
new_face = MaxPlus.Factory.CreateNewTriObject() 
n = MaxPlus.Factory.CreateNode(new_face) 
mesh = new_face.GetMesh() 
mesh.SetNumFaces(1) 
mesh.SetNumVerts(3) 
mesh.GetFace(0).SetVerts(0, 1, 2) 
mesh.GetFace(0).SetEdgeVisFlags(1, 1, 1) 
mesh.GetFace(0).SetSmGroup(2) 
for i in range(0, 3): 
 pt = tri_mesh.GetVertex(face.GetVert(i)) 
 mesh.SetVert(i, pt) 
mesh.InvalidateGeomCache() 

With pymxs we lean on the MAXScript mesh() constructor, which takes vertices and faces directly. The whole per-face body is collapsed to a few lines:

# New — high-level mesh constructor 
rt.convertToMesh(node) 
num_faces = rt.getNumFaces(node) 
for face_idx in range(1, num_faces + 1): 
 face = rt.getFace(node, face_idx) 
 v1 = rt.getVert(node, int(face.x)) 
 v2 = rt.getVert(node, int(face.y)) 
 v3 = rt.getVert(node, int(face.z)) 
 
 new_node = rt.mesh(vertices=rt.Array(v1, v2, v3), 
 faces=rt.Array(rt.Point3(1, 2, 3))) 
 rt.update(new_node) 
 new_node.wireColor = _random_wire_color() 
 applySettings(new_node, addShell, shell_amount, 
 addEditMesh, collapseNode, centerPivot) 

No manual cache invalidation, and the new node lands in the scene automatically. As a small visual nicety, we also assign each exploded face a random wire colour so you can actually see the individual pieces.

The MNMesh path: detach instead of rebuild

The classic MNMesh path was the most painful code in the old sample. To make each polygon, it created a PolyObject, reached into the MNMesh, set vertex/edge/face counts, positioned every vertex, built a visibility list, called MakePoly, then FillInMesh, roughly 20 lines of low-level construction per face.

The pymxs version sidesteps all of it. Instead of rebuilding each face as a new poly, we let polyop.detachFaces do the work and hand us back a node directly:

# New — let polyop detach each face into its own node 
rt.convertToPoly(node) 
num_faces = rt.polyop.getNumFaces(node) 
for face_idx in range(num_faces, 0, -1): 
 rt.polyop.detachFaces(node, rt.Array(face_idx), asNode=True) 
 new_node = rt.objects[-1] 
 new_node.wireColor = _random_wire_color() 
 applySettings(new_node, addShell, shell_amount, 
 addEditMesh, collapseNode, centerPivot) 

A couple of details worth noting:

• We iterate backwards (num_faces … 1). Detaching a face renumbers the remaining faces, so walking from the end keeps the indices we haven’t processed yet stable.

• asNode=True makes detachFaces create a brand-new node for the detached face, which we then grab as rt.objects[-1].

This is dramatically simpler, and it leans on Max’s own, well-tested geometry code instead of our hand-rolled mesh building.

MNMesh mode: each polygon is detached into its own node.

Applying the modifiers

The applySettings helper is conceptually identical between versions — the difference is just how you instantiate a modifier. MaxPlus used the factory and a parameter block:

# Classic 
mod = MaxPlus.Factory.CreateObjectModifier(MaxPlus.ClassIds.Shell) 
mod.ParameterBlock.outerAmount.Value = shell_amount 
n.AddModifier(mod) 

In pymxs, modifiers are just runtime classes you call like constructors, and their parameters are plain attributes:

# New 
mod = rt.Shell() 
mod.outerAmount = shell_amount 
rt.addModifier(n, mod) 

The same pattern covers Edit_Mesh, maxOps.collapseNode, and centerPivot (it reads almost as the MAXScript).

What we added beyond parity

Since we are rewriting it anyway, why not make the tool better? Here are some quality of life improvements we baked in:

Undo as a single operation. Exploding a model creates a lot of nodes. Wrapping the whole run in a pymxs.undo block means a single Ctrl+Z reverts the entire explode instead of unwinding it one face at a time:

with pymxs.undo(True, “Explode Geometry”): 
 ... # all node creation/deletion happens here 

A real progress panel. Exploding a dense mesh can take a while, so the dialog now shows a progress bar plus the current node name and an N of M counter. This matches the .NET dialog with a progress bar. The conversion functions take an on_progress callback and pump QApplication.processEvents() so the UI stays responsive:

def _prog(cur, tot): 
 self.progress_bar.setValue(int(cur * 100 / tot) if tot else 0) 
 QtWidgets.QApplication.processEvents() 

A debug toggle. Rather than littering the code with print calls, we route everything through Python’s logging module to the MAXScript Listener. A “Show Debug Messages” checkbox flips the logger between WARNING and DEBUG.

Note: Verbose logging affects performance, especially around hot paths and loops when there are many nodes/faces to explode. The completion summary is always printed regardless of the toggle.

Timing feedback. We wrap the run with time.perf_counter() and report how long the explode took — handy when you’re comparing the TriMesh and MNMesh paths on the same model.

pymxs.print_(”[ExplodeGeometry] Explode completed in {:.2f} seconds.\n”.format(elapsed)) 

Python 2 to Python 3, while we’re here

The classic sample was Python 2 (note the print msg statements and the Qt4-era PySide/QtGui imports). The port is clean Python 3 on PySide6: QtWidgets instead of QtGui, pymxs.print_() for Listener output, and modern signal connections like checkStateChanged.

Shipping it as an AppBundle

Running a script from the editor is fine for development, but the sample also ships as a proper Automatic Loader AppBundle under Bundle2/, so it can show up as a menu entry right next to the .NET version. The package’s Contents/python/ folder carries explode_geometry.py, and a small macroscript launches it:

macroScript ADNExplodeGeomPyMS 
  category:"ADN Samples"
  tooltip:"Explode Geometry (Python)" 
  buttonText:"Explode Geometry (Python)"
( 
 local scriptDir = getFilenamePath (getSourceFileName()) 
 local pyFile = scriptDir + "..\python\explode_geometry.py"
 python.ExecuteFile pyFile 
) 

How do we run the AppBundle?

You have two ways to get 3ds Max to load the bundle:

• Copy it into an auto-discovered plug-in folder. 3ds Max automatically scans the ApplicationPlugins directories on startup. Drop the Bundle2 folder (renamed to something like ADN-ExplodeGeometry.bundle) into one of:

  • %PROGRAMDATA%\Autodesk\ApplicationPlugins (all users), or

  • %APPDATA%\Autodesk\ApplicationPlugins (current user).

• Point an environment variable at it. Set ADSK_APPLICATION_PLUGINS to the folder containing your bundle before launching Max — handy when you’re iterating and don’t want to copy files around.

#Set ENV var (check terminal specifics for PowerShell/CMD/etc)
set ADSK_APPLICATION_PLUGINS=D:/path/to/bundle/parent/dir

# Launch mamax in the same shell
3dsmax.exe 

See the 3ds Max developer docs on the Plug-in Package (.bundle) format and PackageContents.xml for the full directory layout and the auto-loader search paths.

Once the bundle loads cleanly, you’ll find the tool on the main menu under App Store → Explode Geometry (Python), sitting alongside the original Explode Geometry (.NET) entry. Select your objects, launch it, and you'll see the same dialogue you’d see in the editor.

Not ethat the Python menu entry is part of the GitHub sample, but won’t show if you install the plugin from the AppStore.

One nuance worth knowing: the Python menu entry is only registered on 3ds Max 2027 and up. The post-start-up menu script gates it on the Max version:

-- Only add the Python menu entry for 3ds Max 2027+ (maxVersion 29000), 
-- where Python support in the menu system is available. 
if (maxVersion())[1] >= 29000 then 
( 
 newSubMenu.CreateAction "85045470-A03C-45EC-A13F-538346AF077A" 647394 "ADNExplodeGeomPyMS`ADN Samples" 
) 

The .NET action is added on all supported versions; the Python one is for 2027+ only.

A note on Qt versions

The sample is written against PySide6 (Qt 6), which is what ships with 3ds Max 2026 and 2027 — so on those releases it runs as-is.

On 3ds Max 2022–2025, the bundled Qt is the PySide2 (Qt 5) generation, so the imports and a few API details won’t match out of the box. If you want to run it there, you’ll need to adjust things like:

• from PySide6 import ... → from PySide2 import ...

• Scoped enums back to flat ones — e.g. QtCore.Qt.WindowType.Tool → QtCore.Qt.Tool.

• Signal differences — e.g. the Qt6 checkStateChanged signal versus Qt5’s stateChanged.

• QDialog/QMessageBox.exec() versus the older exec_().

None of these is hard, but they’re version-specific. Consider it a good exercise in learning where PySide2 and PySide6 diverge and a reminder always to check which Qt your target Max ships before writing UI code.

Lessons learned

A few takeaways for anyone facing a similar MaxPlus migration:

• pymxs is usually less code, not more. The instinct is to fear that dropping a “high-level” wrapper means more boilerplate. In practice, the opposite was true — rt.mesh(...) and polyop.detachFaces(..., asNode=True) replaced dozens of lines of manual construction.

• Prefer Max’s own operations over rebuilding geometry. The biggest simplification came from detaching faces instead of reconstructing them. When the SDK already does the thing you want, use it.

• Watch index invalidation. Anything that adds or removes faces/nodes mid-loop can shift the indices under you. Iterating in reverse is a cheap fix.

• qtmax is your friend for UI hosting. GetQMaxMainWindow() plus a Tool window flag gives you a well-behaved dialog without MaxPlus’ dockable helpers.

Try it out

The ported sample lives in the Explode Geometry repository under Python/explode_geometry.py. There are two ways to run it:

• Straight from the editor — open Python/explode_geometry.py in the 3ds Max scripting editor and execute it. Quickest for poking at the code.

• As an AppBundle — load the Bundle2/ package as described above and launch it from App Store → Explode Geometry (Python) (2027+).

Either way: select an object (or several), pick TriMesh or MNMesh, choose your options, and hit Explode. Then enjoy a single Ctrl+Z to put it all back together. It runs as-is on 3ds Max 2026/2027; for 2022–2025 you’ll need the PySide2 tweaks noted above.

The original .NET plug-in was written by Kevin Vandecar, from an idea by Louis Marcoux. The first Python version was developed by Drew Avis. This pymxs port modernises that work for 3ds Max 2022 and beyond.

Original posting here: https://blog.autodesk.io/setting-up-3ds-max-2027-sdk-development-with-visual-studio-2026/

What does the 3ds Max 2027 SDK require?

Per the official SDK Requirements page, 3ds Max 2027 targets:

The SDK Requirements page lists the IDE version as VS2022 17.14.13, but what your build must match is the MSVC v14.38 (17.8) toolset within the v143 family — see the next section for why that difference matters. Any edition of Visual Studio (Community, Professional, or Enterprise) can build 3ds Max plugins; the edition doesn’t matter, the toolset version does.

The SDK Requirements page names Visual Studio 2022 17.14.13 as the IDE baseline, but the build itself is pinned to a specific MSVC v143 build-tools version — v14.38 (17.8), which Microsoft now marks as Out of Support. “v143” is not a single compiler; it’s a family that spans many MSVC minor versions (14.30 through 14.44 and beyond), and 3ds Max 2027 is ABI-locked to the v14.38 set. The platform-toolset name stays v143 across Visual Studio 2022 and Visual Studio 2026 for backward compatibility, but the minor version underneath is what has to match.

This is why Visual Studio 2026 can host 3ds Max 2027 development: the newer IDE is able to install and target the older, out-of-support v14.38 build tools side by side with its own. 3ds Max and its plugins are extremely sensitive to ABI (Application Binary Interface) matching; a plugin must be built with a toolchain binary compatible with the one Autodesk used to build 3ds Max itself. Installing and selecting the v14.38 toolset is what keeps you inside that compatible window while still letting you run the newer IDE.

NOTE: The new IDE is fine; the exact build-tools version is what must match. Build against the v14.38 (17.8) v143 toolset, not whatever newer toolset Visual Studio 2026 installs by default.

What does Visual Studio 2026 ship with?

A default Visual Studio 2026 installation will not build a 3ds Max 2027 SDK project. Out of the box, VS2026 ships:

• the MSVC v14.44 build tools (the current v143 compiler), and

• the Windows 11 SDK 10.0.26100.x.

3ds Max 2027, by contrast, is built against the MSVC v14.38 (17.8) v143 build tools and the Windows 10 SDK 10.0.19041.0. Both VS2026’s defaults are newer than what the SDK expects, and that’s enough to break the build. To make matters more confusing, the v14.38 (17.8) toolset is now marked Out of Support by Microsoft, so it’s tucked away in the installer’s Individual components list rather than offered by default.

So, you must add the exact pieces Autodesk validated, and they come from two different places:

• MSVC v143 — VS 2022 C++ x64/x86 build tools (v14.38-17.8) — through the Visual Studio installer’s Individual components (under Out of Support).

• Windows 10 SDK (10.0.19041.0) — this one is not in the VS2026 installer at all. You download and install it separately, from the older-version downloads on the Windows SDK site.

The newer IDE can host the older, ABI-compatible v14.38 toolchain side by side with its own v14.44. But “possible” still means “you have to install it deliberately and then point your project at it.” The next section is exactly that; install the right pieces, then pin the project to them.

How to set up VS2026 for 3ds Max 2027

Assumptions and prerequisites

• A licensed copy of 3ds Max 2027 installed (you need a real install to test your plugin and to point to your debugger at 3dsmax.exe).

• The 3ds Max 2027 SDK installed.

• Qt 6.8.3 (the LGPL build) if your plugin uses Qt-based UI. Match this version exactly.

• .NET 10 SDK if you build managed or mixed-mode (C++/CLI) assemblies.

Install the right Visual Studio workloads and components

In the VS2026 installer, select the workloads:

• Desktop development with C++.

• .NET desktop development, if you build any managed components.

The workload alone is not enough, you need two more pieces, and they’re installed differently:

1. The v14.38 build tools — from the Visual Studio installer. Open the installer, switch to the Individual components tab, and use the search box to type v14.38. The matching entry — MSVC v143 - VS 2022 C++ x64/x86 build tools (v14.38-17.8) — appears under the Out of Support group; the installer will warn that it’s unsupported. That’s expected. Tick it and install it.

   

2. Windows 10 SDK 10.0.19041.0 — as a separate download. This version is not offered in the VS2026 installer. Download it on its own from the Windows SDK downloads site and run that installer. Once installed, it becomes selectable as a target SDK in your project.

Installing the 3ds Max plugin project wizard

The SDK ships an AppWizard that adds a “3ds Max Plugin” template to Visual Studio’s New Project dialog, pre-filled with the include paths, libraries, and project structure a plugin needs. It was written for Visual Studio 2022, but the setup for VS2026 is essentially works, you just copy the wizard files into the VS2026 IDE directory instead of the VS2022 one.

The wizard lives in:

3ds Max 2027 SDK\maxsdk\howto\3dsmaxPluginWizard\

Open the readme.txt in that folder and follow its steps, with one substitution: wherever it points you at the Visual Studio 2022 IDE directory, use the VS2026 IDE directory instead (the path where VS2026 is installed, under its Common7\IDE location). Copy the wizard’s .vsz / .vsdir and template files to the locations the readme describes, restart Visual Studio, and the 3ds Max plugin template appears in the New Project dialog.

Create, Build, load, verify

Similar to VS2022 workflow, create projects utilizing the Plugin Wizard for 3ds Max 2027. Projects generated still default to the correct v143 toolset.

Build and Run in Hybrid| x64, and confirm your plugin appears and loads cleanly.

If all was configured correctly, you should build successfully and 3ds Max should start and load the plugin.

Tips and tricks

Start from the SDK samples. The 3ds Max 2027 SDK ships sample projects that are already configured correctly. Building one of them first verifies your environment before you po

Always cross-check exact version numbers against the official 3ds Max 2027 SDK Requirements page before you commit your build configuration — point releases can shift toolsets and Windows SDK expectations.

It made sense at the time. There is exactly one server, listening on exactly one port, owning one database pool, one router, and one logger. Why wouldn’t there be one global handle to reach it all? For most of v0.1 through v0.3, that instinct served us well. In v0.4.x we are pulling the cord, replacing MantisBase::instance() with plain old dependency injection. This post is about why, and it’s worth starting with what a singleton actually is before explaining why we’re purging ours.

A quick detour through design patterns

If you’ve written software for any length of time you’ve absorbed design patterns whether or not you’ve read the book Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson & Vlissides, 1994). Patterns are not language features or libraries; they’re names for shapes that keep recurring. Having a shared vocabulary is genuinely useful: “wrap it in a decorator” communicates a whole structure in three words.

And then there’s Singleton.

The Singleton pattern “ensures a class has only one instance and provides a global point of access to it.” Two promises in one sentence, and the second one is the problem. It’s the only creational pattern in the book that most of its own authors would now tell you to avoid. In a 2009 interview, Erich Gamma — one of the four — said plainly:

“When discussing which patterns to drop, we found that we still love them all. (Not really, I’m in favor of dropping Singleton. Its use is almost always a design smell.)”

— Erich Gamma

The reason he gives is the reason this post exists.

How MantisBase became a singleton

MantisBase is an embeddable backend, a BaaS you link into a C++ process and drive. The MantisBase class is the composition root: it owns every subsystem and hands them out.

class MANTISBASE_API MantisBase
{
public:
    static MantisBase& instance();
    static MantisBase& create(const json& config = json::object());

    [[nodiscard]] Database& db() const;
    [[nodiscard]] Router& router() const;
    [[nodiscard]] Logger& logs() const;
    [[nodiscard]] RealtimeDB& rt() const;

    // ...

private:
    MantisBase();                       // creation is private
    static MantisBase& getInstanceImpl();
    std::atomic<bool> m_isCreated = false;
};

The mechanics are the textbook version. The constructor is private, `create()` builds the one instance, and `instance()` hands it back:

MantisBase &MantisBase::instance() {
    auto &app_instance = getInstanceImpl();
    if (!app_instance.isCreated())
        throw std::runtime_error("MantisBase not created yet");

    return app_instance;
}

MantisBase &MantisBase::create(const json &config) {
    auto &app = getInstanceImpl();
    if (app.isCreated())
        throw std::runtime_error("MantisBase already created, "
                                 "use MantisBase::instance() instead.");

    // ...
}

Even our own header documented the constraint as a feature:

Once that door is open, the whole codebase walks through it. Reaching the database from a request handler, a model, an auth check, or a file path resolver—all of it collapses into one convenient line:

// src/core/api_keys.cpp
auto sql = MantisBase::instance().db().session();

// src/core/files.cpp
return fs::path(MantisBase::instance().dataDir()) / "files";

// src/core/sse_mgr.cpp
auto &router = MantisBase::instance().router();

At last count, that pattern appeared across dozens of translation units, and that ubiquity is exactly the trap. Every one of those call sites is a dependency that doesn’t appear in any signature. Which brings us to why we’re ripping it out.

Why we’re ripping it out

1. A singleton is a global variable, dressed nicely

The case against globals is old and settled. Wulf and Shaw made it in 1973 in “Global Variable Considered Harmful”: non-local access makes it impossible to reason about a piece of code in isolation, because any part of the program can influence any other through the shared name. A singleton doesn’t repeal that argument; it just dresses it in a class with a `static` accessor. As Miško Hevery put it in his widely cited critique, Singletons are Pathological Liars: the method signature lies to you. When a `apiKeyLookup(id)` secretly calls `MantisBase::instance().db()`, its true dependency list is nowhere in its declaration. You only discover it by reading the body or by watching it explode at runtime.

This is the Dependency Inversion Principle (the “D” in Robert C. Martin’s SOLID) inverted the wrong way: our high-level model and request code depended directly on a concrete global-access mechanism instead of on abstractions handed to them.

2. The testing harness had to bend around it

This is where the abstraction stopped being free. Because there can only ever be one instance per process, our entire test suite is built around a single global application that must be stood up once and shared by everything. Look at what the test environment has to do:

// tests/common/test_environment.h
inline MbTestEnv::MbTestEnv() {
    // ... assemble config ...
    mb::MantisBase::create(args);          // the one and only create()
}

inline void MbTestEnv::SetUp() {
    serverThread = std::thread([this]() {
        server_running.store(true);
        auto res = mb::MantisBase::instance().run();   // reach back for it
    });

    // sleep, poll /health, hope it came up...
}

Every test then reaches through the same global to get at subsystems:

// tests/unit/test_database.cpp
EXPECT_TRUE(mb::MantisBase::instance().db().isConnected());

// tests/unit/test_models.cpp
mb::EntitySchema base{mb::MantisBase::instance(), "test", "base"};

The consequences are exactly what Michael Feathers warns about in Working Effectively with Legacy Code (2004). He defines a unit test as one that runs fast and in isolation, but singletons destroy isolation by construction. Global state persists between tests, so ordering matters, and you get to write defensive code like this just to survive a `create() > close() > create()` cycle within a single process:

// src/mantisbase.cpp

// Start from a clean slate: on a create() -> close() -> create()
// cycle (e.g. across test runs in one process) the arg vector would
// otherwise accumulate the previous run’s arguments.

app.m_cmdArgs.clear();
app.m_cmdArgs.emplace_back("mantisbase");

That comment is a remnant record of the pain, a state that should have died with an object instead outlives it, because the object is a `static` that never really goes away. Freeman and Pryce, in Growing Object-Oriented Software, Guided by Tests (2009), argue that hard-to-test code is usually a signal of a design problem, not a testing problem. The singleton was our signal, printed in every `instance()` call the tests had to make.

3. We now genuinely need more than one instance per process

The convenience argument for a singleton, “there’s only ever one”, turned out to be false as the product grew. We want to run multiple independent MantisBase instances in a single process: think isolated tenants, an embedding host driving several databases, or simply a test that spins up two servers and asserts they don’t leak into each other. We already have the test that describes the goal:

// tests/integration/test_integration_multi_instance.cpp

TEST_F(MultiInstanceTest, IndependentEntitiesDontInterfere) {
    // create schema multi_inst_a and multi_inst_b, insert into each,
    // and assert each entity sees exactly its own row.
    EXPECT_EQ(body_a["data"]["items_count"], 1);
    EXPECT_EQ(body_b["data"]["items_count"], 1);
}

You cannot express “two independent apps that don’t interfere” when `instance()` is hardwired to return the one true app and `create()` throws the second time you call it. The singleton isn’t just inconvenient here; it makes the requirement unrepresentable.

What we’re replacing it with

The fix is the boring, correct one that Martin Fowler catalogued back in 2004 in Inversion of Control Containers and the Dependency Injection pattern constructor injection. Instead of reaching out to a global, each object is handed the app it belongs to, at construction, as its first parameter.

A locked-in design decision for v0.4.x: the app is the first constructor parameter, so nobody can forget to bind it.

// include/mantisbase/core/http.h

class MantisRequest {
    /// Owning application, injected by the Router when the request is
    /// wrapped. Request-path code reaches shared services (db, router,
    /// realtime, config) via app() instead of the global singleton.

    const MantisBase &m_app;

public:
    explicit MantisRequest(const MantisBase& mb, const drogon::HttpRequestPtr& req);
    const MantisBase& mApp() const { return m_app; }
};

// include/mantisbase/core/models/entity.h
Entity(const MantisBase &app, const nlohmann::json &schema);
Entity(const MantisBase &app, const std::string &name, const std::string &type);

`Router`, `Database`, `Entity`, `EntitySchema`, `SSEMgr`, `WSMgr` each now takes its owning `MantisBase&` up front and stores it. The dependency that used to be invisible is now right there in the signature, allowing the type to tell the truth about what it needs.

The refactor isn’t finished. A handful of `instance()` calls in infrastructure code—the logger, file utilities, date helpers, the SSE manager, and one validator—are deliberately still standing, development in progress (maybe done by the time you are reading this!).

The lesson from v0.4.x isn’t that singletons are bad. It’s that convenience at the composition root has a way of becoming a constraint at the leaves. `MantisBase::instance()` saved us a constructor parameter thousands of times and charged interest on every one. Dependency injection just makes you pay the cost up front, in the open, where the type system can see it, and that turns out to be the cheaper deal.

This work is part of the ongoing MantisBase v0.4.x line. If you want to follow along, check out the v0.4.x branch and watch out for exciting features coming soon!

Why the change?

As MantisBase grew, the API surface accumulated small inconsistencies. Auth took the target entity in the request body while everything else was path-based. File serving lived at `/api/files/...` while the rest of the API was versioned under `/api/v1/`. Admin operations were split awkwardly between the auth namespace and the system namespace.

v0.3.6 makes the whole surface predictable. Everything now lives under `/api/v1/` in a clear set of namespaces:

Authentication is now per-entity

Previously you told MantisBase which entity to authenticate against by putting it in the request body:

# Old (v0.3.5)
curl -X POST http://localhost:7070/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"entity": "users", "identity": "user@example.com", "password": "pw"}'

Now the entity lives in the URL, which is more RESTful and lets each auth entity have its own clearly addressable endpoints:

# New (v0.3.6)
curl -X POST http://localhost:7070/api/v1/auth/users/login \
  -H "Content-Type: application/json" \
  -d '{"identity": "user@example.com", "password": "pw"}'

The same pattern applies to refresh and logout:

curl -X POST http://localhost:7070/api/v1/auth/users/refresh \
  -H "Authorization: Bearer <token>"

curl -X POST http://localhost:7070/api/v1/auth/users/logout \
  -H "Authorization: Bearer <token>"

The `<entity>` must be a registered `auth`-type entity that isn’t a system table and has the API enabled — otherwise you’ll get a clean `404 Route Not Found`.

One more thing: the login response is now wrapped in MantisBase’s standard envelope, so it matches every other endpoint:

{
  "status": 200,
  "data": {
    "token": "eyJhbGci...",
    "user”: { "id": "123456"”, "email": "user@example.com", "name": "John Doe" }
  },
  "error": ""
}

Admins get their own namespace

Admin authentication and account management now live entirely under `/api/v1/sys/admins/`, and admin CRUD is fully supported:

# Create the very first admin (only works when none exist yet)
curl -X POST http://localhost:7070/api/v1/sys/admins/setup \
  -H "Content-Type: application/json" \
  -d '{"email": "admin@example.com", "password": "adminpassword"}'

# Admin login
curl -X POST http://localhost:7070/api/v1/sys/admins/login \
  -H "Content-Type: application/json" \
  -d '{"identity": "admin@example.com", "password": "adminpassword"}'

# Manage admin accounts (requires admin auth)
curl http://localhost:7070/api/v1/sys/admins                   # list
curl http://localhost:7070/api/v1/sys/admins/:id               # get one
curl -X POST   http://localhost:7070/api/v1/sys/admins ...     # create
curl -X PATCH  http://localhost:7070/api/v1/sys/admins/:id ..  # update
curl -X DELETE http://localhost:7070/api/v1/sys/admins/:id     # delete

The old `POST /api/v1/auth/setup/admin` endpoint is gone — use `/api/v1/sys/admins/setup` instead.

Files and settings

File serving is now versioned, matching the rest of the API:

# Old:  http://localhost:7070/api/files/posts/photo.jpg
# New:  http://localhost:7070/api/v1/files/posts/photo.jpg

curl http://localhost:7070/api/v1/files/posts/photo.jpg

And application settings are exposed under the system namespace:

curl http://localhost:7070/api/v1/sys/settings/config   # read
curl -X PATCH http://localhost:7070/api/v1/sys/settings/config \
  -H "Content-Type: application/json" -d '{ ... }'             # update

Under the hood: lighter on memory

Beyond the visible API changes, we refactored how routes are registered. Instead of building a dedicated set of CRUD handlers for every single entity, MantisBase now uses centralized, generic handlers that resolve the target entity from the request path. Schema route handlers were similarly decoupled from the schema object. The result is the same behavior with a smaller memory footprint — especially noticeable on deployments with many entities.

We also refreshed the bundled dependencies (WolfSSL, nlohmann/json, jwt-cpp, spdlog, and the mb-admin dashboard) and fixed a build-target clash around `ztd`.

Something is broken, oh no!

As a result of the API changes, we ended up breaking the admin dashboard. Currently, v0.3.6 admin dashboard is unusable and requires reworking to bring it up to bar. That’s already being worked on and we will push an update once resolved.

Upgrading from v0.3.5

Most apps only need three mechanical updates:

1. Auth calls: move the entity from the body into the path
   (`/api/v1/auth/login` + `"entity": "users"` → `/api/v1/auth/users/login`).

2. Admin calls: repoint admin auth/setup to `/api/v1/sys/admins/...`.

3. File URLs: add the 1 segment (`/api/files/...` → `/api/v1/files/...`).

If you parse the login response, unwrap it from the new `{ status, data, error }` envelope.

That’s it — grab v0.3.6 from the releases page, and check the updated Authentication API and API Reference docs for the full details.

Then, somewhere around the third month, the project stalls. Not dramatically — there’s no postmortem, no cancellation email. It just quietly stops moving. The remaining work never gets easier, the Rust never gets good, and eventually the branch goes stale.

This isn’t a failure of nerve or tooling. It’s a structural property of what porting C++ to Rust actually is — and it’s worth understanding before you spend a quarter learning it the expensive way.

The seduction is real, and so is the wall

The reason the demo is so convincing is that the first 90% genuinely is easy now. Translating C++ control flow, arithmetic, and data structures into syntactically valid Rust is exactly the kind of pattern-matching LLMs are good at. The compiler even helps: if it builds, a lot of bugs are already gone.

The problem is what’s hiding in the last 10%, and it’s the same thing whether a human or a model is doing the work.

C++ does not encode ownership. When you write T* p, the language does not record whether p owns that memory, borrows it, shares it, or aliases something else that’s about to be freed. Those facts live in the programmer’s head, in comments, in naming conventions, and in tribal knowledge about “who frees what.” Rust’s entire value proposition is that these facts must be written down and checked. So a C++→Rust port is not a translation. It’s a reconstruction of invariants that were never explicitly recorded.

That’s why automatic transpilers are so instructive. Tools like c2rust produce Rust that is “almost always correct” — and almost always unsafe and unidiomatic. They faithfully preserve C’s pointer semantics by wrapping everything in unsafe, raw pointers, and libc calls. The output compiles. It is also, in the words of the research, “very different from the kind of Rust code usually written by humans, making it hard to read and maintain” — and it sails straight past the linters that are supposed to catch the problems. You get Rust syntax with C semantics: all of the migration cost, none of the safety payoff.

LLMs improve on this — they can sometimes infer ownership and produce idiomatic code — but the failure mode is sneakier. As DARPA’s program manager for TRACTOR (the agency’s program to automate exactly this translation) put it: ask any model to translate C to safe idiomatic Rust and “something comes out, and it’s often very good, but not always.” When it’s not, the model tends to reach for unsafe to make the borrow checker stop complaining — which is precisely how you end up with code that looks migrated but carries the same latent bugs it always had, now harder to spot because everyone assumes “it’s in Rust, so it’s safe.”

This is the mechanism behind the stall. The borrow checker doesn’t get tired and wave the last 10% through. Every place where the original C++ had a fuzzy ownership story becomes a hard stop that requires a human to decide what the ownership story should be — and frequently to redesign the data structures to express it. That’s design work, not typing work. LLMs removed the typing bottleneck, which was never the bottleneck.

The evidence cuts both ways — but cleanly

The honest read of the industry data is not “Rust good” or “rewrites bad.” It’s that the shape of the project predicts the outcome far better than the language choice does.

Look at what the wins have in common. Android never ported anything — Google’s entire strategy is that new code is Rust and old C++ is left in place; the safety gains come from the fact that “most bugs live in new code”, so you don’t need to touch the old stuff to bend the curve. Pingora wasn’t a translation at all; it was a clean-room reimplementation against a known spec, where the team got to design the ownership model from scratch instead of recovering it from someone else’s pointers. Mozilla picked off self-contained, parallelism-hungry components one at a time and integrated each before starting the next.

Now look at curl. Daniel Stenberg’s team spent roughly five years (2020–2025) trying to let curl use the Rust hyper library as an HTTP backend through an FFI glue layer — and ultimately ripped it out. The reasons are a near-perfect catalog of why these projects die:

• The last 5% was the whole problem. “The final few percent would turn out to be friction enough to now eventually make us admit defeat.”

• Nobody to do the hard part. It needed someone fluent in both C and Rust and the HTTP protocols to drive the integration across the FFI boundary — and almost no one wanted to.

• The FFI seam leaked. They had to remove HTTP/2 support because they’d misunderstood how the API integrated across the language boundary.

• No demand pulling it forward. curl users didn’t care that a backend was in Rust; Rust users didn’t want to maintain glue for a C project.

Stenberg’s conclusion is the bluntest data point in the whole debate: “We’re not going to rewrite curl in Rust. In any language — we’re not going to rewrite it at all.” This from someone who openly acknowledges that roughly half of curl’s historical vulnerabilities are C memory mistakes. He knows the safety case cold. He’s declining anyway, because the migration cost is real and the existing C is hardened by decades of fuzzing and CVE wrangling.

The hidden tax: comprehension debt

There’s a second-order cost that the demo never shows you, and it’s worse with LLM-driven ports than with hand ports.

When a model emits 4,000 lines of plausible Rust, no one on your team owns the mental model of that code. The 2025 research on LLM-generated code calls this comprehension debt and “ownership debt”: “it compiles” is not the same as “someone understands why it’s correct and can change it safely.” With a hand-written port, the engineer who fought the borrow checker comes out the other side understanding the ownership model — that understanding is half the point. With a generated port, you’ve skipped the understanding and kept only the artifact. The first time it needs a non-trivial change, you pay the comprehension cost you deferred, except now under deadline and without the person who’d have built the model.

This is why “the LLM did 90% in a week” is a misleading metric. The week of typing was never the expensive part. The expensive part is owning a correct mental model of a safety-critical system — and that’s exactly what gets skipped when the code arrives pre-written.

A decision framework that actually predicts outcomes

Stop asking “should we port to Rust?” It’s the wrong altitude. Ask these instead:

1. Is this new code or existing code?

If new, strongly favor Rust, and stop reading. The Android data is overwhelming: the cheapest safety win is to stop adding to the C++ pile. No migration risk, all the upside.

2. If existing — is the component self-contained, or is it threaded through the codebase?

A module with a narrow, well-defined interface (a parser, a codec, a proxy data path) is a Stylo/Pingora candidate. A module whose pointers reach into everything will trap you in FFI hell: every call across the C++/Rust seam is an unsafe boundary where Rust’s guarantees evaporate and new bugs breed. The curl/hyper failure was fundamentally an FFI-boundary failure.

3. Do you have a spec, or only the code?

If you can reimplement against a specification or a strong test suite (Pingora had the HTTP spec; you can have a differential test harness), favor a clean-room rewrite over a line-by-line port. You’ll design the ownership model instead of reverse-engineering it, and you can run old and new side by side to prove equivalence.

4. Will someone own the result?

If the answer is “the LLM wrote it and we’ll figure it out later,” you don’t have a migration plan, you have a future incident. Budget the human comprehension cost up front or don’t start.

5. Is the existing C++ actually your risk?

Battle-hardened, heavily-fuzzed C++ that hasn’t thrown a CVE in years is not where your memory-safety risk concentrates. New and frequently-changed code is. Spend the migration budget where the bugs actually are.

The verdict

Use the LLM. It genuinely removed a real cost — the mechanical translation that used to make these projects unaffordable to even start. But understand precisely what it removed and what it didn’t. It removed the typing. It did not remove the thinking: recovering ownership invariants that C++ never recorded, designing data structures that satisfy the borrow checker, and proving the result is equivalent to the original.

That thinking is the project. It was always the project. The reason ports stall at 90% is that the demo completes the 90% that was never hard, and then hands you the 10% that was the entire point — now disguised as “almost done.”

Port new code by default. Port self-contained components against a spec. Leave hardened, stable C++ alone. And treat any plan whose timeline is built on “the model already wrote most of it” as a plan that hasn’t started yet.

There is no shortage of "rewrite it in Rust" stories on the internet. Some are driven by hype, others by genuine engineering needs. This is not the former. What follows is a straightforward account of where MantisBase is headed, why, and what it means for you.

A Growing Ecosystem Worth Taking Seriously

Before getting into the decision itself, it is worth acknowledging the state of Rust as a language and ecosystem. The Rustacean community has grown into one of the most active and technically rigorous developer communities in open source. The crates.io registry now hosts hundreds of thousands of packages, covering everything from async runtimes and HTTP frameworks to database drivers, JWT handling, and mailer integrations — all with first-class tooling and consistently high quality. Rust has also topped Stack Overflow's "most admired language" survey for several consecutive years, which speaks less to popularity and more to developer satisfaction once they have committed to it.

We have been watching this ecosystem closely. It has matured to a point where building a production-grade, single-binary backend on top of it is not only feasible — it is arguably the most sensible path forward for a project with MantisBase's goals.

What Is Already Happening

Work on v0.4 has begun, and it is a full rewrite in Rust. The goal is to reach feature parity with the current C++ release at minimum, and to go further where the new foundation makes it practical to do so. If you want to track progress, the master branch on GitHub already reflects the active rewrite — the repository is already building and running in Rust, with core functionality like entity schemas, REST routing, access rules, JWT authentication, admin dashboard serving, and webhook support already in place.

This is not a distant roadmap item. It is ongoing work, and it is further along than most announcements of this kind tend to let on.

Why the C++ Foundation Was Holding Us Back

MantisBase started as a C++ project for good reasons: raw speed, embeddability, and a single-binary deployment model with no external runtime dependency. Those goals have not changed. What changed is our assessment of the cost of continuing to pursue them in C++.

The C++ codebase accumulated a set of challenges over time — not insurmountable, but expensive to address correctly. Memory management patterns that required careful audit, integration complexity when pulling in third-party libraries, and a build system that made certain kinds of cross-platform testing harder than it needed to be. Fixing these properly would have demanded a significant investment of time — time that should have gone toward improving the product.

The practical result was that several things we wanted to deliver kept getting pushed back. The documentation site needed modernisation. The admin dashboard needed a cleaner, more capable UI. The REST API had features we wanted to expand. Most notably, out-of-the-box SDK support for JavaScript and Python — something users have asked about consistently — was hard to prioritise while we were managing the overhead of the C++ foundation.

We reached a point where the honest assessment was: the language itself had become a constraint on the project's growth, not just a technical detail.

Why Rust, and Not Zig or Go

Once the decision to move away from C++ was made, we evaluated the realistic alternatives that could preserve what made MantisBase useful in the first place: a single compiled binary, genuine performance, and low memory overhead. Rust, Zig, and Go were the serious contenders.

Go produces clean binaries and has an excellent standard library, but its garbage collector introduces latency characteristics that are a poor fit for a backend meant to be embedded inside other applications. Zig is technically compelling and offers tight control over memory, but its ecosystem and tooling are still maturing — pulling in third-party integrations would mean building more from scratch than we wanted.

Rust offered the right combination: compile-time memory safety without a garbage collector, a mature ecosystem through crates.io, and tooling (cargo, rustfmt, clippy, cargo test) that genuinely reduces friction rather than adding to it. The memory safety story was particularly relevant. Part of why the C++ codebase was difficult to maintain was precisely the category of issues that Rust eliminates at the compiler level — use-after-free, data races, invalid pointer dereferences. We could have audited and hardened the C++ code, but choosing Rust means we do not have to keep having that conversation on every future contribution.

Beyond safety, the crate ecosystem makes it straightforward to integrate capabilities that previously required significant custom work: mailer support via lettre, async HTTP with axum, database access via sqlx, and more. These are not afterthoughts — they are well-maintained, widely used libraries that slot in cleanly.

First-class test support via cargo test is also worth naming directly. Writing and running tests in C++ projects of this kind involves considerably more ceremony. In Rust, testing is a natural part of the workflow, which matters when you are trying to build confidence in a rewrite incrementally.

Language SDK Support Becomes Realistic

One of the things we wanted to offer from early on was MantisBase SDKs for JavaScript and Python — not just REST clients, but deeper integration. In the C++ world, producing idiomatic bindings for both languages meant navigating complex FFI boundaries, separate build pipelines, and significant maintenance surface.

From Rust, this is substantially more tractable. The PyO3 project provides a mature path for exposing Rust libraries to Python, and Neon (or WASM targets) covers the Node.js side. We are not committing to a specific release timeline for these yet, but the rewrite removes the structural obstacle that made them impractical before.

What Happens to C++ Support

The original C++ releases are not being abandoned. Binaries up through v0.3.5 remain available on the GitHub releases page, and that code is not going anywhere.

Looking further ahead, we are interested in the model that projects like Slint have demonstrated. Slint is a UI toolkit written in Rust that exposes a fully supported C++ API — developers working in C++ interact with it as though it were a native C++ library, with no Rust toolchain required on their end. Several other projects in the embedded and systems space have taken similar approaches. We are examining what that looks like for MantisBase's embedding use case, and C++ API support remains part of the long-term plan.

What to Expect Next

The v0.4 work is progressing in the open. You can follow along, open issues, or contribute via the GitHub repository. The current Rust codebase is already functional enough to run and experiment with.

A more detailed devlog covering the architecture of the Rust port — including database abstraction, the new schema engine, and the HTTP layer — is coming soon. For updates, subscribe below or follow @allankoechke on X.

MantisBase is an open-source, single-binary Backend-as-a-Service. Visit mantisbase.com for documentation and demos.

Originally posted here:

Explore New Features in 3ds Max 2027 Release Updates

A few weeks ago, 3ds Max 2027 was officially released, introducing new features and capabilities for both artists and developers. With this release, 3ds Max saw many upgrades including Arnold to 5.9.0, USD to 0.14.0, Substance to 3.0.6, performance improvements across tools, modifiers, and render workflows, and much more. Refer to the product release page for a detailed feature breakdown for 3ds Max 2027.

New Features, Improvements, and Updated Workflows

3ds Max 2027 ships with several notable updates across its plugin ecosystem: 

• Arnold for 3ds Max updated to 5.9.0 (Arnold 7.5.0.0)

• USD for 3ds Max updated to 0.14.0

• Substance updated to 3.0.6

• Autodesk Assistant (Technical Preview): An AI-powered tool that helps you quickly find information about features and workflows directly within the product — a welcome addition for developers and artists alike looking to streamline their pipeline research. Read more here.

SDK Changes

Now let's get into what matters most for plugin developers.

• .NET 10.0 Support: 3ds Max 2027 moves plugin development to .NET 10. Note that .NET 8, introduced in 3ds Max 2026, has reached an end of life and is no longer supported. If you are still on an older version, refer to our porting guide from .NET Framework to .NET for plugins for step-by-step migration guidance.

• DirectX 9 Removal: Support for DirectX 9 has been fully removed. This affects several headers that have been dropped from the public SDK — notably id3d9graphicswindow.h, idx9pixelshader.h, and idx9vertexshader.h — along with related interfaces in ihardwarematerial.h, ihardwarerender.h, and RTMax.h. Developers relying on these should migrate to the DirectX 11 equivalents now available in the SDK.

• Updated Core Dependencies: 3ds Max 2027 development specifies Visual Studio 2022 (v17.14.x), C++20, Qt 6.8.3. Review your plugin dependencies against these versions before building. You could also use the newer Visual Studio 2026, when you set the toolset to be v143.

• API Changes: There are targeted API updates across several headers — including new methods in custcont.h, ioapi.h, and IValidateNodeCallback.h, as well as deprecations in object.h, gfx.h, and others.

• Updated Samples and Documentation: Samples and documentation have been updated to reflect all API changes in this release.

We're shipping v0.3.4 today with a handful of quality-of-life improvements, a cleaner configuration story, and a few important bug fixes. Here's what's new.

Unified MB_* Environment Variable Prefix

All environment variables now consistently use the MB_* prefix. If you were previously setting MANTIS_JWT_SECRET, update that to MB_JWT_SECRET — the old name is no longer recognised. This brings every runtime knob under one coherent namespace and makes it easier to manage configuration in Docker and CI environments.

Variable Description Default MB_JWT_SECRET JWT signing secret (set this in production!) built-in default MB_DISABLE_FILE_UPLOADS Set to 1 to disable file uploads globally 0 MB_DISABLE_ADMIN_ON_FIRST_BOOT Set to 1 to skip auto-admin creation browser spin off 0 MB_DISABLE_RATE_LIMIT Set to 1 to disable rate limiting enabled

File Upload Kill Switch

A new MB_DISABLE_FILE_UPLOADS=1 flag lets you turn off file uploads at the server level without touching your schema. Any upload attempt while this flag is active will receive a 403 Forbidden response. Useful for read-only deployments or environments where you want to enforce that no files land on disk.

Docker Improvements

The Dockerfile has been updated to debian:trixie-slim as its base, and the build arg has been renamed from MANTIS_VERSION to MB_VERSION (default 0.3.4) to match the new naming convention. The docker-compose file now also surfaces all MB_* variables as commented-out stubs, so it's clear what you can configure without digging through docs.

The published image on Docker Hub is allankoech/mantisbase — the quick-start command is simply:

docker run -p 7070:80 allankoech/mantisbase

All submodules have also been switched from SSH to HTTPS URLs and set to shallow fetch, which significantly speeds up fresh clones in CI pipelines.

Admin Panel Updates

Several improvements have landed in the admin UI this release:

Entity cloning — You can now clone an existing entity directly from the admin panel. Cloning copies the source entity's schema (field names, types, and structure) into a new entity, giving you a clean starting point to build on without recreating common field sets from scratch. No records are carried over, only the schema.

Entity renaming — Entities can now be renamed from within the admin panel without having to drop and recreate them.

Long entity name overflow fix — Entity names that exceeded the available sidebar/panel width were pushing other UI elements off screen. This has been corrected so long names truncate gracefully and the layout stays intact.

Minor bug fixes and improvements across the admin panel generally.

Bug Fixes

• PATCH requests with password fields — a missing-field error that surfaced when patching records containing a password field has been resolved.

• Last-activity tracking — activity timestamps now only update on actual database record changes, not on every SSE ping or passive connection event. This prevents misleading "active" signals for idle clients.

• SSE session cleanup — auth tokens are no longer held in memory on SSE sessions. The token field is explicitly nulled out after verification, reducing the risk of credentials lingering in heap memory across a long-lived connection.

Internal / Code Quality

• soci_wrappers.h saw a significant cleanup — redundant nesting in the field-binding logic was flattened, making the type-dispatch code considerably easier to follow.

• SSE event queuing now uses emplace instead of push for slightly cleaner construction.

• SQL update column formatting moved to std::format for consistency.

Upgrading

Update your environment variables from MANTIS_JWT_SECRET → MB_JWT_SECRET and pull the new image or rebuild from source. No schema migrations are required for this release.

The full changelog and binaries are available on the GitHub releases page.

If you've been following along, you know I've been busy building MantisBase for a while now. Today feels like a good checkpoint to step back, write a bit, and share what's shipped.

This is the first official devlog. There will be more.

The Project Website is Up

First things first, MantisBase now has a proper home on the internet.

MantisBase | Lightning fast BaaS in C++

It's a landing page for now, but it does the job — gives you a quick feel for what MantisBase is and where it's headed. If you've been curious but haven't dug into the GitHub repo yet, the website is probably the gentler starting point.

Try It Without Installing Anything

This one I'm particularly happy about.

One of the biggest friction points with any self-hosted tool is the "I'll check it out later" trap; you bookmark it, tell yourself you'll spin it up over the weekend, and then never do. I've been guilty of this myself more times than I'd like to admit.

So we now have a live demo environment:

Mantis Admin Dashboard

No installation. No Docker. No config files. Just open it and poke around. If it clicks for you, then you can go down the setup rabbit hole.

Docker Image on Docker Hub

Speaking of setup—for those who are comfortable with Docker and just want to pull and run, we've got you covered.

docker pull allankoech/mantisbase

Full image available at:

allankoech/mantisbase - Docker Image

This is probably the fastest path from zero to a running instance if you're on a server or just want to keep things clean on your local machine.

What's Next

We're currently in the middle of cleaning up the admin UI — ironing out some rough edges and squashing a few bugs that have been on the list. Nothing dramatic, just the kind of polish work that makes the difference between something that works and something that feels solid.

More updates soon. If you want to follow along, the GitHub repo is the most up-to-date place to track progress.

Until the next devlog. ✌️

February 4, 2026 — We're excited to announce the release of MantisBase v0.3.3, bringing real-time database capabilities to this lightweight, high-performance Backend-as-a-Service framework. This release introduces Server-Sent Events (SSE) support for both SQLite and PostgreSQL backends, along with critical bug fixes and improved system observability.

What's New in v0.3.3

Real-Time Database via SSE

The flagship feature of v0.3.3 is native real-time database synchronisation using Server-Sent Events. Unlike traditional polling approaches that waste resources checking for updates, SSE establishes a persistent HTTP connection that allows the server to push changes to clients as they happen.

Why SSE?

Server-Sent Events offer several advantages for real-time database applications:

• Efficient unidirectional streaming — Perfect for database change notifications where data flows primarily from server to client

• Built on standard HTTP — No special protocols or WebSocket infrastructure required

• Automatic reconnection — The browser's EventSource API handles connection recovery automatically

• Firewall-friendly — Works through corporate proxies and firewalls that might block WebSocket connections

• Low overhead — Simpler than WebSockets when you don't need bidirectional communication

Universal Backend Support

Real-time updates now work seamlessly with both SQLite and PostgreSQL databases. Whether you're running MantisBase on an embedded device with SQLite or scaling up with PostgreSQL, you get the same real-time capabilities without changing your code.

Enhanced System Observability

System logs have been moved to a dedicated database and are now accessible through the /api/v1/logs endpoint, providing administrators with powerful filtering and pagination capabilities for monitoring and debugging.

Getting Started with Real-Time

Opening an SSE Connection

Connect to the real-time endpoint and subscribe to entity changes:

// Subscribe to changes on the 'posts' entity
const eventSource = new EventSource(
  'http://localhost:7070/api/v1/realtime?topics=posts'
);

// Listen for all events
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received event:', data);
};

// Handle connection events
eventSource.onopen = () => {
  console.log('SSE connection established');
};

eventSource.onerror = (error) => {
  console.error('SSE connection error:', error);
  // Browser automatically reconnects
};

Subscribing to Multiple Entities

You can monitor multiple database entities on a single connection:

// Subscribe to posts, comments, and users
const eventSource = new EventSource(
  'http://localhost:7070/api/v1/realtime?topics=posts,comments,users'
);

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  
  // Events include the entity name they originated from
  switch(data.entity) {
    case 'posts':
      updatePostsUI(data);
      break;
    case 'comments':
      updateCommentsUI(data);
      break;
    case 'users':
      updateUsersUI(data);
      break;
  }
};

Event Format

Real-time events follow a consistent JSON structure:

{
  "type": "INSERT",
  "entity": "posts",
  "data": {
    "id": "abc123",
    "title": "New Post Title",
    "content": "Post content here",
    "created": "2026-02-03T14:30:00Z",
    "updated": "2026-02-03T14:30:00Z"
  },
  "timestamp": "2026-02-03T14:30:00.123Z"
}

Event Types:

• INSERT — New record created

• UPDATE — Existing record modified

• DELETE — Record removed

Dynamic Topic Management

Update your subscriptions without reconnecting:

// Later, add more topics to the existing connection
async function subscribeToComments() {
  await fetch('http://localhost:7070/api/v1/realtime', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${yourAuthToken}`
    },
    body: JSON.stringify({
      client_id: clientId,
      topics: ['posts', 'comments']  // Updated topic list
    })
  });
}

// Or clear all subscriptions
async function unsubscribeAll() {
  await fetch('http://localhost:7070/api/v1/realtime', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${yourAuthToken}`
    },
    body: JSON.stringify({
      client_id: clientId,
      topics: []  // Empty array clears all topics
    })
  });
}

System Logs API

Access and monitor system logs with the new logs endpoint:

# Get recent logs (requires admin authentication)
curl -H "Authorization: Bearer <admin_token>" \
  http://localhost:7070/api/v1/logs

# Filter by log level
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?level=ERROR"

# Pagination
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?limit=50&offset=100"

# Filter by time range
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?from=2026-02-03T00:00:00Z&to=2026-02-03T23:59:59Z"

Migration Guide

If you're upgrading from v0.3.2, here's what you need to know:

Breaking Changes

There are no breaking changes in v0.3.3. The real-time API is a new addition that doesn't affect existing functionality. To enrol existing entities to be real-time "enabled", update the entities to trigger the real-time monitoring.

Security Considerations

Authentication for Real-Time

Real-time connections respect MantisBase's access control rules:

• For public topics (entities), no additional authentication is required.

• For non-public entities, the following rules are enforced:

  • List Rule: Used to list records in an entity.

  • Get Rule: Used to fetch a record by the record ID.

For non-public entities, provide the authorisation JWT token when creating the EventSource stream.

Installation & Upgrade

Download Pre-built Binaries

Download the latest release from GitHub Releases:

# Linux
wget https://github.com/allankoechke/mantisbase/releases/download/v0.3.3/mantisbase-linux-x64.zip
unzip mantisbase-linux-x64.zip
chmod +x mantisbase
./mantisbase serve

# Windows
# Download mantisbase-windows-x64.zip and extract
mantisbase.exe serve

Build from Source

git clone --recurse-submodules https://github.com/allankoechke/mantisbase.git
cd mantisbase
git checkout v0.3.3
cmake -B build
cmake --build build
./build/mantisbase serve

Bug Fixes

This release includes several important bug fixes:

• Fixed memory leak in SSE connection handling

• Improved database connection pooling for PostgreSQL

• Resolved race condition in concurrent entity updates

• Fixed authentication token refresh timing

• Corrected CORS headers for cross-origin real-time connections

Community & Support

Join our growing community:

• GitHub: github.com/allankoechke/mantisbase

• Documentation: allankoechke.github.io/mantisbase

• YouTube Tutorials: MantisBase Playlist

• Discussions: GitHub Discussions

• Support: Patreon

Acknowledgments

Thank you to everyone who contributed to this release through bug reports, feature requests, and code contributions. MantisBase is built for developers, by developers.

Checkout the video announcement here:

MantisBase—Lightning-fast BaaS in C++. One binary, full backend, anywhere.

For the full changelog, see v0.3.2...v0.3.3

The second edition of the Smart Living & Tech Leadership Conference 2025 ran for two days, with intense, future-focused dialogue. Day one set the foundation — sustainability, leadership, and the evolving role of cities in shaping human experience. Talks centred on energy management, mobility systems, and the ethics of digital transformation.

Day two shifted toward design, technology, and AI, unpacking how digital tools turn ideas into smarter, more liveable environments.

The Core Idea

Smart living isn’t about gadgets. It’s about intentional design. Every decision — spatial, structural, or digital — shapes how we live, move, and connect. Design is the link between people, data, and sustainability.

🗨️ "Design is not just what it looks like and feels like. Design is how it works."
— Steve Jobs

Steve Jobs was a visionary who foretold of what it became of today, a fusion of design and functionality. A move toward designing for use rather than designing for aesthetics alone.

My Session: Smart Living by Design

I presented “Smart Living by Design: Evolving from Digital Tools to AI Decisions.” The session traced design’s evolution—from manual drafting to data-driven modelling and now to intelligent, AI-augmented systems.

• Digital tools like Revit, Inventor, 3ds Max, and Maya redefined collaboration and precision.

• AI now extends creativity — generating forms, predicting outcomes, and guiding sustainable choices.

• Projects like Bernini show how AI-driven 3D generation can reduce waste and optimise performance.

• Digital twins enable continuous feedback loops between the real and virtual worlds, making smart cities adaptive by design.

The key takeaway: AI doesn’t replace creativity — it amplifies it. The future designer leads with intent, while AI accelerates exploration and insight.

Conversations That Followed

Post-session discussions were rich. People wanted to know how data models support interoperability across industries and where the limits of AI automation should be drawn. Others shared case studies on generative layouts for housing, mobility planning, and carbon analysis.

Outside the panels, the networking felt natural. Designers, engineers, urban planners, and educators connected over one shared vision — building systems that think with us, not for us.

Closing Thought

The conference reinforced a simple truth: design is leadership. Tools evolve, but human intention drives change. If we design with purpose — aligning creativity, technology, and sustainability — smart living becomes not an idea, but a lived reality.

Join the conversation!

Qt is a mature and feature-rich framework, but building flexible and declarative UIs often requires more than widgets and signals. That’s where Slint fits in. It provides a compact, declarative syntax for building modern UIs while staying native and lightweight.

Some Qt-based projects, like LibrePCB, already use Slint to modernise their UI without abandoning their existing Qt foundation. Check the full blog details here. Embedding Slint lets you:

• Keep your Qt app logic and backend code intact.

• Use Slint for fast, declarative, and maintainable UI layers.

• Mix and match Slint views with traditional Qt widgets.

• Gradually migrate UI parts without a full rewrite.

Watch the walkthrough video here:

Slint UI 102: Embedding Slint UI Within a Qt Application | C++

What you’ll learn:

• How to embed Slint UI components in a Qt app

• How to compile .slint files to native C++

• How to synchronise data between Qt and Slint

• How to manage event flow and cleanup

Resources:

• Slint Documentation: https://slint.dev/docs

• Slint Source Code: https://github.com/slint-ui/slint

• Slint C++ Template: https://github.com/slint-ui/slint-cpp-template

• Full Source Code from this video: https://github.com/allankoechke/qt-slint-integration-cpp

We have earlier introduced Mantis, a C++ BaaS toolkit, designed to be lightweight but powerful.

Introducing Mantis: The C++ Backend Framework Built for Simplicity and Speed

What's changed?

From our last v0.2.7 release a couple of weeks ago, we have some important fixes and improvements added to our v0.2.8 release. Have a look:

• PostgreSQL Support: v0.2.8 brings full PostgreSQL support for Linux builds. This allows for easy backend database switch when scaling is required while maintaining lightweight backend database (SQLite) where it's needed. How do you switch the database? Easy!

• Minor bug fixes & improvements: Lots of bugs were squashed, solving some performance issues as well as mending some issues that existed. Chief among these is matching data types compatibility for SQLite to/from PostgreSQL, forcing SQLite WAL mode checkpointing for every boot and refactoring project for performance improvements.

Release Release v0.2.8 · allankoechke/mantis

Getting Started?

We have a YouTube video to guide you out; don't fret. Checkout the video below for a walkthrough of the features mantis provides. If you have any question, lets discuss on YouTube or open a GitHub issue.

Enjoy!

We’ve shipped Mantis v0.2.7-beta, a new milestone for our lightweight pluggable backend-as-a-service (BaaS) framework written in C++. This release focuses on making file management a first-class feature while continuing to strengthen stability and prepare for broader database support.

Highlights

File and Files Field Support

• Records now support file and files fields.

• Upload, update, and remove files directly through record operations.

• Safer filename handling with sanitization for long names and unknown characters.

For more information on how to handle files in Mantis, check out the docs below:

mantis/doc/11.files.md at master · allankoechke/mantis

Health check Endpoint

• Added a /api/v1/health endpoint to make it easier to monitor and integrate Mantis into production setups.

Mantis Admin v0.1.7

• Updated to the latest version of the Mantis Admin dashboard with file management capabilities.

• Improved performance in the admin panel when working with larger datasets.

Bug Fixes and Improvements

• Better handling of database value binding with soci::values.

• Performance optimization for table ID generation.

• More consistent cleanup of file references for updates and removals.

PostgreSQL Support (WIP)

• Early integration of PostgreSQL via SOCI.

• Initial support for builds, CLI commands, and CI/CD integration.

• Still marked experimental but progressing quickly.

⚠️ PostgreSQL support is experimental and currently only built for Linux. The feature still has unresolved issues and may fail to launch entirely.

Why It Matters

Mantis is designed as an alternative to Firebase, Supabase, or PocketBase, but lighter, portable, and embeddable directly into your C++ applications. By keeping the runtime minimal and the architecture pluggable, we aim to make backend services faster to integrate and easier to run anywhere.

What’s Next?

• Complete PostgreSQL support for production use.

• Expanded file access controls.

• More integrations for different deployment targets.

Get Started

GitHub Repo: https://github.com/allankoechke/mantis
Release Page: https://github.com/allankoechke/mantis/releases/tag/v0.2.7-beta
Documentation: https://docs.mantisapp.dev/.

Feedback is welcome. If you try out the new file support or start testing PostgreSQL integration, please let us know how it works for you.

In a world dominated by heavyweight frameworks and bloated deployment pipelines, Mantis stands out as a fast, modular C++ backend library designed for simplicity, speed, and embeddability. Whether you're building for the cloud, desktop, or embedded systems, Mantis gives you modern backend capabilities with zero friction.

What Makes Mantis Special?

🚀 Single Binary Deployment

No containers, no dependencies, no problem. Mantis compiles to a single mantisapp binary that runs anywhere—just:

./mantisapp serve -p 8000

It’s ideal for embedded devices, desktop applications, or servers where simplicity is paramount.

Zero-Configuration REST APIs

Define your tables—and that’s it. Mantis auto-generates RESTful CRUD endpoints, complete with JWT-based authentication and fine-grained access control.

🧠 Minimal Runtime Footprint

With SQLite as the default database and tight memory usage, Mantis is engineered for environments where every byte counts.

Key Benefits That Set Mantis Apart

🔧 Embeddable by Design

Unlike traditional backends that require external deployment, Mantis can be embedded directly into your C++ application. Add backend functionality to Qt apps, CLI tools, or microservices—all from within your codebase.

🔐 Built-in Authentication & Security

Mantis handles token generation, validation, and route-level access control using JWT. You get secure, configurable auth out-of-the-box.

📊 Lightweight Admin Dashboard

Each Mantis deployment includes a built-in admin dashboard for managing tables, records, and users—no separate tooling or setup required.

🐳 Docker-Ready

Mantis offers a Docker image with volume mounting support, ideal for containerized environments and CI/CD pipelines.

🛠 Technology Stack

Mantis integrates robust C++ libraries to deliver production-grade performance:

• HTTP Server: httplib-cpp for lightweight HTTP(S) handling

• Database: SOCI as an abstraction layer (SQLite by default; MySQL/PostgreSQL coming soon)

• Authentication: l8w8jwt for secure token management

• Logging: spdlog for structured, high-performance logging

🚧 Future Vision: What’s Coming

Mantis isn’t just stable—it’s growing. Here’s what’s on the horizon:

• Real-Time Sync Engine
  WebSocket-powered data sync between clients and the backend—perfect for offline-first and collaborative apps.

• Full RDBMS Support
  Extend Mantis from SQLite to full support for MySQL and PostgreSQL with seamless migration tooling.

• Pluggable Middleware Architecture
  Customize request handling with user-defined middleware for logging, validation, authentication, or anything else.

Getting Started is Effortless

You can start using Mantis today in one of two ways:

Option 1: Use Prebuilt Binaries

Available for Linux (x86_64) and Windows (x64)—just download and run.

Option 2: Build From Source

If you're targeting another platform or want to embed Mantis into your own C++ application:

git clone --recurse-submodules https://github.com/allankoechke/mantis.git
cd mantis
cmake -B build
cmake --build build
./build/mantisapp serve -p 5000

Access the dashboard at http://localhost:5000/admin.

👉 Read the full setup guide here:
https://allankoechke.github.io/mantis/setup.html

🌟 Why Choose Mantis?

In a space filled with over-engineered solutions, Mantis offers a refreshing alternative: modern backend functionality in a compact, embeddable C++ package. Whether you're targeting embedded devices, developer tools, or just want a backend that won’t get in your way—Mantis delivers.

Ready to Try It?

Explore the GitHub repository, download the binaries, and see what lightweight backend development really feels like.

In the growing jungle of codebases, developer tools, and open-source libraries, one thing remains consistently frustrating: documentation. Whether they're too shallow, too outdated, or just missing altogether, bad docs slow everyone down. But what if you could talk to a codebase like you would a teammate? That’s where DeepWiki comes in.

DeepWiki | AI documentation you can talk to, for every repo

What’s DeepWiki?

It provides up-to-date documentation for any repo in the world that you can talk to. At first glance, you might consider it similar to your favorite LLM, but with the added context of a codebase.

💡 A wiki is a form of hypertext publication on the internet which is collaboratively edited and managed by its audience directly through a web browser. A typical wiki contains multiple pages that can either be edited by the public or limited to use within an organization for maintaining its internal knowledge base.

DeepWiki is powered by Devin AI, but over the past few months, there have been new open-source entrants to the space providing the same functionality.

Where does it find its use?

Consider this: the quality of documentation for repositories can range from excellent to inadequate. Imagine bumping into a repo with no docs, but it seems like a good fit for your needs. This scenario is where DeepWiki can help you create documentation for human understanding without needing to read through the entire codebase line by line.

You ask, it answers. From "What does this function do?" to "How does authentication work in this repo?" DeepWiki gives you direct, conversational insight based on the actual code, not assumptions.

It’s particularly useful when:

• You inherit a legacy code and need to quickly catch up.

• You're actively participating in open-source projects and seeking to understand the internal workings.

• You’re assessing a new library or tool and need to grasp its internals without reading 10 files.

But how does it work?

Behind the scenes, DeepWiki syncs with the repository and builds an internal understanding of the code—structure, logic, and behavior. It doesn’t just summarize; it contextualizes. Ask a question, and it doesn’t respond based on generic training but refers to the actual code. That’s the difference.

How do I get started?

It's actually quite simple. On any GitHub repo you need to look into, replace the GitHub with the DeepWiki domain. For instance, for the SQLite repo above, replace https://github.com/sqlite/sqlite to https://deepwiki.com/sqlite/sqliteand there you'll be ready to chat with your repo.

⚠️ Note that not all repos are already indexed. For those that aren't, you'll have to request indexing and provide your email, and you'll be notified once indexing is completed. Usually in less than an hour or so.

Why it matters

We’re entering a world where shipping fast isn't enough; you also need to understand fast. DeepWiki makes technical onboarding smoother, reduces context-switching, and adds clarity to chaos, especially in large or under-documented codebases.

Sure, it’s not a silver bullet. It won’t replace solid developer docs. But it’s a powerful fallback when the docs are missing, outdated, or nonexistent.

Final thoughts

In a way, DeepWiki brings back the original promise of AI in dev tooling—not to replace developers, but to augment them. It’s not just about code completion or chat-based assistance anymore; it’s about deep understanding. And in that space, DeepWiki has carved out something genuinely useful.

Whether you're delving deeply into a complex system or simply exploring a new library, DeepWiki is a valuable resource.

FAQs

1. What is DeepWiki, and how does it work?

DeepWiki is an AI-powered tool by Devin AI that generates real-time, conversational documentation for any code repository. It analyzes the codebase and lets developers ask natural language questions to understand functionality, architecture, and workflows.

2. Can DeepWiki document private or internal repositories?

Yes, DeepWiki can be used with private repositories as long as you grant it access. It can then generate documentation and allow conversational querying based on your internal codebase.

3. How is DeepWiki different from ChatGPT or other AI coding assistants?

While general AI assistants like ChatGPT are trained on broad programming knowledge, DeepWiki is built to ingest and understand specific repositories, offering contextual, code-aware responses tailored to your exact codebase.

4. Is DeepWiki useful for teams and enterprise-level development?

Absolutely. DeepWiki can dramatically speed up developer onboarding, reduce time spent searching through code, and improve collaboration by acting as a living, interactive documentation layer for your projects.

5. Does DeepWiki replace traditional documentation?

No, but it complements it. While human-written documentation provides structure and intent, DeepWiki helps fill gaps, explain code in real time, and answer questions dynamically—especially when traditional docs are missing or outdated.

Originally posted at:

Autodesk Developer BlogUpgrading 3ds Max .NET projects from .NET Framework to .NET 8

3ds Max 2025 and earlier versions have used the .NET Framework for building plugins, but, with the VFX world transitioning to .NET, 3ds Max 2026 brings this support with it. As such, .NET projects require a bit of housekeeping to get them compiled and working in .NET 8 for our case. This blog is a simple walkthrough of the upgrade process, using the public Explode Geometry Sample hosted here.

The Upgrade Assistant

Microsoft provides an Upgrade Assistant extension to help with porting .NET Framework projects to .NET as well as .NET Core to .NET and much more. The tool simplifies and aids in handling the upgrade intricacies, leaving just a few more steps for us to complete.

First, to get things going, check if you have the Upgrade Assistant installed. If not installed, the Visual Studio Extensions Manager should be your first stop. With Visual Studio opened, navigate to Menu > Extensions > Manage Extensions. Under the Extensions Manager, search for Upgrade Assistant and get it installed as shown below.

With the assistant downloaded, follow the instructions to get it installed. This may include having to restart the IDE to get the extension installed and loaded for use.

Please note that the Upgrade Assistant is available as both a Visual Studio extension and a command-line utility. In this blog, we will only cover using the Visual Studio extension.

Explode Geometry Project .NET Upgrade

Let's work with our [ADN Explode Geometry Sample] (GitHub link) available on GitHub and see how we can get it building and running in .NET 8.

Fetching the project

This is an easy step: clone the repo (SSH, HTTPS, ZIP, or any format you prefer). Note that our GitHub repo is already updated, so fetch the older tagged version for the 2025 code for the sample.

git clone --branch v2.7 https://github.com/ADN-DevTech/3dsMax-Explode-Geometry
cd 3dsMax-Explode-Geometry

In the Source folder, open the .csproj in Visual Studio.

Upgrading to .NET the Assistant way

As detailed in the Microsoft blog on the assistant, we can upgrade by right-clicking the project and selecting Upgrade. This opens a new project upgrade page.

Here, we select the project upgrade way and work with the in-place project upgrade, but feel free to test the other options if they suit your needs.

With the upgrade type ironed out, next, we need to select the .NET version to upgrade to. For our case, we are going for .NET 8.0 LTS; this is the expectation for 3ds Max 2026 .NET plugins. You may optionally get an action requirement to download and install .NET SDK if you don't have it yet; if so, proceed with that installation, then pick it up from here once done.

In the next step, we are required to select the files to upgrade. By default, all files in the project are checked, including the project file. Let's leave it as is and proceed with upgrading the selection. After the process completes, if no errors come up, then our project will have been transformed.

Probably, the project will try to build but fail; we will fix that shortly. To check the logs, switch the combo box as shown below to the Upgrade Assistant option.

At the end of this process, you should have a project file `.csproj` that has been updated to conform to the .NET 8 project format. Running the build fails due to missing references to the Autodesk assemblies that may have been dropped in the upgrade process. Don't worry; fixing this is easy!

To fix the missing Autodesk assemblies or any other internal or 3rd party assemblies, we can achieve that either by;

• Directly edit the csproj file by copying the ItemGroup for the assemblies from the old project file and updating where necessary. For instance, for the Autodesk.Max.dll assembly, we can have it included in the new project file as shown below, with the version updated to 2026, of course. The same will be done for the other project dependencies like CSharpUtilities.dll, ManagedServices.dll, etc.

<ItemGroup>
  <Reference Include="Autodesk.Max">
    <HintPath>$(ADSK_3DSMAX_x64_2026)\Autodesk.Max.dll</HintPath>
    <Private>False</Private>
  </Reference> .... other assemblies
</ItemGroup>

• Another way is making use of the Visual Studio Reference Manager that is accessed from the Menu > Project > Add Project Reference > Browse & find your assemblies. Once all intended libraries are selected, click OK to add them. Just as in the option above, the new assemblies will be added back into the project file. Just FYI, we can change the assembly paths for the Autodesk assemblies to make use of the path variables. This way, any user can use our plugin despite the installation path they chose. For our case, we will use the path as $(ADSK_3DSMAX_x64_2026)\<assembly name>. 

At this stage, we can build our project, and everything should now be okay. But, looking at the logs, our build outputs are going to the default Visual Studio project build directory and not the one defined under our debug/release property group. In .NET Framework project configuration, we had defined <OutputPath> inside each build type (Build/Debug); in .NET, we define it inside the first global <PropertyGroup> where we have our project defaults, as shown below:

<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>  
  ... the other config here
  <OutputPath>C:\Our\intended\path\for\the\assembly</OutputPath> 
</PropertyGroup>

For our case, we will be using the Autodesk plugin path as our output path. This way, any plugin development changes can be updated in the plugin directory for testing.

Note: There may be extra steps to getting the assembly loaded into 3ds Max. If using PackageContents.xml, update where necessary to get the assembly and its dependencies loaded. Refer to the following documentation pages for help: Menu System Migration, Packaging Samples 

Final Housekeeping 

As a close, we need to do a bit of housekeeping. Here are a few things to consider:

• Setting included assemblies as not private: When we add assembly references in our project, the build process ends up copying the assembly references and their dependencies to the `OutputPath` directory, which is not the intended behavior. This results in duplication of assemblies, which may cause 3ds Max to crash. To resolve this, update each of the included assemblies as follows:

<Reference Include="ManagedServices"> 
  <HintPath> $(ADSK_3DSMAX_x64_2026)\ManagedServices.dll </HintPath>  
  <Private> false </Private> 
</Reference> 

• Disabling AppendTargetFrameworkToOutputPath flag: Since plugins for 3ds Max are meant for Windows, we can disable the flag above to ensure the assemblies don't end up nested in a target framework directory.

<AppendTargetFrameworkToOutputPath> false </AppendTargetFrameworkToOutputPath>

• Updating/bumping up plugin versions. This applies to both ApplicationVersion and AssemblyVersion

• Cleaning up some left-behind <ItemGroup> locks, which are not required in .NET 8.

• Since our plugin is intended to run only on the Windows platform, expect to see lots of warnings on platform compatibility. We can safely ignore these warnings using the snippet below:

<NoWarn>$(NoWarn);CA1416</NoWarn>

You can find the complete upgraded sample on our ADN GitHub repo for reference.

What did I miss out on? Please let us know! Happy upgrading: smile:!

A few weeks ago, 3ds Max 2026 saw its official release, introducing new features and capabilities for both artists and developers. With this release, 3ds Max saw many upgrades in Arnold to 5.8, Substance to 3.0.8, performance improvements in different modifiers, and much more. Refer to the release page for a detailed feature change for 3ds Max 2026.

Originally Posted At:

Autodesk Developer BlogWhat’s new in 3ds Max 2026?

SDK Changes

First, let's discuss the SDK changes that came with 3ds Max 2025 last year. We didn't have full information then, as there were breaking changes that are now fully documented.

•  3ds Max 2025 came with a revamped new menu system. The update necessitates the rewriting of all plugins that generate menus or quad menus to align with 3ds Max 2025. Check out more information on the menu changes, menu migration guide, and general plugin migration guide to 2025 using the Explode Geometry Sample.

With that out of the way, what's new in 2026?

• NET 8.0 Support: In 2026, .NET 8 support for plugin development was introduced to align with Autodesk's goal of updating all our projects to more modern standards. This upgrade is a shift from the framework-based projects of previous 3ds Max versions; as such, this breaking change will require project restructuring and rebuilding to work in 2026. Refer to our porting guide from .NET Framework to .NET for plugins.

• Lots of minor API changes in ActionTable, Animatable, CustCont, ColorManagement, Menu System, etc. for performance and/or added functionality.

• SDK licensing updates: SDK header licenses have been updated for conformity to the Autodesk license agreement, which is provided at the time of installation or download.

• Updated samples and documentation to reflect API changes.

Refer to our What's New docs section for a full list of API & SDK changes in 2026.

3ds Max 2025 came with some breaking changes that marked an era of new approaches aimed at improving performance at the core. As a result, some tools tailored to pre-2025 3ds Max versions may fail to load into 2025. In this blog, we will give you a walkthrough of how to handle porting a plugin to 2025, using one of our samples as a base example.

Originally Posted:

Autodesk Developer BlogPorting Plugins from 3ds Max 2024 to 3ds Max 2025

What Changed in 2025?

2025 brings some exciting changes; here are some highlights:

• Menu Changes: 3ds Max 2025 introduces an overhaul of the menu system, deprecating the old MenuManager (menuMan) and introducing the new CuiMenuManager and its associated classes. This brings more ways of creating menus, statically or dynamically.

• shape.h: Introduced 8 helper methods for enhanced Bezier shape handling and end cap material options to improve shape rendering and control.

• spline3d.h: Added methods for checking spline segment linearity , managing angle constraints, and enhancing spline manipulation capabilities.

• splshape.h: Implemented methods to override spline closure prompts, providing customizable control over user interface prompts.

• mnmesh.h: Introduced new classes and optimizations for vertex origins and mesh management, focusing on performance improvements with complex meshes.

• Mesh.h: We have added a helper method in ScopedLockChannels to efficiently update transformed bounding boxes, thereby enhancing mesh rendering accuracy.

• MaxGuid.h: Introduced the MaxGuid class for GUID management within MaxSDK, facilitating efficient unique identifier handling.

• iparamm2.h: A virtual SetRange method has been added for defining UI control ranges, enabling flexible parameter range customization.

• imorpher.h: Established interface classes for Morpher modifiers, expanding morphing capabilities with multiple channels of geometric transformation control.

• control.h: Implemented the GetDefaultController method to select appropriate user controls based on parameter types, ensuring efficient and accurate UI element assignment.

Now that you have seen some SDK changes in 2025, let's see how you would port a 2024 sample to work with 3ds Max 2025.

Porting the Explode Geometry Sample

The Explode Geometry Sample is one of the sample plugins maintained by the ADN team, with the installer available on the Autodesk App Store and the source code hosted on the ADN GitHub repo. To begin the porting process, let's begin with fetching the code we will be working with.

Fetching the source code

Using your favourite tool, whether GitHub Desktop, SourceTree, the command line, etc., clone the Explode Geometry Sample. Note that you need to clone on the version tag indicated below, as the code has been updated already to support newer versions of 3ds Max.

// Lets fetch code from v2.6 tag which supports 3ds Max 2024
// https://github.com/ADN-DevTech/3dsMax-Explode-Geometry/releases/tag/v2.6
git clone --branch v2.6 https://github.com/ADN-DevTech/3dsMax-Explode-Geometry.git
cd 3dsMax-Explode-Geometry

Updating to 2025 Assembly Versions

First, let's start by updating the assembly reference version to 3ds Max 2025 as well as setting our assembly output directory to 2025. In the .csproj project file, update the occurrence of 2024 to 2025, the assumption here being that you already have the 3ds Max 2025 setup installed.

With the project version updated, another interesting section to update is in our AssemblyInfo.cs file. Here we have predefined assembly versions and other organizational details, which may need to be bumped up to match the 3ds Max 2025 version.

// Update the following two lines if need be
[assembly: AssemblyVersion("2.7.0.0")]
[assembly: AssemblyFileVersion("2.7.0.0")]

At this point, we have all versioning details updated and ready to work on 2025 feature changes. First, let's look at our core functionality.

Note: The system requirements for .NET are v4.8, if you have any build issues with version incompatibility, switch to v4.8.1.

MNVert Changes

As noted earlier about some small changes to the C++ API that affect .NET-generated code, MNVert is among the victims of performance optimization. With the C++ API dropping the original copy operator for the C++ default copy, making MNVert trivially copiable and allocatable. This subtle change that works the same on the C++ side results in missing the `Assign` operator on the .NET `MNVert`.

Below is the final output for the 2024 vs. 2025 `ExplodeGeometry` with the MNVert functionality unchanged. You will note that the 2025 version shows no shapes on the scene as the Assign method is missing, which assigns vertex points to the `polyNewFace` which we are using to create new faces.

 How can we remedy this? A quick fix is as shown below:

// Original code ..
polyNewFace.Mesh.V(k).Assign(vert);
// New code ...
polyNewFace.Mesh.V(k).P = vert.P;

Note that the method `Assign` still works on the `MNVert`, but this originates from the `FlagUser`, where `MNVert` derives from.

With that fixed, let's have a look at the menu system changes and how to effect those changes in our sample.

Upgrading to the new Menu System

Unfortunately, we will go over all the menu changes and how to make use of them here, but you can find a detailed guide on the following topic below:

• The Menu System: https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=GUID-FF48D0EC-6669-4EC7-AB43-E9998A14A198 & https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=menu_system

• Menu Migration Guide: https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=menu_migration_guide

 The sample packs a few useful packaging scripts and configuration files. This is where we will be modifying to set up the menu changes. But first, why do we need to make use of the menu in this sample?

The sample is distributed as part of the ADN samples through the Autodesk AppStore. As such, to invoke the sample:

• First, the assembly must be loaded to 3ds Max, which we are achieving by using the `PackageContents.xml` file. You can check the section on ` Packaging Your Project` in the Menu Migration Guide linked above.

• Secondly, we expose the action items through MacroScript. This is not necessary, as we can make use of the Action table IDs directly to invoke the .NET methods.

• Lastly, we create a menu entry under the `App Store` menu item on the main menu bar.

With all that in mind, let's navigate to the `PackageContents.xml` located in the `/Bundle2` directory and start the packaging process upgrade.

PackageContents.xml file

First, let's expand the package runtime environment to support 2025. This can be done by updating the `SeriesMax` value to 2025. Similarly, let's expand the `SeriesMax` for `macroscripts parts` segment as shown below:

<RuntimeRequirements
    OS="Win64"
    Platform="3ds Max"
    SeriesMin="2020"
    SeriesMax="2025"
/>
<Components Description="macroscripts parts">
    <RuntimeRequirements ... SeriesMax="2025" />
    ...
</Components>

With MacroScript support for 2025 added, let's add .NET assembly as shown below.

<Components Description="assemblies parts">
    <RuntimeRequirements OS="Win64" Platform="3ds Max" SeriesMin="2025" SeriesMax="2025" />
    <ComponentEntry AppName="ADNExplodeGeometry" Version="2.6.0" ModuleName="./Contents/ManagedAssemblies/2025/ADNExplodeGeometry.dll" AppDescription="..." />
</Components>

Lastly, let's add a post-startup script for 2025 that will create the menu entry for us on 3ds Max boot. Don't worry for now; we'll create the actual file and its contents next.

<Components Description="post-start-up scripts parts">
    <RuntimeRequirements OS="Win64" Platform="3ds Max" SeriesMin="2025" SeriesMax="2025" />
    <ComponentEntry AppName="ADNExplodeGeometry" Version="2.6.0" ModuleName="./Contents/Post-Start-Up_Scripts/ADNGeometryExplodeSetupMenu2025.ms" AppDescription="Setup Menu to execute tool" />
</Components>

 Creating Menu Entries for 2025

As we noted above in the `PackageContents.xml`, we need to add a new post-startup script that will handle menu creation for our package when it's loaded. We create a new file called ` ADNGeometryExplodeSetupMenu2025.ms` in the `./Bundle2/Contents/Post-Start-Up_Scripts/` directory. Unlike 3ds Max 2024 and earlier versions, 2025 uses callbacks to register new menu entries for both regular and quad menus.

Within the file, let's add code to register our callback as well as get the main menu bar handle, which we will use to add new menu or submenu entries.

function menuCallback = (
    local menuMgr = callbacks.notificationParam()
    local mainMenuBar = menuMgr.mainMenuBar
)

-- Register Callback to the #CuiRegisterMenus
callbacks.removeScripts id:#adnExplodeGeomMenu
callbacks.addScript #cuiRegisterMenus menuCallback id:#adnExplodeGeomMenu

From the callback, we can access the menu manager, which hosts the main menu bar. We'll use the main menu bar to add a sub-menu item, which will have our menu item. Let's see how this is attained:

local stringAppStoreDefaultMenu = "App Store"
-- ADN Explode Geometry MXS
local stringMacroScriptName = "ADNExplodeGeomMS"
local stringMacroScriptCategory = "ADN Samples"
local helpMenuId = "cee8f758-2199-411b-81e7-d3ff4a80d143"

-- ID of the "App Store" menu in the menu bar. Use this ID when in need of adding new submenu items to the "App Store" menu entry.
local appStoreMenuId = "CC18FEFC-E8A4-4B16-B519-664E8FA3B549"
local newSubMenu = mainMenuBar.CreateSubMenu appStoreMenuId stringAppStoreDefaultMenu beforeId:helpMenuId

local separatorId = "96FB49D4-6263-4D8E-AC95-6D304673327B"
newSubMenu.CreateSeparator separatorId
local permanentId = stringMacroScriptName + "`" + stringMacroScriptCategory

-- 647394: MacroScript Action Table ID
newSubMenu.CreateAction "9DE5BDB9-E47F-4614-BDF8-C331B9B38C70" 647394 permanentId

This script defines some local variables like the menu entry name and our menu name, as well as some system data like the `Help Menu` GUID. From the main menu bar, we create a submenu called `App Store` using mainMenuBar.CreateSubMenu⁣. In the submenu, we add a separator at the end of the existing menu items, if any (in our case it may be empty), and then we create a new action entry for our sample.

With the script completed, we have one last piece remaining: adding the built assembly to the package.

Building & Adding Assembly to the Package

Under the `PackageContents.xml` section, we added a reference to a built assembly supporting 2025. From our upgraded project, we build our project, and the generated assembly is written out to our project's `OutputPath` directive. We can copy over this assembly to the `./Bundle2/Contents/ManagedAssemblies/2025/` directory.

The Bundle2 directory can be copied over as is now to the 3ds Max plugin directory, and on the next 3ds Max boot, the plugin will be loaded. For a full guide to plugin packaging, check the docs here: https://help.autodesk.com/view/MAXDEV/2025/ENU/?guid=packaging_plugins.

Final touches

To finalise the plugin details, we can do a couple of things:

•  Update version information for the plugin, as encompassed in the `PackageContents.xml`

• Documentation: Updating the documentation details for new features, fixes, and/or new version information.

We hope you found that helpful!