[Closed] Deploying a renderer plugin

The dll for the renderer has to go in the root 3dsmax folder,
then you have to edit the ini file for the user and add the path somehow.

The info here says:
https://knowledge.autodesk.com/search-result/caas/CloudHelp/cloudhelp/2015/ENU/Max-SDK/files/GUID-3C9643C8-85BE-4449-9D03-4592A95EC606-htm.html

The system plug-in paths are loaded from two locations:

The User Profile data directory.
The 3ds Max install root.

Plug-ins should add a plug-in path to the plugin.ini file that now exists in the 3ds Max install root. This way, the plug-in is available to all users on the system. An installer should, by definition, have permission to write to the 3ds Max install root. The 3ds Max installer is now responsible for creating a blank template plugin.ini file in the system root.

The User Profile plugin.ini file is used by the user to augment the 3ds Max plug-in paths on a per-user basis. These user paths are exposed to the user in the UI when opening the Configure System Paths dialog and clicking on the 3rd Party Plugins tab. This UI feature shows only those paths mentioned in the user’s own plugin.ini file, if it exists, preventing access to system-wide plug-ins in this manner.

There is no definitive method for programmatically locating an individual plugin.ini file in the User Profile directories.

What I do with LuxMax renderer is to just place the plugins in the plugins dir,
and then the renderer dll in root of 3dsmax, then it loads fine.
I do not have a subfolder for it.

I’m not sure how you can solve it, but maybe the installer can append a string to that file for you?
which then would be the install path (plugins/appleseed)…

Do you use visual studio’s installer project for this? or some other 3rdparty tool?

Hi Stig,

I actually just found a solution that allows me to place all the DLLs in <3dsMaxRoot>\plugins\appleseed:

I marked the appleseed DLL as Delay Loaded in the Iinker options of Visual Studio, and I manually load the appleseed DLL from the right location in the LibInitialize() function of the plugin:

__declspec(dllexport)
int LibInitialize()
{
    wchar_t path[MAX_PATH];
    const DWORD path_length = sizeof(path) / sizeof(wchar_t);

    if (!GetModuleFileName(g_module, path, path_length))
        return FALSE;

    PathCchRemoveFileSpec(path, path_length);
    PathCchAppend(path, path_length, _T("appleseed.dll"));

    if (!LoadLibraryEx(path, nullptr, 0))
        return FALSE;

    start_memory_tracking();

    return TRUE;
}

Franz

Thank you for sharing that solution, that seems very elegant.
I’ll try and do the same on my end too, makes the install more clean.

No problem.

I just edited the code because there was a problem with the path length passed to the Win32 functions. The code is now up-to-date.

Franz

It turned out that my solution isn’t completely working, because in general delay-loading a DLL that exports C++ classes with virtual methods is not supported. Indeed, while it works fine in Debug mode, linking fails in Release mode due to some obscure optimizations.

I posted a question on Stack Overflow, hoping that another solution would exist, but it seems unlikely:
http://stackoverflow.com/questions/36814862/search-path-for-a-dll-referenced-by-a-plug-in-dll

Franz

I found a neat solution to the problem, I outlined it on Stack Overflow:
http://stackoverflow.com/questions/36814862/search-path-for-a-dll-referenced-by-a-plug-in-dll