I wish somebody could help me out on the very basics of compiling a mudbox plugin.
I’ve been struggling with it for almost a week, non-stop, and I’ve reached a limbo-guessing state…
All reference and documentations for doing this are so minimal when it comes to preparing a compilation

environment,
and make so many assumptions of knowledge by the reader, it’s really frustrating…

What I’m trying to do, is to compile a Qt-ui-based plugin for Mudbox 2011 x64,
using the provided SDK, visual-studio 2008 (pro-tial) and Qt 4.5.3,
which I downloaded in source and compiled via nmake in vs2008 command line,
especially for this task, as there is no viable explanation anywhere on the web on how to compile a qt-plugin for mudbox, I took this suggestion from a maya post I found somewhere…

There is so much I don’t know and don’t understand in the way Qt dlls should be built via vs2008, so much implicitness, that i’m pretty lost by now…
Please help, in any way you can…

I’m new to C++, Qt and VS in general, but I know the concepts, I just lack experience.
I know all about the compile/link/build process, and the moc process that has to occur before that, but

I don’t know how to configure stuff in VS.

1. What files should the builder use, the Qt ones, the SDK ones, or a certain combination?
2. If it’s a combination, how do I tell the builder what to take from where?
3. I managed to get the examples of the SDK to compile/build, but they don’t include Qt.
4. When I try to add a Qt class via the Qt-add-in, it sais that it cannot add it for projects that where not created by the Qt-VS-add-in.
5. When I start a fresh Qt-dll-project, then I have to configure myself all the build configurations to
customarily tailor specifically for making a .mb mudbox-plugin file, and I have no idea how to do that, and could not find anything on the web.
6. What is the makefile file that is in all the examples? It is calling buildgonfig file on the example’s root folder, right? So I need to do something for that to happen?
7. How come that I manage to build the examples in x64 target-platform, but when I try to build the Qt fresh project, for x64 platform, it sais it can’t do that?
8. I managed to compile the source of the TurntableSDKexample that I found somewhere on the web… It does use Qt, and I did manage to get it compiled for x64 platform, it even loaded correctly in mudbox.
It seems to not require/use a makefile somehow…
The problem is I cannot seem to be able to modify/expand this project-file with it’s configuration without breaking it. If I try to redactor the name of the classes from turntable into something else, or change the file-names, the auto-generated moc_*.* files error out somehow saying they can’t find the class/file turntable*.* stuff…
Also, this build configuration does not use the .ui files method of building an interface, so it makes it harder to change the user-interface of this plugin.
9. I need to make my plugin use xml-rpc to interact with an external data-server. I managed to find a Qt-based project that does that, and even download the source, modify for my needs, compile and build it so it interacts with the data-server. But only within it’s own project’s configuration, using the Qt-VS-Add-In kind of project (.pro file), within it’s own environment, which calls for all the Qt-4.5.3 source, not the mudbox-sdk-qt-source…
Now I want to integrate the 2 projects, and I have 3 options to do that, as I don’t want to get into all the project-configuration stuff as it’s way too complicated…
Option 1: Using the turnTable project that compiles the plugin that loads correctly into mudbox, and
extending it to include the source of the QtXmlrpc project, by either copying the files of the QtXmlrpc stuff into the mudbox/sdk/qt-folders and re-orienting the include-directives to using the mudbox/sdk/qt-source-files, or copying the QtXmlrpc sources into the turnTable’s source files into the local folder of the turnTable project. I have tried both, and in both cases - even after dealing with all the pre-processor include directives to satisfy the pre-processor completely, the Linker complains about many “unresolved external symbol"s (LNK2001 - __cdecl stuff...).
Option 2: Using the QtXmlrpc project, and copying all the turnTable project files into it, and re configure the project configuration to satisfy both projects, applying onto the QtXmlrpc project, all the mudbox-plugin-compilation-relevant configurations from the turnTable project. I have no idea where to begin going about doing that…
Option 3: Using a dll-compiled version of the QtXmlrpc project, within the turnTable project. I don’t know how to do that either…
10. I want to change the plugin-window-type of the turnTable for a QDialog to the mudbox-sdk’s WindowPlugin interface, so it would appear in mudbox as a window that could be opened as docked-within the layers/windows panel… That means sub-classing an “interface” and registering a custom window class or whatever as I understand from the sdk’s documentation… I have no idea how to go about doing that....

Any help is appreciated…

Ok....

I see that my suspicions where right…
I’m probably one of the few people who try to write a UI-based plugin for mudbox…

Soooo, I managed to solve some issues, but not all, and I’d like to share my conclusions so others can benefit, and maybe someone could help me out understanding the remaining issues…

Here goes:
As it turns out, them problem of integrating the QtXMLRPC project, was due to the fact that it was compiles for a 32bit platform, as well as the entire Qt source I compiled, while the Mudbox 2011 64bit version of the SDK, is using Qt compiled code/libraries that where created and compiled as a 64bit target…
I had to re-compile the entire Qt source again, using the 64bit version of the visual studio command prompt, and then do the same for the QtXMLRPC project.

I then re-oriented the mudbox-plugin project (turnTable) into sourcing the complete Qt source and not the one that comes with the SDK…
That was according to a suggestion I got from Wayne, as he said there are some nasty bugs in the SDK version.

I did that as follows:

I re-downloaded the source-code of the 4.5.3 Qt, and extracted it to:
c:\qt\4.5.3-x64

I then changed the system-environment variables:
PATH: &#xQT;DIR%\bin;
QTDIR: changed from “c:\qt\4.5.3-vc” to c:\qt\4.5.3-x64

Then, I ran the shortcut in the start menu programs:
“Microsoft Visual Studio 2008 >
Visual Studio Tools >
Visual Studio 2008 x64 Win64 Command Prompt”

That brings up a command prompt that would compile via visual studio 2008 while targeting for a 64bit platform.

From “c:\qt\4.5.3-x64” I ran:
“configure -platform win32-msvc2005”

A couple of minutes later, when the configuring process was complete, I ran:
“nmake”

That was yesterday…
Today, when the compilation of Qt has finished, I did similar process to compile the QtXMLRPC project.

Then, I just copied the “qtxmlrpc.lib” file that was generated, as well as the mudbox-specific libraries from the “Mudbox2011\SDK\lib” folder ("MudboxFramework.lib" and “cg.lib") into “c:\qt\4.5.3-x64\lib”.
I also copied the entire “Mudbox2011\SDK\include\Mudbox” folder, as is, into “c:\qt\4.5.3-x64\include”

Then, in Visual Studio 2008, I opened the solution file of the turnTable project, and in the main menu I went to the Qt Add-In stuff:
“Qt > Qt Options”
And in the dialog, I added the new x64 compiled version of Qt:
In the “Qt Version” tab, I pressed the “Add” button, and in “Version name:” I wrote “4.5.3-x64”, then I pressed the “...” button next to “path” and sourced the “c:\qt\4.5.3-x64” folder, then pressed “ok”. still in the “Qt Versions” tab of the “Qt Options” dialog, down in the “Default Qt\Win Version:” drop-down list, I choose the new “4.5.3-x64” version.

Then, I changed the project properties by going in the main menu to “Project > turnTable Properties”, and in the dialog, changed the following:
In: Configuration Properties > C/C++ > General : Additional Include Directories:
I replaced “..\..\include” with “$(QTDIR)\include”
In: Configuration Properties >Linker > General : Additional Library Directories:
I replaced “..\..\lib” with “$(QTDIR)\lib”
In: Configuration Properties >Linker > Input: Additional Dependencies:
I added “qtxmlrpc.lib”
Then i pressed “ok”

Then.....
Everything is Ok, and the project is building successfully, while instantiating an object from the “xmlrpc::Client” class that comes from the “qtxmlrpc.lib” file!

Hurray!!!
(… champagne, confetti, etc....)

BUT:
If I tried to move the project folder somewhere else, it stops compiling, saying that it cant find “../../../moc.exe”....
It’s like whatever I do, the “moc_*.*” files that get’s auto-generated, still look for stuff in the relative way in which it only works if the project is in “...Mudbox\SDK\Examples\"…
I went through the entire project properties screen to try to find where It’s defined, and I found squat…
I really don’t understand how/where in visual studio this info about the moc build-process is being defined…
It’s the reason that in this project I can’t use the Qt-Designer…
If anything happens to the currently existing “moc_*.*” files, that get’s re-generated anyways, either by moving the entire project folder somewhere else, or by modifying any moc-related code (signals/slots/Q_OBJECT stuff, or trying to use the Qt-Designer, or changing the file-names from which they are supposedly being generated - the source-files of the turnTable project .cpp/.h files), then all hell brakes loos and the project becomes uncompillable…
Please, someone help me with this, it’s ridiculousness the state I’m in, locked into using a project called “turnTable” with files called “turnTable.cpp/.h” and “turnTableDialogue.cpp/.h”, that all has to still be left in the “...\Mudbox2011\SDK\examples” folder (even though it doesn’t source anything relative to that location anymore, AFAIKT...), and not being able to use the Qt-Designer, when if I start a new Qt project, everything works fine…
It’s like I just need the specific mudbox-plugin-related definitions of compilation, that are in the turnTable project, and re-use them in a new Qt project, and I’ll be set…
Also, I really want to understand what’s going on with this whole moccing process…

Any ideas?

OooooooK, I again see no replies, but increasing views of this topic…
That suggests that there are people trying to do this like me, but are as unsuccessful as me…
This means that there really is an issue in the way the documentation of how to go about doing that is highly incomplete…
Is autodesk aware of this reality?

Anyways, here’s an update:
I successfully managed to compile a Qt-Project into a working mudbox-plugin (!)
Woohoo!
I can now graphically-construct UIs for a mudbox plugin that actually loads and works in mudbox!
What I did, is simply meticulously copying-over, page-by-page and line-by-line, all of the project-properties of the turnTable project, while maintaining every seemingly relevant properties regarding the Qt-compilation process…
I did that for both the “Debug” as well as the “Release” configurations that target the “x64” platform…
I still have no idea what the great majority of these properties even mean, that was a blind copying, but it worked…

Now:
The still-standing problem I have, is my inability to construct a working “WindowPlugin”.
That is to say, I want my UI to be embedded/docked into the native UI of mudbox.
This should be accomplished by making the plugin as a window, which is invokable from either the window-menu, of the tab-contextual-popup-menu of either the main-pane, or the properties-pane (like “Layers”, “Community-help”, etc...).
Now, according to the SDK’s documentation, the way to do that is by implementing an “interface” (abstract-class) called “Mudbox::WindowPlugin”, in the same way the “Community-help” window is built, as it is a sub-class-instance of the “Browser-Plugin” which is an implementation of this “Mudbox::WindowPlugin” interface.
Now, according to the SDK’s documentation, the way to do that is NOT by using the general “MB_PLUGIN” macro decleration, which thereupon requires the use of a call to the “Kernel()->AddCallbackMenuItem” function in order to register it to mudbox’s plugin-repositary and make it available in the plugins menu, but rather the very act of implementing the “Mudbox::WindowPlugin”, would automatically make it available in the “window” menu, as well as the new-tab pop-up menus of the panes.
However, it is seemingly too vague in the documentation on how to go about doing that, and in what way should this new WindowPlugin class-implementation be declared/associated into mudbox…
I found in the SDK’s documentation the way in which you supposedly can sub-class/instanciate the WindowPlugin-derived WebBrowserPlugin, by using the “Kernel()->RegisterWindowPlugin” function.
Needless to say I was unsuccessful at doing neither…
Where do I specify the name and title of my WindowPlugin?
Do I do it in the class-deceleration?
In the Start() function implementation?
Do I make a constructor/destructor which for the class, with the constructor having the insertion of name/title as parameters, as it is in the WebBrowserPlugin implementation?
How do I associate my WindowPlugin with a name and a title, and how do I register it to the mudbox’s windows pool?
Do I really need to use the “Kernel()->RegisterWindowPlugin” function?
It expects a WindowPlugin, which I assume by that meaning a class-implementation, but I implement it using “class <className> : public Mudbox::WindowPlugin”, which means it’s a sub-class of it, and I get an error when I try to pass it into the RegisterWindowPlugin function, saying that a “type-casting exists but is inaccessible"…
Do I need to pass a class-pointer, a class, an instance of the class or an instance-pointer?
Where do I need to place that call?
This is all very ambiguous and confusing…

Finally, got it figured out (!)
:buttrock:
No thanks to any of you guys!
:hmm:

I’m talking to myself here....
Is that healthy?
:argh:

Anyways, as it turns out, you DO still have to use the MB_PLUGIN macro…
Just give it a function that contains the registration call:
“Kernel()->RegisterWindowPlugin()”.
Then, all you have to do, is re-implement every virtual-function, most of the time doing nothing in there…
I also included in the implemented-class a constructor which takes a name and title (as QString) and puts them in it’s protected variables, and an empty destructor.
Word of caution:
In the IsEnabled() implementation, I tried to query my widget-object for IT’s IsEnabled() function, but it caused Mudbox to crash on that line, saying something about illegal-access or something…
So I just returned “true” there..
Also, in the Stop() implementation, I tried to do a Close() or a “delete” on the widget-object, and in both-cases Mudbox crashed with an error upon exiting…
So I left it empty also…

Here is my code:

PipelineToolBox.h:

PipelineToolBox.cpp:

All the UI stuff is being done in the “PipelineToolBoxDialog” files, which include the whole QT moc_ stuff the and .ui file, which enables the usage of Qt-Designer and Qt-Resources.
Here is how the test-UI looks in Qt-Designer:

Here is how it looks in Mudbox in the properties pane:

And, yes - It does add it automatically both to all the right-click context-popup-menus, as well as to the Windows menu, so you can also place it in the main mudbox pane:

So, I hope this helps anyone else, it sure as hell would have helped me if I had read such kind of a post a week ago…
nJoy!

Ah, and F&@# AUTODESK!
Mudbox has one of the lousiest SDK-documentation I’ve seen yet!
Just had to put that one outta the way…

Well done man, its nice to know SOMEONE is playing with the SDK. I wish I knew anything about programming.

Well done, I have no even looked at the SDK for Mud so thanks for talking to your self inthis thread. Im sure that it will inspire others to dig in.

Paul Neale
PEN Productions Inc.
penproductions.ca / paulneale.com
Master Classes for Max, Mudbox and Composite
DotNet Tutorials

MX Driver Car and Trailer Rig On Sale!

What do you have planned up your sleeve ? :)

I’m still learning programming syntax, not even close to touching a SDK, yet.