Browsing"Maxscript"

Retrieving the 3DSMax File Thumbnail with DotNet

Oct 5, 2008 by     12 Comments    Posted under: 3dsMax, DotNet, Maxscript, Technical Research

Firstly, a small disclaimer – If you are unsure about any of the information contained on this page, Please do not try to implement it.

Before Max opted for DotNet integration, You could use the Windows ActiveX thumbnail component to view the 3dsMax file thumbnail. I have always found this small image to be very useful. However, when looking for a method to retrieve this via DotNet, I found it much more difficult. There is very little written about this, and I was getting nowhere until and I was fortunate enough to have Cuney Tozdas of Splutterfish point me towards two C++ files in the SDK examples. Please note that I am not a programmer, so apologies if there are any inaccuracies in my text.

How Max Stores it

The notes in the SDK pointed me towards the notion of IPropertyStorage and Structured Storage. Basically, the summary info of a Max file is set using this method. So not only is the Thumbnail stored in this part of the file, there are options to store many other pieces of information pertaining to the maxfile. You can see this by picking File>Summary Info in 3dsMax. The bad news is that novices like myself are not going to get near the level of programming needed to access this part of a file without some C++ knowledge.

Fortunately, help is at hand because it just so happened that while researching IPropertyStorage I stumbled across something on from Microsoft. MS Office files also use the same method as 3dsMax to store information in office files, using OLE Structured Storage, and Microsoft have provided a class for dealing with the lower level stuff for you called DSOFile.

DsoFile is a COM class and can be freely downloaded from this link

http://support.microsoft.com/kb/224351

And the tricky bit….

Com classes need to be registered, which means that you have to use regsrv32 in order to do this. If you use the installer from the Microsoft website it will perform this step for you. However, should you ever move the dll or are interested here are the steps for performing this manually. If anyone knows about building setup projects in Visual Studio to automate this i’d be grateful if they could let me know, as i would much prefer to give an installer for this and save everyone the trouble.

  1. Once your Window’s operating system has loaded completely, click on Start and then click on Run.
  2. Input in the Run field a command that tells your computer to register the DLL file. You will need to input specific information including the path and the file name. The following is a template for the command: regsvr32 “FileName.dll”
    It is important to note that path is the actually location or directory of where the file is located.

  1. Once the command is input into the Run field correctly, press Enter.
  2. Once the DLL has been registered, you should receive a confirmation in the form of a pop up box.

This message will list your newly registered DLL file and confirm that is was successfully registered into the registry.

Once registered, you will now be able to use this class in Visual Studio. I’m not going to go into how to use DSOfile for this, as you can figure this out from the source provided from microsoft. When you add a reference to a COM class in Visual Studio, it creates an interop class that allows the .net framework and the COM class to talk to each other. So as well as registering the DSOfile dll, you will need to load the InterOp class as an assembly in any MaxScript code to use it.

The MaxFileInfo Class

I have written a basic dotnet class with a few properties and an overloaded method to retrieve the Max Thumbnail. Note that when instantiated, the MaxFileInfo class creates a MaxFileinfo dotnetobject. This means that once created, it will automatically reference the information properties. However, the Thumbnail access is fast so it is generated on demand. In my HitchHiker utility at the top It propagates the control almost immediately.

to create a MaxFileInfo object, you provide a string path variable

MaxFileInfo “<Maxfile path and filename>”

I have provided two options – calling Thumbnail on the file will return a DotNet image, useful if you are building a dotNet rollout in max, or by specifying Thumbnail True will copy this to the clipboard and allow you to use getclipboardBitmap() to put onto a MXS button. I have included a small example of the two methods in the download.

Still to do…

This class will only currently work in 32 bit versions of Max and Windows. Someone very kindly recompiled DSOFile for the X64 platform for me and i am working around a couple of issues at the moment, so I will hope to release a working version for the X64 platform very soon. I am slightly behind on this because my Laptop runs 32bit vista and my work machine XPx64, so i don’t get an awful lot of time to test in this environment. I will be upgrading my laptop shortly in order to develop this further, as without 64bit compatibility it is about as much use as a chocolate teapot. Indeed, i wish it was more straightforward.

I will be the first to say that this implementation is far from perfect. There are a couple of other references that need to be addressed depending on the platform you are running. On XP, I sometimes had to provide the stdole.dll also, as well as visualbasic.compatibility.dll as this is used by the class to convert the picture thumbnail to a dotnet image.

If you have any questions or need help with this class, feel free to email me (pete at lonerobot dot com) or PM me via CGTalk. If you want to use this in any scripts, you are freely welcome to do so, although I’d appreciate a mention!

I have also looked into extending this class with a few GDI+ methods, embedding the file information into the image before it returns it with some layout control, as well as a crude resampling routine to resize the thumbnail to something larger.

Included in the download is a very basic utility written in Visual Studio that allows you to browse files via a treeview. It has drag and drop functionality too. Its just provided as is, in the hope it would be useful to someone.

The other thing to add to this class library would be the comprehensive ability to specify the summary properties of a maxfile via dotnet. If you think this would be of particular use to you, please let me know, and I might be able to find the time to write it for you.

download

MultiThreading in 3D Studio Max using the BackgroundWorker class

Aug 29, 2008 by     10 Comments    Posted under: 3dsMax, DotNet, Maxscript

You will all be aware that when you perform any intensive calculation process within MaxScript that it pretty much ties up that session of max. The solution to this would be to run this process in a separate thread, much like 3DS Max does with all other operations. However, the system.threading class can be tricky to configure. Luckily the DotNet chaps have provided an alternative that does all the hard work for you – The BackgroundWorker.

You create an instance of this class in MXS via the following method –

MainThread = dotnetobject "System.ComponentModel.BackGroundWorker"

This is a small test that demonstrates use of this class. You will notice that when you run the example via MXS, the 3Dsmax UI will be completely tied up. Via the Dotnet method, you can still use the max interface and do other tasks within a single copy of max. It also supports cancellation so you can abort an intensive task should you need to.

The main thread is called via the DoWork() event – specifying this in MaxScript as a dotnethandler allows you to pass a function to operate as the work thread. So you can pretty much put what you like in here and it will run in a thread separate to the UI. This is obviously better suited to work that isn’t viewport related. It is perfect if you want to perform an intensive calculation without starting a separate instance of 3DS Max.

Updating the UI thread from the Worker Thread

Something to understand in VB/C# with this class is that like using other threading methods you have to use delegates if you want to update a UI that was started in a thread different to the one perform the work. If you attempt this in VB/C# it will throw an exception. The backgroundworker class has this delegate functionality built in, providing an easy way to pass progress (and other) information back to the UI thread. I haven’t implemented it here as it didn’t seem to be necessary for the script to work, although i have included it commented out in the code. In VB/C#, The backgroundworker class allows this to happen via the ProgressChanged handler. If you look in the script this can only report back if you set the object’s workerreportsprogress property to true., without this property set will also result in an exception.

Once started with the runworkerasync() function, The mainthread performs the work function. You choose when to update back to the UI thread via the reportprogress method. This takes two arguments, a percentage integer and a userstate object. So, you can put pretty much anything in this object – i have placed an array with various properties in so i can can the userstate[integer]method to retrieve these in the updatethread function. The ProgressChangedEventArgs therefore contains a progresspercentage property to update a progressbar or similar and the userstate property for anything else. For example I have used this to pass the e.progresspercentage argument to the painthandler of a control and use GDI+ to draw a custom progressbar over a bitmap that is loading. You don’t have to provide a userstate property, the eventarg is overloaded (meaning you can choose which arguments to supply) so that you can just return the progress percentage should you wish.

Insert Update Thread pun here…

Whilst the background worker seems to perform well in a VS environment, I had notived a couple of intermittent synchronisation errors when using a this class within 3dsMax. Following a discussion on CGTalk, the dotnet SDK mentions this issue. Here is what it says –

SynchronizingBackgroundWorker Class

Replaces the standard BackgroundWorker provided by the .NET Framework to fix what seems to be a bug causing the BackgroundWorker to fire events in the wrong thread.We have encountered cases where the BackgroundWorker seems to lose track of the main thread or just arbitrarily decide to fire ProgressChanged and RunWorkerCompleted in a new thread rather than in the main thread. This causes synchronization errors.

This replacement class allows the client to specify a ISynchronizeInvoke synchronizer object through which the events will be fired. All Controls implement ISynchronizeInvoke, so any Control should be adequate to act as a synchronizer to invoke the events in the main thread.

I have updated these classes to run with this component by adding a reference to CsharpUtilities in VS. In max, you can just reference it normally like so –

Worker = DotNetObject "CSharpUtilities.SynchronizingBackgroundWorker"

You don’t need to load the assembly as MaxDoes this automatically at startup.

download script