Custom C++ plugin for Motionbuilder 2025

[nayoung.kimRAWN2]

Hi, I'm supporting an in-house C++ plugin for Motionbuilder, which worked fine in Mobu 2023. Now I'm trying to recompile it for Motionbuilder 2025. I used a correct SDK, compilation itself turned out fine, but it crashes when I launch plugin related operations. It turns out that I see in our FBModel derivated class:

* DLL declaration is done.

FBLibraryDeclare( myplugin )
{
    FBLibraryRegisterStorable( MyModel);
    FBLibraryRegisterElement( MyModel );
}
FBLibraryDeclareEnd;

* LibClose and LibRelease are being called when I close Mobu 2025 instance.

But I never see LibInit, LibOpen, nor LibReady are being called, which skips all the variables' initialisation, causes a crash. (While the same code calls LibInit, LibOpen, and LibReady on Mobu 2023 instance startup) I've skimmed through the ORSDK samples but I don't think there's a breaking change. Could somebody please explain what could be missing here?

I tried with the sample entry point literally looks like this and it behaves same:

#include <fbsdk/fbsdk.h>

#include "MyModel.h"

//--- Library declaration.

FBLibraryDeclare( mymodel )

{

    MessageBoxA( NULL, "FBLibraryDeclare", "Debug", MB_OK );

    FBLibraryRegisterStorable( MyModel);

    FBLibraryRegisterElement( MyModel );

    MessageBoxA( NULL, "FBLibraryDeclare End", "Debug", MB_OK );

}

FBLibraryDeclareEnd;

/************************************************

 * Library functions.

 ************************************************/

bool FBLibrary::LibInit()

{

    MessageBoxA( NULL, "LibInit", "Debug", MB_OK );

    return true;

}

bool FBLibrary::LibOpen()

{

    MessageBoxA( NULL, "LibOpen", "Debug", MB_OK );

    return true;

}

bool FBLibrary::LibReady()

{

    MessageBoxA( NULL, "LibReady", "Debug", MB_OK );

    return true;

}

bool FBLibrary::LibClose()

{

    MessageBoxA( NULL, "LibClose", "Debug", MB_OK );

    return true;

}

bool FBLibrary::LibRelease()

{

    MessageBoxA( NULL, "LibClose", "Debug", MB_OK );

    return true;

}

I do have these in MyModel.cpp
FBClassImplementation( MyModel );
FBStorableCustomModelImplementation( MyModel, MYMODEL__DESCSTR );
FBElementClassImplementation( MyModel, FB_DEFAULT_SDK_ICON );

And I do have this in MyModel.h, inside of MyModel class
FBStorableClassDeclare( MyModel, FBModel );

[Ndgt · Accepted solution]

Hi, @nayoung.kimRAWN2

It’s a bit strange that LibClose and LibRelease are being called even though LibInit doesn’t seem to be. Since FBLibraryDeclare is executed, the plugin should have been recognized, so the initialization sequence not being triggered as expected suggests something might be missing or misconfigured.

As a side note, while using MessageBox for debugging isn’t necessarily incorrect, it does require user interaction to proceed, which can make it less suitable during plugin loading or initialization. It's generally safer to use FBTrace() for this purpose. You can launch MotionBuilder with the -console option (e.g., path\to\MotionBuilder.exe -console) to see the trace output in real time.

If LibInit is still not being called, a few things you might want to check:
Make sure the library name used in FBLibraryDeclare() (e.g., "myplugin") isn’t already used by another plugin. If there’s a conflict, MotionBuilder might load the DLL but skip initialization or behave unexpectedly.

Also, try building and running the exact plugin sample you referenced when writing your code. If that version doesn’t work either, there’s likely a problem with your build environment or project settings, rather than with your implementation.

If MotionBuilder launches successfully, you can also attach Visual Studio 2022 to the running process via Task Manager (right-click MotionBuilder.exe, select “Debug”, then choose Visual Studio). If your plugin is built in Debug mode and the .pdb file is in the plugin directory, the debugger should be able to catch any crash and show you where it's happening.

Since LibClose is being called, the plugin is at least partially loaded. You mentioned that LibInit, LibOpen, and LibReady are not called, which you believe causes uninitialized variables and leads to a crash. However, based on the code you shared, those functions only output debug messages, so it’s unclear if any essential initialization actually happens there. Therefore, it’s hard to say for sure that missing initialization is the root cause.

That said, and considering the crash occurs during “plugin-related operations” as you described, the root cause is more likely to be within your plugin’s logic rather than missing initialization. In that case, attaching a debugger as mentioned earlier would help pinpoint the exact source of the issue.

Hope this helps.

Best regards,
Ndgt

[nayoung.kimRAWN2]

Hello @Ndgt ,

Thanks a lot for your reply. I'm sorry for the very late follow-up, I was carried away with the other tasks.

Luckily, we were able to sort out the issue. But to make our plug-in not crashed, we had to append "C:/Program Files/Autodesk/MotionBuilder 2025/bin/x64/python" to our PATH variable before we launch mobu, which was not mandatory for the same plug-in with Mobu 2023. Otherwise, LibInit/LibOpen/LibReady were not called. Do you reckon anything around this?

Thank you in advance for your answer. Have a great day!

[Ndgt]

I'm glad to hear the issue was resolved.

Do you happen to know the root cause? If appending the Python directory to the PATH variable truly resolves the crash, I'm curious what operation was triggering the issue—and how your plugin is designed to work in the first place.

I couldn’t find any relevant information regarding this behavior in the MotionBuilder Release Notes, and I haven't encountered a similar case before. The bin/x64/python directory is indeed the default import path for both Python modules and C++ plugins (DLLs). If explicitly appending it to the PATH variable was required for your plugin to function correctly, it suggests this might not be the default behavior of Mobu, so I’d recommend reinstalling MotionBuilder 2025 to ensure all environment paths are properly configured.

[nayoung.kimRAWN2]

Hello @Ndgt ,

I'm sorry that I reply to this after a very long time! There were summer holidays, other production issues... I hope you had a great summer.

I didn't particularily dig deep down on this issue - we do have .dll and .pyd in our custom plugin package. And .pyd is dependent on pyfbsdk.dll. I'm thinking, even though this .pyd doesn't do anything with C++ Lib initialization, but somehow it blocked the entire package to be properly initialized? Still it's a mystery why it only happens with Mobu 2025.

I do notice there is a change on Mobu 2025, now that it requires pyfbstandalone to be initialized before interacting with pyfbsdk module (https://help.autodesk.com/view/MOBPRO/2025/ENU/?guid=Whats-New-MotionBuilder-2025), so maybe that's why the behavior changed?

So far, I think we'll settle on it as it works... We'll figure out more if it becomes another problem. Thank you so much for your comments, it helped us a lot! I'll probably make a separate thread on the other issue we're having. 😅