Turn View Port Maps On/Off by David Mackenzie

Turn View Port Maps On

A simple script that wrote quite some time ago. It seems to have a great deal of staying power as artists continure to use it on a daily basis. It is very simple and only has a few options. At the moment it support standard materials and V-Ray materials including nested Multi Sub-Materials. If there are any other types of materials that you would like me to implement just let me know, even though I may not use them I am more than happy to add them for the sake of completeness.

Turn View Port Maps On/Off Screen Capture
Turn View Port Maps On/Off Screen Capture

I hope it helps you out. If you have any ideas for features to add just leave me a comment.

You can download it here.

To install just copy "" to your 3dsmaxroot/Scripts directory and then run the included macro ("". Once the macro has been run you can find the script under the category "Daves Tools".


29/07/2010  I have updated the version for download. Changes include:

  • I have fixed the problem that lead to bump maps not being turned off and on.
  • I have Added support for MR Arch Design material s.



Maxscript, speed up your workflow by David Mackenzie


Every day I get asked if a can whip up a script for this or a script that etc. More often than not I just walk over to the artist machine and do a very simple type in, maybe a few lines at most and that will solve their problem. Now not that I mind walking to someones desk to help them I thought I might take a second to discuss some ideas about manipulating large numbers of objects quickly, effectively and working on specific object types.  I really believe that scripting can empower artists, many artists shy away from scripting especially when there sitting next to a TD but a simple understanding of some simple scripting ideas can speed up an artists ability to work. I do not intend this to be a introduction to scripting. I just want to show you how you can manipulate objects quickly using simple loops, basic conditional statements and the max script listener.

For Loops

Loops are how we iterate over objects, numbers, arrays etc. I found the best explanation of it in the Maxscript help file, "The for loop iterates through a range of numbers, time values, or a sequenced collection of values, such as an array or object set."

In this example we will be iterating over materials, a specific type of material. There are a number of way one can accomplish this you could simple iterate through sceneMaterials and check to see if each material is the correct class that you want, this however would be slow and unnecessary. Instead we are going to use the getClassInstances function that will return an array of objects of a given type. For exmaple:

getClassInstances Sphere -- This would return an array of every instance of a sphere in the scene. getClassInstances VrayMtl -- This will return an array of every Vray Material in the scene.

It is very simple to use the array returned by getClassInstances() in a loop. for i in (getClassInstances VrayMtl) do(print i) --This will print every Vray Material in the scene

So now that we can iterate a given type of object or "class" we really want to be able to do something with them. An important concept to understand is that when we loop through the returned array each item in the array as we move through it is stored in the variable "i". Consider the following code:

for i in (getClassInstances Sphere) do(i.radius = 100)

That statement will set the radius of every sphere to equal 100. It does this by first collecting them using the getClassInstances() function and "moving" the variable "i" through the array where "i" is used to access the  radius property and set to 100. We could also do something a bit more interesting like set the radius of every sphere to be random. We will use the random function in this example to give us a random integer. for i in (getClassInstances Sphere) do(i.radius = (random 25 100)) Now each sphere will have a random radius between the 25 and 100.

Unless you really wanted to create Spheres with a random radius lets move on and learn how to do something useful.

The Maxscript Listener

Using the listener you are able to record your "actions" so to speak. This is a very easy way to query a property that you may wish to manipulate in a script. For example you might want to turn off trace reflections on all V-Ray Materials. To do this open the max script listener (Maxscript -> Maxscript Listener or hit F11). Once the listener is open go to the Macro Reorder menu and enable the macro recorder.

Open Maxscript Listener Screen Capture

Maxscript Listener Enabled Screen Shot

If you now go and open the Material editor select a V-Ray Material and Turn off Trace reflections. Imediately you should notice that Listener updating, in this example it should read something like:

meditMaterials[1].option_traceReflection = off

In the above piece of code where are interested in everything after the ".", meditMaterials provides access to the materials in the editor (another article for that).

Now using what we learnt in the section covering loops we can now go ahead an change every V-Ray material in the scene:for i in (getClassInstances VrayMtl) do(i.option_traceReflection = false)

How easy was that? As you can see simple type in expressions or loops can save you a great deal of time. Just to recap we very quickly went over using loops with the getClassInstances() function and using the listener to ascertain what property's we need to change. If you have any question then please just post in the comments I will do my get back to ASAP. Also remember the maxscript help file is your friend it is a fantastic help, if you are having trouble of some of the more basic concepts I suggest you start there.

I hope that shed some light on some very simple scripts that you might be able to use. If you have an idea for a tutorial use this form, I am more than happy to tackle any challenges you have in 3d or 2d.



3D Library Management by David Mackenzie


I was discussing my Library Management software for handling 3d assets in a blog entry I wrote  on the Ivolve Studios blog. I thought that I might take a moment to expand on the technical aspects of it a bit further. Over the years asset management or library management has become an ever more challenging problem. Commercial solutions are often large all encompassing pieces of software that tends to shoe horn the way you work to fit there pipeline. As I begun to research different solutions It became obvious to me that a small light weight artist focused solution would work best, it would empower artists and have a small foot print on the pipeline.

3d Studios that  operate in the Architectural Visualization  and general 3d animation spaces often create library's of assets that can be used in new projects. In my experience these library's usually consist of a large number of folders to create a structure that should be easy to find things, this however is rarely the case. That workflow usually results in a couple seniors who have been there the longest that know where everything is and all the other artists have no idea. Once we had decided to go down the custom road there where a few things we had consider:

  • What did we actually want our software to do?
  • How did we want it to work?
  • How were we going to implement it?
  • Development Cost?

These 4 points where are guiding light during the development stages. We identified key features that we needed and features that we wanted to add at a later date.  These features included:

  • Keyword Search. Search is the modern way to navigate larges amounts of data, our library was no different. Search also has the added bonus of requiring little to  no time to learn for new artists.
  • Small lite weight interface. Above all we wanted an uncluttered interface. 90% if the time artist would either be saving an asset to the library or adding one to there scene, early on I decided that administration tools could tucked away.
  • User accounts. Having user accounts with different privilege was a must as we wanted to limit artists ability to remove assets in certain circumstances, for instance blocking a junior from deleting assets.
  • Speed. Our software had to be fast it needed to load as quickly as possible.

Knowing the features we needed to include we moved on to the implementation. Things that we knew we wanted in the implementation were:

  • A human readable file structure.
  • Modular design. We wanted to promote code reuse and ensure that developing either new tools around the solution or expanding it in the future would be a simple process.
  • Database for the back end. This decision was made early on. We experimented with XML, flat file databases and in the end we settled on MySQL. It was readily available there are plenty of DBA's that know the software, plus we like to use Open Source software when possible.

At this stage we got coding since we where developing the first version exclusively for 3d Studio Max we chose Max Script and .Net as our weapons of choice. We started by developing a bunch of library code for simplifying interaction with the database and files. These were all unified under a common namespace SQLTools(). Moving forward we developed more library's which handled users (UserTools()) and assets (AssetTools()). SQLTools() was written primarily in .Net and then wrapped in max script. Each of these librarys is generic by design and have proved to be very versatile and have now grown in to mature library's.

All the library's were brought together under a singular namespace assetMan(). This was very important as it enabled us to replace any of the underlying library's very quickly and easily should we need to change the back end etc.  After about 6 weeks we rolled the first version (Below) and released it to the artists. This first version worked well and was used for some time, we used this time to identify exactly what we needed to change.

Version 1 Screen Capture

We Identified a number of areas for improvement such as the need for rendered previews of assets. We also decided the next version should not be limited just to 3d objects.  As we kept working we finally rolled out a new version with a new interface that was greatly simplified. From here we moved on to implementing the rest of our planed features including keyword search, rendered previews, support for textures (images files) and shaders. This latest version proved very successful with a significant gain in production speed.

Version 2 screen capture

We have now gone on to add support for Fusion composites, PSD's and Nuke files which can be accessed and managed through a standalone application written in Python. We are hoping as time permits to write native interfaces for each of these applications. That back end has undergone some changes as well the most significant is the abstraction of data to allow for arbitrary file types and applications.

Thus far we have been very happy with the progress of the software, I am hoping to make more information available as I can. I have since been working on a new solution that has includes the features mentioned above along with a host of improvement including a very nice web interface. As I get time I am sure it will become the subject of an article.

Thanks for reading, if you made it this far I am very impressed!

Cheers, Dave